Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On Mon, Jul 23, 2007 at 10:06:03PM -0500, Bruce Dubbs wrote: Randy McMurchy wrote: The other, iproute2-2.6.22-070710, is something we need to discuss. The problem is with the packaging. The package expands to the current directory. The issue is what to do. Here is what I see as the options: 1. Ignore the update for now. 2. Use our own repackaged version. 3. Add a note or other comments to to the iptables page Both Dan and I have written to the iptables maintainer and have not heard any response. Opinions? Anything that expands to the current directory is more aggravation than it's worth, so IMO 3 is right out. I'm not totally against the idea of repackaging it, but I am reluctant - particularly when we're close to a release. The changelog from the announcement on lwn has: David Lamparter (1): iproute2: Format IPv6 tunnels endpoints nicely. Mike Frysinger (1): ip/routef lifesaver Patrick McHardy (1): Fwd: Re: more iproute2 issues (not critical) Pavel Roskin (1): ip: add support for displaying link types 802 and 803 Stephen Hemminger (11): Revert Increase internal clock resolution to nsec Add xt_tcpudp.h incorrect initialization headers update to 2.6.22 fix last change fix build warnings netem: static Add TC_LIB_DIR environment variable. ss: fix issues with signed inodes Thomas Graf (2): iproute2: support for goto/nop action and detached flag iproute2: Support IFF_LOWER_UP and IFF_DORMANT Yasuyuki KOZAKAI (1): Fix symbolic link to tc-bfifo.8 jamal (2): SAD info SPD info Most of these mean nothing to me, the only one that sounds important is the ip/routef change. I guess this is from gentoo http://bugs.gentoo.org/show_bug.cgi?id=139853 - looks worthwhile, but not critical (the dates suggest it went upstream a year ago) so I vote for ignoring the update. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Ken Moffat wrote: ip/routef lifesaver This sounds fairly important, but I have no idea if it actually is... incorrect initialization Depending on whether this would get hit by any of our users, it may be important. Probably not critical though. headers update to 2.6.22 Might be nice, but in reality I think this is only helpful if you're trying to use bleeding-edge features, so probably not needed. Fix symbolic link to tc-bfifo.8 I believe there was some discussion on this symlink earlier. Probably not worth repackaging a whole new release just for this, though, since we have a workaround already (the fix dangling symlinks sed in chapter06/iproute2.xml). So I'd vote to keep the version we have now, too (for 6.3, of course). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGpd9iS5vET1Wea5wRA3BsAKDA0FaAChCbjgf0BNUxOen2USghGACgjLG3 VSnqCMQwqD9e/Od1LskNXk0= =uvJG -END PGP SIGNATURE- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Jeremy Huntwork wrote: Here's the results from what is currently in the branch: http://linuxfromscratch.org/~jhuntwork/test.log http://linuxfromscratch.org/~jhuntwork/search_dirs.log One last thing dude. Could you please advise exactly what host system you're using and also show the output of: ls -ld /l* BTW, I've reproduced the problem here and think I know what's going on. Just need to gather more info and perform some further tests. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD Users
On 7/23/07, Alexander E. Patrakov [EMAIL PROTECTED] wrote: Craig Jackson wrote: I can hack the init scripts a bit to get it to work, but its command line parameters are not very intuitive. This was my least favorite upgrade from 5.x. I do understand the need for the update. (IPv6 support). LFS doesn't support IPv6, so the move to iproute2 is unjustified from this viewpoint. I will take back this opinion as soon as LFS bootscripts start supporting IPv6. I thought the reason for using iproute2 was because net-tools is unmaintained. But I think we could add support for IPv6 in the net scripts. Couldn't be too much work. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: most recent iproute2
On 7/23/07, Bruce Dubbs [EMAIL PROTECTED] wrote: Randy McMurchy wrote: Bruce Dubbs wrote these words on 07/23/07 22:06 CST: The other, iproute2-2.6.22-070710, is something we need to discuss. The problem is with the packaging. The package expands to the current directory. The issue is what to do. Here is what I see as the options: 1. Ignore the update for now. 2. Use our own repackaged version. 3. Add a note or other comments to to the iptables page Both Dan and I have written to the iptables maintainer and have not heard any response. Not sure what the iptables maintainer has to do with an issue with the iproute package, but I'm guessing this a typographic error. However, if the current update in the iproute package sucks and doesn't perform to our expectations, then blow it off. What is in the book works. That means I vote for #1. s/iptables/iproute2/ :( The changelog's most recent entry is 2006-03-21, so it has not been kept up to date. You may want to wait for Matthew's comments since I think he has been testing the new version. I'd personally rather use the new version since it syncs to the 2.6.22 interfaces and that's the kernel we'll be running. I'll try poking the maintainer again. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD Users
Dan Nicholson wrote: I thought the reason for using iproute2 was because net-tools is unmaintained. Yes, when the discussion for the change took place, this was the main reason. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Inconsistent use of in BOOK
@@ -41,10 +41,10 @@
with Man-DB, in order for them to be accessible in both traditional and
UTF-8 locales:/para
-screenuserinputmv man/de{_DE.88591,} amp;amp;
-mv man/es{_ES.88591,} amp;amp;
-mv man/it{_IT.88591,} amp;amp;
-mv man/ja{_JP.eucJP,} amp;amp;
+screenuserinputmv man/de{_DE.88591,}
+mv man/es{_ES.88591,}
+mv man/it{_IT.88591,}
+mv man/ja{_JP.eucJP,}
sed -i 's,\*_\*,??,' man/Makefile.in/userinput/screen
paraThe second change is a commandsed/command substitution to delete
@@ -298,7 +298,7 @@ install -m755 convert-mans /usr/bin/userinput/screen
(ulink url=http://ccb.club.fr/man/man-fr-1.58.0.tar.bz2/) can be
installed with the following command:/para
-screen role=nodumpuserinputmkdir -p /usr/share/man/fr amp;amp;
+screen role=nodumpuserinputmkdir -p /usr/share/man/fr
cp -rv man? /usr/share/man/fr/userinput/screen
paraIf upstream distributes manual pages in UTF-8 (i.e., quotefor
diff --git a/BOOK/chapter06/module-init-tools.xml b/BOOK/chapter06/module-init-tools.xml
index 3dcc8bf..77228fc 100644
--- a/BOOK/chapter06/module-init-tools.xml
+++ b/BOOK/chapter06/module-init-tools.xml
@@ -44,8 +44,8 @@
commandmake distclean/command command is required to clean up the source
tree, as the source gets recompiled as part of the testing process):/para
-screenuserinput./configure amp;amp;
-make check amp;amp;
+screenuserinput./configure
+make check
make distclean/userinput/screen
paraPrepare Module-Init-Tools for compilation:/para
diff --git a/BOOK/chapter06/ncurses.xml b/BOOK/chapter06/ncurses.xml
index 00d5de4..a2092bd 100644
--- a/BOOK/chapter06/ncurses.xml
+++ b/BOOK/chapter06/ncurses.xml
@@ -121,16 +121,16 @@
rm -vf /usr/lib/lib${lib}.so ; \
echo INPUT(-l${lib}w) gt;/usr/lib/lib${lib}.so ; \
ln -sfv lib${lib}w.a /usr/lib/lib${lib}.a ; \
-done amp;amp;
+done
ln -sfv libncurses++w.a /usr/lib/libncurses++.a/userinput/screen
paraFinally, make sure that old applications that look for
filename class=libraryfile-lcurses/filename at build time are still
buildable:/para
-screenuserinputecho INPUT(-lncursesw) gt;/usr/lib/libcursesw.so amp;amp;
-ln -sfv libncurses.so /usr/lib/libcurses.so amp;amp;
-ln -sfv libncursesw.a /usr/lib/libcursesw.a amp;amp;
+screenuserinputecho INPUT(-lncursesw) gt;/usr/lib/libcursesw.so
+ln -sfv libncurses.so /usr/lib/libcurses.so
+ln -sfv libncursesw.a /usr/lib/libcursesw.a
ln -sfv libncurses.a /usr/lib/libcurses.a/userinput/screen
note
@@ -140,10 +140,10 @@ ln -sfv libncurses.a /usr/lib/libcurses.a/userinput/screen
of some binary-only application, build them with the following
commands:/para
-screen role=nodumpuserinputmake distclean amp;amp;
+screen role=nodumpuserinputmake distclean
./configure --prefix=/usr --with-shared --without-normal \
- --without-debug --without-cxx-binding amp;amp;
-make sources libs amp;amp;
+ --without-debug --without-cxx-binding
+make sources libs
cp -av lib/lib*.so.5* /usr/lib/userinput/screen
/note
diff --git a/BOOK/chapter07/network.xml b/BOOK/chapter07/network.xml
index 7df7ae8..dc4f05a 100644
--- a/BOOK/chapter07/network.xml
+++ b/BOOK/chapter07/network.xml
@@ -109,8 +109,8 @@
paraThe following command creates a sample filenameipv4/filename
file for the emphasiseth0/emphasis device:/para
-screenuserinputcd /etc/sysconfig/network-devices amp;amp;
-mkdir -v ifconfig.eth0 amp;amp;
+screenuserinputcd /etc/sysconfig/network-devices
+mkdir -v ifconfig.eth0
cat gt; ifconfig.eth0/ipv4 lt;lt; EOF
literalONBOOT=yes
SERVICE=ipv4-static
diff --git a/BOOK/chapter08/grub.xml b/BOOK/chapter08/grub.xml
index 8374c57..913ed5f 100644
--- a/BOOK/chapter08/grub.xml
+++ b/BOOK/chapter08/grub.xml
@@ -134,7 +134,7 @@ EOF/userinput/screen
be symlinked to filename class=symlink/etc/grub/menu.lst/filename. To
satisfy this requirement, issue the following command:/para
-screenuserinputmkdir -v /etc/grub amp;amp;
+screenuserinputmkdir -v /etc/grub
ln -sv /boot/grub/menu.lst /etc/grub/userinput/screen
/sect1
diff --git a/BOOK/chapter08/kernel.xml b/BOOK/chapter08/kernel.xml
index 1ba8dfc..fb6216a 100644
--- a/BOOK/chapter08/kernel.xml
+++ b/BOOK/chapter08/kernel.xml
@@ -129,7 +129,7 @@
paraInstall the documentation for the Linux kernel:/para
-screenuserinputinstall -d /usr/share/doc/linux-linux-version; amp;amp;
+screenuserinputinstall -d /usr/share/doc/linux-linux-version;
cp -r Documentation/* /usr/share/doc/linux-linux-version;/userinput/screen
paraIt is important to note that the files in the kernel source
diff --git a/BOOK/general.ent b/BOOK/general.ent
index c5c3f47..aced25c 100644
--- a/BOOK/general.ent
+++ b/BOOK/general.ent
@@ -1,6 +1,6 @@
?xml version=1.0 encoding=ISO-8859-1?
-!ENTITY version SVN-20070723
-!ENTITY releasedate July 23, 2007
+!ENTITY version SVN-20070724
+!ENTITY releasedate July 24, 2007
!ENTITY milestone 6.3
!ENTITY generic-version development !-- Use development, testing, or x.y[-pre{x
Re: most recent iproute2
On 7/24/07, Matthew Burgess [EMAIL PROTECTED] wrote: I'd personally rather use the new version since it syncs to the 2.6.22 interfaces and that's the kernel we'll be running. I'll try poking the maintainer again. Thanks Dan. Maybe keeping the package freeze open for IPRoute2 Glibc-2.5.1 during the RC process will enable Bruce to move forward with cutting the -rc1 version fairly soon? Well, it looks like I'm the only one left in Aye column :) Let's just move on with what's in the book, then. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Inconsistent use of in BOOK
Dan Nicholson wrote: I was going to edit something on the ncurses page the other day and noticed some in chained commands. It seems that usual way in LFS is not to do this. Compare the linker script section of ncurses to the localedef commands in glibc. http://www.linuxfromscratch.org/lfs/view/development/chapter06/ncurses.html http://www.linuxfromscratch.org/lfs/view/development/chapter06/glibc.html Assuming they're unwanted, I grepped through for 'amp;amp;' and found quite a few. Attached is a patch to remove the offenders, but I thought I'd post here first before committing. ACK the DB, NCurses and Man-DB bits. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
x86_64 build method
This is a continuation from here: http://linuxfromscratch.org/pipermail/lfs-dev/2007-July/059737.html Starting a new thread because the last one was getting unwieldy and had several different topics running through it. Greg, the host I was working from was a current CLFS development snapshot. All that 'ls -ld /l*' shows me is: drwxr-xr-x 5 root root 2696 2007-07-19 16:35 /lib As an aside, the effects of their not having a /lib64 dir or symlink seems to be that if I want to use a CLFS system as a host, I *must* use their pure64 patch. I tried a build last night without using that patch and just using --disable-multilib and appropriate symlinks and gcc pass1 failed when it got to stage1 of the bootstrap. I didn't get the opportunity to add a /lib64 symlink and test it further... I suppose that if the above is correct this also means that your native build expects a /lib64 dir or symlink on the host? I found a Ubuntu CD and a spare partition, so I'll be using them as a host for my next test. I may also run a DIY build, just to familiarize myself more with your current setup. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Inconsistent use of in BOOK
On Tue, 24 Jul 2007 20:08:04 +0600, Alexander E. Patrakov [EMAIL PROTECTED] wrote: ACK the DB, NCurses and Man-DB bits. The rest of the bits look fine to me as well. Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
linux-2.6.22.1 headers break iptables-1.3.7
Hello, the following failure appears during iptables-1.3.7 compilation against linux-2.6.22.1 headers (spotted during a full rebuild of the LiveCD): make[2]: Entering directory `/lfs-livecd/packages/iptables/iptables-1.3.7' make PREFIX=/usr LIBDIR=/lib BINDIR=/bin MANDIR=/usr/share/man KERNEL_DIR=/usr make[3]: Entering directory `/lfs-livecd/packages/iptables/iptables-1.3.7' Making dependencies: please wait... make[3]: Leaving directory `/lfs-livecd/packages/iptables/iptables-1.3.7' make[3]: Entering directory `/lfs-livecd/packages/iptables/iptables-1.3.7' Unable to resolve dependency on linux/netfilter_ipv4/ip_conntrack.h. Try 'make c lean'. Unable to resolve dependency on linux/netfilter_ipv4/ip_nat_rule.h. Try 'make cl ean'. Extensions found: IPv4:NFLOG IPv4:connbytes IPv4:dccp IPv4:recent IPv4:string IP v6:NFLOG IPv6:REJECT IPv6:esp IPv6:hashlimit IPv6:sctp cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.7\ -f PIC -o extensions/libipt_ah_sh.o -c extensions/libipt_ah.c cc -shared -o extensions/libipt_ah.so extensions/libipt_ah_sh.o cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.7\ -f PIC -o extensions/libipt_addrtype_sh.o -c extensions/libipt_addrtype.c cc -shared -o extensions/libipt_addrtype.so extensions/libipt_addrtype_sh.o cc -O2 -Wall -Wunused -I/usr/include -Iinclude/ -DIPTABLES_VERSION=\1.3.7\ -f PIC -o extensions/libipt_comment_sh.o -c extensions/libipt_comment.c cc -shared -o extensions/libipt_comment.so extensions/libipt_comment_sh.o make[3]: Leaving directory `/lfs-livecd/packages/iptables/iptables-1.3.7' make[2]: *** [compile-stage2] Error 2 So far, I am going to try to compile iptables against raw headers in /lib/modules/2.6.22.1/build/include - but anyway, this is a bug in one of the books that has to be fixed. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Obsolete text on the X Window System Components page
The following text is obsolete, because there is no /etc/fonts/*.conf file, and DejaVu is known to Fontconfig-2.4.2 by default: Earlier it was mentioned that |/etc/fonts/fonts.conf| could be modified to use DejaVu using the default family names. Since DejaVu is a replacement for Bitstream Vera fonts, it can be substituted for that family. Visually inspect the |fonts.conf| to see how fonts are grouped together under the generic family names within alias tags and a preference list is created within prefer tags. To replace Bitstream Vera with DejaVu, run the following command as the |root| user: sed -i 's/familyBitstream Vera/familyDejaVu/' /etc/fonts/fonts.conf To see which fonts will be used as the generic fonts in your locale, run the command *fc-match monospace*. Substitute sans or serif to see the fonts that will be used for those aliases. (thanks to Archaic for spotting this) -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: linux-2.6.22.1 headers break iptables-1.3.7
On Tue, 24 Jul 2007 20:50:58 +0600, Alexander E. Patrakov [EMAIL PROTECTED] wrote: the following failure appears during iptables-1.3.7 compilation against linux-2.6.22.1 headers (spotted during a full rebuild of the LiveCD): Any chance you could give iptables-1.3.8 a try please? I've not compiled it myself, but the changelog (http://ftp.netfilter.org/pub/iptables/changes-iptables-1.3.8.txt) mentions various compile time fixes such as removal of unneccessary headers. Thanks, Matt. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: linux-2.6.22.1 headers break iptables-1.3.7
Matthew Burgess wrote: On Tue, 24 Jul 2007 20:50:58 +0600, Alexander E. Patrakov [EMAIL PROTECTED] wrote: the following failure appears during iptables-1.3.7 compilation against linux-2.6.22.1 headers (spotted during a full rebuild of the LiveCD): Any chance you could give iptables-1.3.8 a try please? This version worked - so this is just a matter of updating some entities in the BLFS book. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: x86_64 build method
Jeremy Huntwork wrote: As an aside, the effects of their not having a /lib64 dir or symlink seems to be that if I want to use a CLFS system as a host, I *must* use their pure64 patch. I tried a build last night without using that patch and just using --disable-multilib and appropriate symlinks and gcc pass1 failed when it got to stage1 of the bootstrap. I didn't get the opportunity to add a /lib64 symlink and test it further... I suppose that if the above is correct this also means that your native build expects a /lib64 dir or symlink on the host? This is confirmed. Adding /lib64 and /usr/lib64 symlinks to a CLFS host enables gcc to bootstrap in pass1 without using the pure64 patch. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
Hello Everyone, I'm trying to decide how best to alter the x86_64 branch. If we adopt the basic principles from DIY-Linux, it would mean that as far as build instructions go, we only have to add 3 things: * Add --disable-multilib to each build of GCC (this has no effect on a x86 build) * In GCC pass 2, adjust the multilib spec, MULTILIB_OSDIRNAMES. DIY just removes this completely. * Add the symlinks /lib64 - /lib and /usr/lib64 - /usr/lib The question is, do we want x86_64 to be a separate book, or simply roll these small changes into a conglomerate book with x86? If we did, for the latter two additions we could add a uname test before the command. Personally I favor making them one book, but were we to do that, we would have to rethink a few things: 1) The way the text reads when it speaks about target triplets and dynamic linkers and the appropriate names for these. For x86_64, the dynamic linker is ld-linux-x86-64.so.2 and the target triplet is usually x86_64-unknown-linux-gnu. 2) The commands to adjust the gcc spec file would have to change to incorporate either dynamic linker. (Also, the current command in chapter 5's adjusting the toolchain, gcc -dumpspecs | sed '[EMAIL PROTECTED]/lib/ld-linux.so.2@/tools@g' \, assumes that we will find the name of the dynamic linker at the beginning of the line. In x86_64, this isn't the case. 3) The toolchain tests would have to be changed to reflect the output of either testcase. Usually this is because the output of the test involves the name of the dynamic linker or the target triplet. Lastly, we would want to test to see if someone is building natively from a CLFS host that doesn't include /lib64 or /usr/lib64. If they are, it's a simple matter of adding those symlinks before starting the build. Even with all the above, it seems much simpler than trying to maintain two separate books. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
Jeremy Huntwork wrote: Hello Everyone, I'm trying to decide how best to alter the x86_64 branch. If we adopt the basic principles from DIY-Linux, it would mean that as far as build instructions go, we only have to add 3 things: snip / Even with all the above, it seems much simpler than trying to maintain two separate books. -- JH Forgive the intrusion but I thought this worth saying... Of course it might be complete hogwash in which case please enlighten me ;-) (I'm quite thick-skinned too) A while ago now I looked at building CLFS for my AMD 64 processor. But after doing some research, IIRC I discovered that there was almost no gain to be had from building LFS as *pure* 64bit and there were quite a few problems, namely: * Bootloader, or rather lack-of * Building BLFS on top of a pure 64b LFS was - at the time - impractical and untested * Several apps and closed-source binaries widely used were not available for 64bit architectures. Unless this has significantly changed (in which case I'll be building a new LFS64 next week ;-)) I think some rather bold and legible text at the start of the book needs to make it clear that there may be little point in doing this unless you know what to do next. Alan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
On Tue, 24 Jul 2007 11:40:24 -0400, Jeremy Huntwork [EMAIL PROTECTED] wrote: The question is, do we want x86_64 to be a separate book, or simply roll these small changes into a conglomerate book with x86? I'd certainly prefer them to be in the same book, or at least in the same sources/svn repository. I think Dan suggested we could use some XSL-foo (profiling?) to generate two different books from the same XML sources. This is certainly my preferred method as it eases maintainance (both books receive fixes/feature enhancements at the same time) and eases readability (readers only see 1 straight flow of instructions, even there would only be 2 if...else type choices to make currently). I think this is also how CLFS works with its different targets, though I'll admit it's been a very long time since I looked at those sources. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
Matthew Burgess wrote: On Tue, 24 Jul 2007 11:40:24 -0400, Jeremy Huntwork [EMAIL PROTECTED] wrote: The question is, do we want x86_64 to be a separate book, or simply roll these small changes into a conglomerate book with x86? I'd certainly prefer them to be in the same book, My biggest problem with this approach is that it gets to be a nightmare to edit. But, it is do-able. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
Alan Lord wrote: * Bootloader, or rather lack-of Yes, I keep forgetting about the boot loader. There's one more difference - we'd probably want to add lilo/bin86 to the build. Of course, you can always install grub to the mbr or partition without installing grub's shell into the OS. Use the LiveCD, for example. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
On Tue, 24 Jul 2007 11:59:39 -0400, Jeremy Huntwork [EMAIL PROTECTED] wrote: Matthew Burgess wrote: On Tue, 24 Jul 2007 11:40:24 -0400, Jeremy Huntwork [EMAIL PROTECTED] wrote: The question is, do we want x86_64 to be a separate book, or simply roll these small changes into a conglomerate book with x86? I'd certainly prefer them to be in the same book, My biggest problem with this approach is that it gets to be a nightmare to edit. But, it is do-able. Hmm, that nightmare seems a bit extreme. Certainly, for native x86-64, which is the only additional target we're contemplating at the moment, having 2 paragraphs (or small sections at the most) in the book surrounded in the relevant profiling syntax, doesn't seem too onerous to me. Once in there, I doubt they'd need amending much - probably only if newer GCC versions change relevant portions of the specs file. Of course, if more targets are desired in the future, our approach may well need to change, but for now I think x86 x86-64 native builds capture the largest section of the LFS audience and anyone else can continue on to CLFS. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
Matthew Burgess wrote: Hmm, that nightmare seems a bit extreme. Certainly, for native x86-64, which is the only additional target we're contemplating at the moment, having 2 paragraphs (or small sections at the most) in the book surrounded in the relevant profiling syntax, doesn't seem too onerous to me. Once in there, I doubt they'd need amending much - probably only if newer GCC versions change relevant portions of the specs file. Of course, if more targets are desired in the future, our approach may well need to change, but for now I think x86 x86-64 native builds capture the largest section of the LFS audience and anyone else can continue on to CLFS. Well, if that's the preferred method, I'll give it a go. Let me see what I can do... -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
Matthew Burgess wrote: On Tue, 24 Jul 2007 11:59:39 -0400, Jeremy Huntwork [EMAIL PROTECTED] wrote: Matthew Burgess wrote: On Tue, 24 Jul 2007 11:40:24 -0400, Jeremy Huntwork [EMAIL PROTECTED] wrote: The question is, do we want x86_64 to be a separate book, or simply roll these small changes into a conglomerate book with x86? I'd certainly prefer them to be in the same book, My biggest problem with this approach is that it gets to be a nightmare to edit. But, it is do-able. Hmm, that nightmare seems a bit extreme. Certainly, for native x86-64, which is the only additional target we're contemplating at the moment, having 2 paragraphs (or small sections at the most) in the book surrounded in the relevant profiling syntax, doesn't seem too onerous to me. Once in there, I doubt they'd need amending much - probably only if newer GCC versions change relevant portions of the specs file. Of course, if more targets are desired in the future, our approach may well need to change, but for now I think x86 x86-64 native builds capture the largest section of the LFS audience and anyone else can continue on to CLFS. There is one other place we need to address in a x86_64 system: ii. Audience Why would you want to build an x86_64 system? To me there are more drawbacks than advantages. I'm not saying not to do it, because one of the reasons to build it is because It is there. and one of the major objectives of the book is education. Other reasons to build it include the need to manipulate very large (3G) files, to work with very large databases, to fully take advantage of physical RAM 4G, or to run specialized software efficiently (Computational fluid dynamics anyone?). The disadvantages are numerous and need to be mentioned. Issues include boot loader problems, lack of support for 64-bit closed source binaries such as flash, and potential problems in building some open source packages. Minor issues include slightly larger binaries. Also the point needs to be made that the speed of execution will probably not significantly increase for most applications and in some cases may be slower than a 32-bit systems. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Plans for LFS-6.3
Bruce Dubbs wrote: I guess I can do it again. Most of the stuff is mechanical. We'd need to decide on a package freeze. Right now there are a total of 16 open Can we cut trunk to a release/testing/6.3 branch so that we can begin doing 7.0 type work on trunk? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Plans for LFS-6.3
Jeremy Huntwork wrote: Bruce Dubbs wrote: I guess I can do it again. Most of the stuff is mechanical. We'd need to decide on a package freeze. Right now there are a total of 16 open Can we cut trunk to a release/testing/6.3 branch so that we can begin doing 7.0 type work on trunk? I tagged 6.3-rc1. I also added 7.0 to the wiki milestones and 6.3-rc1 and 7.0 to the versions for tickets. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Plans for LFS-6.3
Bruce Dubbs wrote: I tagged 6.3-rc1. I also added 7.0 to the wiki milestones and 6.3-rc1 and 7.0 to the versions for tickets. Thanks. :) -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
El Martes, 24 de Julio de 2007 17:59, Jeremy Huntwork escribió: My biggest problem with this approach is that it gets to be a nightmare to edit. But, it is do-able. See how HLFS manages the Glibc/uClibc - Linux-2.4/2.6 books flavours and ask Robert if it hard to maintain. Four sepparte books are generated from one common sources tree. CLFS uses a diferent, more complex, method due that 12 book need be generated. But also, there is only one common sources tree. I prefer to use the HLFS-way for x86_64 integration. -- 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/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
On 7/24/07, M.Canales.es [EMAIL PROTECTED] wrote: El Martes, 24 de Julio de 2007 17:59, Jeremy Huntwork escribió: My biggest problem with this approach is that it gets to be a nightmare to edit. But, it is do-able. See how HLFS manages the Glibc/uClibc - Linux-2.4/2.6 books flavours and ask Robert if it hard to maintain. Four sepparte books are generated from one common sources tree. CLFS uses a diferent, more complex, method due that 12 book need be generated. But also, there is only one common sources tree. I prefer to use the HLFS-way for x86_64 integration. Out of curiosity, will the Relax NG XML ease in generating multiple books from a common source? If we're considering using Relax NG for LFS-7.0, that should be kept in mind. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [PATCH] Add screen install attributes for final system packages
El Sábado, 21 de Julio de 2007 01:42, Dan Nicholson escribió: Another jhalfs helper. As has been discussed before, it would be nice to mark the screen sections with an attribute to announce that it will be installing to the system rather than just working in the source/build tree. Manuel suggested adding the attribute userlevel=install, so I've done that for the Ch. 6 packages and the kernel in Ch. 8. IMHO, both this and the sect1info patch are good additions for the 7.x milestone. But I think also that could be better to apply they after the final 6.3 release to can do more easy merges from/to the 6.3 branch to/from trunk. -- 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/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
El Martes, 24 de Julio de 2007 19:51, Dan Nicholson escribió: Out of curiosity, will the Relax NG XML ease in generating multiple books from a common source? Not, what Relax-NG make more easy is to customize the schema declaration. I.e, to add new tags or attributes (placed on a diferent namespace) to the default DocBook-XML set while allowing separate or combined schemas validation. For example, in the old times when the migration to XML/XSLT was initiated, one of the cool new features discussed was that we would be able to change the book screen blocks to nALFS sintax. That has no sense right now, of course. -- 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/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
El Martes, 24 de Julio de 2007 20:12, Jeremy Huntwork escribió: M.Canales.es wrote: I prefer to use the HLFS-way for x86_64 integration. Well, you obviously know that setup better than I do. If you could help me set that up, I'd appreciate it. I have many fronts open right now, with priority on doing the jhalfs-2.3 release. Could you continue using the x86_64 branch for now until jhalfs-2.3 will be released? I think that at the weekend I will can start mergin the x86_64 changes into trunk. For a full set-up a new top-level index.html file must be created and the Makefile need be modified to support multiple books build. -- 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/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
M.Canales.es wrote: Could you continue using the x86_64 branch for now until jhalfs-2.3 will be released? No problem. I think that at the weekend I will can start mergin the x86_64 changes into trunk. For a full set-up a new top-level index.html file must be created and the Makefile need be modified to support multiple books build. If I end up getting it sorted it out, I'll let you take a look before I commit anything. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LFS 6.2-rc1 Released
The Linux From Scratch community is pleased to announce the first release candidate of LFS 6.3. Please see http://www.linuxfromscratch.org/lfs/view/6.3-rc1/chapter01/whatsnew.html for a complete list of new packages since the last release. This being a test release, we would appreciate you taking the time to try it out and report any bugs you find in it to the LFS development team at [EMAIL PROTECTED] Bruce Dubbs LFS 6.3 Release Manager -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
6.3-rc1 Release announcement
I updated the website and have created the -rc1 files. In the announcement to lfs-announce, the subject erroneously says 6.2-rc1 instead of 6.3-rc1, but the contents are correct. I won't send a correction to lfs-announce becuase we can fix it with -rc2 or the stable 6.3 announcement as appropriate. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
DocBook XSL 1.73.0 Released
Manuel, I don't know if it matters at this point, but the new version of the XSL stylesheets were released. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: DocBook XSL 1.73.0 Released
Dan Nicholson wrote these words on 07/24/07 17:10 CST: Manuel, I don't know if it matters at this point, but the new version of the XSL stylesheets were released. Keep in mind that the .0 versions of the stylesheets are not the stable series. -- Randy rmlscsi: [bogomips 1003.23] [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] 17:20:00 up 12 days, 10:27, 1 user, load average: 0.00, 0.04, 0.04 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
