Greg Schafer wrote:
Matthew Burgess wrote:
Is there any particular reason you made the symlink as opposed to just
doing a `sed -i -e 's@/bin/rm@/tools@ lib/blkid/test_probe.in`?
That'd probably work.. and is cleaner too. Best to avoid those pesky
symlinks if at all possible..
OK, I'll
Matthew Burgess wrote:
Yep, I noticed that. I'll let Jeremy sort that out, if he thinks it is
worth tackling, if you don't mind Jeremy?
No problem. I'll get to it shortly.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe:
Hello All,
On a system based on very recent LFS development (last week or so...) I
see this:
# grep /tools /usr/bin/* -R
/usr/bin/mk_cmds:SED=/tools/bin/sed
This is because e2fsprogs is built before our final sed. (The book even
mentions in the Appendix that sed must be built before e2fsprogs.)
El Jueves, 30 de Noviembre de 2006 17:11, Jeremy Huntwork escribió:
Or are there any other ideas?
Maybe to install Sed before E2fsprogs like is done in CLFS?
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en castellano:
On 11/30/06, M.Canales.es [EMAIL PROTECTED] wrote:
El Jueves, 30 de Noviembre de 2006 17:11, Jeremy Huntwork escribió:
Or are there any other ideas?
Maybe to install Sed before E2fsprogs like is done in CLFS?
I can't recall, but there might be an issue with moving sed up like
that. But I
Jeremy Huntwork wrote:
On a system based on very recent LFS development (last week or so...) I
see this:
# grep /tools /usr/bin/* -R
/usr/bin/mk_cmds:SED=/tools/bin/sed
This is because e2fsprogs is built before our final sed.
Already reported... sadly, no action.
Greg Schafer wrote:
Jeremy Huntwork wrote:
On a system based on very recent LFS development (last week or so...) I
see this:
# grep /tools /usr/bin/* -R
/usr/bin/mk_cmds:SED=/tools/bin/sed
This is because e2fsprogs is built before our final sed.
Already reported... sadly, no action.
Greg Schafer wrote:
Already reported... sadly, no action.
http://linuxfromscratch.org/pipermail/lfs-dev/2006-October/058411.html
Oh dear. Sorry about that folks. As Bruce points out though, Trac's
much better at remembering bugs than I am!
I think the easiest solution here is to move
Matthew Burgess wrote:
Oh dear. Sorry about that folks. As Bruce points out though, Trac's
much better at remembering bugs than I am!
This must-use-trac attitude from the LFS project is abhorrent IMHO. Most
open source projects are just happy to receive any feedback whatsoever.
Whatever
Greg Schafer wrote:
Matthew Burgess wrote:
Oh dear. Sorry about that folks. As Bruce points out though, Trac's
much better at remembering bugs than I am!
This must-use-trac attitude from the LFS project is abhorrent IMHO. Most
open source projects are just happy to receive any feedback
Greg Schafer wrote:
This must-use-trac attitude from the LFS project is abhorrent IMHO. Most
open source projects are just happy to receive any feedback whatsoever.
Not must-use, but requested politely to avoid double work. If you
notice the problem, you are in the best position to explain
Greg Schafer wrote:
The /bin/rm issue is only indirectly related. After the moving of
e2fsprogs, just look at the e2fsprogs testsuite build log and you'll see
why the /bin/rm symlink is needed.
Is there any particular reason you made the symlink as opposed to just
doing a `sed -i -e
Matthew Burgess wrote:
Is there any particular reason you made the symlink as opposed to just
doing a `sed -i -e 's@/bin/rm@/tools@ lib/blkid/test_probe.in`?
That'd probably work.. and is cleaner too. Best to avoid those pesky
symlinks if at all possible..
Sidenote: I recently got rid of the
Greg Schafer wrote:
Sidenote: I recently got rid of the /bin/stty symlink by modifying the
Expect installation:
http://www.diy-linux.org/reference-build/temptools.html#tt-expect
Inspired by my recent commit? :) Yours is better, though, I will admit,
since it actually removes the need for any
14 matches
Mail list logo
