Re: ICA diff in cc1 and cc1plus
On 3/20/07, Dan Nicholson [EMAIL PROTECTED] wrote: Attached are two patches to add the glibc branch update patch in Ch. 5 and force /usr/include to be used as the preferred system include directory after the toolchain re-adjustment. No comments, so I'm applying these. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: debugging strategies
GDB doesn't build, or doesn't work? Robert On Friday March 23 2007 03:11, Rogelio Serrano wrote: Whats the best debugging strategy for an PIE and ET_DYN system? i cant get gdb to work. im being forced to add self test code in all programs that crash. making them all verbose is not an option. -- the thing i like with my linux pc is that i can sum up my complaints in 5 items pgpFZZb2uIzjr.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
BLFS book entities
Currently in LFS, there's a single entity blfs-root; that points to www.lfs.org/blfs/. However, there are a few places in the book that contain specific links to BLFS pages: db, inetutils and shadow offhand. These end up hardcoding the rest of the path link. Something like: ulink url=blfs-root;view/svn/security/cracklib.html/ There are two things I'd like to address here. 1. We shouldn't always point to the svn version. When a stable book is released, it should probably point to the stable version of the BLFS book. Although, there could be a time lapse where this could be a bad idea, i.e. LFS-6.2 + BLFS-6.1. Still, if someone's following the stable LFS book, they probably don't want to get forwarded into the development version of BLFS. 2. More nitpicky, but we could easily absorb the view/$version part into another entity. I suggest the following two entity additions to general.ent: !ENTITY blfs-version svn !ENTITY blfs-view blfs-root;view/blfs-version;/ We have a similar convention in the BLFS book for referring to the LFS book. Thoughts? -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc replaces kernel headers [Was Re: LFS-20070209 shadow not playing nice with more_control_pkg_man]
On 3/2/07, Dan Nicholson [EMAIL PROTECTED] wrote: On 3/2/07, Matthew Burgess [EMAIL PROTECTED] wrote: On Friday 02 March 2007 22:50, Dan Nicholson wrote: Thanks for the info, Arden. That's good enough for me to ensure that the scsi headers only get installed by glibc. Patch attached. Patch looks fine to me, feel free to commit it Dan, thanks. Is this worth reporting upstream (i.e. to David Woodhouse) - both the fact that Glibc installs SCSI headers and that the headers in the kernel tarball cause userland compilation failures? Well, I'm pretty sure knows about it since he's the maintainer for the Fedora glibc-kernheaders package and they're doing the same thing. Still, I'd be interested in seeing any conversation on the subject. I'm applying this patch now, but I just wanted to touch on the Fedora thing quickly. Their headers are now generated as a separate -headers package for kernel. This is what it says in the spec file: # glibc provides scsi headers for itself, for now rm -rf $RPM_BUILD_ROOT/usr/include/scsi rm -f $RPM_BUILD_ROOT/usr/include/asm*/atomic.h rm -f $RPM_BUILD_ROOT/usr/include/asm*/io.h rm -f $RPM_BUILD_ROOT/usr/include/asm*/irq.h http://cvs.fedora.redhat.com/viewcvs/devel/kernel/kernel-2.6.spec?view=markup atomic.h, io.h and irq.h don't get installed on x86 looking at my recent build. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc replaces kernel headers
Dan Nicholson wrote these words on 03/23/07 17:03 CST: I'm applying this patch now, but I just wanted to touch on the Fedora thing quickly. Their headers are now generated as a separate -headers package for kernel. This is what it says in the spec file: Just out of curiosity, why is this necessary? Aren't the Glibc headers copied over the kernel headers during the Glibc installation? -- Randy rmlscsi: [bogomips 1003.28] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 17:14:00 up 14 days, 15:13, 1 user, load average: 0.27, 0.26, 0.20 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc replaces kernel headers
On 3/23/07, Randy McMurchy [EMAIL PROTECTED] wrote: Dan Nicholson wrote these words on 03/23/07 17:03 CST: I'm applying this patch now, but I just wanted to touch on the Fedora thing quickly. Their headers are now generated as a separate -headers package for kernel. This is what it says in the spec file: Just out of curiosity, why is this necessary? Aren't the Glibc headers copied over the kernel headers during the Glibc installation? Yeah, it's not stricly necessary in the context of the book. This is more a preference not to have conflicting files. I think we talked about doing the same thing with man-pages. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: docbook-4.5
On Thu, Mar 22, 2007 at 11:54:13PM +, Ken Moffat wrote: Is there something I should have done to transition from a 4.4 installation which used to work? I've built sgml-common and docbook-4.5 per blfs scene two: ĸen: Eek! Poisoned by a surfeit of docbooks! (Simulates a violent choking death, with ad-lib repeats in response to any applause) Yes, mea culpa, I built the wrong sodding package (docbook sgml). Sorry about the noise. ĸ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: debugging strategies
Robert Connolly wrote:
GDB doesn't build, or doesn't work?
For me it does build, but fails like this:
$ cat gdb-test.c EOF
int main()
{
return 42;
}
EOF
-
$ gcc -ggdb -v -o gdb-test gdb-test.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../butterfly-toolchain/configure --prefix=/usr
--libexecdir=/usr/lib --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++
--enable-checking --enable-bootstrap
Thread model: posix
gcc version 4.1.1
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/cc1 -quiet -v -D_FORTIFY_SOURCE=2
gdb-test.c -fPIE -fstack-protector-all -O -quiet -dumpbase gdb-test.c
-mtune=pentiumpro -auxbase gdb-test -ggdb -version -o /tmp/cc42vwe1.s
ignoring nonexistent directory
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include
/usr/include
End of search list.
GNU C version 4.1.1 (i686-pc-linux-gnu)
compiled by GNU C version 4.1.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 7dab25506487cc63d4fe4f4a489fe76a
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/bin/as
-V -Qy -o /tmp/ccq06cYU.o /tmp/cc42vwe1.s
GNU assembler version 2.17 (i686-pc-linux-gnu) using BFD version 2.17
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/collect2 --eh-frame-hdr -m
elf_i386 -dynamic-linker /lib/ld-linux.so.2 -z now -z relro -z combreloc
-pie -o gdb-test /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../Scrt1.o
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../crti.o
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/crtbeginS.o
-L/usr/lib/gcc/i686-pc-linux-gnu/4.1.1
-L/usr/lib/gcc/i686-pc-linux-gnu/4.1.1
-L/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/lib
-L/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../.. /tmp/ccq06cYU.o -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/crtendS.o
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../crtn.o
-
$ gdb ./gdb-test
GNU gdb 6.6
[snip warranty]
Using host libthread_db library /lib/libthread_db.so.1.
(gdb) b main
Breakpoint 1 at 0x656
(gdb) r
Starting program: /home/mordae/w/gdb-test
Failed to read a valid object file image from memory.
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x656: Input/output error.
(gdb) quit
The program is running. Exit anyway? (y or n) y
-
$ gdb /lib/ld-linux.so.2
GNU gdb 6.6
[snip warranty]
Using host libthread_db library /lib/libthread_db.so.1.
(gdb) b main
Function main not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (main) pending.
(gdb) run ./gdb-test
Starting program: /lib/ld-linux.so.2 ./gdb-test
Failed to read a valid object file image from memory.
Program exited with code 052.
(gdb) quit
-
$ /sbin/paxctl -permsx ./gdb-test
$ /sbin/paxctl -v ./gdb-test
PaX control v0.4
Copyright 2004,2005,2006 PaX Team [EMAIL PROTECTED]
- PaX flags: -p-s-m-x-e-r [./gdb-test]
PAGEEXEC is disabled
SEGMEXEC is disabled
MPROTECT is disabled
RANDEXEC is disabled
EMUTRAMP is disabled
RANDMMAP is disabled
-
$ # Repeated both `gdb ./gdb-test` and `gdb /lib/ld-linux.so.2` (run
./gdb-test) with exactly same results...
-
$ cp /lib/ld-linux.so.2 ./
$ cp /lib/libc.so.6 ./
$ export LD_LIBRARY_PATH=.
$ /sbin/paxctl -permsx ./ld-linux.so.2
$ /sbin/paxctl -v ./ld-linux.so.2
PaX control v0.4
Copyright 2004,2005,2006 PaX Team [EMAIL PROTECTED]
- PaX flags: -p-s-m-x-e-r [./ld-linux.so.2]
PAGEEXEC is disabled
SEGMEXEC is disabled
MPROTECT is disabled
RANDEXEC is disabled
EMUTRAMP is disabled
RANDMMAP is disabled
$ /sbin/paxctl -permsx ./libc.so.6
$ /sbin/paxctl -v ./libc.so.6
PaX control v0.4
Copyright 2004,2005,2006 PaX Team [EMAIL PROTECTED]
- PaX flags: -p-s-m-x-e-r [./libc.so.6]
PAGEEXEC is disabled
SEGMEXEC is disabled
MPROTECT is disabled
RANDEXEC is disabled
EMUTRAMP is disabled
RANDMMAP is disabled
$ ./ld-linux.so.2 --list ./gdb-test
linux-gate.so.1 = (0xe000)
libc.so.6 = ./libc.so.6 (0xb7e7)
/lib/ld-linux.so.2 = ./ld-linux.so.2 (0x8000)
-
# Both gdb runs failed once again -- now with paxctl'ed libc and once
again even with paxctl'ed dynamic loader. Same errors...
-
And second prob... How to compile without hardening?
- Mordae
--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: FOP-0.93
El Viernes, 23 de Marzo de 2007 23:24, Randy McMurchy escribió:
Hi all,
I'm ready to update the book to FOP-0.93, but wanted to throw out a
note that we cannot use it to produce PDF output from the SVN XML
sources.
Yes, that it a known issue. Our current stylesheets (both the DocBook-XSL
version used and our customizations layout) are very old to use it.
It appears Manuel needs to work some magic to produce
compatible .fo files.
Better said, almost a full rewrite to can match DocBook-XSL 1.72.1 version,
when released. Before that, and in case LFS-6.3 is released without having
finished the XSL upgrade, I will try to do a quick fix.
I would to start working on the XSL rewrite the next week, using the most
current DocBook-XSL snapshopt as the base.
I don't see any harm in updating, as there really is no need right
now to produce .pdf forms of the book.
I neither. As a worse scenario we could say that the PDF file for {,B}LFS-6.3
books has been created using FOP-0.20, pointing to the BLFS-6.2 book for
installation instructions.
--
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/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: debugging strategies
This thread is the same as what you're asking about: http://grsecurity.net/pipermail/grsecurity/2005-October/000581.html It says to run 'paxctl -spm' on the program and libraries, but it sounds like you tried that. CFLAGS=-nopie -fno-pic -norelro -nonow -fno-stack-protector -D_FORTIFY_SOURCE=0 should disable the compiler flags. There's a chance -fstack-protector-all is the cause of the crashes (like with Python and -O3), so you might want to leave that in. Even with these flags, you will probably still need to use 'paxctl -spm'. Adding '-g3 -ggdb' might also help. If that doesn't work, rebuild gdb itself with the above flags. robert pgpuF4RcbFjd9.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Dash tarball links
On 3/23/07, Randy McMurchy [EMAIL PROTECTED] wrote: I don't see an issue. Perhaps a short sentence (in para form) after the Package Information bullets noting the difference in the name, though they are the same files. As long as you don't see an issue, I don't feel like cluttering up the page. Moving on. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Dash tarball links
Dan Nicholson wrote these words on 03/23/07 18:20 CST: On 3/23/07, Randy McMurchy [EMAIL PROTECTED] wrote: I don't see an issue. Perhaps a short sentence (in para form) after the Package Information bullets noting the difference in the name, though they are the same files. As long as you don't see an issue, I don't feel like cluttering up the page. Moving on. Well, actually, I meant I don't see an issue with your proposal of adding the other file name. -- Randy rmlscsi: [bogomips 1003.28] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 18:33:00 up 14 days, 16:32, 1 user, load average: 0.11, 0.04, 0.05 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Dash tarball links
On 3/23/07, Randy McMurchy [EMAIL PROTECTED] wrote: Dan Nicholson wrote these words on 03/23/07 18:20 CST: On 3/23/07, Randy McMurchy [EMAIL PROTECTED] wrote: I don't see an issue. Perhaps a short sentence (in para form) after the Package Information bullets noting the difference in the name, though they are the same files. As long as you don't see an issue, I don't feel like cluttering up the page. Moving on. Well, actually, I meant I don't see an issue with your proposal of adding the other file name. Actually, I was agreeing in the most vague way possible :) I meant that if you don't see an issue with the file name conflicts, then I'll add the new tarball but without any accompanying text. I don't want to write/format the extra text if it's unnecessary. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: BLFS book entities
Dan Nicholson wrote: 1. We shouldn't always point to the svn version. When a stable book is released, it should probably point to the stable version of the BLFS book. Although, there could be a time lapse where this could be a bad idea, i.e. LFS-6.2 + BLFS-6.1. Still, if someone's following the stable LFS book, they probably don't want to get forwarded into the development version of BLFS. They may think they don't, but they probably do. The -dev version of the book is appropriate until the corresponding version of blfs is released. In the last cycle, that took quite a long time. As a rule of thumb, when using lfs-x.y, use blfs-dev until blfs-x.y is released. Currently, there is no way to go back and change released books. The only alternative is to use the errata page. One way I can think of is to point to a pseudo blfs on the web site and use appropriate symbolic links to the right pages. Initially they would point to -dev and then would be changed to point to the appropriate version ov blfs when that is released. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc ldd needs /bin/bash
Dan Nicholson wrote: On 3/14/07, Bruce Dubbs [EMAIL PROTECTED] wrote: Matthew Burgess wrote: How about: The commandldd/command shell script contains Bash-specific syntax. Change its shebang line to force the script to be interpreted by Bash in case other shells (see link href=whateverBLFS/link) are installed and linked to filename class=symlink/bin/sh/filename later: I don't particularly like using the word 'shebang' in the book. It's slang and I think the book is a bit more formal than that. Unfortunately I don't really have a suggestion for a replacement that I really like. How about: Change its invocation (shebang) line to ... I'm going ahead with this now with my preferred default program interpreter. Anyone can feel free to change this that doesn't work for them. What's a program interpreter? I'd prefer default shell. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc ldd needs /bin/bash
On 3/23/07, Bruce Dubbs [EMAIL PROTECTED] wrote: I'm going ahead with this now with my preferred default program interpreter. Anyone can feel free to change this that doesn't work for them. What's a program interpreter? I'd prefer default shell. When you set the shebang line, you're describing what program will interpret the file. It doesn't have to be a shell. It could be perl, python, awk, env, etc. We can use something besides program interpreter, but I don't think default shell is accurate for what we're doing. http://en.wikipedia.org/wiki/Shebang_(Unix) -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc ldd needs /bin/bash
Bruce Dubbs wrote these words on 03/23/07 19:01 CST: What's a program interpreter? I'd prefer default shell. Hopefully, Bruce is just joking. :-) I've been using the term since back in the days I was using a Tandy color computer with a 'basic' program interpreter cartridge plugged in. The shebang line doesn't have to be a shell. It can be any program that interprets the following lines in the file. Hence, 'program interpreter'. -- Randy rmlscsi: [bogomips 1003.28] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 19:06:00 up 14 days, 17:05, 1 user, load average: 1.11, 0.95, 0.47 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc ldd needs /bin/bash
Randy McMurchy wrote: Bruce Dubbs wrote these words on 03/23/07 19:01 CST: What's a program interpreter? I'd prefer default shell. Hopefully, Bruce is just joking. :-) I've been using the term since back in the days I was using a Tandy color computer with a 'basic' program interpreter cartridge plugged in. The shebang line doesn't have to be a shell. It can be any program that interprets the following lines in the file. Hence, 'program interpreter'. Of course I was joking. I forgot the :). Sorry about that. Actually, I was confused a little and thought we were discussing dash vs bash in general and not for a specific application. Program interpreter is fine in this context. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: BLFS book entities
On 3/23/07, Bruce Dubbs [EMAIL PROTECTED] wrote: Dan Nicholson wrote: 1. We shouldn't always point to the svn version. When a stable book is released, it should probably point to the stable version of the BLFS book. Although, there could be a time lapse where this could be a bad idea, i.e. LFS-6.2 + BLFS-6.1. Still, if someone's following the stable LFS book, they probably don't want to get forwarded into the development version of BLFS. They may think they don't, but they probably do. The -dev version of the book is appropriate until the corresponding version of blfs is released. In the last cycle, that took quite a long time. As a rule of thumb, when using lfs-x.y, use blfs-dev until blfs-x.y is released. True, but there should be a middle ground there. If you're doing you're first LFS and you wisely picked the stable book, you'd get plopped into the -dev BLFS book with no knowledge whatsoever about where it stands in it's development history. Maybe it's a good time like after LFS-6.2 was released, or maybe it's right now and you're about to be thrown a wave a cairo/gtk updates. Currently, there is no way to go back and change released books. The only alternative is to use the errata page. Right. One way I can think of is to point to a pseudo blfs on the web site and use appropriate symbolic links to the right pages. Initially they would point to -dev and then would be changed to point to the appropriate version ov blfs when that is released. Maybe view/lfs-compat? This could be a good compromise and would save us having to do things like write Warning: Don't use the BLFS stable book anymore! on the web page. All it would take is a change of a symlink at LFS release time. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: BLFS book entities
Dan Nicholson wrote: Dan, I just did a check: $ grep -r blfs *|grep -v svn chapter06/revisedchroot.xml:instructions for this (see ulink url=blfs-root;/)./para chapter06/man-db.xml:ulink url=blfs-root;view/cvs/postlfs/compressdoc.html/./para chapter07/console.xml: to blfs-support list -- chapter07/symlinks.xml:be found in ulink url=blfs-root;BLFS/ulink./para chapter09/whatnow.xml: Book. The BLFS project is located at ulink url=blfs-root;/./para general.ent:!ENTITY blfs-root lfs-root;blfs/ $ It looks like the only place there is a specific reference is view/cvs/postlfs/compressdoc.html. There are references to BLFS in vim, db, pkgmgt, inetutils, and revisedchhroot but none of them have URLs. And the cvs reference above should be changed to svn. (There is already a sym link vrom cvs-svn). In any case, are we making a big deal out of this for one page? The last significant change to compressdoc was Mar 06 when LFS changed from man to man-db. This page isn't likely to change much unless LFS changes. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: BLFS book entities
On 3/23/07, Bruce Dubbs [EMAIL PROTECTED] wrote: Dan Nicholson wrote: Dan, I just did a check: $ grep -r blfs *|grep -v svn chapter06/revisedchroot.xml:instructions for this (see ulink url=blfs-root;/)./para chapter06/man-db.xml:ulink url=blfs-root;view/cvs/postlfs/compressdoc.html/./para chapter07/console.xml: to blfs-support list -- chapter07/symlinks.xml:be found in ulink url=blfs-root;BLFS/ulink./para chapter09/whatnow.xml: Book. The BLFS project is located at ulink url=blfs-root;/./para general.ent:!ENTITY blfs-root lfs-root;blfs/ That's not a good grep because -v svn knocks out all the links that say ulink url=...view/svn/.../. Check inetutils and shadow, for instance. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: BLFS book entities
Dan Nicholson wrote: That's not a good grep because -v svn knocks out all the links that say ulink url=...view/svn/.../. Check inetutils and shadow, for instance. Right. How about: chapter02/creatingfilesystem.xml: ulink url=blfs-root;view/svn/postlfs/filesystems.html/./p ara chapter06/inetutils.xml: at ulink url=blfs-root;view/svn/basicnet/inetutils.html/. N ote that chapter06/shadow.xml: ulink url=blfs-root;view/svn/postlfs/cracklib.html/ for installing chapter06/vim.xml: url=blfs-root;view/svn/postlfs/editors.html/ for suggested chapter06/vim.xml: url=blfs-root;view/svn/postlfs/editors.html#postlfs-editors-vim/./para chapter06/glibc.xml:ulink url=blfs-root;view/svn/general/libidn.html/). chapter06/db.xml: installed. See ulink url=blfs-root;view/svn/server/databases.html#db/ chapter06/db.xml: url=blfs-root;view/svn/general/gdbm.html//para chapter06/man-db.xml:ulink url=blfs-root;view/cvs/postlfs/compressdoc.html/./para chapter07/profile.xml: ulink url=blfs-root;view/svn/introduction/locale-issues.html/./para chapter08/kernel.xml: url=blfs-root;view/svn/longindex.html#kernel-config-index/:/para Thats 11 references. Please disregard my earlier poet. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: BLFS book entities
On 3/23/07, Bruce Dubbs [EMAIL PROTECTED] wrote: And the cvs reference above should be changed to svn. (There is already a sym link vrom cvs-svn). If we had an entity, this would never have happened in the first place ;) -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
