Re: Summary: Debian Lenny as host
Randy McMurchy wrote: > Jeremy Huntwork wrote: > >> Well, at least I'm learning something. :/ Looks like I need to change >> some of my work/test habits so that I don't keep tripping over what >> should be simple stuff. > > And because the LFS staff working on this is only you, and > I've read many things (Greg's comments) that disagree with > your analysis, I'd sure like more discussion before any of > this is committed. > > Please Jeremy, get community approval before anything is > committed. > Randy, Jeremy did start a thread "Merging the jh branch to trunk" on the 31st to discuss just that issue. I haven't been contributing much, but I've been following along. The discussion has been quite good and very professional. The progress has been very good and I don't think anyone is going to be surprised by unanticipated commits. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On Sun, Sep 02, 2007 at 11:15:25PM -0500, Randy McMurchy wrote: > And because the LFS staff working on this is only you, and > I've read many things (Greg's comments) that disagree with > your analysis, I'd sure like more discussion before any of > this is committed. Most of what is currently in the jh branch agrees with what Greg has suggested. If you had really been paying close attention to the development, you would have seen the evolution that the branch has taken largely due to these very discussions. In fact the only thing that I can think of that is currently not in harmony with his many comments is the -m64 bits, which will now be removed thanks to the further disussion that occurred in this thread. > Please Jeremy, get community approval before anything is > committed. You sound unnecessarily worried. Have you not seen my repeated requests for comments and noticed that I had been deliberately keeping all of these items in a separate branch, waiting for community approval?\ The whole point for the branch was that I would be able to work with some new concepts in a _publicly_viewable_ and therefore _easily_discussed_ arena without altering trunk. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
Jeremy Huntwork wrote: > Well, at least I'm learning something. :/ Looks like I need to change > some of my work/test habits so that I don't keep tripping over what > should be simple stuff. And because the LFS staff working on this is only you, and I've read many things (Greg's comments) that disagree with your analysis, I'd sure like more discussion before any of this is committed. Please Jeremy, get community approval before anything is committed. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On Sun, Sep 02, 2007 at 08:04:47PM -0600, Jeremy Huntwork wrote: > Yes, that is true. I need to set up another test case, mostly just to > satisfy myself on this issue. And it seems you're correct. Without -m64, the 32-bit ld and gcc produced in pass 1 generate 64-bit code by default. I guess that's because the host is x86_64-unknown-linux-gnu and we've disabled multilib in the said compiler and linker. I suppose what confused me there is that the default (shown in the specs file) for the host is 32-bit even though it is multilib. Well, at least I'm learning something. :/ Looks like I need to change some of my work/test habits so that I don't keep tripping over what should be simple stuff. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On Mon, Sep 03, 2007 at 11:26:13AM +1000, Greg Schafer wrote: > It's irrelevant if they happen to be > 32-bit binaries. What *is* relevant is whether they produce 64-bit code or > not. Yes, that is true. I need to set up another test case, mostly just to satisfy myself on this issue. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
Jeremy Huntwork wrote: > On Fri, Aug 31, 2007 at 08:11:22AM +1000, Greg Schafer wrote: >> PS - This addition seems like overkill as most multilib setups default to >> m64. It appears Jeremy is catering to those "unsupportable with current >> build method" non-standard 32/64-bit setups such as Alex's Debian Lenny >> example. > > Yes, it was added originally to cover that scenario, but I'm no longer > "catering" to that host. > > When it came time to commit a few necessary changes today, I decided to > leave it in since it will always force binutils and gcc to build 64-bit on > pass1. As you say it is probably unnecessary even there, but at least by > including it, we know without doubt that we're getting 64-bit, even on > multilib hosts. Thereafter, of course, it isn't necessary at all since > we'll be using our 64-bit only compiler. > > If you think it's better to leave it out entirely, please explain why. Because it's *COMPLETELY* unnecessary. There is absolutely no need at all to force the pass1's to be 64-bit. It's irrelevant if they happen to be 32-bit binaries. What *is* relevant is whether they produce 64-bit code or not. Please see my other posting where I solved the Debian Lenny issue. My build worked perfectly even though binutils-pass1 and the stage1 gcc were themselves compiled as 32-bit binaries. The critical thing is the `target': checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking build system type... x86_64-unknown-linux-gnu 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: Summary: Debian Lenny as host
On Fri, Aug 31, 2007 at 08:11:22AM +1000, Greg Schafer wrote: > PS - This addition seems like overkill as most multilib setups default to > m64. It appears Jeremy is catering to those "unsupportable with current > build method" non-standard 32/64-bit setups such as Alex's Debian Lenny > example. Yes, it was added originally to cover that scenario, but I'm no longer "catering" to that host. When it came time to commit a few necessary changes today, I decided to leave it in since it will always force binutils and gcc to build 64-bit on pass1. As you say it is probably unnecessary even there, but at least by including it, we know without doubt that we're getting 64-bit, even on multilib hosts. Thereafter, of course, it isn't necessary at all since we'll be using our 64-bit only compiler. If you think it's better to leave it out entirely, please explain why. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
Dan Nicholson wrote: > Except that you're still using the host grep, which may not have the > -q option (don't remember when it was added). FWIW circa 2000 Red Hat 6.2 (grep-2.4) has it. PS - This addition seems like overkill as most multilib setups default to m64. It appears Jeremy is catering to those "unsupportable with current build method" non-standard 32/64-bit setups such as Alex's Debian Lenny example. 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: Summary: Debian Lenny as host
On Thu, Aug 30, 2007 at 02:33:18PM -0700, Dan Nicholson wrote: > > > > Do you recall which revision that was? > > 8258 Ah, that explains it. I know I copied the entire repository, but I've only been changing items in BOOK and therefore only merged commits to BOOK. When it gets merged back to trunk, we'll only need to concentrate on changes to items under BOOK. I think it is all up to date now and the only differences are changes relevant to the new features added in the jh branch. I've generated a new diff, too: http://linuxfromscratch.org/~jhuntwork/jh.diff -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On 8/30/07, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > On Thu, Aug 30, 2007 at 02:16:13PM -0700, Dan Nicholson wrote: > > It seems to also be missing a udev-config fix to handle usb devices in > > 2.6.22+ kernels. > > Do you recall which revision that was? 8258 http://wiki.linuxfromscratch.org/lfs/changeset/8258 -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On Thu, Aug 30, 2007 at 02:16:13PM -0700, Dan Nicholson wrote: > It seems to also be missing a udev-config fix to handle usb devices in > 2.6.22+ kernels. Do you recall which revision that was? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On Thu, Aug 30, 2007 at 02:16:13PM -0700, Dan Nicholson wrote: > Except that you're still using the host grep, which may not have the > -q option (don't remember when it was added). I knew there was a reason! :P -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On Thu, Aug 30, 2007 at 05:05:58PM -0400, Bryan Kadzban wrote: > uname -m | grep -q 64 && M64="-m64" > > instead? The -q option to grep will prevent any output, and just return > an appropriate exit code. Yeah, that's definitely simpler. Not sure why I did it the original way. Sometimes I think I just get stuck on a certain method. > Also, I see that the console log level change hasn't been merged into > the jh branch either (that was r8222, and perhaps a few revs around it > also -- chapter07/console.xml). Thanks, I'll take a look. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On 8/30/07, Bryan Kadzban <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: RIPEMD160 > > Jeremy Huntwork wrote: > > On Thu, Aug 30, 2007 at 07:32:53PM +0200, M.Canales.es wrote: > >> I agree, at least as a starting point for 7.0 milestone. Some plans > >> to start merging jh branch into trunk? > > > > I would like to get it in as soon as we can, but considering that > > there are a number of changes, I was hoping that more people would > > have had time to look at the branch and comment before we merge. For > > quick reference again, here's the rendered book: > > > > http://linuxfromscratch.org/~jhuntwork/lfs-JH/ > > > > and a diff between it and trunk: > > > > http://linuxfromscratch.org/~jhuntwork/jh.diff > > I've been reading through the diff, and I saw this in binutils-pass1: > > +test $(uname -m | grep 64) && > M64="-m64" > > Why not just: > > uname -m | grep -q 64 && M64="-m64" > > instead? The -q option to grep will prevent any output, and just return > an appropriate exit code. Except that you're still using the host grep, which may not have the -q option (don't remember when it was added). grep 64 >/dev/null works, too. I also was thinking that you would want to do `|| M64=""' in case there was a stray M64 variable in the environment, but maybe that's too paranoid. > Also, I see that the console log level change hasn't been merged into > the jh branch either (that was r8222, and perhaps a few revs around it > also -- chapter07/console.xml). It seems to also be missing a udev-config fix to handle usb devices in 2.6.22+ kernels. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Jeremy Huntwork wrote: > On Thu, Aug 30, 2007 at 07:32:53PM +0200, M.Canales.es wrote: >> I agree, at least as a starting point for 7.0 milestone. Some plans >> to start merging jh branch into trunk? > > I would like to get it in as soon as we can, but considering that > there are a number of changes, I was hoping that more people would > have had time to look at the branch and comment before we merge. For > quick reference again, here's the rendered book: > > http://linuxfromscratch.org/~jhuntwork/lfs-JH/ > > and a diff between it and trunk: > > http://linuxfromscratch.org/~jhuntwork/jh.diff I've been reading through the diff, and I saw this in binutils-pass1: +test $(uname -m | grep 64) && M64="-m64" Why not just: uname -m | grep -q 64 && M64="-m64" instead? The -q option to grep will prevent any output, and just return an appropriate exit code. Also, I see that the console log level change hasn't been merged into the jh branch either (that was r8222, and perhaps a few revs around it also -- chapter07/console.xml). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1zE1S5vET1Wea5wRA7MiAJ9dXxbR/tfAGbx0owVciFfSZ2p8rACfaCsM /CEzMyUOnnOCGV2eOdvm/iI= =r/SE -END PGP SIGNATURE- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On Thu, Aug 30, 2007 at 11:40:20AM -0700, Dan Nicholson wrote:
> Try using svn diff.
>
> svn diff svn://svn.linuxfromscratch.org/LFS/{trunk,branches/jh}
>
> or use -I in diff to ignore the '$Id:' regex:
>
> diff -pNur -I '\$Id:' trunk jh
Ah, ok. Thanks.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On 8/30/07, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 30, 2007 at 12:13:46PM -0600, Jeremy Huntwork wrote:
> > Oh, yeah, I didn't even notice that. Will do.
>
> Fixed and the diff regenerated, though the commit seems to be too big to
> be posted to the list. Also, there are still references to lfs-xsl in
> the diff due to differences in the committer's name. :/ Oh well.
Try using svn diff.
svn diff svn://svn.linuxfromscratch.org/LFS/{trunk,branches/jh}
or use -I in diff to ignore the '$Id:' regex:
diff -pNur -I '\$Id:' trunk jh
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On Thu, Aug 30, 2007 at 12:13:46PM -0600, Jeremy Huntwork wrote: > Oh, yeah, I didn't even notice that. Will do. Fixed and the diff regenerated, though the commit seems to be too big to be posted to the list. Also, there are still references to lfs-xsl in the diff due to differences in the committer's name. :/ Oh well. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On Thu, Aug 30, 2007 at 11:08:34AM -0700, Dan Nicholson wrote: > Do you mind syncing the docbook-xsl-snapshot with what's in trunk to > reduce the diff a bit? It's the majority of the size right now. Oh, yeah, I didn't even notice that. Will do. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On 8/30/07, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > On Thu, Aug 30, 2007 at 07:32:53PM +0200, M.Canales.es wrote: > > I agree, at least as a starting point for 7.0 milestone. Some plans to start > > merging jh branch into trunk? > > I would like to get it in as soon as we can, but considering that there > are a number of changes, I was hoping that more people would have had > time to look at the branch and comment before we merge. It seems pretty sane to me, but I'm about to go into BLFS-6.3 mode, so I don't foresee testing it until that's in better shape. > For quick > reference again, here's the rendered book: > > http://linuxfromscratch.org/~jhuntwork/lfs-JH/ > > and a diff between it and trunk: > > http://linuxfromscratch.org/~jhuntwork/jh.diff Do you mind syncing the docbook-xsl-snapshot with what's in trunk to reduce the diff a bit? It's the majority of the size right now. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
On Thu, Aug 30, 2007 at 07:32:53PM +0200, M.Canales.es wrote: > I agree, at least as a starting point for 7.0 milestone. Some plans to start > merging jh branch into trunk? I would like to get it in as soon as we can, but considering that there are a number of changes, I was hoping that more people would have had time to look at the branch and comment before we merge. For quick reference again, here's the rendered book: http://linuxfromscratch.org/~jhuntwork/lfs-JH/ and a diff between it and trunk: http://linuxfromscratch.org/~jhuntwork/jh.diff > On a related topic, have you tried to build the jh branch using jhalfs? I has > not time yet to try it and I'm not sure if it might work without some fixes > on the jhalfs code. Yes, I have used jhalfs with it, but not in the last couple of weeks. The only changes to the branch are compatible with jhalfs' current logic, I believe. There's only commnad changes and package version changes, so it should be no problem. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Summary: Debian Lenny as host
El Jueves, 30 de Agosto de 2007 19:08, Jeremy Huntwork escribió: > Because of that, I'm inclined to let the matter rest, at least for now. > The current build method works for every default setup I've tested so > far - I think that is good enough. At least until we encounter some more > information. I agree, at least as a starting point for 7.0 milestone. Some plans to start merging jh branch into trunk? On a related topic, have you tried to build the jh branch using jhalfs? I has not time yet to try it and I'm not sure if it might work without some fixes on the jhalfs code. -- 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
Summary: Debian Lenny as host
Hello, Here's the build status of the jh branch: Debian Lenny for x86: Success Debian Lenny for amd64 (multilib with 64-bit userspace): Success Debian Lenny for amd64 (multilib with 32-bit userspace installed with debootstrap command): Fail Fedora Core 7 for amd64 (multilib with 64-bit userspace): Success I still don't know what exactly is causing the 32-bit userspace to fail on Debian Lenny - and I'm not sure what next to do to debug it. However, to achieve the environment that is causing failure, you either have to set up a 64-bit kernel for an x86 system, or set up a 32-bit userspace for an amd64 system. Neither of these scenarios are the default setup for Lenny, and I'm unsure as to how well they're supported or suggested for use. Because of that, I'm inclined to let the matter rest, at least for now. The current build method works for every default setup I've tested so far - I think that is good enough. At least until we encounter some more information. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
