Re: Use of Entities in the cross-lfs book
El Martes, 21 de Junio de 2005 01:56, Archaic escribió: A hybrid of something like BLFS does might be nice. However, I don't like the idea of having package-specific entities spread across multiple files. Here's an idea for a packages.ent (or even left in general.ent) file: To place entities on the files headers isn't a good idea for LFS, IMHO. I think that Jim is proposing that new packages.ent to can do packages updates, when no commands changes are needed, editing only the *.ent and changelog files. !-- Package 1 -- !ENTITY package-version 2.59 !ENTITY package-size 2.3 MB !ENTITY package-url http://url/to/package/official/download; !ENTITY package-buildsize-x86 81 MB !ENTITY package-buildsize-ppc 81 MB !ENTITY package-buildsize-x86_64 81 MB !ENTITY package-buildsize-mips 81 MB !ENTITY package-buildsize-sparc 81 MB Some packages, like Glibc and GCC, will require several blocks like that, one for each time that the package is builded. !ENTITY package-time-x86 0.3 SBU !ENTITY package-time-ppc 0.3 SBU !ENTITY package-time-x86_64 0.3 SBU !ENTITY package-time-mips 0.3 SBU !ENTITY package-time-sparc 0.3 SBU The same here, if want SBUs for pre-final-system packages. !ENTITY package-patch_name-patch package-package-version;-foo-1.patch Not sure about this. I see more easy to handle patches agrupped by arch, like they are currently in patches.ent. Also, we don't need to declare the new packages.ent file on each XML file. Is enouch declaring it in general.ent (the same is valid for patches.ent). In general that look like a good idea. Could do more easy simple packages updates. -- 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.com 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: Use of Entities in the cross-lfs book
SBU's are going to be invalid up to chapter 9, chapter 9 will be the first chapter that we could provide SBU information. My plan for packages.ent was something simliar to what archaic was suggesting !-- Package 1 -- !ENTITY package-version 2.59 !ENTITY package-size 2.3 MB !ENTITY package-url http://url/to/package/official/download; !ENTITY package-buildsize 81 MB !ENTITY package-time 0.3 SBU The one thing I'm not sure on is if the SBU's will be the same on the different architectures, as far as the build size goes, it should be the same except for one package which is gcc, since we have a 32bit ABI build, 32/64 ABI build, and 32/n32/64 ABI build. But these are things I'm trying to find out at this time. I have a script that I have been working on that will calculate the build disk usage. So far they are all within a few K of each other, but I need others to validate the findings, once I feel the scripts are working properly. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Use of Entities in the cross-lfs book
M.Canales.es wrote: El Martes, 21 de Junio de 2005 21:42, Jim Gifford escribió: SBU's are going to be invalid up to chapter 9, chapter 9 will be the first chapter that we could provide SBU information. I agree. That meant that SBUs could be removed in other chapters, true? My plan for packages.ent was something simliar to what archaic was suggesting !-- Package 1 -- !ENTITY package-version 2.59 !ENTITY package-size 2.3 MB !ENTITY package-url http://url/to/package/official/download; !ENTITY package-buildsize 81 MB !ENTITY package-time 0.3 SBU The one thing I'm not sure on is if the SBU's will be the same on the different architectures, I we can to use the same SBU and build size on al archs that would be great. IMHO a desviation 5 % (or maybe 10%) could be acceptable for both, SBUs and build sizes. Sounds good to me, but I will defer to Matt to say if it's ok. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Use of Entities in the cross-lfs book
On Tue, 21 Jun 2005, Jim Gifford wrote: The one thing I'm not sure on is if the SBU's will be the same on the different architectures, as far as the build size goes, it should be the same except for one package which is gcc, since we have a 32bit ABI build, 32/64 ABI build, and 32/n32/64 ABI build. My guess is that outside the toolchain, SBUs will be broadly in line, partly because many packages fall into the minimum SBU is 0.1. However, that is ignoring the time to run test suites (yes, I realise cross-lfs cannot run test suites in what we now call chapter 5) which seems to be the new consensus (and in practice, it's often the test suites which take the time, both in LFS and BLFS). In the toolchain, I expect everything to vary greatly (e.g. I assume a multilib binutils creates a library to process both architectures, so I expect it to take longer). But these are things I'm trying to find out at this time. I have a script that I have been working on that will calculate the build disk usage. So far they are all within a few K of each other, but I need others to validate the findings, once I feel the scripts are working properly. Ah, more joy of scripts ;) I deviate by symlinking /etc/mtab to proc for chroot, then it's just repeatedly df -k with a grep for something identifying the relevant filesystem (/mnt/lfs, rootfs, whatever), and repeat before the untarring, after installing, and after cleaning up. Of course, any logs had better be on a different fs (mount --bind) and I think cross-lfs builds host tools in ~/ which doesn't always lend itself to accurate space calculations in a running system. (growing logs if /home is on same fs as /, or just general output from users/processes) Fun! I'll surprised if glibc sizes are similar for many different architectures. Going back as far as LFS-5.0, glibc on ppc (32) always used to be considerably bigger than the x86 figures in the book, because all ppc instructions are the same length. Is/are the cross-lfs book(s) being regularly rendered in html yet ? I'm on a trial run of (LFS-6.1/BLFS-6) x86_64 blfs at the moment following a very broken hack on Ryan's scripts, but I expect to have another go at building x86_64 from i686 next week. At the moment I'm in the infinite number of monkeys with typewriters stage, but one day I might crack it. Ken -- 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: Use of Entities in the cross-lfs book
Ken Moffat wrote: On Tue, 21 Jun 2005, Jim Gifford wrote: The one thing I'm not sure on is if the SBU's will be the same on the different architectures, as far as the build size goes, it should be the same except for one package which is gcc, since we have a 32bit ABI build, 32/64 ABI build, and 32/n32/64 ABI build. My guess is that outside the toolchain, SBUs will be broadly in line, partly because many packages fall into the minimum SBU is 0.1. However, that is ignoring the time to run test suites (yes, I realise cross-lfs cannot run test suites in what we now call chapter 5) which seems to be the new consensus (and in practice, it's often the test suites which take the time, both in LFS and BLFS). In the toolchain, I expect everything to vary greatly (e.g. I assume a multilib binutils creates a library to process both architectures, so I expect it to take longer). But these are things I'm trying to find out at this time. I have a script that I have been working on that will calculate the build disk usage. So far they are all within a few K of each other, but I need others to validate the findings, once I feel the scripts are working properly. Ah, more joy of scripts ;) I deviate by symlinking /etc/mtab to proc for chroot, then it's just repeatedly df -k with a grep for something identifying the relevant filesystem (/mnt/lfs, rootfs, whatever), and repeat before the untarring, after installing, and after cleaning up. Of course, any logs had better be on a different fs (mount --bind) and I think cross-lfs builds host tools in ~/ which doesn't always lend itself to accurate space calculations in a running system. (growing logs if /home is on same fs as /, or just general output from users/processes) Fun! I'll surprised if glibc sizes are similar for many different architectures. Going back as far as LFS-5.0, glibc on ppc (32) always used to be considerably bigger than the x86 figures in the book, because all ppc instructions are the same length. Is/are the cross-lfs book(s) being regularly rendered in html yet ? I'm on a trial run of (LFS-6.1/BLFS-6) x86_64 blfs at the moment following a very broken hack on Ryan's scripts, but I expect to have another go at building x86_64 from i686 next week. At the moment I'm in the infinite number of monkeys with typewriters stage, but one day I might crack it. Ken Ken, It's not rendered on lfs.org yet, we are going to set it up one of these days. A couple of us have it rendered http://documents.jg555.com/cross-lfs http://www.linuxfromscratch.org/~jhuntwork/cross-lfs -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Use of Entities in the cross-lfs book
On Tue, Jun 21, 2005 at 08:21:27PM +0200, M.Canales.es wrote: To place entities on the files headers isn't a good idea for LFS, IMHO. Please explain what is not good about having all package-specific entities in one place. I think that Jim is proposing that new packages.ent to can do packages updates, when no commands changes are needed, editing only the *.ent and changelog files. Same thing happens here. I proposed they all go into either packages.ent or general.ent. Either way, the actual instructions xml won't have to be touched. Some packages, like Glibc and GCC, will require several blocks like that, one for each time that the package is builded. And those same blocks would be required whether or not the entity is defined here or in the package's main xml page. This way centralizes things and seems to allow for easier editing. !ENTITY package-patch_name-patch package-package-version;-foo-1.patch Not sure about this. I see more easy to handle patches agrupped by arch, like they are currently in patches.ent. I'm not overly committed to the grouping scheme, so perhaps they should be grouped separately. Also, we don't need to declare the new packages.ent file on each XML file. Is enouch declaring it in general.ent (the same is valid for patches.ent). I'm not sure where that came from since I didn't suggest it. In general that look like a good idea. Could do more easy simple packages updates. That's the hope, anyway. :) -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Use of Entities in the cross-lfs book
El Martes, 21 de Junio de 2005 22:49, Archaic escribió: On Tue, Jun 21, 2005 at 08:21:27PM +0200, M.Canales.es wrote: To place entities on the files headers isn't a good idea for LFS, IMHO. Please explain what is not good about having all package-specific entities in one place. To place entities on the files headers (in the XML headers, like in BLFS) isn't a good idea for LFS. More clear now? Also, we don't need to declare the new packages.ent file on each XML file. Is enouch declaring it in general.ent (the same is valid for patches.ent). I'm not sure where that came from since I didn't suggest it. Is a comment for when that entities changes will be implemented. If a package.ent file is created, we can declare it in general.ent instead on each XML file (like was done for patches.ent). -- 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.com 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: Use of Entities in the cross-lfs book
On Tue, Jun 21, 2005 at 11:00:52PM +0200, M.Canales.es wrote: More clear now? Ah, yes. I had said a hybrid of BLFS and also suggested putting those entities in one file. I agree that putting them in individual package pages would be a bad thing. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Use of Entities in the cross-lfs book
Hey all, I was just thinking about making use of some more entities in the cross-lfs book. 1 - File Sizes for the Downloads and Patches, for packages it would be in general.ent(I would like to move the packages to packages.ent, also if everyone agree's, and leave general.ent to just the general stuff}, and for patches they would be in patches.ent. 2 - Disk Space Usage, this also depends on how we decide to do this, if we take all architectures and do them individually or just use a a standard of i686 building a i686. 3 - SBU's for the Chapters 10 and above, since the chapters below 10 are build on a different machine since the SBU's will be different on the host than the target. Thanx for listening -- Jim Gifford [EMAIL PROTECTED] [EMAIL PROTECTED] -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Use of Entities in the cross-lfs book
On Mon, Jun 20, 2005 at 04:09:48PM -0700, Jim Gifford wrote: .. A hybrid of something like BLFS does might be nice. However, I don't like the idea of having package-specific entities spread across multiple files. Here's an idea for a packages.ent (or even left in general.ent) file: !-- Package 1 -- !ENTITY package-version 2.59 !ENTITY package-size 2.3 MB !ENTITY package-buildsize-x86 81 MB !ENTITY package-buildsize-ppc 81 MB !ENTITY package-buildsize-x86_64 81 MB !ENTITY package-buildsize-mips 81 MB !ENTITY package-buildsize-sparc 81 MB !ENTITY package-time-x86 0.3 SBU !ENTITY package-time-ppc 0.3 SBU !ENTITY package-time-x86_64 0.3 SBU !ENTITY package-time-mips 0.3 SBU !ENTITY package-time-sparc 0.3 SBU !ENTITY package-patch_name-patch package-package-version;-foo-1.patch !-- Package 2 -- !ENTITY package2-version 2.59 !ENTITY package2-size 2.3 MB !ENTITY package2-buildsize-x86 81 MB !ENTITY package2-buildsize-ppc 81 MB !ENTITY package2-buildsize-x86_64 81 MB !ENTITY package2-buildsize-mips 81 MB !ENTITY package2-buildsize-sparc 81 MB !ENTITY package2-time-x86 0.3 SBU !ENTITY package2-time-ppc 0.3 SBU !ENTITY package2-time-x86_64 0.3 SBU !ENTITY package2-time-mips 0.3 SBU !ENTITY package2-time-sparc 0.3 SBU !ENTITY package2-patch_name-patch package2-package-version;-bar-1.patch -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
