Re: [lfs-dev] LFS-7.5 is released
On 3/2/2014 4:31 PM, Bruce Dubbs wrote: The Linux From Scratch community is pleased to announce the release of LFS Version 7.5. [snip] I would like to say that it pleases me that the LFS community is as active as it is, and congratulations on another release of this fine product. LFS is as active as it ever has been, and I've been part of the community for 10+ years. Thanks to everyone involved that is making all these good things happen, and a special shout-out to Armin who almost single-handedly kept the systemd branch active and current. Though I do not contribute very much any more, I just want to say how much I appreciate everyone's effort. It is amazing to see this community thriving after all these years. Way to go everyone! Best Regards, Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS 7.3: ISO discussion
cybertao wrote these words on 03/12/13 22:24 CST: I just realised I chose the development branch without much consideration, when the stable version my be more appropriate. If only for the convenience of release cycle guidelines. I focus on making a bootable CD and USB image for now using the vanilla-SVN build and replace it with a release build later if it's more appropriate. i686 and x86_64 on the same image, like Arch, is a good idea isn't it? Either one would be great, though I think a 7.3 stable ISO would be perfect. If a dual i686 and x86_64 is doable, then great, otherwise two ISOs for the two platforms shouldn't be that much harder then the combo. At least it seems that way to me. My ambition is a terminal environment with the tools to build LFS, SSH, screen, jhalfs, and build the book. Any bells and whistles can be added by anyone through some sort of SquashFS or UnionFS shenanigans (or perhaps BLFS using jhalfs). This sounds perfect. A boot ISO with SSH probably fits most folks desires to build LFS, and can be used as a rescue CD. Perfect. -- Randy rmlscsi: [bogomips 1003.23] [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] 22:44:00 up 97 days, 7:43, 1 user, load average: 0.66, 0.17, 0.05 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [systemd branch] Why is XML::Parser on the same page as Perl?
Armin K. wrote these words on 03/02/13 11:28 CST: Dana 2.3.2013 18:14, Pierre Labastie je napisao: I do not understand why the above has been done. I understand XML::Parser is a Perl module. But glibc (for example) is a C library, and we do not put it on the same page as GCC... I agree completely with Pierre on this one. There really is no reason I can think of that XML::Parser cannot have its own page for package management simplicity. I put it on the same page. We do same with glibc and tzdata - both on one page ... According to your logic, you'd have to recompile glibc when tzdata gets upgraded, which can be everything but true ... It isn't worth the new page, trust me ... Perhaps you could provide something more substantial than trust me. This has really never gone over well in the LFS community. -- Randy rmlscsi: [bogomips 1003.23] [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] 11:14:00 up 87 days, 21:13, 1 user, load average: 1.20, 1.29, 0.83 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] texinfo-5.0 breaks gcc in Chapter 6
Bruce Dubbs wrote these words on 02/24/13 17:45 CST: Ken Moffat wrote: For anyone who builds ada (really ? why ? :) in BLFS, I guess they are going to be missing the ada info files. I did some Ada coding once (1990s), but not for production. It has *very* strong type checking and is sometimes used where very high reliability is needed. For instance, I could see (but don't know) Ada being used in the Mars lander. Very interesting that you used NASA stuff as an example. I hired a guy that had coded for a NASA contractor and his thing was ADA. He said that the NASA standards used ADA extensively. -- Randy rmlscsi: [bogomips 1003.23] [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:05:00 up 81 days, 4:04, 1 user, load average: 0.51, 0.31, 0.17 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] texinfo-5.0 breaks gcc in Chapter 6
Bruce Dubbs wrote these words on 02/23/13 20:13 CST: I still am not in favor of putting this in LFS-7.3. It's so much easier to omit the .info build completely and, of course, there is no sense at all in building it in Chapter 5. I really don't understand why texinfo-5.0 had to go into LFS-7.3 at all. What benefit does it give? (none?) And it is bound to break several BLFS packages. Seems a needless headache just to have an updated package that really provides no additional benefits. JMHO. -- Randy rmlscsi: [bogomips 1003.23] [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] 21:00:02 up 80 days, 6:59, 1 user, load average: 0.42, 0.27, 0.11 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] texinfo-5.0 breaks gcc in Chapter 6
Bruce Dubbs wrote these words on 02/23/13 21:23 CST: About the only reason why is to avoid questions like Why isn't the latest version of package X in the book? Because it came out while LFS-7.3 was in package-freeze mode. Oh wait, we don't do package-freeze! :-) I look at it as similar to the issues we've had several times with new versions of packages like glibc or gcc which caused a lot more problems than generating .info files that are usually distributed in a package's tarball. Yeah, but we use 'makeinfo' to create .html and .txt documentation in many, many packages in BLFS. Randy rmlscsi: [bogomips 1003.23] [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] 21:23:01 up 80 days, 7:22, 1 user, load average: 0.08, 0.03, 0.07 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Ncurses pkgconfig .pc files
Hi all,
I just ran into a package (VLC from BLFS) that looks for the ncurses package
by checking for pkgconfig files. VLC fails to find ncurses because there are
no .pc files installed by ncurses using the LFS instructions. In order for
ncurses to install the pkgconfig files, you must use the --enable-pc-files
switch passed to configure.
Doing so results in 5 .pc files installed into /usr/lib/pkgconfig. Here are
the contents of the files:
rml@rmlinux: ~/build/ncurses-5.9 cat destdir/usr/lib/pkgconfig/*
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
major_version=5
version=5.9.20110404
Name: formw
Description: ncurses 5.9 add-on library
Version: ${version}
Requires: ncursesw
Libs: -lformw
Cflags:
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
major_version=5
version=5.9.20110404
Name: menuw
Description: ncurses 5.9 add-on library
Version: ${version}
Requires: ncursesw
Libs: -lmenuw
Cflags:
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
major_version=5
version=5.9.20110404
Name: ncurses++w
Description: ncurses 5.9 add-on library
Version: ${version}
Requires: panelw menuw formw ncursesw
Libs: -lncurses++w
Cflags:
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
major_version=5
version=5.9.20110404
Name: ncursesw
Description: ncurses 5.9 library
Version: ${version}
Requires:
Libs: -lncursesw
Cflags:
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
major_version=5
version=5.9.20110404
Name: panelw
Description: ncurses 5.9 add-on library
Version: ${version}
Requires: ncursesw
Libs: -lpanelw
Cflags:
VLC looks for ncursesw.pc. I can only think that over time more and more
package maintainers are going to expect the ncurses .pc files to exist. I
am not sure if they need to be modified because we move the libraries to
/lib and the libdir in the .pc files points to /usr/lib, but I think it
would be alright as any package wanting to link with ncurses libs will
use the .so files that do exist in /usr/lib.
Thoughts about adding the --enable-pc-files switch to the ncurses
instructions?
--
Randy
rmlscsi: [bogomips 1003.23] [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]
16:34:01 up 55 days, 2:33, 1 user, load average: 0.01, 0.03, 0.06
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Ncurses pkgconfig .pc files
Bruce Dubbs wrote these words on 01/29/13 16:57 CST: Can you please post $ ls destdir/usr/lib/pkgconfig/* LOL. Though not necessary as the names of the files are in the name field of each of the files I posted, here is an ls. rml@rmlinux: ~/build/ncurses-5.9 ls -l destdir/usr/lib/pkgconfig/* -rw-r--r-- 1 rml install 243 Jan 29 16:30 destdir/usr/lib/pkgconfig/formw.pc -rw-r--r-- 1 rml install 243 Jan 29 16:30 destdir/usr/lib/pkgconfig/menuw.pc -rw-r--r-- 1 rml install 272 Jan 29 16:30 destdir/usr/lib/pkgconfig/ncurses++w.pc -rw-r--r-- 1 rml install 235 Jan 29 16:30 destdir/usr/lib/pkgconfig/ncursesw.pc -rw-r--r-- 1 rml install 245 Jan 29 16:30 destdir/usr/lib/pkgconfig/panelw.pc -- Randy rmlscsi: [bogomips 1003.23] [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:03:00 up 55 days, 3:02, 1 user, load average: 0.04, 0.05, 0.07 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Ncurses pkgconfig .pc files
Armin K. wrote these words on 01/29/13 17:49 CST: I'd also recommend that you add symlinks as you do for libraries (form - formw, menu - menuw, etc). Right. Good call. -- Randy rmlscsi: [bogomips 1003.23] [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:56:01 up 55 days, 3:55, 1 user, load average: 0.00, 0.00, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] gptfdisk
On 12/30/2012 3:00 AM, Matt Burgess wrote: On Sat, 2012-12-29 at 21:40 -0800, Nathan Coulson wrote: On Sat, Dec 29, 2012 at 8:51 PM, Bruce Dubbs bruce.du...@gmail.com wrote: I would like to propose adding gptfdisk to LFS. I do prefer it for it's simplicity over parted, but I think BLFS would be good enough for that tool. As nice as it is, we don't use fdisk or gdisk in LFS. (And in BLFS, we have the choice of parted or gdisk) I agree. We use the host's tools to create the partition layout for LFS, so they can continue to be used should things need altering before hitting BLFS. It looks like a useful addition to BLFS though. Maybe an additional sentence or two in the note in chapter02/creatingpartition.xml could point the reader in the right direction for GPT and EFI partitioning schemes and related software? FWIW, I also agree with Nathan and Matt. I also think that with so many disk partitioning software choices available that LFS should not choose *one* to put in the book. To me it takes away from the Your distro, your rules motto. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Minor cleanups and consistancy fixes
Bruce Dubbs wrote these words on 08/22/12 21:05 CST: I think the difference between GB and gigabytes is more style than grammar. I'd like other opinions. You can use either. It certainly is not grammar. It is totally interchangeable. In one place you change five gigabyte to 5 gigabyte. Generally I think a single digit should be spelled out, but you are right that we are not completely consistent. My take is that numbers less than 10 should be spelled out. At least that is the current form of correct writing according to most respected authorities. -- Randy rmlscsi: [bogomips 1003.24] [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] 21:27:00 up 2 days, 8:31, 1 user, load average: 0.12, 0.05, 0.01 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Proposed package freeze
Bruce Dubbs wrote these words on 08/21/12 12:13 CST: I am proposing that we freeze LFS for 7.2 with the packages we now have in svn. There is one outstanding ticket to address glibc issues, but that does not require a package change. Util-linux may come out with a new release in the next week or so, but I think we can hold off on that until after 7.2 is released. Sounds great to me. That way I will be building what will be LFS-7.2 and can test BLFS stuff against it. -- Randy rmlscsi: [bogomips 1003.24] [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] 14:18:02 up 1 day, 1:22, 1 user, load average: 1.73, 1.37, 0.88 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Introduction
Hi all, Though some may remember me from my work in the LFS community, many of you will not. So, I would like to re-introduce myself. My name is Randy McMurchy and I have been building LFS since March of 2004. Hard to believe more than eight years have gone by since that first build. Though my work for the LFS community has mostly been in BLFS, I have done some work on LFS proper as well. I should have time in the upcoming months to work on the BLFS project again. I am looking forward to it. I am going to build a current SVN LFS and use that as my base system for development of BLFS, unless y'all think it would be better to use the last stable LFS. Please let me know. Anyway, I'm glad to be back and I look forward to getting back working on the BLFS book again. I have kept up with the mailing lists, but not everything, so if I ask something that has already been discussed, please just say so, and I will search the archives. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Email/Mailing List Timing test
Matt Burgess wrote these words on 08/20/12 15:04 CST: Pings are about right here ~300ms. That said, I was checking my email this morning using the web client on quantum and it saw the same delay. Odd. I'll see how things go tonight. Thanks for taking a look! FWIW, I have been seeing intermittent delays of about 90 minutes all day today. I'm still waiting for a commit message to BLFS-BOOK from hours ago. -- Randy rmlscsi: [bogomips 1003.24] [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] 15:10:01 up 2:14, 1 user, load average: 0.05, 0.02, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Email/Mailing List Timing test
Bruce Dubbs wrote these words on 08/20/12 17:41 CST: I think we've got it fixed. Mailman issue. Thanks for the test. I'm seeing almost instantaneous response now. Thanks for fixing the problem, Bruce. -- Randy rmlscsi: [bogomips 1003.24] [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:43:01 up 4:47, 1 user, load average: 1.32, 0.57, 0.30 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Introduction
Ken Moffat wrote these words on 08/20/12 15:50 CST: Who ? ;-) Oh, just some guy that search engines took me to the LFS web site when I was building GNOME back in early 2004! But seriously, Welcome Back! Thanks, Ken. I look forward to working with you again. -- Randy rmlscsi: [bogomips 1003.24] [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:54:01 up 5:58, 1 user, load average: 0.16, 0.12, 0.18 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Andy Benton
Bruce Dubbs wrote these words on 07/31/12 16:25 CST: With great sadness, I have to report the passing of Andy Benton. I am sorry to hear this news. Though Andy and I had our differences of opinion on some things, I always appreciated and admired the work he did for the (B)LFS community. He will be greatly missed. -- Randy rmlscsi: [bogomips 1003.27] [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] 10:40:00 up 13:22, 1 user, load average: 0.27, 0.16, 0.08 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: TeX Live is Alive!
On 1/21/2011 3:18 PM, Bruce Dubbs wrote: There is another problem. In the command: for FN in `find /usr/bin -type l`; do if [ `readlink $FN | grep \.\./texmf` ]; then ln -svf `readlink $FN | sed 's|\.\./texmf|../share/texmf|'` $FN fi done unset FN I get `/usr/bin/man' - `../share/texmf/doc/man' I'll have to check, but make install may be overwriting /usr/bin/man. William had put that in the ticket, but because my installation does not do anything like that, I simply dismissed it. I think we may have to explicitly set mandir and bindir. I am curious. On your system is /usr/share/texmf/doc/man a file or a directory? My installation it is a directory. Here is my configure command: ./configure --prefix=/usr \ --bindir=/usr/share/texmf/bin \ --sysconfdir=/etc/texlive \ --mandir=/usr/share/texmf/man \ --infodir=/usr/share/info \ --disable-native-texlive-build \ --enable-shared \ --without-luatex \ --enable-mktextex-default \ --with-banner-add= - BLFS \ --with-system-libgs \ --with-libgs-includes=/usr/include/ghostscript \ --with-system-xpdf \ --with-system-gd \ --with-system-freetype2 \ --with-system-t1lib \ --with-system-libpng \ --with-system-zlib \ --with-system-zziplib \ --with-x Notice I set bindir and mandir to locations inside the texmf tree (on purpose, I don't mind taking 30 seconds to update the path in /etc/profile and the couple of mods to /etc/mandb.conf) Now look at the results: rml@rmlinux: ~/build ls -l /usr/bin/man -rwxr-xr-x 1 root root 160704 Oct 29 19:26 /usr/bin/man (notice the date is much earlier than the dates on my TeX files) rml@rmlinux: ~/build ls -l /usr/share/texmf/doc/man total 28 -rw-r--r-- 1 root root 361 Dec 31 18:44 Makefile drwxr-xr-x 2 root root 20480 Dec 31 18:44 man1 drwxr-xr-x 2 root root 4096 Dec 31 18:44 man5 rml@rmlinux: ~/build ls -l /usr/share/texmf/bin/tex -rwxr-xr-x 1 root root 277068 Dec 31 19:32 /usr/share/texmf/bin/tex rml@rmlinux: ~/build ls -l /usr/share/texmf/bin/man ls: cannot access /usr/share/texmf/bin/man: No such file or directory As you can see it does not install a man file (or symlink). Weird. If you feel like messing with it, set bindir and mandir to the appropriate places (/usr/bin and /usr/share/man) and see what happens. As you can see, I did not see the same behavior as you. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Should xz-utils installed before man-db
xinglp wrote these words on 01/04/11 10:49 CST: It seems that man-db depends on xz-utils. The configure out puts below 111 checking for pic... pic 112 checking for gzip... gzip 113 checking for compress... no 114 checking for bzip2... bzip2 115 checking for xz... xz 116 checking for gzopen in -lz... yes Good observation. CC'ing -dev as this is a -dev issue. Anyway, if man-db can use XZ compression, we might as well put XZ-Utils in a position where man-db can use it. -- Randy rmlscsi: [bogomips 1003.25] [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] 10:52:00 up 8 days, 13:49, 1 user, load average: 0.45, 0.12, 0.15 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.16 gcc omit-frame pointer
Bruce Dubbs wrote these words on 12/01/10 14:50 CST: In Chapter 5, we are not doing a full bootstrap, so we add -fomit-frame-pointer so it will produce the same codes as if it was a full bootstrap. In Chapter 6, we do the same thing. I think, but I'm not sure, that -fomit-frame-pointer is the default for x86_64. If this is correct, perhaps we can tweak the text a little to clarify. I seem to recall reading in the GCC mailing lists that -fomit-frame-pointer is the default on all builds now. I don't recall what version this was started. It would be easy enough to find out. Anyone with a x86 could start a GCC build and look at the first few times in the log where something is compiled and see if the flag is in the line. If you see it once, you will know it is now default. -- 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] 15:51:00 up 29 days, 22:45, 1 user, load average: 0.24, 0.25, 0.26 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
udev-164-testfiles.tar.bz2
is not located where the dev book says it is: http://anduin.linuxfromscratch.org/sources/other/udev-164-testfiles.tar.bz2 Would it be any different than the 163 version? -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Glibc requirement
Hi all, I went to build a new LFS (development version) today so that I could begin getting BLFS ready for a release. I got bit in that my host's kernel version (an old LFS build from 2007) was one release too short (2.6.21.5 instead of 2.6.22.5). I've built 3 versions of LFS since this host, but have wiped them out as they were never completed, thus I'm using the old 2007 version as a host and have nothing newer. Anyway, I'll update the kernel. But I also noticed that my Glibc is 2.5 and the requirement is 2.5.1. What exactly is going to fail if I continue on with 2.5 instead of the 2.5.1 listed requirement? -- Randy rmlscsi: [bogomips 1003.23] [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:25:00 up 9:34, 1 user, load average: 0.01, 0.02, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: How can I contribute?
Ken Moffat wrote: Just for the record, BLFS is still targetted at LFS-6.5, so build instructions should be appropriate to that version. That should probably change now. I'm not sure any active developers are using 6.5. I am open to suggestions, but I feel BLFS may need to just simply target the LFS Development book. Anybody who could contribute some alternate ideas would certainly be helpful. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Website
Bruce Dubbs wrote: I have to say that I agree. In my mind, the current site is quite adequate. I'm not going to be 'for' or 'against' a change, but I don't see the value in changing. Ken, us old guys need to stick together. :) Count me in as one of the old guys! -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: BLFS: Where does it stand?
Randy McMurchy wrote these words on 03/30/10 18:06 CST: All the servers I feel pretty good about. And not to exclude Ken, I've got Ghostscript and CUPS already updated, Gutenprint is already being tested against the other two. Oh, and I mix in Samba just to really test the installation. -- Randy rmlscsi: [bogomips 1003.22] [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:14:00 up 93 days, 23:22, 1 user, load average: 0.01, 0.03, 0.06 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: BLFS: Where does it stand?
Randy McMurchy wrote: Randy McMurchy wrote these words on 03/30/10 18:06 CST: All the servers I feel pretty good about. And not to exclude Ken, I've got Ghostscript and CUPS already updated, Gutenprint is already being tested against the other two. Oh, and I mix in Samba just to really test the installation. This went to to the wrong list. Sorry. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Testing
Robert Xu wrote these words on 03/28/10 16:38 CST: I'm just having the problem of getting all the emails about 6-10 hours late. Like now, I just got an email sent at 10:24 AM, and it's 5:38 PM now. I also reported the same exact behavior from the mail server on quantum to the sysadmin, but I was told all is well and good. The behavior is sporadic, like right now mail is being delivered timely. But the last few days it has been running 6-20 hours behind (on occasion). It is working, you just can't count on reliable delivery from the LFS lists (any of them). -- Randy rmlscsi: [bogomips 1003.22] [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] 07:46:01 up 92 days, 11:54, 1 user, load average: 0.23, 0.11, 0.03 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Testing
Sorry for the noise if it comes through, but David Jensen emailed to me saying he hasn't received mail from these two groups in some time, and he also sent a test mail. -- Randy rmlscsi: [bogomips 1003.22] [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] 13:40:01 up 91 days, 17:48, 1 user, load average: 0.02, 0.04, 0.21 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Quantum server and mail issues
Hi all, I've noticed that recently there are times (such as right now) that it takes 3 or 4 hours for LFS mail to be delivered to my mail client. However, that same mail hits the Gmane News server in mere moments. Anyone have any idea what is going on with the Quantum server? -- Randy rmlscsi: [bogomips 1003.22] [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] 07:39:01 up 82 days, 11:47, 1 user, load average: 0.19, 0.20, 0.41 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: grammar correction chap 4.1 LFS 6.6
Chris Staub wrote these words on 03/12/10 13:09 CST: Hmm, then you might want to take a look at the LFS Prerequisites page, and the Less, M4, Groff, GCC, and Glibc pages in Chapter 6. Then again, it might be better for your sanity if you don't... Entering late (on purpose) because it is such a senseless thread now (at least to me), but I'll go on record that I've been around various flavors of Unix's for almost 25 years and I've never heard anyone pronounce su as soo, or sue. It has *always* been es you. And in that case, regardless what the opposition says, proper grammar says that you would write it out as an su command. Please don't expect another reply by me on this thread, I just wanted to cast my vote. -- Randy rmlscsi: [bogomips 1003.22] [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] 14:08:00 up 75 days, 19:16, 1 user, load average: 0.29, 0.16, 0.11 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
E2fsprogs patch
Hi all, I have submitted a patch upstream to the E2fsprogs maintainers to add a function to the libcom_err library so that it will be compatible with Heimdal. Without the patch to E2fsprogs, Heimdal will end up adding a new libcom_err library in /usr/lib and overwrite the .so file that points to the E2fsprogs library, /lib/libcom_err.xxx. E2fsprogs is already trying to support Heimdal. They added a file to the package called com_right.c and added a definition to com_err.h which adds the Heimdal com_right function. However, Heimdal apparently has added a new function to their version of libcom_err called com_right_r. My patch (from arch-linux) adds this function so Heimdal will then use the existing libcom_err library from E2fsprogs and everything works properly. I would appreciate if the LFS dev team would consider adding this patch to the E2fsprogs build in the -dev book until E2fsprogs adds it to a new version of the package. For people building LFS-dev, the patch means that Heimdal will install clean and not install an unneeded library. I'll have to figure out something for the Heimdal package for users installing on LFS-6.5 and LFS-6.6. -- Randy rmlscsi: [bogomips 1003.22] [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] 10:18:01 up 68 days, 15:26, 1 user, load average: 0.14, 0.03, 0.01 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Traceroute
Hi all, Is it worth maintaining the Traceroute package in BLFS when Inetutils from LFS ships a working traceroute program? Is one better than the other? -- Randy rmlscsi: [bogomips 1003.22] [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] 21:59:00 up 57 days, 3:07, 5 users, load average: 0.00, 0.00, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: suggestion: add wget
Bruce Dubbs wrote: clark hammer wrote: It would be beneficial if the community added wget to lfs. This would allow lfs users to download additional software once they build their own lfs system. This has been discussed before. One thing Bruce didn't mention is that you have full FTP capability after building an LFS system. Just a suggestion. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Standards Base
Dan Nicholson wrote: The major reason for the existence of the LSB is to support ISVs who want to distribute software for linux. They want to have some base to be able to say here's a package that will work on your system. If you don't want or need to support that, the LSB is not for you. Seems LFS is more the opposite, give us the source and we make the package work for our system. And if so, perhaps we don't even need to be LSB compliant. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: zlib instructions - 'rm /lib/libz.so'?
Bruce Dubbs wrote: Bryan Kadzban wrote: But we don't put *any* .so (or .a) files into /lib, because the only reason for /lib is to hold libraries that are required before /usr may be mounted (i.e. early bootscripts). And when you're compiling -- which is the only time .so or .a files are used -- /usr had better be mounted. :-) Actually .so files are used any time a dynamically linked executable needs them, not just when 'compiling'. But I think you know that. Yeah, but dynamically linked executables never need them (unless of course the package only provides a .so or .a file. Typically, what is needed for dynamically linked packages are files such as libfile.so.1. That is why we leave libfile.so.1 and libfile.so.1.37 in /lib. So, actually, .so and .a files are really only needed at compile time for other packages. :-) Actually, I think we may have several unnecessary files in /lib. I'm not sure why libhistory Probably for the bash shell. , libnss*, These are Glibc files used for resolving names, likely needed in single user mode. libpcre, Probably bash again. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-6.5 RC2 plans
Matthew Burgess wrote these words on 07/26/09 15:22 CST: I'm intending to push 6.5-RC2 out midweek, at which point I'll also declare a full feature/package freeze. Cool. It's at that point I build a 6.5 system and start testing BLFS packages. But until then ... -- Randy rmlscsi: [bogomips 1003.25] [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] 15:44:01 up 20 days, 4:12, 1 user, load average: 0.64, 0.34, 0.39 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
New BLFS Editor
Hi all, I'd like to announce that Wayne Blaszczyk has accepted a position as a BLFS Editor. Wayne has recently been sending in patches for the BLFS book to add new packages. Wayne will make a fine addition to the BLFS team and I encourage everyone to welcome him as the newest addition to the editing team. -- Randy rmlscsi: [bogomips 1003.25] [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] 09:17:00 up 15 days, 21:45, 1 user, load average: 0.34, 0.10, 0.03 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: inetutils
Tobias Gasser wrote these words on 07/21/09 16:25 CST: conclusion / request: add a paragraph in the top of the changelog telling how to use the wiki log/trunk to get some more details. knowing about this wiki entries makes my life a lot easier (at least concerning lfs ;) ). up to today i checked the changes by eye (i don't have to tell about how often i overlooked a small but nasty detail...) in the future i won't read the changelog. i just go to the wiki, browse source and then revision log. (i just bookmarked the wiki /lfs/log and /blgs/log...) The easiest and best way to keep track of changes is to subscribe to LFS-Book and read the commit messages. If it ain't there, then it didn't happen. -- Randy rmlscsi: [bogomips 1003.25] [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] 16:47:01 up 15 days, 5:15, 1 user, load average: 0.00, 0.02, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-6.5-RC1 released
Matthew Burgess wrote these words on 07/18/09 10:05 CST: The Linux From Scratch community is pleased to announce the release of LFS Version 6.5 Release Candidate 1. [snip] It is our intention to release LFS-6.5 final within 2 weeks. Just my opinion, but I think that is too aggressive of a timeline. I realize that the proposed 6.5 actually *builds*, but has anyone actually tried using it, in real-life situations? I don't think two weeks is enough time for anyone to build a functional desktop and/or server system and actually test it out, especially with BLFS lagging so badly. Half the BLFS instructions probably don't work with LFS-6.5, which makes the building process of an actual functional machine even harder and longer. Just my thoughts. -- Randy rmlscsi: [bogomips 1003.25] [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] 10:39:02 up 11 days, 23:07, 1 user, load average: 1.11, 0.62, 0.51 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-6.5-RC1 released
Bruce Dubbs wrote these words on 07/18/09 10:53 CST: I understand your concerns, but let me mention an alternative view. If we wait too long, there will be updates to several packages and the longer we wait, the more pressure to incorporate those newer packages into the 'upcoming' release. It doesn't seem to hamper the GNOME project which puts package freeze in place much, much before we do. But as I said earlier, it's your call. I just think it is premature to release a version of LFS that nobody has actually tested in any real life situation. It's only one person's opinion, please don't get worked up about it. I just thought I'd throw it out there. -- Randy rmlscsi: [bogomips 1003.25] [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] 12:08:20 up 12 days, 36 min, 1 user, load average: 2.48, 0.84, 0.33 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: BDB and GDBM
Matthew Burgess wrote these words on 07/17/09 06:24 CST: BDB was added ages ago when we moved to iproute2, whose arpd implementation links against BDB. Personally, I never use arpd, but I guess it's useful for some network-admin types. We could drop BDB and therefore lose arpd (potentially pointing folks at BLFS for BDB instructions), but I really don't care either way to be honest. No, BDB was added when we moved to man-db. Before that, we didn't build the arpd program, which is what I suggest we do now. If we don't drop BDB (which we should), then at least let's fix the text that essentially says you are on your own if you use GDBM with man-db. -- Randy rmlscsi: [bogomips 1003.25] [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] 06:32:00 up 10 days, 19:00, 1 user, load average: 0.00, 0.00, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: BDB and GDBM
Matthew Burgess wrote these words on 07/17/09 06:35 CST: I'd agree that your proposal is the right thing to do. Bruce, do you mind if we squeeze this in for 6.5? We would also have to put back the short note in the program that builds arpd, that if you need arpd, then follow BLFS to build BDB. -- Randy rmlscsi: [bogomips 1003.25] [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] 06:44:00 up 10 days, 19:12, 1 user, load average: 0.19, 0.21, 0.10 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
BDB and GDBM
Hi all, So I don't have to try and scour through the archives, can someone help me figure out why GDBM was added to chapter 6 of the book, yet BDB was left in as well. Do we have packages in Chapter 6 that depend on both being installed? -- Randy rmlscsi: [bogomips 1003.25] [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:55:00 up 10 days, 6:23, 1 user, load average: 0.00, 0.00, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: no libidn/ in glibc-2.9
Matthew Burgess wrote these words on 03/20/09 07:02 CST: On Fri, 20 Mar 2009 12:35:06 +0100 (MET), Alexander Kozlov akoz...@nada.kth.se wrote: there is no libidn/ in glibc-2.9 release, contrary to the contents of Chap.6. It appears in gnu snapshots though. Could you be more specific please? I can't see any reference to libidn in http://www.linuxfromscratch.org/lfs/view/development/chapter06/glibc.html and a grep over the book sources only shows hits for commented out sections in chapter06/glibc.xml and chapter03/packages.xml. Matt, the OP is right. In official releases, the Glibc tarball does not ship with libidn. But we've been using snapshots which *do* include it. I commented out the stuff about libidn when I updated the book to use a snapshot, but now that we're back to an official tarball, we need the instructions to download the libidn tarball like the book *used* to be. HTH. -- Randy rmlscsi: [bogomips 1003.24] [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] 07:27:00 up 20 days, 16:30, 1 user, load average: 0.00, 0.01, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 5.5. GCC-4.3.3 - Pass 1
Jack Stone wrote: Matthew Burgess wrote: Such a big warning is already present at the bottom of 5.3 (General Compilation Instructions). Does it really need repeating on each and every package instruction page? [snip] It just seems that people don't realise this so maybe it should be more explicit. I don't know, just an idea is all. Keep in mind Jack, that the OP of this thread is obviously struggling with the English language. Don't you think this could be part of the issue? I don't mean that in a ridiculing or demeaning manner. I'm simply pointing out that I believe it to be part of the problem for the OP. I can only remember one other incident of this particular issue, but perhaps there's been others I don't remember. I'm with Matt on this one. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: libusb-compat requires pkg-config
Matthew Burgess wrote these words on 02/28/09 17:00 CST: Just to let you know that trying to build libusb-compat early on in a BLFS build fails (hard fail in ./configure) if pkg-config isn't installed. I'll fix this right now. This situation with pkg-config is just going to get worse and worse. I would almost recommend that we put the package in LFS as it goes forward, as almost *every* BLFS package is going to require it. -- Randy rmlscsi: [bogomips 1003.24] [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:57:03 up 1 day, 4:56, 1 user, load average: 0.16, 0.06, 0.01 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: libusb-compat requires pkg-config
Bruce Dubbs wrote these words on 02/28/09 19:33 CST: While I'm not completely against putting pkg-config in LFS, we could also put it into Chapter 3 of BLFS, 'After LFS Configuration Issues'. It wouldn't surprise me if some LFS package looks for pkg-config in the near future. At that time, we'll have to put it in LFS. Until then, it's a crap-shoot as to include it or not. I really don't care on the LFS side, but in BLFS, it is becoming mandatory for almost all packages. Discussion of this issue is in order. My vote is to add it to LFS. I sort of look at it like the autotools. They aren't required, but you'll need it for sure down the road. -- Randy rmlscsi: [bogomips 1003.24] [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:56:01 up 1 day, 5:55, 1 user, load average: 0.11, 0.09, 0.33 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Management
DJ Lucas wrote these words on 02/12/09 17:18 CST: Randy McMurchy wrote: I realize I could keep my old logs from packages I've since removed and replaced, but I'm wondering how others do it. I didn't...hadn't even considered it when logging installations. I've since moved to DESTDIR so my latest logging scripts were destroyed (but I'm pretty sure I still have earlier versions on my mail server). I also moved to DESTDIR installation of all packages long ago. LFS starting in Chapter 6 and all BLFS packages. I script and log everything, create a binary (.bz2) package of all the files in each package, then copy DESTDIR to the actual filesystem. Works for me. I actually have a routine at the end that compares each file in DESTDIR against all the installed files in the actual filesystem. Anyway, I'd make the installation (removal by upgrade) a part of the logging tool, in fact that was exactly how I handled upgrades in my previous tool. In the event of an upgrade, it wouldn't be a big deal to compare line by line (grep by output of cut) the old log file for files that do not appear in the new, then check to see if they still exist. This is probably the best suggestion, and what I had intended on doing, but wanted to get any other ideas others may have. If you use rmdir for directories when removing the old version of a package that you intend to upgrade, you could simply ignore (or capture) the error when removing a directory (because it is not empty). If a dir is in the old log that isn't in the new one, and it still exists on the filesystem, then it should be appended to the new log file. Right. Again, this is what I had intended on doing, just wondered if there was something easier than having to add stuff to my existing scripts. Thanks to everyone who commented (though some of the comments weren't relevant to my questions, such as using package-users - yuck!) and I'm right back where I was, but with the knowledge that LFS package management is in its infancy right now. I really had no problem, I just want the ability to always define (have logs on) how a file/directory was created on my system. And since I was removing old log files of packages that have been updated, some directories wouldn't show in logs. A very small issue that is fixed using the suggestions provided by DJ (which was what I had concluded was my only alternative). Some (DJ and Jack Stone) have mentioned they have notes for using DESTDIR during LFS. I have more than notes, I have actual commands and scripts that do it - perfectly. In fact, months (years?) ago I offered these scripts and ideas to the community, but nobody seemed interested. Perhaps it was because it was reinventing the wheel. I'm not sure if DIY started doing DESTDIR before or after I did, but regardless, it is so easy that it would be a snap to put into LFS. -- Randy rmlscsi: [bogomips 1003.24] [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] 09:38:01 up 6 days, 2:01, 1 user, load average: 0.26, 0.10, 0.02 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Package Management
Hi all, Though this topic may be borderline off-topic for the -dev lists, they have the most traffic, and just may be relevant. My question is this: How do others handle the situation where directories are created by a package during the package install, and then other packages install other files in these directories? Take for example, GLib. During my installations, Glib is one of the first packages I install (in fact do it during the chroot phase of LFS). Anyway, for example GLib will create a /usr/share/gtk-doc directory and the corresponding html directory and then populate it. Later on other packages will populate /usr/share/gtk-doc/html with other files/directories. Now, a bit later, I may want to update GLib to a more recent version. The first thing I do is use my log of installed files and directories during the initial Glib installation to remove anything it had installed. I don't like overwriting files, I prefer to remove all old files from the previous version before commencing an installation of a newer version. But I can't remove the /usr/share/gtk-doc directory as other packages have also used it since. After removing all the GLib files, I will usually remove all the log files associated with that initial installation. And this leaves me with the dilemma that there is now no package that shows it created the /usr/share/gtk-doc directory. This is not harmful, but from a logging standpoint it has a deficiency in that I can't determine what package initially installed the directory. I realize I could keep my old logs from packages I've since removed and replaced, but I'm wondering how others do it. -- Randy rmlscsi: [bogomips 1003.24] [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] 16:05:00 up 5 days, 8:28, 1 user, load average: 0.00, 0.03, 0.06 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Let William comment and make tickets
William Immendorf wrote these words on 02/11/09 16:04 CST: THIS IS UNFAIR! WILLIAM NEEDS TO HAVE TICKET PREMITIONS!! Why must you feel you have to shout in ALL CAPS? You'd be so much more accepted if you just followed the decorum we've established over the years. You continuously break the rules, and we've all tired of it. William, I really think that you could help the project if you followed the rules, but you persist in not following them. What is wrong with you? Do you just revel in attention, regardless how bad the attention you gather is? Now, I'll go on record as saying that Bruce's measure is a bit extreme. I think it will only cause a reduction in input from the regular community. But William must promise to change his posting habits. Can that happen? I don't think so, but I'd like to give him one more chance. If he cannot show some improvement then, yes, we have to do whatever it takes so that he doesn't disrupt the community. Sheesh, William, just do some research before posting. It's not that hard. From now on, you *MUST* show that you've researched something and that 'because I say so, it is so', is what is getting you in trouble. C'mon, man, straighten up or get lost. -- Randy rmlscsi: [bogomips 1003.24] [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] 16:13:00 up 4 days, 8:36, 1 user, load average: 0.40, 0.08, 0.03 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Let William comment and make tickets
William Immendorf wrote these words on 02/11/09 16:37 CST: On Wed, Feb 11, 2009 at 4:31 PM, Bruce Dubbs bruce.du...@gmail.com wrote: Let William post to -dev. If he demonstrates that he has an emotional age greater than 12, we can consider restoring ticket privileges. And I am showing a emotional age greater than 12 right now. Actually, you are not. Repeating something while refuting it, is in fact childish in nature. Come up with something original why you should have privileges restored and perhaps Bruce may consider your request. It is up to him, and I stand behind Bruce's call on this matter. Your last two posts have only hindered your chances. -- Randy rmlscsi: [bogomips 1003.24] [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] 16:45:01 up 4 days, 9:08, 1 user, load average: 0.25, 0.08, 0.06 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Let William comment and make tickets
Bruce Dubbs wrote these words on 02/11/09 16:31 CST: Let William post to -dev. If he demonstrates that he has an emotional age greater than 12, we can consider restoring ticket privileges. Promises won't cut it. Only actions will be considered. Very well put, Bruce, thank you. It is up to William now, and his chances seem to be decreasing with every post he makes. Sheesh, you'd think he would straighten up if he actually cared for this project. Just a side thought, but does anyone think that William doesn't exist, and is only a sock puppet for someone disgruntled with the project? I strongly believe this, as I don't think anyone could be as stupid as he pretends to be. And if it is not pretending, then I do think the individual is nothing more than an adolescent with too much time on his hands. -- Randy rmlscsi: [bogomips 1003.24] [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] 16:47:00 up 4 days, 9:10, 1 user, load average: 0.46, 0.18, 0.09 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: LFS Ticket system
Bruce Dubbs wrote these words on 02/01/09 12:25 CST: Thanks for the tip Matt. I wasn't seeing the error on any browser so it was difficult to figure out. Perhaps we should just delete all accounts and ask everyone to re-register. The Admin page (for BLFS and LFS) shows a lot of addresses without a Last Login date/time (probably before an update to Trac) and a lot with users that have not logged in for six months or more. Thoughts? My thoughts are the system is broken and needs to be fixed. I cannot use the BLFS trac system as it stands. Someone said that Jeremy updated some Trac plugins which broke the system. Can't these updates be undone? And why are things updated, which breaks the system, and then just left that way? -- Randy rmlscsi: [bogomips 1003.24] [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] 11:57:00 up 1 day, 4:20, 1 user, load average: 0.21, 0.55, 0.36 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Adapting LFS SVN for multilib
Ryan Oliver wrote: Greg Schafer wrote: Hopefully, there are others like me that do not mind this banter between Ryan and Greg. I don't look at it as arguing, or trying to one-up each other. It is simply their way of expressing their own ideas. I like it. And I'm learning from it. If you feel the need to write in about spouting insults, personal attacks or other such personal feelings, please just STFU. Let the men do their talking in their own way. There is technical information being passed. Simply look at what is being said, and don't worry how it is being said. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Quantum HTTP processes using 100% CPU?
Hi all, If anyone with privileges to Quantum could look in and see why the Quantum server is so bogged down, I sure would appreciate it. It seems as though it has been really, really sluggish the last few days. Top shows that HTTP processes have the CPU running at 100%. Perhaps if the Apache server was restarted, things might be better. The Apache server has been running since June. -- Randy rmlscsi: [bogomips 1003.23] [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] 11:39:00 up 18:59, 1 user, load average: 0.09, 0.28, 0.16 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: CLFS Bashing - Fork?? When??
Dan Nicholson wrote: We can call CLFS whatever we want, but by typical open source project standards, it is definitely a fork. I agree, that is why I've always referenced it as a fork. And as Dan says below, I don't consider that a bad thing. It simply is an accurate description. I don't intend that as bashing in any way and admire what you guys have done. Really. I agree with this as well. In fact, I've referenced CLFS while doing a multilib build a few months back. Though I only looked at it if something didn't work properly, or I had second thoughts about something. I wanted to learn the hard way, as unfortunately for me that usually is the only way to make the knowledge permanent. I too admire the work, as LFS didn't provide what CLFS brought to the table. And I'm in the camp with several recent posters that think the project would be better off as a whole if things could get straighted out and the projects somewhat merged. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: CLFS antics
Jeremy Huntwork wrote: Hi Rob, I would love to see what you and Robert C. have suggested happen. [snip good stuff] Anyway, as far as I am concerned, I would be glad to give up any commit privileges I have in the projects and work only from the sidelines if it would help remove the rift and get people working together. Ditto this from me. I don't recall really ever having issues that were that bad in my opinion (other than some cross times with Jeremy U, that I thought we got past) but it does appear somehow I've gotten under Jim's skin. I realize I've commented a couple of times over the years about the way CLFS cut and pasted hundreds of pages directly from BLFS without attribution (I don't consider the buried deep in the license mention of BLFS attribution), but that's all it was: comments. And truthfully, every time I mentioned it, it was in the hopes that CLFS would do something similar to almost all other forks (see http://poppler.freedesktop.org/ for an example) in that they could mention BLFS with a link to the development book or the web site. Seems so simple. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Future LFS 7.x Plans
Jim Gifford wrote: I also hope anything from what people have done towards the LFS's 7.0 goal, that the appropriate credit is giving. This is funny. They copy hundreds of BLFS pages (verbatim, mind you) into the work at http://cblfs.cross-lfs.org/index.php/Main_Page and don't mention anywhere in their book that the work was copied directly from BLFS. There's even this note on CBLFS: Please don't add information from BLFS without acknowledging the source. BLFS is copyrighted but copying is allowed with attribution. Too bad that they don't practice what they preach. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Mailing lists archives
Dan Nicholson wrote: On Wed, Dec 3, 2008 at 12:37 PM, William Harrington [EMAIL PROTECTED] wrote: Hello Everybody, Is there any way to get some of the archives from the mailing lists? They are all error 403 right now. I could be wrong, but I think Gerard disabled the archives because they were causing too much traffic on the server. That was on the old server, though, which was way overloaded. I don't know if that's still the case on the new server. I originally read this and thought, 'I've never had any trouble accessing the archives'. Now I see others posting about problems with the archives. I can read any of the archives just fine, and always have been able to. What exactly is supposed to be wrong? -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Future LFS 7.x Plans
Jeremy Huntwork wrote: Can we please put aside the egos and pointing fingers and work together to reach the common goal? Absolutely. More than anything, I got a chuckle this morning reading this thread and ended up posting something that was actually just me thinking out loud. I apologize for saying anything at all as it did not contribute to anything worthwhile in this thread. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Is LFS 6.4 ready for release?
Bruce Dubbs wrote: I don't know of any outstanding issues except the GMP issue with some combinations of hardware and CFLAGS setting. Although we recommend not using CFLAGS, that could be addressed with a note. It has not even been one week since the RC1. I don't think that is enough time. I would wait a bit, especially if there are not going to be any more RC versions. Unless of course, you are in a *hurry* to get it done. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Version in glibc
Ken Moffat wrote: #define RELEASE stable -#define VERSION 2.8 +#define VERSION 2.8-20080929-LFS [snip] Is there any interest in doing something like this ? I like it except the -LFS. As we don't modify it one bit, why add the LFS? It is a stock weekly tarball unmodified. I don't think LFS is appropriate. JMHO. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: wget/download utility
Rob Thornton wrote these words on 11/06/08 17:52 CST: There may be good reason for this but after building LFS for the 3rd time, I've come to realize there's no direct method of building BLFS packages with the final LFS system. No method for downloading packages exist if you're not building from a host with the tools already available. I built the system using the LFS CD on a PC with a clean HDD and had no method of acquiring wget, or any other package from BLFS, once I had booted the system into LFS. I had to re-boot the LFS 6.3 Live CD to acquire wget. FTP? If worse comes to worse, Anduin always has FTP sources available. -- Randy rmlscsi: [bogomips 1003.23] [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:55:01 up 2 days, 23:18, 1 user, load average: 0.12, 0.14, 0.09 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux API Headers
Bruce Dubbs wrote these words on 10/26/08 14:12 CST: Why do we do: make INSTALL_HDR_PATH=dest headers_install cp -rv dest/include/* /usr/include instead of: make INSTALL_HDR_PATH=/usr/include headers_install I just asked that question a week ago! (and was answered) Anyway, it's because the headers_install process first completely removes everything in the target directory which would wipe out the stuff that is in there in Chapter 5. In Chapter 6 we could actually change it to go straight to /usr/include as there should be no files in there at the time of the headers install. -- Randy rmlinux: [bogomips 3992.15] [GNU ld version 2.17] [gcc (GCC) 4.1.2] [GNU C Library stable release version 2.5] [Linux 2.6.21.5 i686] 14:16:00 up 4 days, 5:27, 5 users, load average: 2.00, 2.13, 2.80 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux API Headers
Bruce Dubbs wrote these words on 10/26/08 14:28 CST: OK. I'll add a sentence to explain that. Would you go ahead and assign yourself ticket #2167 as well? ( http://wiki.linuxfromscratch.org/lfs/ticket/2167 ) -- Randy rmlinux: [bogomips 3992.15] [GNU ld version 2.17] [gcc (GCC) 4.1.2] [GNU C Library stable release version 2.5] [Linux 2.6.21.5 i686] 14:30:00 up 4 days, 5:41, 5 users, load average: 2.31, 2.23, 2.45 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux API Headers
Jeremy Huntwork wrote these words on 10/26/08 14:34 CST: Before you go changing anything, see here: I didn't mean Bruce should actually change anything. My response was more on the technical side in that if it *were* changed, the end result of someone following the book would be identical to what we have now. -- Randy rmlinux: [bogomips 3992.15] [GNU ld version 2.17] [gcc (GCC) 4.1.2] [GNU C Library stable release version 2.5] [Linux 2.6.21.5 i686] 14:38:01 up 4 days, 5:49, 5 users, load average: 2.33, 2.22, 2.34 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: ICA/Farce
Bruce Dubbs wrote these words on 10/26/08 16:32 CST: Greg Schafer wrote: I've never looked at jhalfs but I understand it implements my ICA algorithms. My own scripts have been getting exceptionally clean results lately now that the randomness in GCC builds has apparently gone as of GCC 4.3. I'll happily check any results you can post up. Umm, no. jhalfs parses the xml of the book and creates a Makefile that builds by the LFS book. Actually, it is quite convenient. It was my understanding that the ICA stuff was built into jhalfs. You just had to set the switch for it to actually do it. I could be wrong, but it seems Manual used to do that all the time. Gee, I miss Manual being around. -- Randy rmlinux: [bogomips 3992.15] [GNU ld version 2.17] [gcc (GCC) 4.1.2] [GNU C Library stable release version 2.5] [Linux 2.6.21.5 i686] 16:37:01 up 4 days, 7:48, 5 users, load average: 3.25, 2.53, 2.36 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Findutils-4.4.0 testsuite failure (r8685)
Matthew Burgess wrote these words on 10/21/08 12:39 CST: Done, #2257. Targetted for 6.4. This ticket is a duplicate of #2240. I've closed #2257 and have had #2240 assigned to me. I'll be updating the book and closing all my tickets as soon as my current build finishes, and I've built a few BLFS packages. BTW, I'm building with the 2.6.27.2 kernel. So far, no problems. All the toolchain packages compile perfectly and 0 errors were noted in the test suites. -- Randy rmlinux: [bogomips 3992.15] [GNU ld version 2.17] [gcc (GCC) 4.1.2] [GNU C Library stable release version 2.5] [Linux 2.6.21.5 i686] 13:10:00 up 1 day, 17:29, 4 users, load average: 0.39, 0.31, 0.14 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New Linux Headers method
Jeremy Huntwork wrote: There is a problem, however. The script uses open() but with 3 arguments instead of 2. From what I've found so far, this change in syntax was introduced in perl-5.8.0, so the installation of Linux Headers fails if the host's version of perl is 5.8.0. I'm investigating possibilities, such as modifying the script to use two parameters, but at least for now, adding a minimal perl to /tools beforehand solves the issue. The last stable release of Perl pre-5.8.0 was 5 years ago and the first stable release of Perl-5.8.0 was 6 and a half years ago. I'm not sure that LFS needs to worry about someone using a host from that vintage. It wouldn't pass many of the other prerequisites either. I realize this was just FYI, but since you casually mention adding a minimal Perl to /tools, I'd thought I'd mention that it really wouldn't do us any good. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Patch-2.5.9
[ from http://wiki.linuxfromscratch.org/lfs/ticket/2239 ] #2239: patch-2.5.9 Comment (by [EMAIL PROTECTED]): It used to be on the Gnu alpha site: http://alpha.gnu.org/gnu/ but is no longer there. The only place I can find it is: http://ftp.de.debian.org/debian/pool/main/p/patch/patch_2.5.9.orig.tar.gz I do remember a discussion from a few years ago about moving to this version, but since it was only on the 'alpha' server and not the main Gnu server, it was determined to stay with what we have (as it works). Not sure if we want to revisit this or not, but looking around today I noticed that most Distro's are using the 2.5.9 version in one way or another. Every one of the Distro's, however, is using it patched in one way or another. Makes me wonder if it is safe to use unpatched. The NEWS file in the package mentions some bug-fixes and some minor updates, but not much really. I didn't look at the actual ChangeLog. I think I'll post this over on -dev just to see if there is any input from the community. I will say this, I've never had a problem with the 2.5.4 version with anything, ever. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Udev Rules
Matthew Burgess wrote: I'd prefer to follow upstream and put the Udev supplied default rules in /lib/udev/rules.d. Bruce Dubbs wrote: I say keep them in /etc. Do we flip a coin? :-) Actually, I lean towards /lib/udev and I believe DJ and Dan do as well. Does this sort of make it a non-unanimous decision to go with /lib/udev? -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Chapter 6 Coreutils installation
Hi all, Just to satisfy my curiosity, why do we have the Coreutils installation so far up in the build order in Chapter 6? Is there a Coreutils binary that won't operate correctly from /tools/bin? Perhaps the chroot command? No big deal, just wondering if anyone knows. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Shadows 'groupmems' program segfaults
Hi all, I don't consider this a big issue, but want to throw it out there. I noticed when I ran the new Shadow 'groupmems' program, it segfaults. I didn't think to much about it at the time as this program is new to Shadow and the man page says you must create a special group and set the program with GID permissions (2775) which I didn't do. However, looking at the console, I see the actual errors produced by the segfault. Wondering if anyone can make anything from this: groupmems[13783]: segfault at 72657375 ip b7feb18b sp bf8eac2c error 4 in libc-2.8.so[b7f79000+13a000] groupmems[13823]: segfault at 72657375 ip b7fa118b sp bfea11dc error 4 in libc-2.8.so[b7f2f000+13a000] groupmems[13824]: segfault at c ip 0804975f sp bfbb6780 error 4 in groupmems[8048000+5000] -- Randy rmlscsi: [bogomips 1003.23] [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] 11:09:00 up 17 min, 1 user, load average: 0.33, 0.72, 0.56 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: A little problem in lfs-book
Jean-Philippe MENGUAL wrote these words on 10/12/08 11:20 CST: I followed the lfs updates via lfs-book. But in archives (and in my mailbox), revisions go from r8593 to r8595, without r8594. And when I study r8595, I see something happent in r8594. Is there a way to see what happent? what are changes in this revision? Or if someone can tell me files which changed, I could compare new source and former source file (in html joo.. That must be the commit that Robert made that simply added a -v to the cp command in the Expect instructions. Robert didn't at the time have proper permissions to post to -book, therefore the post didn't come through. You can check the ChangeLog on October 6 and see the entry. HTH. -- Randy rmlscsi: [bogomips 1003.23] [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] 11:29:01 up 37 min, 1 user, load average: 0.04, 0.02, 0.15 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Chapter 6 Coreutils installation
Robert Connolly wrote these words on 10/12/08 11:27 CST:
There may not be a technical reason for installing Coreutils early, just that
it's one of the most heavily used packages.
I know there was much work put into rearranging the build order of
the various packages so that as much as possible would be built in
alphabetical order.
I'm trying to figure out why the binaries in /tools/{,s}bin wouldn't
work. I'm sure there's a good reason, I'd just like to know what it
is. :-)
Same with the Sed package, why couldn't /tools/bin/sed be adequate
until Sed is built in Chapter 6?
--
Randy
rmlscsi: [bogomips 1003.23] [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]
11:31:00 up 39 min, 1 user, load average: 0.04, 0.03, 0.13
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Chapter 6 Coreutils installation
Dan Nicholson wrote these words on 10/12/08 11:46 CST: Usually the reason is because the path to the tools gets built into another script/program. In the dependencies appendix, it says that sed must be built before e2fsprogs. I think it's mk_cmds that hardcodes the location of sed, but that's just a guess. I think coreutils must be built before bash because of something that gets substituted into bashbug. I was out at the barn feeding the animals and I thought the same exact thing. That some *broken* packages have hard-coded paths to /usr. But it's been a long time since we alphabetized the installation and almost every package has been updated since. I wonder if that brokenness has been fixed. Worth a jhalfs try to see if we can move coreutils and sed into alphabetic order. -- Randy rmlscsi: [bogomips 1003.23] [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] 11:54:00 up 1:02, 1 user, load average: 0.07, 0.02, 0.03 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Shadows 'groupmems' program segfaults
Robert Connolly wrote: As root, I tried every 'groupmems' option, and they all work. I'm using shadow-4.1.2.1, glibc-2.8-20080908, binutils-2.18.50.0.9, and gcc-4.2.5-20080903. I cannot reproduce the segfault. Not sure why. Strange. One thing that needs to be reported upstream, however. The groupmems program only updates /etc/group and doesn't update /etc/gshadow. Seems the program should update both for consistency sake. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Bootscripts and Udev-config
Hi all, Mostly a question for DJ, but FYI for everyone else. I noticed in your experimental book you use an updated version of the bootscripts. Does SVN need to be updated as well? I know you and Dan did some stuff for the LSB side of things, but not sure if SVN needs to be updated. Probably so, as it can't hurt? And has there been any changes with the udev-config file since the 0522 version? -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: r8651 - in trunk/BOOK: chapter01 chapter06
[EMAIL PROTECTED] wrote: Author: dj Date: 2008-10-12 13:04:50 -0600 (Sun, 12 Oct 2008) New Revision: 8651 Modified: trunk/BOOK/chapter01/changelog.xml trunk/BOOK/chapter06/iproute2.xml Log: Removed broken move in iproute2 commands. DJ, there's much more broken than just that. The entire Iproute2 instruction set is hosed right now. See http://wiki.linuxfromscratch.org/lfs/ticket/2225 I didn't notice it because I actually *use* DESTDIR during Chapter 6 LFS so I don't see the issue. It is hard for me to test this as well, without overwriting some files on my system. Bumping the priority of the ticket to a blocker as we can't release until this is fixed. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Making the LFS System Bootable
[cc'ing to LFS-Dev] Wolfgang Messingschlager wrote: I suggest before issuing within grub setup (hd0) the file /boot/grub/menu.lst should be created. This is much safer, because it can happen that the system crashes between overwriting the MBT and creating /boot/grub/menu.lst. What is your opinion? I agree completely and my scripts have been doing it that way since forever. I really never bother to look at the book for this part of the build as my scripts have everything in it I need. In fact I create a README file, just to have info handy: cat /boot/grub/README EOF Edit the menu.lst file to set up the various boots you may have on the machine. Then run the grub program. At the grub prompt, use the following commands: root (hd0,3) # This tells grub where to find the staging files setup (hd0) # This is where grub will write the MBR Grub's nomenclature is different than Linux or Lilo. Grub starts numbering the hard drives at 0 and partitions at 0. Grub also skips cdroms and only lables hard disks. So, if Hard Disk A was the first device on IDE1 and a cdrom was the second device on IDE1, the first hard disk at IDE2 would be hd1. EOF Hopefully, someone else will comment and we'll open a ticket about this. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Making the LFS System Bootable
Trent Shea wrote: On Sunday 12 October 2008 14:11:49 Trent Shea wrote: I wouldn't want to start altering instructions to reflect possible scenarios though. Well, still... It feels odd that we would be worried about the system crashing at this point (ie. the last thing we are doing:). And configuring before installing feels weird *shrug*. Well, perhaps you could be convinced with the following. Note that I'm running the commands that the book tells you to run, and it actually looks for and utilizes the menu.lst file. And if the book says to create this file *after* running the following commands, don't you find *that* weird? grub root (hd0,3) Filesystem type is ext2fs, partition type 0x83 grub setup (hd0) Checking if /boot/grub/stage1 exists... yes Checking if /boot/grub/stage2 exists... yes Checking if /boot/grub/e2fs_stage1_5 exists... yes Running embed /boot/grub/e2fs_stage1_5 (hd0)... 15 sectors are embedded. succeeded Running install /boot/grub/stage1 (hd0) (hd0)1+15 p (hd0,3)/boot/grub/stage2 /boot/grub/menu.lst... succ eeded Done. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Udev Rules
Hi all, There was a ticket opened, and since closed as invalid that some Udev rules belong in /lib/udev instead of /etc/udev. To me, Udev rules are configuration items and belong in /etc, but that's just my opinion. There was a mention (not sure how valid it is) that the Udev maintainers suggest /lib/udev as the proper place. I'm posting this to see if anyone has any other information that may be relevant to this issue. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Udev Rules
DJ Lucas wrote: Sorry...already reopened as I didn't see Bruce's comment about closing it. Closed it again. Well anyway, Dan posted a link to the conversation upstream. http://thread.gmane.org/gmane.linux.hotplug.devel/12895 Bottom line, it is still left to opinion for now. However, I too am leaning towards /lib/udev/rules.d myself for both rule sets. Taken from the README: Count me as sitting on the fence with no preference. If anything, I lean to going with what the maintainers prefer. If the rules are not meant to be edited, then I'm indifferent. Count my vote to whatever the majority agrees upon. We can always open the ticket again. But discussion should occur here, and not in -book. Here's me, sitting on the fence, leaning towards Kay Seivers (sp?). -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Using the 'readlink' command
DJ Lucas wrote: Randy McMurchy wrote: I used the readlink command in the Udev instructions to move the .so files to /usr/lib as they are initially installed in /lib. Credit Dan Nicholson for the initial work on this change. This was started in BLFS and I believe it to be the right direction to go. Wait, which libs? I haven't got a chance to look at a finished system. Are any of those libs used when udev starts? If so, then the situation is easy, the libraries cannot be moved. Simple test case: Um, DJ, I was speaking of the .so files, not the actual libraries. .so files belong in /usr/lib, just like .la and .a files. The point being is that I used a different method to recreate them in /usr/lib and I'm trying to see if the community approves of it. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Udev test suite
Bruce Dubbs wrote: I noted that it didn't do anything too. I suppose we need to now add: This package does not come with a test suite. That was done during the package update. :-) -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Linux Headers Installation
Hi all, There's a minor ticket about explaining what the installation commands in the Linux Headers installation do, and it occurred to me that is it possible that there's a redundant step? Here's the existing commands (with my comments for the book inserted as well): First ensure the source tree is completely clean: make mrproper Next, ensure all the required headers are complete and available: make headers_check Now here is where I don't really see the need for two commands: make INSTALL_HDR_PATH=dest headers_install cp -rv dest/include/* /usr/include Couldn't we just use the command: make INSTALL_HDR_PATH=/usr headers_install and be done with it? Pardon me if I'm missing the obvious, or I'm not doing my research. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Does the M4 package need to be identified as a host requirement?
DJ Lucas wrote: Randy McMurchy wrote: Jeremy Huntwork wrote these words on 10/06/08 10:45 CST: I would think that adding it to the Host Requirements page would be slightly preferable. Here's my thinking: We already have bison as a host req. Bison depends on m4, so most distros I know will have m4 installed as a dependency of bison. Even building bison from source requires that you first build m4, anyway. So I tend to think of Bison and M4 going hand in hand. Why add an extra thing to build if by far the majority of systems will have already had m4 installed due to the bison req? I lean to agreeing with Jeremy on this one. If M4 is probably present on the host (due to it being required by bison), then it is one less package that needs to be built in Chapter 5. We need to resolve this issue, so let's make some sort of decision one way or another. Other suggestions are welcome. It has to built in Chpater 5 for the chapter6 GMP regardless. When is the only question. I see no need to add a host requirement if m4 can be built right after binutils' first pass. I suppose it could be moved way up in the chain for Chapter 6, but I though that we wanted all tools compiled by the last built version of gcc and binutils. Obviously, BinUtils, GMP and MPFR are exceptions to this rule (but are compiled by the same version of the target compiler type and libs), should M4 be an exception also? Sorry for quoting the entire previous post, but the material is all relevant, and we need to make a decision. Here's the choices: 1. Use Jeremy's suggestion that since Bison is already a prerequisite, which mean that m4 is probably on the host as well, simply disregard the issue and leave the Chapter 5 M4 installation in its alphabetical position. 2. Make M4 a prerequisite. 3. Move the M4 Chapter 5 installation to be right after the Binutils Pass 1 installation. Let's make a decision and put this one to bed. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Headers Installation
Reece Dunn wrote: I asked this question on 21/11/2007 (Linux Headers question [http://linuxfromscratch.org/pipermail/lfs-dev/2007-November/060618.html]), which likely resulted in that ticket item. I got essentially the same response from Thomas Trepl and Mark Rosenstand: Thomas Trepl wrote: Because this would clean the /usr/include first and than install the headers. With this, some installed headers will be lost. Ahh, I didn't realize that INSTALL_HDR_PATH/include was cleaned before the headers were installed. This would explain Chapter 5 but not Chapter 6. /usr/include would be empty during the Headers installation in chapter 6. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Time for some football :-) (off-topic)
Hi all, I'm probably off-line the rest of the night as my son is playing in a college football game on TV and it's about to start. I'm going to sit back, relax and watch it. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [LFS Trac] #2056: Consider using --disable-shared for gcc pass 1
LFS Trac wrote: #2056: Consider using --disable-shared for gcc pass 1 +--- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: enhancement | Status: closed Priority: high|Milestone: 6.4 Component: Book| Version: SVN Severity: normal | Resolution: fixed Keywords: | +--- Changes (by [EMAIL PROTECTED]): * status: assigned = closed * resolution: = fixed Comment: Fixed in r8647. [Football game over :-) ] In my opinion, this puts the objective of releasing the new version at the end of the month sort of at risk. Perhaps I'm being too concerned about it, but changing the build of a toolchain package a couple weeks before release is risky. I'm not saying the change is a bad thing, I just think it interferes with Bruce's release schedule. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Udev test suite
Hi all, Starting in version 126 of Udev, the test directory including the udev-test.pl test file no longer ships in the tarball. Though DJ's instructions for version 126 does indeed change the 'make test' to 'make check', 'make check' does nothing. I've been looking over the udev mailing list and cannot see a thing about the test directory being removed. They still actively update and patch the udev-test.pl file in the git repo as noted in the ChangeLog they speak of it on the mailing list. Does anyone know if this 'test' directory and the included udev-test.pl test file is for internal udev developer use only now? For the time being, I'm updating the book to version 130 and will simply say that this package does not have a test suite. Not sure how DJ worked out that 'make check' did something. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Using the 'readlink' command
Hi all, I used the readlink command in the Udev instructions to move the .so files to /usr/lib as they are initially installed in /lib. Credit Dan Nicholson for the initial work on this change. This was started in BLFS and I believe it to be the right direction to go. This has benefits, and drawbacks. The benefits being that we'll never have to update the command to reflect the maintainer of the package updating the library file names (foobar.so.0.0.1 to foobar.so.0.1.0 and so forth and so on). The drawback being that if the commands are issued more than once, after the /lib/file.so file has been removed, the command will fail in that it will create invalid symlinks. I'm looking for the community to decide which way to go. If you're not sure what I'm speaking of, compare the current Readline instructions to recreate the .so files in /usr/lib against the new instructions used for the Udev instructions. I really don't care either way, I just want the community to be in agreement. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Problems with 'file --exclude troff'
Hi all,
I'm new to this list but I searched the archives for
anything that might be related to the issue I'm about
to describe and couldn't find anything so I thought
I'd bring it up here.
It was brought to my attention that sometime after
the 4.23 release the -e (--exclude) parameter did not
work for the 'troff' test. Using 4.26, I looked into
into the code and found the following:
Using the output from the man page, there are 3 -e
tests that don't work. The 'fortran', 'token', and
'troff' tests. Seems to me looking through the ChangeLog
that the 'fortran' test was converted into a 'soft'
test, so that explains why that one wouldn't work
(though the man page could use updating).
The 'token' test fails, because the man page actually
identifies it incorrectly and it should be 'tokens'
instead. I can't figure out the 'troff' test as there
isn't anything in any of the ChangeLogs that show that
it was intentionally removed.
Anyway, I created this patch (which probably is wrong
because I re-enabled the fortran test), but it does
fix the 'tokens' and 'troff' tests.
Please let me know if indeed the 'troff' exclude test
was intentionally removed, or if it had been done by
mistake somehow.
Patch follows:
diff -Naur file-orig/doc/file.man file-4.26/doc/file.man
--- file-orig/doc/file.man 2008-03-07 15:00:07.0 +
+++ file-4.26/doc/file.man 2008-10-08 13:57:37.0 +
@@ -192,7 +192,7 @@
Don't consult magic files.
.It tar
Don't examine tar files.
-.It token
+.It tokens
Don't look for known tokens inside ascii files.
.It troff
Don't look for troff sequences inside ascii files.
diff -Naur file-orig/src/file.c file-4.26/src/file.c
--- file-orig/src/file.c2008-07-03 15:48:18.0 +
+++ file-4.26/src/file.c2008-10-08 13:59:14.0 +
@@ -148,9 +148,11 @@
{ ascii, MAGIC_NO_CHECK_ASCII },
{ compress, MAGIC_NO_CHECK_COMPRESS },
{ elf,MAGIC_NO_CHECK_ELF },
+ { fortran,MAGIC_NO_CHECK_FORTRAN },
{ soft, MAGIC_NO_CHECK_SOFT },
{ tar,MAGIC_NO_CHECK_TAR },
{ tokens, MAGIC_NO_CHECK_TOKENS },
+ { troff, MAGIC_NO_CHECK_TROFF },
};
/* makes islower etc work for other langs */
--
Randy
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
[Fwd: Re: Problems with 'file --exclude troff']
FYI. This means that the troff test in the File package is not broken. I see no reason to update to the latest version. I also cannot see using the patch I wrote, but I will put a 'sed' in the instructions to fix the man page so that the correct --exclude tests are identified. Original Message Subject: Re: Problems with 'file --exclude troff' Date: Thu, 9 Oct 2008 13:26:24 -0400 From: [EMAIL PROTECTED] (Christos Zoulas) Reply-To: Announcements for the file UNIX utility [EMAIL PROTECTED] Organization: Astron Software To: Announcements for the file UNIX utility [EMAIL PROTECTED] CC: LFS Development lfs-dev@linuxfromscratch.org On Oct 9, 3:04am, [EMAIL PROTECTED] (Randy McMurchy) wrote: -- Subject: Problems with 'file --exclude troff' [snip my message to the list] Well, both the fortran test and the troff test have been converted to soft tests. I have removed them from the doc and changed token to tokens. Thanks, christos -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Fwd: Re: Problems with 'file --exclude troff']
Randy McMurchy wrote: This means that the troff test in the File package is not broken. I see no reason to update to the latest version. That should be: I see no reason to *not* update to the latest version. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Shadow update
Hi all, I made many, many changes to the Shadow package during the update to the most recent version. I like the changes, but I encourage everyone that can to render the book and look at it. If you can't render it, it will be available tomorrow in the SVN book. If there are problems or questions, let's discuss here first, and if we have to, we'll open a new Trac ticket. The old ticket for the Shadow update was filled with many, many entries and there was no consensus reached on what to do with the useradd issue. I did what I thought was best. Please review. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New personal experimental book
DJ Lucas wrote: Roll back to file-4.21. The newer versions of file do not display the character set if type is text/troff Well, that is a separate issue. File is still broken (either 4.21 with illogical guessing at the character encoding of text files, or 4.25 with non-working -e switch). I didn't bother trying the -e switch with 4.26 because I incorrectly assumed that the missing charset= output was a regression. I can't determine what version of File to use in the book. I used 4.26. DJ's book uses 4.23 (4.23 is what is in SVN right now). I really couldn't find the resolution of the problem described above in all the different posts on the subject, so I don't know which version to use. I'll skip the File package update for now. Any advice would be appreciated. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New personal experimental book
DJ Lucas wrote: I reverted to 4.23. I never got a chance to see if 4.26 worked. In 4.25, the -e (exclude) switch is broken, both long an short options do not work. Yes, I've confirmed that. However, only *parts* of the -e switch are broken. And I see in the code why. I actually was able to patch the file.c source and things work again. Only thing is, it isn't broken per se. The code was actually removed from the source, yet left in the man page. Not sure what is up with that. I'm subscribing to the dev list for file and report this. If I get a reply back, I'll post back here. In the meantime, I feel good about using my patch, as all tests that I could muster seem to work okay. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New personal experimental book
Randy McMurchy wrote:
I actually
was able to patch the file.c source and things work again.
If anyone is interested in looking at or testing the patch,
here it is (it's also in the repo):
Submitted By:Randy McMurchy randy_at_linuxfromscratch_dot_org
Date:2008-10-08
Initial Package Version: 4.26
Upstream Status: Attempting to notify upstream of the problem
Origin: Self
Description: Fixes the -e (--exclude) parameter to actually do
what the documentation says it should do
diff -Naur file-orig/doc/file.man file-4.26/doc/file.man
--- file-orig/doc/file.man 2008-03-07 15:00:07.0 +
+++ file-4.26/doc/file.man 2008-10-08 13:57:37.0 +
@@ -192,7 +192,7 @@
Don't consult magic files.
.It tar
Don't examine tar files.
-.It token
+.It tokens
Don't look for known tokens inside ascii files.
.It troff
Don't look for troff sequences inside ascii files.
diff -Naur file-orig/src/file.c file-4.26/src/file.c
--- file-orig/src/file.c2008-07-03 15:48:18.0 +
+++ file-4.26/src/file.c2008-10-08 13:59:14.0 +
@@ -148,9 +148,11 @@
{ ascii, MAGIC_NO_CHECK_ASCII },
{ compress, MAGIC_NO_CHECK_COMPRESS },
{ elf,MAGIC_NO_CHECK_ELF },
+ { fortran,MAGIC_NO_CHECK_FORTRAN },
{ soft, MAGIC_NO_CHECK_SOFT },
{ tar,MAGIC_NO_CHECK_TAR },
{ tokens, MAGIC_NO_CHECK_TOKENS },
+ { troff, MAGIC_NO_CHECK_TROFF },
};
/* makes islower etc work for other langs */
--
Randy
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Final Updates
Hi all, Sorry about not getting these final few package updates in the book. Real Life got in the way a little bit. I should have it all done by this evening, however. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
