Re: 7.0 Goals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 TheOldFellow wrote: On Thu, 30 Aug 2007 11:14:37 -0700 Dan Nicholson [EMAIL PROTECTED] wrote: Now that 6.3 is finally done, I wanted to think about things that could be done for the 7.0 release. These are in addition to the normal updates/bug fixes/etc. snip * LSB bootscripts - I'd like to shed the current custom bootscripts and move to the standardized LSB style. The advantages (to me) are standardization, removal of crufty custom functions and entry points in our current implementation, and managed service levels (dependencies in the script header mean you don't have to guess run numbers). snip Just remember that there are a few of us who don't use sysvinit, and don't want complex bad-standard (LSB) bootscripts. I want my system up, fast, accepting login, and then all the other cruft (networking for instance) can start while I'm typing my secure password :) R. SSHH!! don't be mean about the loco standard boo-boo. After all a BASE standard is required, to bad the FSF's LSB group went about 10 billion light years beyond a base standard. [ when they started specifying applications they left a base standard behind. ie: should have a package manager, not MUST HAVE RPM SUPPORT. ] about the only part of LSB I'll implement is the file-system hierarchy, the rest is to far beyond a base standard to be usable as such. Jaqui -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG18z+ylMakk+oQ1oRAvMrAJ44m0VzLU0I8n5OVhX4pFFSp772lACfae9P qcIXXl88kVOoCq8ssDW0CkM= =42Ff -END PGP SIGNATURE- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 7.0 Goals
On Thu, Aug 30, 2007 at 08:52:11PM -0600, Jeremy Huntwork wrote: Relax. I would have thought that my previous post showed that I don't intend to leave it as it is, but I wanted to foster discussion on what it should be. I've gone ahead and added '--disable-bootstrap' to GCC pass 2 and final GCC. This, at least, puts us in the same setup as with previous versions of GCC and should make the merge of the jh branch to trunk a less radical one. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Merging the jh branch
Hello, People have been mostly quiet on the matter, so I'm assuming that everyone's okay with the idea of merging the jh branch to trunk. I will wait just a little bit longer, however, for comments. Anyway, I want to fix up the 'Making the LFS System Bootable' section before I merge so that there aren't any 'regressions'. Right now the section is written up with only Grub legacy in mind. I'm thinking to change the whole section so that a user can choose between Grub legacy, Grub 2 or lilo/bin86. Any suggestions on how to proceed? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Released jhalfs-2.3.1
El Viernes, 31 de Agosto de 2007 15:27, sacarde escribió: Alle venerdì 31 agosto 2007, sacarde ha scritto: can you suggest me a way to re-initialize jhalfs in blfs step after a building stop in previus release ? Please, use the alfs-discuss list for that typo of questions, thanks. -- 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/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Merging the jh branch to trunk
Hi guys,
I've been thinking of how best to get the work that Jeremy's done into trunk.
I think what I'd prefer to see is the package upgrades handled separately from
the 64-bit related changes. That way, I'm hoping it'll be clearer what each
change entails. As such, I've started working on a quilt-series of patches
that aim at closing off the package version bump related tickets in Trac, but
are based heavily on Jeremy's work.
For example, to upgrade to Glibc-2.6.1, my patch touches packages.ent,
chapter01/{changelog,whatsnew}.xml as usual. It also touches
chapter0{5,6}/{coreutils,gzip}.xml to fix the futimens issue and
chapter05/gcc-pass2.xml and chapter06/gcc.xml to use --with-arch=i486 so that
Glibc compiles on my x86 box.
My gcc patch would bump the versions, and change the specs patch to the sed,
and add the --disable-bootstrap switch. It wouldn't, however, add the
--disable-multilib or other multi-arch/64-bit features. These would be brought
along in separate commits so they can easily be backed out without having to
revert the version bump as well.
Does this sound sane to everyone? If so, I'll endeavour to complete the patch
series as soon as possible and post it here for review.
Thanks,
Matt.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Merging the jh branch to trunk
On Fri, Aug 31, 2007 at 11:40:30AM -0600, Matthew Burgess wrote: Does this sound sane to everyone? If so, I'll endeavour to complete the patch series as soon as possible and post it here for review. Yes, that sounds reasonable. Perhaps by the time you're ready to do the x86_64 bits, we can have had the boot loader issues ready for integration. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Merging the jh branch to trunk
On 8/31/07, Matthew Burgess [EMAIL PROTECTED] wrote: Does this sound sane to everyone? If so, I'll endeavour to complete the patch series as soon as possible and post it here for review. Very sane, and I applaud your efforts to keep the diffs nice and clean instead of dropping a patchbomb on trunk. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Merging the jh branch
On Fri, 31 Aug 2007 11:19:14 -0600, Jeremy Huntwork [EMAIL PROTECTED] wrote: Any suggestions on how to proceed? Doh, looks like our emails crossed (admittedly, I was supposed to hit 'save to drafts' instead of 'send' so I could check for new messages before sending mine, but obviously hit the wrong button!). Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Merging the jh branch to trunk
On Fri, Aug 31, 2007 at 11:40:30AM -0600, Matthew Burgess wrote: Does this sound sane to everyone? If so, I'll endeavour to complete the patch series as soon as possible and post it here for review. Actually, this is good that you're doing it this way. I just noticed something that I'm surprised I didn't notice before. On the GCC pages the uname test will fail for x86. When I ran tested the build on x86, I did so manually and used slightly different commands, so I never noticed that 'case $(uname -m)' would never match 'x86'. Going to fix that up momentarily. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Merging the jh branch to trunk
Matthew Burgess wrote:
Hi guys,
I've been thinking of how best to get the work that Jeremy's done
into trunk. I think what I'd prefer to see is the package upgrades
handled separately from the 64-bit related changes. That way, I'm
hoping it'll be clearer what each change entails. As such, I've
started working on a quilt-series of patches that aim at closing off
the package version bump related tickets in Trac, but are based
heavily on Jeremy's work.
For example, to upgrade to Glibc-2.6.1, my patch touches
packages.ent, chapter01/{changelog,whatsnew}.xml as usual. It also
touches chapter0{5,6}/{coreutils,gzip}.xml to fix the futimens issue
and chapter05/gcc-pass2.xml and chapter06/gcc.xml to use
--with-arch=i486 so that Glibc compiles on my x86 box.
My gcc patch would bump the versions, and change the specs patch to
the sed, and add the --disable-bootstrap switch. It wouldn't,
however, add the --disable-multilib or other multi-arch/64-bit
features. These would be brought along in separate commits so they
can easily be backed out without having to revert the version bump as
well.
Does this sound sane to everyone? If so, I'll endeavour to complete
the patch series as soon as possible and post it here for review.
That makes sense to me, but I have other issues.
Before the jh branch is merged, there needs to be some textual changes
to describe what we are trying to do. The issues of advantages/
disadvantages of 64-bit vs 32-bit systems needs to be discussed.
Perhaps the best place may be in section 1.2 What's new since the last
release or perhaps earlier.
The section iv. Host System Requirements probably needs to be expanded
too.
I'd like to see the question answered. I have a 64-bit system. How
can I build a 32-bit system?
There also needs to be more explanation in the text interspersed with
the instructions. For instance in 5.4. GCC-4.2.1 - Pass 1 we have:
Also, the --with-arch flag is only necessary for x86 machines.
The WITHARCH variable seems to be a configure option, but I can't find
it in ./configure --help or with a grep of configure. In any case, I
have Pentium 4 CPU. Why do I want to use --with-arch=i486 instead of
--with-arch=pentium4.
The M64 variable on the other hand is a gcc compiler option. Why are we
using -m64 for 64 bit architectures? The info page says that is a
deprecated option.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Remove perl libc patch?
Hi,
We could conceivably remove the perl libc patch by using the following
commands:
cp -v hints/linux.sh{,.orig}
sed 's:/lib/\$\?libc:${prefix}:' hints/linux.sh.orig hints/linux.sh
echo 'locincpth=
loclibpth=
glibpth=${prefix}/lib
usrinc=${prefix}/include' hints/linux.sh
It's just a suggestion. I prefer not to use patches for items that are
easy adjustements from the command line and that are for changes due to
our build method. Of course, it's obviously more typing, so I can also
understand why others may prefer the patch.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Merging the jh branch to trunk
On Fri, Aug 31, 2007 at 04:54:50PM -0500, Bruce Dubbs wrote: I'd like to see the question answered. I have a 64-bit system. How can I build a 32-bit system? Well, that's an easy answer. Boot a x86 (or 32-bit) kernel and build for x86. The default on the x86 LiveCD works perfectly. There also needs to be more explanation in the text interspersed with the instructions. For instance in 5.4. GCC-4.2.1 - Pass 1 we have: Also, the --with-arch flag is only necessary for x86 machines. The WITHARCH variable seems to be a configure option, but I can't find it in ./configure --help or with a grep of configure. In any case, I have Pentium 4 CPU. Why do I want to use --with-arch=i486 instead of --with-arch=pentium4. The top-level configure doesn't make use of it, but the value is carried over to the sub-configure scripts which do use it. Although, from a cursory examination, it doesn't seem to be used specifically for x86 machines. I'll have to look closer, but I know from experience that it allows Glibc to build whereas it wouldn't before. In any case, yes, there needs to be more description here. I admit I was lazy on that - I was more interested at the time in getting the commands tested. As Greg mentioned, by using --with-arch, we are effectively introducing optimization into the build. Much text in the book needs to be adjusted to show why we are using this and what is considered 'safe'. Also, AFAIK, you could conceivably use pentium4, or whatever fits your CPU - again, it's optimization. The M64 variable on the other hand is a gcc compiler option. Why are we using -m64 for 64 bit architectures? The info page says that is a deprecated option. Hrm? The man page for gcc 4.2.1 still lists it under 'i386 and x86-64 Options' And then it says: The 64-bit environment sets int to 32 bits and long and pointer to 64 bits and generates code for AMD's x86-64 architecture. Perhaps you were looking under the wrong architecture? Anyway, we use it twice, once for binutils pass 1 and once for gcc pass 1. In each case, the idea is that it forces the compiler to build 64-bit binaries in case it is a multilib system and the default is set to build 32-bit binaries. Since we're currently not supporting the build of a multilib LFS, we want to produce 64-bit only. Once we build a 64-bit ld and a 64-bit gcc, we will by default be producing 64 bit. For most 64-bit hosts, the default is to build 64-bit, so for most cases the use of '-m64' isn't even necessary for those two cases. But it can't hurt to be explicit until we know for sure what we're producing. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Merging the jh branch to trunk
Jeremy Huntwork wrote: On Fri, Aug 31, 2007 at 04:54:50PM -0500, Bruce Dubbs wrote: I'd like to see the question answered. I have a 64-bit system. How can I build a 32-bit system? Well, that's an easy answer. Boot a x86 (or 32-bit) kernel and build for x86. The default on the x86 LiveCD works perfectly. There also needs to be more explanation in the text interspersed with the instructions. For instance in 5.4. GCC-4.2.1 - Pass 1 we have: Also, the --with-arch flag is only necessary for x86 machines. The WITHARCH variable seems to be a configure option, but I can't find it in ./configure --help or with a grep of configure. In any case, I have Pentium 4 CPU. Why do I want to use --with-arch=i486 instead of --with-arch=pentium4. The top-level configure doesn't make use of it, but the value is carried over to the sub-configure scripts which do use it. Although, from a cursory examination, it doesn't seem to be used specifically for x86 machines. I'll have to look closer, but I know from experience that it allows Glibc to build whereas it wouldn't before. In any case, yes, there needs to be more description here. I admit I was lazy on that - I was more interested at the time in getting the commands tested. As Greg mentioned, by using --with-arch, we are effectively introducing optimization into the build. Much text in the book needs to be adjusted to show why we are using this and what is considered 'safe'. Also, AFAIK, you could conceivably use pentium4, or whatever fits your CPU - again, it's optimization. The M64 variable on the other hand is a gcc compiler option. Why are we using -m64 for 64 bit architectures? The info page says that is a deprecated option. Hrm? The man page for gcc 4.2.1 still lists it under 'i386 and x86-64 Options' And then it says: The 64-bit environment sets int to 32 bits and long and pointer to 64 bits and generates code for AMD's x86-64 architecture. Perhaps you were looking under the wrong architecture? My mistake. It is the -mcpu, -m386, -m486, etc that are deprecated. Anyway, we use it twice, once for binutils pass 1 and once for gcc pass 1. In each case, the idea is that it forces the compiler to build 64-bit binaries in case it is a multilib system and the default is set to build 32-bit binaries. Since we're currently not supporting the build of a multilib LFS, we want to produce 64-bit only. Once we build a 64-bit ld and a 64-bit gcc, we will by default be producing 64 bit. For most 64-bit hosts, the default is to build 64-bit, so for most cases the use of '-m64' isn't even necessary for those two cases. But it can't hurt to be explicit until we know for sure what we're producing. These are generally good answers. My biggest point was to make sure the text is updated in the branch (it doesn't have to be perfect, we can tweak later) before the merge to trunk is made. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
