Re: initramfs support
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Alexander E. Patrakov wrote: The one sticking point is the same sticking point I had with dmraid -- how do you get the /dev/md/* named device nodes to be recreated once the initramfs is finished, from the system bootscripts? I think that it cannot be supported. I will test now to see whether Debian can be installed on such /dev/md/meaningful_name array. Not sure what the testing came up with, but I figured out a way to get it to work: mkdir /dev/md for array in /dev/md[0-9]* ; do # subshell so the $MD_* variables don't carry between arrays ( eval `mdadm --detail --export $array` [ -z $MD_NAME ] exit 0 # v0.9 metadata has no name real_name=`echo $MD_NAME | cut -d: -f2` # if there's no host field (no colon), use the full name [ -z $real_name ] real_name=$MD_NAME cp -a $array /dev/md/$real_name cp -a $array /dev/md_$real_name # might or might not be needed; my setup works without: rm $array ) done I have not tested this on a metadata=0.9 array, but as long as those don't provide an MD_NAME in --detail --export, it should work fine. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGoJf1S5vET1Wea5wRAyejAJ0c58ar6LwzStC0umrDfZWvxyA8rQCgmQnO p6kc5EHd5IYHE9VZ2ktTEjs= =70fD -END PGP SIGNATURE- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Refactor newlines in dump-commands XSL
El Viernes, 20 de Julio de 2007 02:08, Dan Nicholson escribió: Manuel, I was playing with the dump-commands output and saw a couple things that I thought could be cleaned up. First, I think it's nicer to create a global variable for newlines instead of always using the entity directly. Second, there were an excessive number of newlines in the output. Now, there is just an extra newline at the end of each screen block. What do you think? Looks good to me. Actually, when updating to the new XSL code, I was tempted to remove dump-commads.xsl in favour of jhalfs generated scripts, but keeped due that is more fast and their output is more raw. -- 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: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Jeremy Huntwork wrote: On Thu, Jul 19, 2007 at 09:59:31PM -0400, Joe Ciccone wrote: LFS could be made to accommodate x86_64 (multilib) with very few changes and a bunch of new pages. Where multilib gets tricky is where lfs stops and blfs begins. With the introduction of pkg-config and all those fun *-config programs and hard coded library paths. And non-multilib is even fewer changes, and would be much easier for BLFS to accomodate. I suppose the only concern is compliance with standards and/or user expectations. I'm working on getting a LFS-style native build done on x86_64 with as few changes as possible. I'll let you know how it goes. There is even a bigger problem with non-multilib builds. The way clfs does it, all the 64bit libs go into /lib and such. FHS specifies ld.so for 64bit x86_64 to be at /lib64/ld-linux-x86_64.so.2. If ld.so is in /lib, all those nice 64 binary packages need to be modified or a compatibility symlink has to be put in place. Plus a 64bit build will be incapeable of running 32bit binaries, unless 32lib libraries are put on the system somewhere, and /lib/ld-linux.so.2 knows where to look for them. You can have /lib64/ld-linux-x86_64.so.2 (symlink to /lib), /lib/ld-linux.so.2 (32bit), and /lib/ld-linux-x86_64.so.2 (64bit). Your 64bit libs in /lib. and your 32bit libs in /lib32 or some weird place lib /opt/emul_32/lib. A hint about using /opt/emul_32/lib for the specific purpose of running wine could definitely be written up. That would be useful for clfs too. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Refactor newlines in dump-commands XSL
On 7/20/07, M.Canales.es [EMAIL PROTECTED] wrote: El Viernes, 20 de Julio de 2007 02:08, Dan Nicholson escribió: Manuel, I was playing with the dump-commands output and saw a couple things that I thought could be cleaned up. First, I think it's nicer to create a global variable for newlines instead of always using the entity directly. Second, there were an excessive number of newlines in the output. Now, there is just an extra newline at the end of each screen block. What do you think? Looks good to me. OK, I'm going to commit that. Do you mind if I use a similar variable in jhalfs/LFS/lfs.xsl? Actually, when updating to the new XSL code, I was tempted to remove dump-commads.xsl in favour of jhalfs generated scripts, but keeped due that is more fast and their output is more raw. The jhalfs stylesheet is a lot more complicated due to all the workarounds. We should try to fold some of those back into the XML to get rid of the hacks. But it's nice to have the dump-commands templates for quick testing. I guess I could go either way. It might be nicer to have the jhalfs stylesheet here and just sync them. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Refactor newlines in dump-commands XSL
El Viernes, 20 de Julio de 2007 19:22, Dan Nicholson escribió: OK, I'm going to commit that. Do you mind if I use a similar variable in jhalfs/LFS/lfs.xsl? If you have commits right to the ALFS repo, fell free to do the changes. I'm very busy now trying to install some usable host system with full hardware support for my new AMD64 machine. -- 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: Refactor newlines in dump-commands XSL
On 7/20/07, M.Canales.es [EMAIL PROTECTED] wrote: El Viernes, 20 de Julio de 2007 19:22, Dan Nicholson escribió: OK, I'm going to commit that. Do you mind if I use a similar variable in jhalfs/LFS/lfs.xsl? If you have commits right to the ALFS repo, fell free to do the changes. No, but I will now give them to myself. Well, I might mess around in a local branch for a while first. -- Dan -- 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: ...)
On Fri, Jul 20, 2007 at 12:45:37PM -0400, Joe Ciccone wrote: There is even a bigger problem with non-multilib builds. The way clfs does it, all the 64bit libs go into /lib and such. FHS specifies ld.so for 64bit x86_64 to be at /lib64/ld-linux-x86_64.so.2. If ld.so is in /lib, all those nice 64 binary packages need to be modified or a compatibility symlink has to be put in place. Plus a 64bit build will be incapeable of running 32bit binaries, unless 32lib libraries are put on the system somewhere, and /lib/ld-linux.so.2 knows where to look for them. all those nice 64 binary packages - I suppose that means nvidia or ati kernel modules ? I don't know of anything else that comes as 64-bit without source. Yeah, if people want to run binaries, they do need a multilib build. Personally, I'd rather have the discussion about where LFS should be going _after_ the holiday season. Hey, gcc-4.2 might even be working on ppc64 in clfs by then - although I doubt it ;) ĸ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: ...)
On 7/20/07, Joe Ciccone [EMAIL PROTECTED] wrote: Jeremy Huntwork wrote: On Thu, Jul 19, 2007 at 09:59:31PM -0400, Joe Ciccone wrote: LFS could be made to accommodate x86_64 (multilib) with very few changes and a bunch of new pages. Where multilib gets tricky is where lfs stops and blfs begins. With the introduction of pkg-config and all those fun *-config programs and hard coded library paths. And non-multilib is even fewer changes, and would be much easier for BLFS to accomodate. I suppose the only concern is compliance with standards and/or user expectations. I'm working on getting a LFS-style native build done on x86_64 with as few changes as possible. I'll let you know how it goes. There is even a bigger problem with non-multilib builds. The way clfs does it, all the 64bit libs go into /lib and such. FHS specifies ld.so for 64bit x86_64 to be at /lib64/ld-linux-x86_64.so.2. If ld.so is in /lib, all those nice 64 binary packages need to be modified or a compatibility symlink has to be put in place. Plus a 64bit build will be incapeable of running 32bit binaries, unless 32lib libraries are put on the system somewhere, and /lib/ld-linux.so.2 knows where to look for them. You can have /lib64/ld-linux-x86_64.so.2 (symlink to /lib), /lib/ld-linux.so.2 (32bit), and /lib/ld-linux-x86_64.so.2 (64bit). Your 64bit libs in /lib. and your 32bit libs in /lib32 or some weird place lib /opt/emul_32/lib. A hint about using /opt/emul_32/lib for the specific purpose of running wine could definitely be written up. That would be useful for clfs too. Thanks for the info. I think just to get started on handling multiple arches in LFS, we should focus on non-multilib 64 and just symlink /lib - /lib64. Hopefully it doesn't bite elsewhere, but I think it's the fastest way to get up and running. Multilib is definitely the way to go, but I think it's more important to just get a 64 bit build in before handling the much larger case. Then again, I haven't done anything, so this is just speculation. -- Dan -- 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: ...)
On Fri, Jul 20, 2007 at 11:38:30AM -0700, Dan Nicholson wrote: Thanks for the info. I think just to get started on handling multiple arches in LFS, we should focus on non-multilib 64 and just symlink /lib - /lib64. Hopefully it doesn't bite elsewhere, but I think it's the fastest way to get up and running. Multilib is definitely the way to go, but I think it's more important to just get a 64 bit build in before handling the much larger case. Then again, I haven't done anything, so this is just speculation. Agreed. I believe I have the necessary changes worked through in a working copy of the x86_64 branch I made the other day. Due to time constraints I haven't been able to finish a full build, but I believe what is there will work. I do plan on testing it fully before I commit any changes, but I figured I'd show what I have and give someone else the opportunity to build it if they like and/or look for any obvious errors. Here's the rendered book: http://linuxfromscratch.org/~jhuntwork/lfs-x86_64 And here's the current diff (so you can see the changes in a glance): http://linuxfromscratch.org/~jhuntwork/x86_64-changes.diff The two gcc pure64 patches come from CLFS. -- JH -- 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: On Fri, Jul 20, 2007 at 11:38:30AM -0700, Dan Nicholson wrote: Thanks for the info. I think just to get started on handling multiple arches in LFS, we should focus on non-multilib 64 and just symlink /lib - /lib64. Hopefully it doesn't bite elsewhere, but I think it's the fastest way to get up and running. Multilib is definitely the way to go, but I think it's more important to just get a 64 bit build in before handling the much larger case. Then again, I haven't done anything, so this is just speculation. Agreed. I believe I have the necessary changes worked through in a working copy of the x86_64 branch I made the other day. Due to time constraints I haven't been able to finish a full build, but I believe what is there will work. I do plan on testing it fully before I commit any changes, but I figured I'd show what I have and give someone else the opportunity to build it if they like and/or look for any obvious errors. Here's the rendered book: http://linuxfromscratch.org/~jhuntwork/lfs-x86_64 Should we add lfs-x86_64 to to jhalfs now or wait a few weeks/months? I assume there will be a multi-lib version after all objections/ideas have been aired. (planning ahead for jhalfs) And here's the current diff (so you can see the changes in a glance): http://linuxfromscratch.org/~jhuntwork/x86_64-changes.diff The two gcc pure64 patches come from CLFS. -- JH -- 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: ...)
El Viernes, 20 de Julio de 2007 22:29, George Boudreau escribió: Should we add lfs-x86_64 to to jhalfs now or wait a few weeks/months? I assume there will be a multi-lib version after all objections/ideas have been aired. (planning ahead for jhalfs) Depends on how the changes are applied in the branch. If the branch will contains only x86_64 pure64 libs commands for now (i.e. replacing the needed x86 trunk commands by the ones for pure64), current jhalfs should work fine. If we start merging directly the new pure64 command/packages with the current x86 ones using XSL profiles to generate separate books, then jhalfs will need be updated to can handle such profiles in a similar way than HLFS do. -- 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: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On Fri, Jul 20, 2007 at 01:29:20PM -0600, Jeremy Huntwork wrote: Here's the rendered book: http://linuxfromscratch.org/~jhuntwork/lfs-x86_64 You have correctly dropped grub from the list of packages (nobody has managed to build it successfully on a pure64 system), but it's still referenced in Chapter 8 - Making the LFS System Bootable. A slightly bigger problem might be that you don't seem to have a replacement for it. ĸen, trying not to use the 'l' word because it usually leads to flame-wars ;-) -- 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: ...)
On Fri, Jul 20, 2007 at 09:51:48PM +0100, Ken Moffat wrote: A slightly bigger problem might be that you don't seem to have a replacement for it. Indeed. I meant to drop something in, but forgot about it. bin86/lilo would probably be alright. Anyone tried grub2? -- JH -- 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: ...)
On Fri, Jul 20, 2007 at 10:47:16PM +0200, M.Canales.es wrote: Depends on how the changes are applied in the branch. If the branch will contains only x86_64 pure64 libs commands for now (i.e. replacing the needed x86 trunk commands by the ones for pure64), current jhalfs should work fine. If we start merging directly the new pure64 command/packages with the current x86 ones using XSL profiles to generate separate books, then jhalfs will need be updated to can handle such profiles in a similar way than HLFS do. And for these reasons I vote to wait wrt adjusting jhalfs. Let's see where this will go - and for now, I believe current jhalfs will build the new branch. -- JH -- 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: ...)
On 7/20/07, Ken Moffat [EMAIL PROTECTED] wrote: On Fri, Jul 20, 2007 at 01:29:20PM -0600, Jeremy Huntwork wrote: Here's the rendered book: http://linuxfromscratch.org/~jhuntwork/lfs-x86_64 You have correctly dropped grub from the list of packages (nobody has managed to build it successfully on a pure64 system), but it's still referenced in Chapter 8 - Making the LFS System Bootable. The 1.9.x versions, too? -- Dan -- 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: ...)
El Viernes, 20 de Julio de 2007 22:54, Jeremy Huntwork escribió: Indeed. I meant to drop something in, but forgot about it. bin86/lilo would probably be alright. Anyone tried grub2? IMHO, for now lilo should be used due that the build commands could be copied from CLFS. For the future, see Alexander comment on http://wiki.linuxfromscratch.org/lfs/ticket/1955 -- 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: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On Fri, Jul 20, 2007 at 02:06:00PM -0700, Dan Nicholson wrote: On 7/20/07, Ken Moffat [EMAIL PROTECTED] wrote: On Fri, Jul 20, 2007 at 01:29:20PM -0600, Jeremy Huntwork wrote: Here's the rendered book: http://linuxfromscratch.org/~jhuntwork/lfs-x86_64 You have correctly dropped grub from the list of packages (nobody has managed to build it successfully on a pure64 system), but it's still referenced in Chapter 8 - Making the LFS System Bootable. The 1.9.x versions, too? No idea - playing with experimental bootloaders scares the crap out of me. I got yaboot building with a natively 64-bit gcc last year, I'm hoping not to touch anything in that line this year ;) ĸ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: ...)
Dan Nicholson wrote: On 7/20/07, Ken Moffat [EMAIL PROTECTED] wrote: On Fri, Jul 20, 2007 at 01:29:20PM -0600, Jeremy Huntwork wrote: Here's the rendered book: http://linuxfromscratch.org/~jhuntwork/lfs-x86_64 You have correctly dropped grub from the list of packages (nobody has managed to build it successfully on a pure64 system), but it's still referenced in Chapter 8 - Making the LFS System Bootable. The 1.9.x versions, too? I'll have to check on the more recent versions. I know that 1.9.2 (the last time I tried) still needed a 32bit glibc. I don't have a pure64 build around but I think the new one (1.9.5) may work. grub2 is a completely different beast then grub legacy. Still no documentation. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[PATCH] Add package info in sect1info elements
From 464c7bc0fa13ca8d6eb554d798eae2186867ac14 Mon Sep 17 00:00:00 2001 From: Dan Nicholson [EMAIL PROTECTED] Date: Thu, 19 Jul 2007 18:15:20 -0700 Subject: [PATCH] Add package info in sect1info elements I've been playing around with jhalfs and I realized that there was no easy way to access the package name and version on a given page. Manuel and I had a discussion on alfs-discuss and he suggested using the productname and productnumber children of the sect1info elements. http://linuxfromscratch.org/pipermail/alfs-discuss/2007-July/009376.html These are currently unused, so shouldn't have any conflicts. Further, the sect1info element is protected by the condition attribute to prevent it from being processed by the HTML or PDF stylesheets. I added these elements to all the packages in Ch. 5 and Ch.6 and the kernel page in Ch. 8. The HTML output was diffed and no changes were shown. Any objections? -- Dan BOOK/chapter05/bash.xml |5 + BOOK/chapter05/binutils-pass1.xml|5 + BOOK/chapter05/binutils-pass2.xml|5 + BOOK/chapter05/bison.xml |5 + BOOK/chapter05/bzip2.xml |5 + BOOK/chapter05/coreutils.xml |5 + BOOK/chapter05/dejagnu.xml |5 + BOOK/chapter05/diffutils.xml |5 + BOOK/chapter05/expect.xml|5 + BOOK/chapter05/findutils.xml |5 + BOOK/chapter05/flex.xml |5 + BOOK/chapter05/gawk.xml |5 + BOOK/chapter05/gcc-pass1.xml |5 + BOOK/chapter05/gcc-pass2.xml |5 + BOOK/chapter05/gettext.xml |5 + BOOK/chapter05/glibc.xml |5 + BOOK/chapter05/grep.xml |5 + BOOK/chapter05/gzip.xml |5 + BOOK/chapter05/linux-headers.xml |5 + BOOK/chapter05/m4.xml|5 + BOOK/chapter05/make.xml |5 + BOOK/chapter05/ncurses.xml |5 + BOOK/chapter05/patch.xml |5 + BOOK/chapter05/perl.xml |5 + BOOK/chapter05/sed.xml |5 + BOOK/chapter05/tar.xml |5 + BOOK/chapter05/tcl.xml |5 + BOOK/chapter05/texinfo.xml |5 + BOOK/chapter05/util-linux.xml|5 + BOOK/chapter06/autoconf.xml |5 + BOOK/chapter06/automake.xml |5 + BOOK/chapter06/bash.xml |5 + BOOK/chapter06/binutils.xml |5 + BOOK/chapter06/bison.xml |5 + BOOK/chapter06/bzip2.xml |5 + BOOK/chapter06/coreutils.xml |5 + BOOK/chapter06/db.xml|5 + BOOK/chapter06/diffutils.xml |5 + BOOK/chapter06/e2fsprogs.xml |5 + BOOK/chapter06/file.xml |5 + BOOK/chapter06/findutils.xml |5 + BOOK/chapter06/flex.xml |5 + BOOK/chapter06/gawk.xml |5 + BOOK/chapter06/gcc.xml |5 + BOOK/chapter06/gettext.xml |5 + BOOK/chapter06/glibc.xml |5 + BOOK/chapter06/grep.xml |5 + BOOK/chapter06/groff.xml |5 + BOOK/chapter06/grub.xml |5 + BOOK/chapter06/gzip.xml |5 + BOOK/chapter06/iana-etc.xml |5 + BOOK/chapter06/inetutils.xml |5 + BOOK/chapter06/iproute2.xml |5 + BOOK/chapter06/kbd.xml |5 + BOOK/chapter06/less.xml |5 + BOOK/chapter06/libtool.xml |5 + BOOK/chapter06/linux-headers.xml |5 + BOOK/chapter06/m4.xml|5 + BOOK/chapter06/make.xml |5 + BOOK/chapter06/man-db.xml|5 + BOOK/chapter06/man-pages.xml |5 + BOOK/chapter06/mktemp.xml|5 + BOOK/chapter06/module-init-tools.xml |5 + BOOK/chapter06/ncurses.xml |5 + BOOK/chapter06/patch.xml |5 + BOOK/chapter06/perl.xml |5 + BOOK/chapter06/procps.xml|5 + BOOK/chapter06/psmisc.xml|5 + BOOK/chapter06/readline.xml |5 + BOOK/chapter06/sed.xml |5 + BOOK/chapter06/shadow.xml|5 + BOOK/chapter06/sysklogd.xml |5 + BOOK/chapter06/sysvinit.xml |5 + BOOK/chapter06/tar.xml |5 + BOOK/chapter06/texinfo.xml |5 + BOOK/chapter06/udev.xml |5 + BOOK/chapter06/util-linux.xml|5 + BOOK/chapter06/vim.xml |5 + BOOK/chapter06/zlib.xml |5 + BOOK/chapter08/kernel.xml|5
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Ken Moffat wrote: all those nice 64 binary packages - I suppose that means nvidia or ati kernel modules ? I don't know of anything else that comes as 64-bit without source. I know a few people use Opera too. I personally use a binary JDK if I need java. If someone wanted to use a binary firefox / seamonkey / thunderbird they'd fall in that group. It is definitaly a small group of people that would need that functionality, but it still exists. -- 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: but I figured I'd show what I have and give someone else the opportunity to build it if they like and/or look for any obvious errors. It appears you haven't allowed for a surprising gotcha that means GCC-Pass2 will search for libs on the host thus rendering the build method ineffective. This (and the fix) is all documented in the DIY Refbuild. More info here: http://www.diy-linux.org/pipermail/diy-linux-dev/2006-September/000871.html 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: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On 7/20/07, Joe Ciccone [EMAIL PROTECTED] wrote: Dan Nicholson wrote: The 1.9.x versions, too? I'll have to check on the more recent versions. I know that 1.9.2 (the last time I tried) still needed a 32bit glibc. I don't have a pure64 build around but I think the new one (1.9.5) may work. grub2 is a completely different beast then grub legacy. Still no documentation. Well, I had a look at the 1.9.5 version, and it looks like configure is forcing 32bit for target_cpu=x86_64. So, I'd say probably not. http://cvs.savannah.gnu.org/viewvc/grub2/configure.ac?root=grubview=markup -- Dan -- 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: ...)
On Fri, Jul 20, 2007 at 07:10:59PM -0400, Joe Ciccone wrote: Ken Moffat wrote: all those nice 64 binary packages - I suppose that means nvidia or ati kernel modules ? I don't know of anything else that comes as 64-bit without source. I know a few people use Opera too. I personally use a binary JDK if I need java. If someone wanted to use a binary firefox / seamonkey / thunderbird they'd fall in that group. It is definitaly a small group of people that would need that functionality, but it still exists. I'll give you java, so I have to accept there are binary 64-bit applications. But I can't find any 64-bit binaries for firefox or opera. ĸ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
[PATCH] Add screen install attributes for final system packages
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.
This allows a really simple stylesheet to be created so that interesting
things can be done. For instance, I created a paco stylesheet to wrap the
install commands like so:
paco -lp+ ${package}-${version}
make install
Combined with the previous patch to export the package name and version
number, LFS is practically ready for a package manager and it required
no additional hacks.
Any objections? Again, there was no diff in the HTML. There might still
be interest in deciding what are install actions and what aren't, but
that's a separate discussion.
--
Dan
BOOK/chapter06/autoconf.xml |2 +-
BOOK/chapter06/automake.xml |2 +-
BOOK/chapter06/bash.xml |2 +-
BOOK/chapter06/binutils.xml |4 ++--
BOOK/chapter06/bison.xml |2 +-
BOOK/chapter06/bzip2.xml |4 ++--
BOOK/chapter06/coreutils.xml |6 +++---
BOOK/chapter06/db.xml|4 ++--
BOOK/chapter06/diffutils.xml |2 +-
BOOK/chapter06/e2fsprogs.xml |4 ++--
BOOK/chapter06/file.xml |2 +-
BOOK/chapter06/findutils.xml |4 ++--
BOOK/chapter06/flex.xml |6 +++---
BOOK/chapter06/gawk.xml |2 +-
BOOK/chapter06/gcc.xml |6 +++---
BOOK/chapter06/gettext.xml |2 +-
BOOK/chapter06/glibc.xml | 14 +++---
BOOK/chapter06/grep.xml |2 +-
BOOK/chapter06/groff.xml |4 ++--
BOOK/chapter06/grub.xml |2 +-
BOOK/chapter06/gzip.xml |4 ++--
BOOK/chapter06/iana-etc.xml |2 +-
BOOK/chapter06/inetutils.xml |4 ++--
BOOK/chapter06/iproute2.xml |4 ++--
BOOK/chapter06/kbd.xml |4 ++--
BOOK/chapter06/less.xml |2 +-
BOOK/chapter06/libtool.xml |2 +-
BOOK/chapter06/linux-headers.xml |2 +-
BOOK/chapter06/m4.xml|2 +-
BOOK/chapter06/make.xml |2 +-
BOOK/chapter06/man-db.xml|4 ++--
BOOK/chapter06/man-pages.xml |2 +-
BOOK/chapter06/mktemp.xml|2 +-
BOOK/chapter06/module-init-tools.xml |2 +-
BOOK/chapter06/ncurses.xml | 14 +++---
BOOK/chapter06/patch.xml |2 +-
BOOK/chapter06/perl.xml |2 +-
BOOK/chapter06/procps.xml|2 +-
BOOK/chapter06/psmisc.xml|6 +++---
BOOK/chapter06/readline.xml |6 +++---
BOOK/chapter06/sed.xml |2 +-
BOOK/chapter06/shadow.xml|8
BOOK/chapter06/sysklogd.xml |4 ++--
BOOK/chapter06/sysvinit.xml |4 ++--
BOOK/chapter06/tar.xml |2 +-
BOOK/chapter06/texinfo.xml |4 ++--
BOOK/chapter06/udev.xml | 12 ++--
BOOK/chapter06/util-linux.xml|2 +-
BOOK/chapter06/vim.xml |8
BOOK/chapter06/zlib.xml |8
BOOK/chapter08/kernel.xml| 10 +-
BOOK/stylesheets/dump-commands.xsl |2 +-
52 files changed, 106 insertions(+), 106 deletions(-)
diff --git a/BOOK/chapter06/autoconf.xml b/BOOK/chapter06/autoconf.xml
index b85fd8b..fb4d980 100644
--- a/BOOK/chapter06/autoconf.xml
+++ b/BOOK/chapter06/autoconf.xml
@@ -56,7 +56,7 @@
paraInstall the package:/para
-screenuserinputmake install/userinput/screen
+screen userlevel=installuserinputmake install/userinput/screen
/sect2
diff --git a/BOOK/chapter06/automake.xml b/BOOK/chapter06/automake.xml
index 2ede092..6204a59 100644
--- a/BOOK/chapter06/automake.xml
+++ b/BOOK/chapter06/automake.xml
@@ -54,7 +54,7 @@
paraInstall the package:/para
-screenuserinputmake install/userinput/screen
+screen userlevel=installuserinputmake install/userinput/screen
/sect2
diff --git a/BOOK/chapter06/bash.xml b/BOOK/chapter06/bash.xml
index e9b69e9..721029b 100644
--- a/BOOK/chapter06/bash.xml
+++ b/BOOK/chapter06/bash.xml
@@ -92,7 +92,7 @@ chown -Rv nobody .//userinput/screen
paraInstall the package:/para
-screenuserinputmake install/userinput/screen
+screen userlevel=installuserinputmake install/userinput/screen
paraRun the newly compiled commandbash/command program (replacing
the one that is
currently being executed):/para
diff --git a/BOOK/chapter06/binutils.xml b/BOOK/chapter06/binutils.xml
index bc86ff3..3925219 100644
--- a/BOOK/chapter06/binutils.xml
+++ b/BOOK/chapter06/binutils.xml
@@ -103,12 +103,12 @@ cd ../binutils-build/userinput/screen
Re: [PATCH] Add screen install attributes for final system packages
Dan Nicholson wrote:
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.
This allows a really simple stylesheet to be created so that interesting
things can be done. For instance, I created a paco stylesheet to wrap the
install commands like so:
paco -lp+ ${package}-${version}
make install
Combined with the previous patch to export the package name and version
number, LFS is practically ready for a package manager and it required
no additional hacks.
Any objections? Again, there was no diff in the HTML. There might still
be interest in deciding what are install actions and what aren't, but
that's a separate discussion.
These additions are benign and will have no impact on older versions
of jhalfs (2.2 or less). During the last quarter of 2006 similar changes
were discussed for jhalfs-3.0 but it died from lack of interest.
--
Dan
--
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: ...)
Ken Moffat wrote: I'll give you java, so I have to accept there are binary 64-bit applications. But I can't find any 64-bit binaries for firefox or opera. I could have sworn they existed but I just checked and couldn't find them either. So strike two more off the list. That still leaves java. Which is a major one. -- 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: ...)
- Original Message -
From: Jeremy Huntwork [EMAIL PROTECTED]
To: LFS Developers Mailinglist lfs-dev@linuxfromscratch.org
Sent: Friday, July 20, 2007 10:54 PM
Subject: Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Indeed. I meant to drop something in, but forgot about it. bin86/lilo
would probably be alright. Anyone tried grub2?
Hello.
Grub-0.9x is old Grub legacy and no-more maintained.
Grub-1.x is new one (latest I tried was 1.95, release 2006-10-15) but
it's still experimental and doesn't support all file-systems features
(xfs btrees aren't supported as example) but it will support much
file-systems than old one; I tried it only x86 but there was a similar
discussion in Debian for x86-64 arch support.
Supported archs are: PC (i386), Mac (powerpc), Pegasos II (powerpc),
Sparc v9 (Sun UltraSparc) - under development, Mac (i386) - under
development.
Supported file-systems: ext2, fat (+ long filenames), ufs (versions 1
and 2), minix (versions 1 and 2), iso9660 (plus rockridge extensions),
jfs, hfs, affs, sfs, xfs (no btrees).
Supported loaders: PC (chainloader, linux, multiboot), Mac (linux).
Terminals: PC (VGA framebuffer, textmode, VESA framebuffer - in
progress), PPC UltraSparc ( ANSI - Open Firmware).
Partition maps: standard pc and extended partitions, BSD partitions,
Macintosh partitions, Amiga style partitions (RDB), Sun partitions, GPT
(used by EFI).
Features: memory management, module loading, font support (framebuffer
only), grub-emu (testing/debugging), argument parsing interface,
rescue/normal mode, variable support, compression support, command
history/tab completion (normal mode), scripting.
Anyway you can find more on the GRUB Wiki - http://grub.enbug.org/ -
under GRUB 2.
Regards,
Luca
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
