Re: ICA/Farce
Jeremy Huntwork wrote: > Bruce Dubbs wrote: >> Umm, no. jhalfs parses the xml of the book and creates a Makefile that >> builds >> by the LFS book. Actually, it is quite convenient. > > ICA is in fact implemented as an optional feature of jhalfs. Which means > that when it's done building LFS by the book, it will try to build > itself again twice, much like the gcc bootstrapping process. I stand corrected. I see it now: [ ] Run comparison analysis on final stage -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fwd: Re: Document version not set with jhalfs-20081011
George Boudreau wrote: > Matthew Burgess wrote: >> Forwarding to lfs-dev...I'm currently unable to commit to SVN (my own >> network setup here). I'd guess we either need to revert back to the '-' or >> change it to '–' (note the additional ';'). >> >> George, how does 'xmllint' puke? It'd be nice if the LFS Book's validation >> Makefile target could catch this. >> > > xmllint prologue bookinfo.xml produces the following. > > Entity: line 1: parser error : Entity 'ndash' not defined > > 1999–2008 This looks like a problem with xmllint or it's invocation. Why doesn't it know about entities? This change was made in revision 4648 on 02/19/05. Why is is coming up now? I'd perver to keep the entity. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fwd: Re: Document version not set with jhalfs-20081011
George Boudreau wrote: > Bruce Dubbs wrote: >> George Boudreau wrote: >>> Matthew Burgess wrote: >>>> Forwarding to lfs-dev...I'm currently unable to commit to SVN (my own >>>> network setup here). I'd guess we either need to revert back to the '-' or >>>> change it to '–' (note the additional ';'). >>>> >>>> George, how does 'xmllint' puke? It'd be nice if the LFS Book's validation >>>> Makefile target could catch this. >>>> >>> xmllint prologue bookinfo.xml produces the following. >>> >>> Entity: line 1: parser error : Entity 'ndash' not defined >>> >>> 1999–2008 >> This looks like a problem with xmllint or it's invocation. Why doesn't it >> know >> about entities? This change was made in revision 4648 on 02/19/05. Why is >> is >> coming up now? >> >> I'd perver to keep the entity. > > After dusting off my xml. Predefined entities in xml "quot, amp, apos, > lt, gt". The hyphen '-' or 'endash' is not a defined in XML but is > defined for XHTML. You must either add in > general.ent or just use a hypen in the copyright date span. Either way > I am happy. Fixed at LFS revision 8715. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
perl-5.10.0
I'm puzzling over two tickets concerning perl: 2071 and 2227
It looks like 2071 says that we need to add -Dvendorprefix=/usr to the
configuration process, but configure.gnu doesn't support it.
Dan mentions that he uses:
sh ./Configure -des \
-Dprefix=/usr \
-Dsiteprefix=/usr \
-Dvendorprefix=/usr \
-Doptimize="${CFLAGS}" \
${LDFLAGS:+-Dldflags="$LDFLAGS"} \
-Dscriptdir=/usr/bin \
-Dman1dir=/usr/share/man/man1 \
-Dman3dir=/usr/share/man/man3pm \
-Dhtml1dir=/usr/share/doc/perl5/html1 \
-Dhtml3dir=/usr/share/doc/perl5/html3 \
-Dpager="/usr/bin/less -isR" \
-Dmyhostname=localhost \
[EMAIL PROTECTED]
Are there any comments about this? Should I just drop in these instructions?
The second ticket, 2227, concerns a group of patches, including one reasonably
severe security patch. This seems to be fixed in the existing patch. The
question is whether we really need to add any additional perl patches. There
seem to be a lot of patches, but they are not consolidated. I can't tell which
are meaningful and which are not. I'm tempted to mark this wontfix.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Package freeze
Right now all the tickets for packages and instructions have been fixed. Any new packages should be targeted to 7.0 from now on. If there is a strong security issue, we will address that, but normal updates should not go into 6.4. There are three open tickets for 6.4. One is a bootscript issue and two are text issues. I will plan on cutting a -rc1 about next Wednesday to let the current -dev percolate a bit. If all goes well, then a full release should occur around Nov 15. That's about two weeks late, but not bad considering the aggressive schedule we set. Comments are welcome. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-20081031
TheOldFellow wrote: > Just a note to say that I built and booted it today. No issues. I > even ran almost all the tests. I added Device-mapper+LVM2 and replaced > SysVinit with runit as is my wont, so this doesn't test the bootscripts. Thank you for the feedback Richard. I am planning on cutting -rc1 later today. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LFS 6.4-rc1 is released
The Linux From Scratch community is pleased to announce the release of LFS Version 6.4 Release Candidate 1. This release includes numerous changes to LFS-6.3 (including update to Linux-2.6.27.4, GCC-4.3.2, Glibc-2.8) and security fixes. It also includes editorial work on the explanatory material throughout the book, improving both the clarity and accuracy of the text. You can read the book online at http://www.linuxfromscratch.org/lfs/view/6.4-rc1/, or download to read locally from http://www.linuxfromscratch.org/lfs/downloads/6.4-rc1/ Feedback to [EMAIL PROTECTED] is appreciated. -- Bruce Dubbs LFS Release Manager -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Download for Ncurses 5.6 broken in LFS 6.4 rc-1
Rick Houkes wrote: > While attempting to build LFS 6.4 rc-1, during to process of getting > all necessary packages and patches I found out the download link for > Ncurses 5.6 is broken. Ncurses 5.6 can still be downloaded here: > ftp://ftp.gnu.org/gnu/ncurses/ncurses-5.6.tar.gz. Fixed. Thanks. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: expect 5.43.0 / tcl 8.5.x
Tobias Gasser wrote: > the current rc1 and SVN-20081106 both require the following patch > > expect-5.43.0-tcl_8.5.4_fix-1.patch > > > both versions use tcl 8.5.5. > > as i did not compile the book but just am downloading the packages i > can't tell you wether the fix is still required or not. > > but imho either rename the patch or remove the patch. I renamed the patch. Thanks. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gmp required ABI=32
Gilles Espinasse wrote: > From: "Tobias Gasser" <[EMAIL PROTECTED]> >> i had to add ABI=32 as my system was identified ad 64bit. >> >> ./configure ABI=32 --prefix=/usr --enable-cxx --enable-mpbsd >> >> i'm using CFLAGS="-O3 -march=i486" as a global setting, overwritten for >> some special cases mentionned in the book. >> >> any idea why i have to add ABI=32 ??? >> > What is the answer of uname -m on this machine? or /proc/cpuinfo ? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Is LFS 6.4 ready for release?
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. -- Bruce -- 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?
Randy McMurchy wrote: > 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. I thought it was a whole week. I sent the announcement of -rc1 at 00:55 Last Thursday. Doing all that needs to be done for the final release will take me a day. I'm not in a particular hurry if there are issues, but I really haven't heard any. The "hurry" is that we haven't released a book since Aug 28 last year. How long do you think we should wait? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Version in glibc
Randy McMurchy wrote: > 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. It would be useful to identify the distro. This could easily be done in a sed. I like 2.8-20080929-for_LFS -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: man-pages-3.13
Lefteris Dimitroulakis wrote: > Is it too late to update to man-pages-3.13? We probably need to put a note into the book that the man pages are updated relatively frequently and the latest version can probably be used without issues. Thoughts? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: License of the book - really version 2.0 of creative commons?
Thomas Reitelbach wrote: > Am Sonntag 16 November 2008 09:31:20 schrieb Thomas Reitelbach: >> Hello list, >> >> I'm currently in the process of translating current 6.4 LFS to german. >> Now I'm wondering about licensing. The book says it's licensed under >> „Attribution-NonCommercial-ShareAlike 2.0“. >> >> But: I cannot find this licence at creativecommons.org, at least not for >> the USA. Only Version 3.0 seems to be available. And at a first glance it >> looks like the license text in the book is an exact copy of version 3.0 of >> this license (though I did not compare each and every character of the >> licence texts). >> >> So maybe there is a typo? Is it possible that you chose „Attribution- >> NonCommercial-ShareAlike 3.0“ as licence but by mistake wrote "2.0"? >> >> Please can you clarify this? It is important to know because I have to >> choose the correct translated license text from creativecommons.org for the >> book. > > Replying to myself ... I now found a "generic" version of the 2.0 licence > which seems the correct one, used in the book. But I still see no obvious > difference between them. 2.0 was current when I added the license. Perhaps they rolled the number ot make it the same as GPL, but that's just speculation. Since the entire text is in the book and not just a reference, I don't see a need to change it. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Please add a l10n block for "de" in lfs-l10n.xml
Thomas Reitelbach wrote: > Hello list, > > can someone please add the following translated l10n block to > > stylesheets/lfs-xsl/lfs-l10n.xml > > (diff also attached as file). This is necessary to provide german > translations > for some standard terms. Other languages are already included in the file, so > i guess it will not be a problem to include german as well :-) OK, added. Thanks for doing this. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: License of the book - really version 2.0 of creative commons?
Thomas Reitelbach wrote: > Am Sonntag 16 November 2008 19:37:43 schrieb Bruce Dubbs: >> 2.0 was current when I added the license. Perhaps they rolled the number >> ot make it the same as GPL, but that's just speculation. Since the entire >> text is in the book and not just a reference, I don't see a need to change >> it. > > I didn't want to ask to change the number. > I wasn't able to find the mentioned licence version 2.0 on the website of > creative commons. Now I found it. > > The reason why this is useful to me is, that there exist ready-to-use > translations of various licence texts at creativecommons.org. Now I only have > to choose the correct licence text and thus the correct translation for the > book. > > Now that I found the correct english licence text I can choose the correct > german licence text and use it without translating it myself. In fact I did > not really include the translated licence text into the book because the > german licence uses a completely different text structure, which is > incompatible with the present docbook structure of in the book. > So I have chosen to not translate the licence but instead include a link to > the german translation to the website of creative commons. > > Hm, what a longish explanation ;-) LOL. OK. Thanks for the info. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Releasing LFS-6.4
LFS-6.4-rc1 has been out two and a half weeks now and there are really no significant issues that I know about. Of course there are some changes that could be made, but I don't know of any that really *need* to be made. A problem with delaying is that newer packages continue to be available, so the longer we go, the more out of date -rc1 becomes. Are there any objections to me releasing 6.4 tomorrow (23 Nov)? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LFS 6.4 is released
The Linux From Scratch community is pleased to announce the release of LFS Version 6.4. This release includes numerous changes to LFS-6.3 (including update to Linux-2.6.27.4, GCC-4.3.2, Glibc-2.8) and security fixes. It also includes editorial work on the explanatory material throughout the book, improving both the clarity and accuracy of the text. For a full list of package changes, see http://www.linuxfromscratch.org/lfs/view/stable/chapter01/whatsnew.html You can read the book online at http://www.linuxfromscratch.org/lfs/view/6.4/, or download to read locally from http://www.linuxfromscratch.org/lfs/downloads/6.4/ -- Bruce Dubbs LFS Release Manager -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS 6.4 is released
Thomas Reitelbach wrote: > The german translation is already available at my site. > > http://oss.erdfunkstelle.de/lfs-de/ Thanks Thomas. I updated the website to add a link to 6.4 German version. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Problems with PDF Output
/S/SBUThomas Reitelbach wrote: > Hello list, > > the german translation for LFS 6.4 is already finished. But I got a problem > with the PDF output and I'm pretty sure that you can help me :) > > Attached you'll find a little screenshot which shows, how the translated PDF > looks like. You'll notice, that the translated text is too long, which makes > it break into the next line. > > I'll have to modify the margin in such a way, that the column with "22 SBU" > has more space to the left. But I cannot find the correct place in the books > stylesheets. Can someone please point me to the correct place? That is some magic that is in stylesheets/lfs-xsl/lfs-pdf.xsl or in one of the files in stylesheets/lfs-xsl/pdf/. I didn't publish a pdf for LFS 6.4 because there were many problems. There are many places, like in the included boot scripts and especially udev files, where the line length exceeds 72 characters and causes overflow to the right and truncation. There is an even greater problem where the number of lines in a single construct are too much for a page. This includes many of the boot scripts and also the table in 6.47. Man-DB-2.5.2. I don't know how to fix this so I just didn't include the pdf in the downloads section. If someone can come up with a fix, I'd be glad to publish the pdf too. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS 6.4 is released
Benjamin John wrote: > Hello, it would be nice if someone could create a tag for 6.4 in the svn > repository. All older versions are tagged and jhalfs serches in the tags for > the sources of the book. OK, done. Thanks for the reminder. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Problems with PDF Output
Thomas Reitelbach wrote: > But it would have been wise to fix this before the release. I'm of course not > one of those people to decide such things. But for the last releases i > believe that someone (who?) resolved rendering issues like this with the > book. I've made that last couple of releases. In this case, I decided to release without the pdf for now because further delay would make too many packages out of date. We need to discuss a couple of issues. 1. How do we handle the bootscripts and udev config files' excessive line length? We can go in and adjust the bootscripts' line lengths to have a max of 72 characters, but the udev config does not allow line breaks. 2. How do we break up long sections so the rendering goes across multiple pages? One solution would be to strip the bootscripts and udev files completely from the book (at least for the pdf rendering) as was done before 6.4. The still leaves the problem of properly rendering the long table in Man-DB. I suppose we could double it up to four columns. Comments? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Problems with PDF Output
DJ Lucas wrote: > Forgive the obvious, but I'm thinking a smaller font for these parts. I > don't see any problem with having smaller text in these sections of the > book as they are tables and appendixes, not necessarily required > reading. I don't have any clue how to go about doing this, but it seems > to me that this would be the best option. Yes, I thought of that, but I don't know how to adjust it within the pdf. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: The value of 64-bit vs 32-bit
On Thu, Nov 27, 2008 at 8:23 PM, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: I'm responding to the initial post, but I've read several responses and implicitly am responding to those too. > About a month or so ago I'd said I'd start looking into writing a > section for LFS that deals with pros/cons of using full 64-bit > libs/binaries in Linux, since LFS is considering adding in 64-bit support. > > I came across this article: > > http://forums.amd.com/devblog/blogpost.cfm?threadid=93648&catid=317 > > and several other articles from people who at various times benchmarked > performance with 32-bit vs 64-bit on the same hardware. An interesting article. One thing to note is that a 5% or 10% performance change is really negligible. A person needs to see at least a 50% improvement to even notice. I think that's documented in research, but I can't put my finger on it right now. > Just two quick questions: > > * Any comments on the details provided in the above article, > specifically in how that might relate to LFS? The issue is compatibility vs speed. The speed improvements are not significant for most applications. It's true that if you are going to memory map a very large file, as in editing a movie, then the increased address space would be quite useful. Other areas are when physical ram exceeds 4G or very high accuracy calculations (e.g. solving systems of differential equations) are needed, the increased address space and register size is needed. One commenter said that virtually everything except flash and grub were 64 bit. I believe that flash is a very important application for many users and until that becomes available, many users will reject 64-bit Linux. Compatibility of older hardware is also an issue. Many of the older hardware drivers may have issues when trying to run in 64-bit mode. I've heard of a lot of problems with things like wifi drivers in some commercial 64 bit distros. Building a multi-lib system will be much more complicated than a 32-bit system. For that reason alone, I wouldn't recommend that users try it until they were successful in building a 32-bit LFS and a great deal of 32-bit BLFS. > * If you were to benchmark 32-bit vs 64-bit on an LFS system, what would > your tests include? For us, the easiest benchmark is compile times. We really don't have the resources to benchmark real applications. In addition, many of the "benchmarks" I see published are garbage -- frames / second of some Windows game comes to mind. As a side note to Bryan: The Itanium is still alive and kicking. It was all over the place at the Supercomputer 2008 Conference in Austin earlier this month. The biggest 'Pro' to doing a 64-bit LFS is "Because we can, and we like to experiment." I still feel for the vast majority of users, it is not needed for every day use. There is a huge difference between the jump from 16-bit processors to 32-bit processors and the next jump from 32-bits to 64-bits. Remember that the numbers here are exponents. Each increment represents doubling the address space and the value a single entry can represent. 16 bits was clearly unsatisfactory because a 64K byte address space just wasn't enough. It's not clear that most users need more than 4G of address space. Remember that the most common size of data is still the 8-bit char for integer data and even the 80287 did floating point with an 80-bit standard. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[Fwd: LFS 6.4: Helped me with with "/tools/bin/ld: cannot find -lgcc_eh " in Chapter 5.7 Patch for glibc --]
Original Message Subject: LFS 6.4: Helped me with with "/tools/bin/ld: cannot find -lgcc_eh " in Chapter 5.7 Patch for glibc -- Date: Thu, 27 Nov 2008 20:43:45 +0100 From: Druckerfehler <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Hey there, i wan't to submit the patch http://trac.cross-lfs.org/browser/trunk/patches/glibc-2.8-libgcc_eh-1.patch?format=txt because I get'nt clear through Chapter 5.7 (also S support mailing list- most of others didn't do http://www.linuxfromscratch.org/hints/downloads/files/one-partition-hint.txt). Every time i tried to install 5.7. Glibc-2.8-20080929 i got the following: /tools/bin/ld: cannot find -lgcc_eh collect2: ld returned 1 exit status make[2]: *** [/mnt/lfs/sources/glibc-build/iconv/iconvconfig] Error 1 make[2]: Leaving directory `/home/Druckerfehler/lfs-packages/glibc-2.8-20080929/iconv' make[1]: *** [iconv/others] Error 2 make[1]: Leaving directory `/home/Druckerfehler/lfs-packages/glibc-2.8-20080929' make: *** [all] Error 2 The directory contains I did an symlink to /home/Druckerfehler/lfs-packages/glibc-2.8-20080929 as /mnt/lfs/sources/ of the following reasons: - I have not enough space to build it directly on /mnt/lfs/ (i want to save space) - Just wan't to keep a backup of these downloaded files - Jus't have to "rm -r" the folders where i did a compile procedure - Mounted (as slightly mentioned before) a file as a filesystem with the help ov /losetup /dev/loop0 ... - Can't create a partition (sincy i have three primary partitions, which take the whole place, and don't want to change them) Now I'm on Part 6.25 and nothing seems to be wrong with that patch.. im using a cat /proc/version "Linux version 2.6.26-3.slh.1-sidux-686 (Debian 2.6.26-21) ([EMAIL PROTECTED]) (gcc version 4.3.1 (Debian 4.3.1-9) ) #1 SMP PREEMPT Wed Aug 20 23:56:34 UTC 2008" wich didn't work, until this patch, from a real and a virtual machine, using the same os,... :-( But this helped me... Btw I'd appreciate if youl'd make a notice to this patch in that (and the other chapters as well) in chapter 5.7 of LFS 6.4... Greetz -- http://linuxfromscratch.org/mailman/listinfo/patches FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Aiming for 7.0
Bryan Kadzban wrote: > Jeremy Huntwork wrote: >> Anything else? > > Ticket 2033 -- initramfs. This way people with crappy software "RAID1 > cards" (e.g. Promise, Highpoint, etc.) that require drivers in Windows, > can still boot from those cards. Also, support for MD RAID (*real* > software RAID ;-) ), LVM, and encrypted rootfs would be nice. > > (The mkinitramfs repo linked to from that ticket will already work for > everything above, except encrypted rootfs.) Even it it's poor hardware support, does the frequency of occurrence rise to the level of needing to be in the LFS book? As several comments in the ticket suggest, initramfs would be more appropriate for BLFS, but I'm thinking that even that is too much and an updated hint or wiki entry would be more appropriate. -- bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Aiming for 7.0
Jeremy Huntwork wrote: > Ok, so we have a fair amount of items we'd like to push into 7.0, some > of which, work has already begun. > > As far as step-by-step plan of attack goes, how does this sound? > > 1. Move to DIY's new build method in trunk. If we ignore multilib and > any extra arch support for this step, the changes required aren't > actually that many, and they all take place pretty early in chapter 5. > We can have trunk using the new build method within a day. That sounds fine to me. > 2. Add instructions for DESTDIR commands. I don't think there has yet > been a consensus yet on what type of PM to use. But, if we make the > instructions just slightly more PM friendly by adding in DESTDIR > commands it opens up a wide range of possibilities. If we limit the > changes now to just adding in DESTDIR commands and a short explanation > about what these mean somewhere or how to work with them, we should be > able to drop this into trunk in a short time (a day or two?). Otherwise > we may need a separate branch for PM. This is also good. IMO, trunk is fine. > 3. Merge all recent changes in trunk to the jh branch, copy that branch > to a new multi-arch branch and strip out anything extra that doesn't > really have to do with adding multiple archs. (I don't think there are > many, but I'd just have to do a quick look.) Hopefully making this its > own branch again would encourage a few more people to get involved in > finsihing up these changes. If desired, multilib support could also be > added to this branch. I'm not a big fan of branches. This would be fine for the trunk, but after the above two items are done and the changes have matured a bit. Do we have a solution for the boot loader for this? As a personal note, I guess I'll need to get a 64-bit system. I'm really still pretty happy with my current 3.2GHz/2G Ram. It almost never swaps and I use KDE and Vmware. I think my wife's system would work (it's an Intel 2160 with two cores) but she would not be happy. ... thinking about it, I don't think that's a viable solution. :) > 4. Ticket 2284, upgrade of Udev, and strip out udev-config. I doubt this > needs its own branch. What sort of time/work is involved here? Just do it. I don't think it will be a large time consumer. It could be done now. > 5. Ticket 2033. Include support for initramfs. Would this require a > separate branch, and can it be worked on in parallel to other changes, > or is it better to wait until other above changes are sorted out? This is one I don't agree with. This should be in BLFS. A pointer to a BLFS page in LFS would be OK, but this goes beyond the philosophy of LFS as it is only rarely needed. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Optional prefixes (targeting 7.0)
DJ Lucas wrote: > Guys and gals, > > Is there any real desire to support the optional installation prefixes > of X, QT, Gnome, and KDE in the book after package management enters? > Maybe I'm just being lazy, but at this point, I kinda view it as an > unnecessary maintenance burden. Not to mention that the idea of > building Gnome and various groups of dependents 2 more times is a bit > unattractive, (it's scripted after the first run so it's not like it's a > huge pile of work, just takes background time). That's probably even > extreme as I chose to do the most difficult pattern first. The minor > changes needed for this variant aren't likely to affect the other 3 > possible combinations, but I'll do at least the easy one once anyway for > validation. > > I imagine the same difficulty occurs with maintaining QT, KDE, and later > KDE-4. I'm not sure about supporting both KDE-3 and KDE-4. In my case, I need to have qt3 and qt4 installed simultaneously at least for the next year or two. I support an application that uses qt3 and am porting it to qt4 (probably a full year's project). The headers and libraries of the two don't conflict, but the applications, especially qmake, do. IMO, placing qt/kde/gnome in /opt is an important technique for users to be able to experiment with multiple versions with the ability to back up to a previous working version when (not if) a build problem is not detected until the system is running. > AFAIK, our counterparts all install in /usr. > With package management coming, it > shouldn't be any more difficult I suppose, but even more unnecessary IMO > now that I actually use what I consider to be a good package management > scheme. The only downside I see to dropping optional prefixes, is our > value to upstream in not revealing bugs in configure scripts that might > affect someone else. AFAIK, we've always been good at finding the out > of the ordinary bugs and upstreaming patches or docs. Our audience is quite a bit different from the typical distro. Our users experiment with build flags, specific components installed, and deciding what non-mandatory dependencies to install. I even hesitate to install X in /usr because I don't want to drop back to the command line when something goes wrong. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Aiming for 7.0
Gordon Schumacher wrote: > Bruce Dubbs wrote: > >> Bryan Kadzban wrote: >> >>>> Ticket 2033 -- initramfs. This way people with crappy software "RAID1 >>>> cards" (e.g. Promise, Highpoint, etc.) that require drivers in Windows, >>>> can still boot from those cards. Also, support for MD RAID (*real* >>>> software RAID ;-) ), LVM, and encrypted rootfs would be nice. >>>> >>>> (The mkinitramfs repo linked to from that ticket will already work for >>>> everything above, except encrypted rootfs.) >>> > > Again, this is very, very probably something I will need to do for > Linux-Live support; I'm not 100% positive yet, but I do know that for > the sort of application I am after, I personally will need an initramfs; > I need something that will run on any PC system, which means I can't > just compile the specific drivers I need for boot into the kernel. (And > indeed, that includes fakeraid.) > >> Even it it's poor hardware support, does the frequency of occurrence rise to >> the >> level of needing to be in the LFS book? As several comments in the ticket >> suggest, initramfs would be more appropriate for BLFS, but I'm thinking that >> even that is too much and an updated hint or wiki entry would be more >> appropriate. > > So, here's something to ponder... is it a requirement that the LFS book > be 100% linear? That is to say, that the build process is always identical? Generally, we want to minimize any differences between builds. When we go to 64-bit, we'll probably need to cover more than one boot loader though. > The reason I ask is this: if you're starting from the XML, using > profiling it's pretty simple to generate different books out of the same > source. Perhaps a hybrid approach could be taken to generating the > HTML, with something like a little JavaScript page at the beginning to > set options like initramfs or package management, and the necessary > links and sections could be displayed accordingly? Failing that, > perhaps a message to the effect of "If you do not require initramfs > support, you may skip this section" with a helpful link to do so? > > Just some thoughts, I'm not sure of the best way for such a thing myself. I'm not saying to not do it. I'm saying that LFS is the wrong place. BLFS is where the user picks and chooses. I don't want to 'hide' anything in the book by having different content for different situations. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Little spelling error
Marc Ferland wrote: > I hope this is the right mailing list for reporting spelling errors. Yes, exactly the right place. > I'm currently following LFS v6.4. in chap. 5.21 > > The paragraph: "This parameter bypasses the search for mktime in configure > and > uses the version in glibc. The is necessary due to a change in gcc that has > not been incorporated into this package yet. " > > Should be:"This parameter bypasses the search for mktime in configure and > uses > the version in glibc. _This_ is necessary due to a change in gcc that has not > been incorporated into this package yet. " > > Also, in the same chapter (5.21) the paragraph saying "Compilation is now > complete. As discussed earlier..." should be after the "make" command, not > before. Since 6.4 is in the stable book, we can't change that, but I put this in the errata on the web site. I will fix it in the -dev version of the book. Thanks. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.4 - 5.17.1 Coreutils
Rob Thornton wrote: > Quote: "There's an internal issue with Coreutils which makes some of the > programs behave abnormally if you build using an older kernel." > > It doesn't state what is considered "old." 2.2? 2.4? 2.6.xx.x? Hard to say. Take a look at the patch. "We provide a fallback for ENOSYS (for example, compiling against Linux 2.6.25 kernel headers and glibc 2.7, but running on Linux 2.6.18 kernel)." -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Missing operand in kernel installation doc
Marc Ferland wrote: > Hi, > > I've discovered another very small error in the kernel installation doc > (chapter 8.3, in LFS 6.4). > > The line: > "If the kernel source tree is going to be retained, run chown -R 0:0 on the > linux-2.6.27.4 directory to ensure all files are owned by user root. " > > Should be: > "If the kernel source tree is going to be retained, run chown -R 0:0 * on the > linux-2.6.27.4 directory to ensure all files are owned by user root. " > > The "*" operand is missing. That's really not an error. If it were in a highlighted section, it would be a problem, but in this case, we are saying what to do, but not *exactly* how to do it. The command may be 'chown -R 0:0 /usr/src/linux-2.6.27.4' and that would be good too. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Proper use of digests [was: Re: lfs-dev Digest, Vol 1235, Issue 1]
Gordon Schumacher wrote: > But what is the further intent here The intent is for the subject line to reflect the general content of the reply. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: The new build method is in...
Jim Gifford wrote: > Jeremy Huntwork wrote: >> Greg Schafer wrote: >> >>> the Acknowledgments page will suffice. "... Technical Writer and Architect >>> of the Next Generation 64-bit-enabling Build Method" or similar. >>> >> I'll give you a day or so to decide on the exact wording you prefer, or >> for someone else to offer a suggestion. Then I'll add this in. > Your violating his license if you don't put it in. Why play these petty > games, you need to include his license and the terms of his license, > since you have fully stated that your borrowed from his work. Jeremy's request is reasonable, Jim. I don't think there was ever any thought of not giving proper attribution to either Greg or CLFS. Please give us a break here. The changes are reasonably large and everything wasn't perfect on the first commit. All this will get sorted out pretty quickly. Personally, I'd really hope that the approach would be something like "Hey guys, you forgot...", or "X really isn't right. It should be..." There is nothing wrong with making mistakes. Please don't suggest unethical personal motivations unless an editor is unresponsive to polite suggestions. I look forward to any contributions you or Greg can make. Together we can make a large step forward. One last note. I see that you still have LFS commit privileges. If you want, I see no problem with you making commits directly. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: The new build method is in...
William Harrington wrote: > It's a community endeavor and each project with it's own goal. Each project > may borrow from another, and each project needs to give credit to the source. > If any part of the source is used credit needs to be given. It's a black and > white line. William, While I agree with your sentiments, there are a couple of issues. First of all, nobody is using another's *source*. What is being done is incorporating 'methods and concepts'. From a legal standpoint, source is copyrighted and methods are patented. What has been done so far has not violated those standards. From an ethical standpoint, we need to credit the persons who developed the methods and concepts. There is every intention of doing so. If it's not been done yet, it is merely an oversight and it *will* be corrected. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: The new build method is in...
Jim Gifford wrote: > Enough on that subject, OK. Time to move on. > As far as LFS Dev privs, thanx but no thanx. You can delete them, not to > mention, someone changed by password on me a while back, because they > were afraid when CLFS moved away to it's own servers. I have no interest > in LFS goals, except to help out with any issues that my expertise can > be useful. OK, but as far as I'm concerned, you are welcome. I'll reset your password if you want. No problem either way. > CLFS is a subproject of LFS. CLFS does have a separate leadership, Ryan, > Joe, and myself. CLFS is not fork. > CLFS does have developers that work exclusively on CLFS projects. > CLFS does have it's own servers. > CLFS does use a different license. > > CLFS was originally intended to be the future of LFS, not necessarily > the cross-compiling, but pulling the updates required by new releases of > the toolchain. As it has been stated, CLFS can be easily be modified > make a LFS style book with no cross compiling. That's clear enough. I think its good to share each other's ideas. I hope that we can all benefit from whatever CLFS or DIY or LFS is doing. I want us all to be colleagues who respect all input. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: The new build method is in...
Jim Gifford wrote: > Jeremy Huntwork wrote: >> Jim, you have not yet said how you would like CLFS to be credited. > The license specifies the terms. > http://cross-lfs.org/view/1.1.0/x86/appendices/license.html Jim, I took a look at the page and am having a bit of difficulty in determining how it applies. AFAICT, we are not using the CLFS document either modified or unmodified. We are incorporating the ideas, but not 'modified versions of documents covered by this license'. In academia, the accepted method of using other authors' ideas is to just create a bibliographic entry. In BLFS, the first section of the Introduction is Acknowledgments, but there is no similar section in LFS. Perhaps a similar section should be added to the LFS Preface. Would this be a reasonable solution in your view? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: The new build method is in...
Olaf wrote: > Bruce Dubbs wrote: >> In academia, the accepted method of using other authors' ideas is to just >> create >> a bibliographic entry. In BLFS, the first section of the Introduction is >> Acknowledgments, but there is no similar section in LFS. Perhaps a similar >> section should be added to the LFS Preface. >> >> Would this be a reasonable solution in your view? >> >> > Does it really matter whether this > http://www.linuxfromscratch.org/lfs/view/stable/appendices/acknowledgements.html > > is in Preface or Appendices section ? That is as much as a Credits section as an Acknowledgment section. I think they should be broken out into separate sections. Promoting both a rewritten Acknowledgments section and a new Credits section seems to be the right thing to do. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.13 GMP-4.2.4 Installation of GMP
William Harrington wrote: > Prepare Zlib for compilation: > > Prepare GMP for compilation: Fixed. Thanks. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package management and creating the file system layout
DJ Lucas wrote: > DJ Lucas wrote: >> a technical reason not to create the entire 'base' while in chapter 4? >> > Oops, that should have been 'chapter 5'. Can you explain what you mean by "create the entire 'base'". -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package management and creating the file system layout
DJ Lucas wrote: > Bruce Dubbs wrote: >> Can you explain what you mean by "create the entire 'base'". >> > Again, looking at this from a packaging point of view, IMO, all files > and directories that are created manually should be together on one page > so that a single package can be generated and called 'lfs-base' or > something to that effect. I had the chapters screwed up, but basically, > we should create all of the directories first and the then the essential > files (not symlinks) on the same page. Follow that up with mounting > virtual file systems and then chroot. The symlinks can (and should) > still be created after entering chroot (the last three sets of > instructions would never be packaged). Hmm. My initial reaction is that I don't really like it. Under that scenario, we wouldn't be using the new packages as they are built. I'm not sure if we can build everything without using our new packages because some may depend on others. I use DESTDIR all the time, but I generally do: make DESTDIR=/tmp/$package/install install then examine what was installed and then go back again and do sudo make install but I suppose I could use something like cp -a instead. To me it makes a lot more sense package by package instead of one big blob of multiple packages. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package management and creating the file system layout
DJ Lucas wrote: > Woah..reading a bit too much into it. As David correctly pointed out, > I'm only suggesting that creating the basic filesystem (sections > 6.2-6.6) be reordered, or rather reworked. > > Creating packages at build time is the goal, however, the packages would > be installed immediately. The 'lfs-base' package would be 2 files, plus > 5 empty ones that would only be created by the install routine, not > stored, plus the base directory structure would also be created. No > need to add DESTDIR commands or anything of that like until the first > package is installed in chapter 6. OK, I don't have time for studying it now, but I did misunderstand the proposal. I'll go back and study it some more. It may be helpful if you listed the instructions you propose. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Mailing list problems
I have just gone through a lot of messages being held on both the -dev and -support lists. I rejected most of the messages because they had html embedded in them. Do *not* post in HTML. Further posts may either be rejected or just discarded depending on how patient I feel. See: http://www.linuxfromscratch.org/faq/#netiquette One other thing to add. When replying to a digest message, changed the subjec to reflect the topic you want to discuss. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: md5sum for lfs-bootscripts-20081031.tar.bz2
jp wrote: > hi, all > > I rendered the xml of the development book. Surprisingly, the md5sum of > lfs-bootscripts differs from what is on the website. > > Can someone explain what is happening ? You don't say what version you are rendering. In any case, there are a couple of scripts, make-aux-files.sh and aux-file-data.sh that adjust the md5sums when the book is run. Do the md5sums in your copy of the book match those of the bootscripts and udev tarballs that are generated? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: ExtLinux Bootloader Information
Jim Gifford wrote:
> Bryan Kadzban wrote:
>> I assume an initramfs is possible via some kind of "initrd" type line?
>> I'll have to look.
>>
>> (I give a udev by-id symlink for root=, which is resolved by initramfs.)
>>
>>
> APPEND initrd=initrd.img
>
> That will take care of that
>>> extlinux --install /boot
>>> dd if=/dev/zero of={/dev to root drive} bs=446 count=1
>>>
> This one removes the old mbr without affecting the partition table
>>> dd if=/usr/share/syslinux/mbr.bin of={/dev to root drive}
>>>
>>
> This actually loads the syslinux supplied mbr.
>
> Been playing around with it all night very surprised with it's features.
Jim,
What features surprise you?
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
kernel section mismatch
I've been getting a warning when building the kernel (2.6.27.4): WARNING: vmlinux.o(.cpuinit.data+0x0): Section mismatch in reference from the variable initial_code to the function .init.text:i386_start_kernel() The variable __cpuinitdata initial_code references a function __init i386_start_kernel(). If i386_start_kernel is only used by initial_code then annotate i386_start_kernel with a matching annotation. After doing some googling, I found a patch: --- arch/x86/kernel/head_32.S.orig 2008-10-14 17:04:39.0 -0500 +++ arch/x86/kernel/head_32.S 2008-10-14 17:03:12.0 -0500 @@ -600,6 +600,7 @@ .section .cpuinit.data,"wa" .align 4 +__REFDATA ENTRY(initial_code) .long i386_start_kernel Evidently only some combinations of options triggers the warning. The above patch fixed it for me. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Sysroot based sane multilib toolchain build for LFS style builds [update]
Greg Schafer wrote: > Ryan Oliver wrote: > >> # Sysroot based SANE multilib cross-compiler build for LFS style builds > > Heh, this is hilarious. A new and improved build method goes into LFS and > CLFS folks awake from the dead :-) Feeling some pressure guys? :-) > > Sorry mate, but this whole thing looks of very poor quality and not at > all suitable for a mainstream LFS build method. It looks like same old > CLFS bodged up to imitate DIY/LFS! But the worst part is it comes complete > with all the CLFS design flaws, crazy hackery, silly patches and > unnecessary configure switches! Sorry dude, but if you're going to bob > up here with attitude and put up shite on this list then I'm going to > criticize it. > > And dude, it doesn't make it any saner the more times you write the word > `sane' in caps. It's like you're trying to bamboozle everyone with how > many toolchain buzzwords you can throw around. You might be able to > impress your IRC wannabe cronies with this caper but you ain't fooling me. > I've started tearing this apart piece by piece and will put up my finished > notes when I return from holidays. > > A mainstream build method suitable for a project like LFS needs to be > simple, clean, robust and (sorry to be blunt) reasonably idiot-proof. > You fail on all counts IMNSHO. Merry Christmas and/or winter solstice to you too Greg. What you say is a reasonable opinion. The way you say it comes across as stroking your own ego. The only person you are really putting down is yourself. Unfortunately, that makes many tend to disregard some valuable input. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Glibc download location
Chris Staub wrote: > LFS builders in IRC are reporting on a daily basis that they cannot > download the Glibc version listed in the book since that snapshot is no > longer available at the redhat ftp site. The link in the book should > point to the LFS ftp download site, > ftp://ftp.lfs-matrix.net/pub/lfs/lfs-packages/development/glibc-2.8-20080929.tar.bz2. > > The location for Glibc needs to be changed in the dev book, and added to > the Errata for 6.4. Thanks Chris. I'll go ahead and do this right now. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: CLFS discussion
Tushar Teredesai wrote: > I still don't get it. Does the current LFS leadership get to decide > what every project that ever "forked" from LFS can and cannot do? No, and I don't think it's even being tried. There are some expressions of regret that there are personality conflicts and a wish by some, including me, to get together, but I don't see anyone trying to direct anything. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
libusb and usbutils
We have a problem with libusb and usbutils. libusb has released 1.0.0 on 2008-12-13. usbutils is at version 0.73 released on 2007-10-24. usbutils configure wants a function, usb_get_string_simple(), that is not in libusb-1.0.0. There are functions libusb_get_string_descriptor() and libusb_get_string_descriptor_ascii() vi in the new libusb. The second seems to use the same parameters as usb_get_string_simple(). As I see it, there are a few things that we can do. 1. Just leave out usbutils for now. 2. Revert to the earlier version of libusb. 3. Try to hack usbutils to use the new libusb. Looking at the code, this is non-trivial and I don't have the time or inclination to do it. 4. Try to install both the old and new versions simultaneously. 5. There is a libusb-compat-0.1 compatibility layer. It aims to look, feel and behave exactly like libusb-0.1. As it is a replacement, you cannot install it alongside libusb-0.1 on the same system. There have only been about 4 messages since January in the usbutils mailing list (none since September) so it is not very active. Waiting for a new release may take a long time. The following packages use libusb: usbutils pilot-link gnome/add/gok kdeedu kdebase gnupg gnupg2 sane It's unlikely that any use the new libusb. Opinions on what to do? I'm leaning toward #5. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Can I publish a translation of LFS
Thomas Reitelbach wrote: > Lookling at the books licence general I would say, you can publish your > translated book in any form if you like. Um, no. The license is NonCommercial. "You may not exercise any of the rights granted to You in Section 3 above in any manner that is primarily intended for or directed toward commercial advantage or private monetary compensation." I've forwarded the original request to Gerard. Lets give him a few days. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Pages printed twice in index of PDF.
Martin Miehe wrote: > In the indices of current stable book (and in 6.3 as well) are several > page numbers printed twice after one entry. E.g. at > Programs -> acinstall > Programs -> aclocal > Programs -> addpart > Programs -> autoconf > > and so on. > > Has this been done purposely or is it a side effect and should be fixed? Moving to -dev. Please answer there. This is only an artifact of pdf, not the html. Looking at automake.xml, there is ... and ... but aclocal-version is not in the index (pdf or html). I think that this is an xsl problem, but I don't know how to fix it. -- Bruce -- 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
Jim Gifford wrote: > I can't take one individuals word on things, because frankly I don't > trust some I can't validate myself. Trust has very little to do with it, but I agree. Any scientific investigation has to provide enough details to be able to duplicate the results. To do this, we have to know the method (in this case a script or set of scripts), and what the results are that cause the author to draw the conclusions made. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LFS Ticket system
Chris Staub wrote: > > I would have created a Trac ticket, but Trac appears to be broken at the > moment. I keep seeing stuff like "Warning: > " on the top of > every page, and cannot create or edit tickets. Chris, I took a look at the tickets and I don't see any problem with viewing tickets either logged in or not. I checked and see you should be able to log in OK. I'd like to ask your to shut down your browser completely and restart it. You may also want to delete any cookies associated with the site. Get back to me if you still have problems with the ticket system. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Ticket system
Chris Staub wrote: > Nope, still can't create or edit tickets. Also, "Moody" in IRC has > reported the same problem (actually, he mentioned it first, which is > what caused me to look at Trac in the first place). Plus, I get exactly > the same result in both Firefox and Links. > > Now that I look closer, it seems to be some kind of permissions problem, > because attempting to create a ticket results in an error about needing > ticket create privileges. > > I just remembered I have 2 accounts on Trac. It's my > ch...@linuxfromscratch login that doesn't work. OK, I deleted that login from LFS trac, so please re-register the same one. I also gave you TICKET_ADMIN privs, but any authenticated user should be able to do a TICKET_CREATE or TICKET_APPEND. The only thing an unauthenticated (not logged in) user can do is *_VIEW Let me know if that helps. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Ticket system
Matthew Burgess wrote: > On Sun, 1 Feb 2009 11:19:18 +0100, Thomas Trepl > wrote: > Just to let you know that I also had this same issue immediately after Jeremy > upgraded > one of the Trac plugins a couple of weeks ago. I carried on browsing Trac > until, at > some point it prompted me to confirm my email/login. Once I'd confirmed it, > then > everything started working OK. > > You could try logging in and going to 'Preferences' and see if changing > anything in > there is enough to fix things up. 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? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Pending package updates
Matthew Burgess wrote: > Just thought I'd drop a note on the pending package updates I've assigned to > myself. I have patches to the book for all of these now. > > However, as expected by looking at ticket #2322, there's slight issues with > Groff-1.20.1 and its interaction with Man-DB-2.5.3. My feeling is that you ought to go ahead and commit what you have to -dev, but add a note to the appropriate pages describing the problem. We can always revert to an older version of problematic packages and some problems won't affect all users. I'm generally in favor of committing frequently to -dev even if there are problems. It gets issues more into the open and has the potential to get them fixed faster. -- Bruce -- 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
Randy McMurchy wrote: > 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. I didn't want to affect other users, but it became necessary. 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. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
LFS trac password file is hosed
Guys, I accidentally hosed the lfs password file. Registration doesn't seem to work either. I'm working on it. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS trac password file is hosed
Bruce Dubbs wrote: > Guys, >I accidentally hosed the lfs password file. Registration doesn't seem to > work either. I'm working on it. The registration problem I had was an issue with my browser. Registration works. We don't have a backup of the password file, so everyone will have to re-register. If you use the same login ID, permissions will not need to be changed. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS trac password file is hosed
Bruce Dubbs wrote: > Bruce Dubbs wrote: >> Guys, >>I accidentally hosed the lfs password file. Registration doesn't seem to >> work either. I'm working on it. > > The registration problem I had was an issue with my browser. Registration > works. We don't have a backup of the password file, so everyone will have to > re-register. If you use the same login ID, permissions will not need to be > changed. Well here's some good news. I found a backup of the password file from Feb 25. I've restored it. If you didn't make any changes since then, then you should be OK. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: coreutils instructions
Matthew Burgess wrote: > PS: Nice to see you back on the lists, Archaic. I agree. Archaic, don't be a stranger. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: coreutils instructions
Dan Nicholson wrote: > A while back I sanitized the bootscripts for POSIX sh compatibility, > and I think DJ has been maintaining that goal. I think it's a nice > (and obtainable) goal to target since having sh != bash can save on > bloat. Save on bloat? For what? My copy of bash is 500K. dash is about 80K. The smallest HD you can get now is about 100G. The savings is about 0.0004% of the disk. Unless you are doing something that requires busybox for an extremely small non standard LFS installation, then it's a non-issue. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: coreutils instructions
Matthew Burgess wrote: > On Fri, 20 Mar 2009 10:58:45 -0700, Dan Nicholson wrote: >> On Fri, Mar 20, 2009 at 8:38 AM, Matthew Burgess >> wrote: >>> Given that LFS only installs bash, does any of this matter? :) >> A while back I sanitized the bootscripts for POSIX sh compatibility, >> and I think DJ has been maintaining that goal. I think it's a nice >> (and obtainable) goal to target since having sh != bash can save on >> bloat. > > Yes, I agree that's a reasonable objective. So, do we want to move '[' > and 'test' to /bin then, just in case the user installs a shell > that doesn't include builtins for those utilities? I would really go the other way and make all the scripts start with #!/bin/bash and use the features of bash. When we use the lowest common denominator, we prevent progress. If someone wants to use dash or another incomplete shell as a default, then they should customize the startup scripts too. The same thing goes if the user wants to use tcsh or ksh as a default. Using alternative shells should be a hint or other suitable reference. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: coreutils instructions
Archaic wrote: > On Fri, Mar 20, 2009 at 01:41:53PM -0500, Bruce Dubbs wrote: >> I would really go the other way and make all the scripts start with >> #!/bin/bash >> and use the features of bash. When we use the lowest common denominator, we >> prevent progress. If someone wants to use dash or another incomplete shell >> as a >> default, then they should customize the startup scripts too. > > Wow, I didn't mean to open a hornet's nest. It's not a hornet's next, but a discussion. Tushar points out that we've had this discussion before. Sometimes it's useful to revisit some discussions. For instance, I came across this: http://elliotth.blogspot.com/2007/12/dash-helps-bash-users-relive-bad-old.html It claims that an old system boots 2 (out of 45) seconds faster with dash. I just don't see any speed issue with different shells during boot. My LFS laptop boots quite nicely with bash in 20 seconds (without X, but with sshd, apache, nfs, and samba). Once the shell is loaded, it stays in memory and then the small scripts used during the boot cycle will all run at the same speed. About the only thing I've seen that is a significant script during boot is from Oracle and that is a monster. Of course, that's not open source. > But this does raise a > question. Is there any feature of bash that is commonly used that cannot > be done in some fashion with POSIX sh? I'm not talking about the need to > do things with different syntax, but the need to use non-sh utilities to > match the functionality. If there is such a common use of bash, then I > would agree with Bruce, otherwise, I don't see any loss of progress and > would prefer portability. That's a reasonable position to take, but then again, dash is an NP-complete language -- that means that anything you can do with one language, you can do with another. There is nothing magic about *sh. You could make the default shell python if you wanted. The issue would be compatibility with other scripts. > Unfortunately, this problem creeps up in the packages LFS installs, too, > where #!/bin/sh is used, but bash-specific code is found. We've caught > some in the past (probably from previous ash-only enthusiasts). There > may be others. Yes, that's the issue. We would like to be POSIX complaint, but what does that mean? Does POSIX define what is needed? I found http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html, but that doesn't specify what shells are complaint. AFAICT, what is does not prohibit is a superset. According to Wikipedia, dash omits a POSIX required $LINENO variable. When checking scripts, what about ash? korn? posh? zsh? What about the original Bourne sh? How far do we go? My thought would be to use #!/bin/bash for our scripts since that is what we install, but make the scripts not intentionally use any capabilities not in POSIX. If a user wants to change to sh, then that's his distro. I did find this pdf on the web that presents some differences between bash and dash: http://princessleia.com/plug/2008-JP_bash_vs_dash.pdf For instance, you can't do: somecommand &> /dev/null in dash. Of course it can be worked around. The real issue to me is to answer the question: Are there scripts that are run using dash (or ash) that *won't* run properly with bash? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: perl's use or non-use of pthread
Archaic wrote: > To use -Dusethreads or not, that is the question. :) > > Without, I get 2 files that are linked to pthread: > > /usr/lib/perl5/5.10.0/i686-linux/auto/DB_File/DB_File.so > /usr/lib/perl5/5.10.0/i686-linux/auto/Time/HiRes/HiRes.so > > With, I get: > > /usr/bin/perl5.10.0 > /usr/bin/perl (hardlink to perl5.10.0) > /usr/bin/a2p > /usr/lib/perl5/5.10.0/i686-linux-thread-multi/auto/DB_File/DB_File.so > /usr/lib/perl5/5.10.0/i686-linux-thread-multi/auto/Time/HiRes/HiRes.so > /usr/lib/perl5/5.10.0/i686-linux-thread-multi/auto/threads/threads.so > /usr/lib/perl5/5.10.0/i686-linux-thread-multi/auto/threads/shared/shared.so > > Notice the 2 in the first list are in the 2nd list, but are installed in > i686-linux-thread-multi instead of i686-linux. I'm no perl expert, but > it would seem logical that if perl itself didn't support threading, then > a module supporting it would be meaningless. This may have implications > on reentrancy. I currently have access only to Arch Linux and FreeBSD, > and the main perl binary in those links to libpthread. I'm curious what > debian-based and redhat-based distros are doing. On a ubuntu system is: $ ldd `which perl` linux-gate.so.1 => (0xe000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7f3d000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7f16000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7efe000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dbd000) libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7d8f000) /lib/ld-linux.so.2 (0xb7f4f000) On RHEL: $ ldd `which perl` libperl.so => /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so (0x0094b000) libresolv.so.2 => /lib/libresolv.so.2 (0x0091f000) libnsl.so.1 => /lib/libnsl.so.1 (0x00ad7000) libdl.so.2 => /lib/libdl.so.2 (0x0089b000) libm.so.6 => /lib/tls/libm.so.6 (0x008a1000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x008ec000) libutil.so.1 => /lib/libutil.so.1 (0x00b6b000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x008d8000) libc.so.6 => /lib/tls/libc.so.6 (0x0076a000) /lib/ld-linux.so.2 (0x0075) So I'd say that -Dusethreads should normally be used. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: coreutils instructions
Dan Nicholson wrote: > On Fri, Mar 20, 2009 at 11:15 AM, Bruce Dubbs wrote: >> Dan Nicholson wrote: >> >>> A while back I sanitized the bootscripts for POSIX sh compatibility, and >>> I think DJ has been maintaining that goal. I think it's a nice (and >>> obtainable) goal to target since having sh != bash can save on bloat. >> Save on bloat? For what? My copy of bash is 500K. dash is about 80K. > > Right, bash is 4 times the size of dash. That adds up when you're forking the > shell a hundred times or whatever during boot. Come on Dan. You know better than that. When you fork a program, the code segment is not duplicated, but only any necessary data. For that, there would be no significant difference between bash and dash. > The last time I tested, it shaved like 4 seconds off boot using dash instead > of bash. > > http://linuxfromscratch.org/pipermail/lfs-support/2008-February/034192.html > I use bash all the time and I wouldn't consider using a minimal posix shell > for my login shell. For any non-trivial script, I use bash. However, for a > generic shell script, I don't know why you couldn't make it posix compliant. > That allows people to have flexibility without much loss. The bootscripts are > pretty simple. As you mention, bootscripts are pretty simple and in no way are a stress test. Four seconds doesn't seem very significant to me. It's not enough to notice unless you are doing a timing test. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: coreutils instructions
Agathoklis D. Hatzimanikas wrote:
> On Mon, Mar 23, at 07:12 Dan Nicholson wrote:
>> On Fri, Mar 20, 2009 at 4:44 PM, Bruce Dubbs wrote:
>>
>> If you were looking at a system (not just a computer system) and you
>> found that one part took twice the resources and twice as long to
>> start up as another part offering similar functionality, why would you
>> dismiss it?
>
> In a perfect world? You have to adopt the best technology.
> But in the case of Linux, Bash is the single most sacred piece of code.
>
> Objectively, Dash is more suitable for login and system scripts than Bash,
> because is faster,
Yes, but is it significant
more stable
this is an unsupported assertion
and offers portability
portability to what?
and compliance with
> POSIX specifications, which is very important in a project like ours.
Dash is arguably less in compliance than bash as it does not support the LINENO
variable specified in the PSOIX standard.
The advantages of dash/ash are that they are smaller and faster. The real
question is whether the speed differences and size are significant for an LFS
system.
The drawback to dash/ash is that they offer fewer features. It's a trade off.
>> Maybe the original part offers better features than the
>> replacement, but that doesn't mean the other facts can be ignored.
>
> And in the case of interactivity, Zsh offers an unquestionable superior
> technology than any other existing shell.
Perhaps. I really haven't looked at zsh much.
> But again, if the purpose of Bash is to write scripts for administrative
> tasks, in my opinion and if a script is going to be more that few lines of
> code, is much better to write it in one of the popular and portable scripting
> languages, like Python and Ruby (even Perl!), rather than to rely on Bash
> extensions.
That's an option. You can even use php for scripts. It's really a nice
language.
Perl is difficult because it has so many side effects and lends itself to
writing code that is difficult to understand if you are not a Perl expert.
Python has the drawback that it is dependent on blank space. It's not
something
that I like. YMMV.
> As a side note, and speaking for the future of shell.
> In my opinion, (the) shell nowadays has reached its limits and honestly
> its not that appealing to the young generation (I don't know for you but
> for me the latter is really crucial).
> This mostly happens, because a young kid which invests some of his valuable
> time (just to be a little productive with the shell), needs to learn a
> series of commands, with its own syntax and idiosyncrasy (sometimes really
> complex), and then to chain them via pipes (for more complex tasks).
> Most of the times this is ugly, fragile and sometimes the result is
> unexpected, though through experience this way can be truly efficient (I
> am not denying it).
> Count on this that most kids are familiar with languages with excellent
> syntax (like Python) or beautiful syntax (like Ruby's).
>
> For what? Just to work in a resource hog, ugly and plain slow bloating
> environment like Bash.
The real power of bash is at the command line, not as a scripting language.
Personally, I think anything over about 200 lines should not be done in any
shell variant.
Perhaps I should look at ksh...
> And try to compare with a shell concept, where everything (directories
> and files) are plain objects and you just send messages (applying
> methods) to those objects.
> What we take is consistent syntax (no matter the kind of operations you
> apply), and a powerful language in our disposal with almost no limitation.
>
> E.g., (an example from a Ruby based experimental shell concept named Rush)
>
> dir = home['somedir/']
> dir['*.txt'].each {|f| f.destroy}
In bash: rm -f $HOME/somdir/*.txt
You really think Ruby is easier?
> However if this is not going to happen, which is quite possible, I would
> prefer to use #!/bin/bash rather than #!/bin/sh in our scripts.
> Keep /bin/sh for only POSIX compliant scripts.
That's a reasonable position.
> Oh well, almost all. I'd rather get rid of Bash.
One other comment. For a commercial distro, the vast majority of users will
never look at a script let alone write them. This is completely different from
the typical LFS user that, as a minimum, creates scripts in Chapter 7. I would
bet a reasonable amount that 99% of users customize at least the .bash_profile
and .bashrc scripts. As one who writes scripts, my preference is power over
speed.
I have one bash script that I run fairly often from the command line that
builds
an application I'm developing (about 150K SLOC C++). It's 17 lines long, but
three lines are blank. Also, all my build s
Re: vimrc recommendation
Archaic wrote: > The vimrc that LFS creates is very spartan. There is a default > configuration that isn't bad plus it gives new users a quick idea of how > powerful the rc can be. > > cp runtime/vimrc_example.vim /etc/vimrc > > The if statement for bg=dark is not included, but could be appended if > so desired. There is already a pretty good link to an extended example vimrc in BLFS. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: m4 badness
Greg Schafer wrote: > Hi, > > Just stumbled across this. You will likely want to fix it: > > http://lists.gnu.org/archive/html/m4-patches/2009-02/msg00010.html Thanks Greg. I've removed it from -dev and added an errata item to the website for the stable book. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Vulnerabilities in udev
Ken Moffat wrote: > When building an old version, don't forget to use the instructions > that applied when you built it originally! You do keep either the > version of the book that you used, or buildscripts, right ? The > released version of the books are mostly at > http://archive.linuxfromscratch.org/lfs-museum/ > > The following distros support the following versions: > debian: 105, 125 > fedora: 124, 127 > gentoo: 124 > ubuntu: 079, 113, 117, 124 - unfortunately, I've been unable to > download from ftp.ubuntu.com for the past few days. > > I've listed these distros because they are usually easy to access > for the source. If for some reason you are running an even older > version of udev, there are some fixes in other distros. Older versions of udev for stable releases of LFS are found at http://anduin.linuxfromscratch.org/sources/LFS/conglomeration/udev/ Almost all of sources for the released versions of udev are found at http://www.kernel.org/pub/linux/utils/kernel/hotplug/ -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LFS-6.5
I am proposing that we release LFS 6.5 in the next week or so. We really haven't made a lot of progress on the main issues of the targeted 7.0 release, but there has been good incremental progress on the routine updates of package versions in the book. LFS-6.4 was released last November. I've created a new 6.5 milestone and put the tickets that appear to be appropriate for a 6.5 release in that milestone: http://wiki.linuxfromscratch.org/lfs/query?status=new&status=assigned&status=reopened&group=milestone&order=priority I've already fixed several tickets that seemed quick and the others should go fairly fast too. I'm proposing that the now current 6.5 tickets be fixed in the next week and then release a 6.5-rc1 around May 24. Then we can target a full release for somewhere around June 14. Comments? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-6.5
DJ Lucas wrote: > OK...The what happens for BLFS? I'm guessing BLFS-6.4 will be a no go, > and BLFS should be targeting current SVN? I would think that is reasonable. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
zdiff problem
I'm trying to address ticket #2315 that says zdiff doesn't work. I confirmed this by creating two files with a one line difference and compressing them: gzip file1 gzip file2 But 'zdiff file1.gz file2.gz' gives no output. Older versions of the script work properly. The code in the script is really convoluted. I found an error report in the gzip archives about this: http://lists.gnu.org/archive/html/bug-gzip/2008-02/msg2.html I note that there was never a reply to the message and that was over a year ago. The problem code looks like: gzip_status=$( exec 4>&1 (gzip -cdfq -- "$1" 4>&-; echo $? >&4) 3>&- | ( (gzip -cdfq -- "$2" 4>&-; echo $? >&4) 3>&- 5<&- &3) 5<&0 added We can fix this with this with the following: sed -i 's/5 -)/5 >\&3)/' zdiff but I don't understand what is really going one here. Should I make this change? Comments? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: zdiff problem
Dan Nicholson wrote: > On Sun, May 17, 2009 at 6:49 PM, Bruce Dubbs wrote: >> I'm trying to address ticket #2315 that says zdiff doesn't work. I confirmed >> this by creating two files with a one line difference and compressing them: >> >> gzip file1 >> gzip file2 >> >> But 'zdiff file1.gz file2.gz' gives no output. Older versions of the script >> work properly. >> >> The code in the script is really convoluted. I found an error report in the >> gzip archives about this: >> >> http://lists.gnu.org/archive/html/bug-gzip/2008-02/msg2.html >> >> I note that there was never a reply to the message and that was over a year >> ago. > > The bug-gzip list unfortunately is pretty dead. I subscribed to it to > submit a patch for this specific problem, but I never got around to > submitting the patch or unsubscribing. :) > >> The problem code looks like: >> >> gzip_status=$( >> exec 4>&1 >> (gzip -cdfq -- "$1" 4>&-; echo $? >&4) 3>&- | >> ( (gzip -cdfq -- "$2" 4>&-; echo $? >&4) 3>&- 5<&- >eval "$cmp" /dev/fd/5 -) 5<&0 >> ) >> >> When I look at /dev/fd, I only have 0 through 3 (and on RH and Ubuntu other >> systems too, but none use gzip-1.3.12). > > /dev/fd/ is just a symlink to the current process file descriptors. > Typically you have 0, 1 and 2 for stdin, stdout and stderr. But a > process can open up any more it wants. In this case, fd 5 is opened by > the redirection. > >> The fix appears to be changing the last line above to >>eval "$cmp" /dev/fd/5 - >&3) 5<&0 >> added >> >> We can fix this with this with the following: >> >>sed -i 's/5 -)/5 >\&3)/' zdiff >> >> but I don't understand what is really going one here. >> >> Should I make this change? Comments? > > I think that's right looking at the rest of the script (I agree it's a > pretty hairy script). I wish I could find the patch I made before, but > I can't seem to locate it now. After I made the original post, I found the same fix in the current Debian patch. I guess I'll go ahead and add the sed. Thanks for the confirmation Dan. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: zdiff problem
Bryan Kadzban wrote:
> Bruce Dubbs wrote:
>> The problem code looks like:
>>
>> gzip_status=$(
>>exec 4>&1
>>(gzip -cdfq -- "$1" 4>&-; echo $? >&4) 3>&- |
>> ( (gzip -cdfq -- "$2" 4>&-; echo $? >&4) 3>&- 5<&- > eval "$cmp" /dev/fd/5 -) 5<&0
>> )
>
> Sheesh, that's complicated!
Yes, it's bad. Earlier they have:
for file
do
test "X$file" = X- || <"$file" || exit 2
done
but file is never defined, so this always fails. It might be for another shell
or architecture, but it isn't commented and look screwy.
Let's see if I can decipher...
>
> Duplicate FD 1 into FD 4. Then start a subshell with FD 3 closed
> (...but where was 3 opened? before this?);
Yes, earlier it does
exec 3>&1
Why we need to use 3 at all is a mystery to me.
in that subshell, gunzip $1
> to FD 1, closing FD 4 before doing so, and echo the exit status into FD
> 4. Pipe FD 1 (the decompressed file) into another subshell, and
> duplicate that input stream into FD 5 (hmm; FDs 0 and 5 are both this
> stream...).
>
> In that second subshell, start yet another subshell with FDs 5 and 3
> (...again, with 3) closed, and with stdin coming from /dev/null (not the
> pipe); in that subshell, gunzip $2 to stdout with FD 4 closed, and echo
> the exit status of this gzip into FD 4 as well. Pipe the decompressed
> file into "eval $cmp /dev/fd/5 -" (whatever $cmp is; presumably - means
> stdin).
cmp='${DIFF-diff}'
> Both exit statuses are put into gzip_status, along with whatever "$cmp"
> outputs. This last bit might be the bug, depending on where FD 3 is
> going. If FD 3 is a duplicate of the output stream of zdiff (e.g. they
> did an "exec 3>&1" earlier), then your fix is correct: the output of
> $cmp needs to be shown to the user, not dumped into the gzip_status
> variable.
>
> Looks like it's attempting to run "$cmp" (whatever it is) on the two
> streams of gunzip output.
Yes and keep it all in memory. They don't want to do any disk IO here.
(/dev/fd/X is the current process's file
> descriptor X; useful for programs like diff and cmp that require file
> names, when you want to compare a stream.)
>
> It's a giant Y; the two arms of the Y are the gunzip streams, and the
> point in the middle is the $cmp invocation. The rest is just
> scaffolding to be able to capture the exit status of each gzip, and to
> make sure programs can't get at FDs they shouldn't be able to get at.
>
> (Does that actually help? :-) )
Yes. I hadn't run into a script that closed file streams with things like 3>&-
before.
>> When I look at /dev/fd, I only have 0 through 3 (and on RH and Ubuntu other
>> systems too, but none use gzip-1.3.12).
>
> That's because the ls process only has stdin, stdout, and stderr open;
> FD 3 is a handle to the /proc/self/fd directory itself in this case
> (because you're looking at its contents; opendir() returned 3).
That's a new one for me.
> (Oh: /dev/fd is a symlink to /proc/self/fd; see /lib/udev/devices.)
That part I knew. In any case, its fixed up in the book and I did test it,
so it does work.
Thanks for the feedback.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
LFS-6.5 Issues
As discussed at http://wiki.linuxfromscratch.org/lfs/ticket/2391, we've run into an issue with util-linux-ng. The best solution appears to hold off LFS-6.5 until util-linux-ng-2.16 is released in 2 to 3 weeks. This change will also affect e2fsprogs as libuuid is being transitioned from e2fsprogs to util-linux-ng. While we have this extra time, I'm proposing that we address some of the other tickets that are targeted for LFS-7.0. http://wiki.linuxfromscratch.org/lfs/query?status=new&status=assigned&status=reopened&group=milestone&order=priority It appears to me that #2266 and #2401 could be promoted to 6.5. We might also want to consider #1929, #3092, and even #2073 and #2184. I'd add #2337 to this list, but I really don't have the background to address alternate character sets. As far as the current 6.5 tickets go, I plan on providing input to #2398 and #2399 as soon as we finalize the package issues. Considering the above, I'll take ownership of any tickets that Matt would like me to do. If others would like to handle specific tickets, lets discuss here. Comments? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
glibc-2.10.1 make check fails
I've been going through the -dev book manually and have run into a problem at the start of Chapter 6. The build of glibc-2.10.1 goes without a problem, but make check fails even with the -k parameter: /usr/bin/perl scripts/begin-end-check.pl argp/argp.h ... > /sources/glibc-build/begin-end-check.out make[1]: Target `check' not remade because of errors. make[1]: Leaving directory `/sources/glibc-2.10.1' make: *** [check] Error 2 I'll back off to glibc-2.9 and see if that gives different results. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: glibc-2.10.1 make check fails
Bryan Kadzban wrote: > Bruce Dubbs wrote: >> The build of glibc-2.10.1 goes without a problem, but make check fails even >> with >> the -k parameter: >> >> /usr/bin/perl scripts/begin-end-check.pl argp/argp.h ... >>> /sources/glibc-build/begin-end-check.out >> make[1]: Target `check' not remade because of errors. >> make[1]: Leaving directory `/sources/glibc-2.10.1' >> make: *** [check] Error 2 > > Hmm; isn't this normal with "make -k"? It runs through all its targets' > dependencies, and if any of them fail, keeps going -- but still fails at > the end, and gives this "target `xxx' not remade because of errors" > message. > > Or at least, that's what "make -k" was doing for me in a different setup > (well, "different" as in "not glibc"), where I knew there were compile > errors in lots of files, but wanted to build as much as possible anyway, > to see all the files that needed to be fixed still. > > Unless the scripts/begin-end-check.pl isn't the last test to normally > run? That would be a problem... There aren't any errors in the logs for 6.4 on quantum. This may be a gcc-4.4 problem. I got basically the same error on glibc-2.9. There I got: root:/sources/glibc-build# grep Error glibc-check-log make[2]: *** [/sources/glibc-build/math/test-ildoubl.out] Error 1 make[1]: *** [math/tests] Error 2 make[2]: [/sources/glibc-build/posix/annexc.out] Error 1 (ignored) make: *** [check] Error 2 root:/sources/glibc-build# cat /sources/glibc-build/math/test-ildoubl.out testing long double (inline functions) Failure: Test: expm1 (1) == M_El - 1.0 Result: is: 1.71828182845904523532e+00 0xd.bf0a8b1457695350p-3 should be: 1.71828182845904523543e+00 0xd.bf0a8b1457695360p-3 difference: 1.08420217248550443401e-19 0x8.p-66 ulp : 1. max.ulp : 0. Maximal error of `expm1' is : 1 ulp accepted: 0 ulp Test suite completed: 3618 test cases plus 3005 tests for exception flags executed. 2 errors occurred. and The following identifiers will be ignored since the compiler defines them by default: unix linux i386 Tested files: === aio.h === * invalid macro `SIGPROF' ... lots more I'm going to recheck glibc-2.10.1 with gcc-4.3.2 -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: glibc-2.10.1 make check fails
OK, I ran the instructions to build glibc-2.10.1 on a LFS-6.4 system and ithe checks completed normally. There was one error identified: make[2]: [/mnt/lfs/sources/glibc-build/posix/annexc.out] Error 1 (ignored) but this is already identified in the book. I think we may have some problems with gcc-4.4, probably in the libraries that are included from other libraries. I'll continue to investigate. Suggestions will be appreciated. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: glibc-2.10.1 make check fails
Bruce Dubbs wrote: > OK, I ran the instructions to build glibc-2.10.1 on a LFS-6.4 system and ithe > checks completed normally. There was one error identified: > > make[2]: [/mnt/lfs/sources/glibc-build/posix/annexc.out] Error 1 (ignored) > > but this is already identified in the book. I think we may have some > problems > with gcc-4.4, probably in the libraries that are included from other > libraries. > > I'll continue to investigate. Suggestions will be appreciated. I haven't found the source of the make check problem yet, but I have found the following email: http://sources.redhat.com/bugzilla/show_bug.cgi?id=448 This indicates that sed -i '/vi_VN.TCVN/d' localedata/SUPPORTED is not needed any more. The fix was made 2005-10-14, but Alexander indicated it was still broken in Feb 2007: http://linuxfromscratch.org/pipermail/lfs-dev/2007-February/058933.html The file glibc-2.10.1/localedata/locales/vi_VN has: revision "1.1" date "2004-01-09" I'm thinking we should drop the sed unless we get additional confimation that it is still a problem. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: glibc-2.10.1 make check fails
Another glibc issue: We use: ../glibc-2.10.1/configure --prefix=/usr \ --disable-profile --enable-add-ons \ --enable-kernel=2.6.0 --libexecdir=/usr/lib/glibc Where: --enable-kernel=VERSION compile for compatibility with kernel not older than VERSION but I found http://www.mail-archive.com/arch-dev-pub...@archlinux.org/msg08016.html which says: The minimum kernel version required for glibc was bumped from 2.6.16 to 2.6.18 Therefore, I think we should modify the configure statement to read: --enable-kernel=2.6.18 -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: glibc-2.10.1 make check fails
Trent Shea wrote:
> On Sunday 24 May 2009 16:31:12 Trent Shea wrote:
>> I'll see if I can hack jhalfs to keep my build directories and provide up
>> to date information this week.
Thanks, Trent.
> I'm just running a jhalfs build right now. A bunch of errors:
What version of the book did you use? Are you using gcc-4.4.0? I did not run
into the make -k check aborting problem with GCC-4.3.2.
> grep Error 068-glibc
> make[3]: *** [/sources/glibc-build/libio/tst-fgetwc.out] Error 1
> make[2]: *** [libio/tests] Error 2
I've traced this down to a locale problem, but I don't have a fix. The code is
doing this:
if (setlocale (LC_ALL, "de_DE.utf8") == NULL)
{
puts ("setlocale failed");
return 1;
}
And the error file does have 'setlocale failed'.
> make[3]: [/sources/glibc-build/posix/annexc.out] Error 1 (ignored)
> make[3]: *** [/sources/glibc-build/nptl/tst-mutex5.out] Error 1
> make[3]: *** [/sources/glibc-build/nptl/tst-mutex9.out] Error 1
> make[3]: *** [/sources/glibc-build/nptl/tst-mutex5a.out] Error 1
> make[2]: *** [nptl/tests] Error 2
> make[3]: *** [/sources/glibc-build/rt/tst-mqueue5.out] Error 1
> make[2]: *** [rt/tests] Error 2
> make[1]: *** [check] Error 2
>
> The host is a LFS 6.4 system. As mentioned I've kept the build directories
> and
> can provide details upon request. I'll set up a build on an ubuntu host
> tonight too and report any errors.
I'm still investigating too.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: glibc-2.10.1 make check fails
Trent Shea wrote: > On Sunday 24 May 2009 16:31:12 Trent Shea wrote: >> I'll see if I can hack jhalfs to keep my build directories and provide up >> to date information this week. > > I'm just running a jhalfs build right now. A bunch of errors: > > grep Error 068-glibc > make[3]: *** [/sources/glibc-build/libio/tst-fgetwc.out] Error 1 > make[2]: *** [libio/tests] Error 2 > make[3]: [/sources/glibc-build/posix/annexc.out] Error 1 (ignored) > make[3]: *** [/sources/glibc-build/nptl/tst-mutex5.out] Error 1 > make[3]: *** [/sources/glibc-build/nptl/tst-mutex9.out] Error 1 > make[3]: *** [/sources/glibc-build/nptl/tst-mutex5a.out] Error 1 > make[2]: *** [nptl/tests] Error 2 > make[3]: *** [/sources/glibc-build/rt/tst-mqueue5.out] Error 1 > make[2]: *** [rt/tests] Error 2 > make[1]: *** [check] Error 2 OK, I've got the problem solved. My errors are similar to the above, but the only errors I'm getting are tst-fgetwc.out and annexc.out. If tst-fgetwc is corrected properly, then the (ignored) error will not trigger the Error 2 at the end of the file. The Error 2 is what was confusing me in the beginning because I don't normally get that. I don't get the nptl or rt errors. I know how to fix tst-fgetwc. It requires a change to libio/tst-fgetwc.c and libio/Makefile. I think our options are to 1. Ignore the error 2. Document the error 3. Modify the files to fix the test case. That will take two separate seds: Before changing to glibc-build: sed -i s/utf8/UTF-8/ libio/tst-fgetwc.c sed -i '/tst-fgetws-ENV/ a\ tst-fgetwc-ENV = LOCPATH=$(common-objpfx)localedata' libio/Makefile Comments? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: glibc-2.10.1 make check fails
Matthew Burgess wrote: > On Mon, 25 May 2009 01:53:33 -0500, Bruce Dubbs wrote: > >> OK, I've got the problem solved. My errors are similar to the above, but >> the only errors I'm getting are tst-fgetwc.out and annexc.out. > > Firstly, apologies for not noting the failures I saw when committing the > upgrade. > I get the same failures as you, Bruce. I've seen the annexc.out failure for > as > long as I can remember. I took a quick look on google for the tst-fgetwc > failure > but couldn't see anything obvious. > >> I think our options are to >> >> 1. Ignore the error >> 2. Document the error >> 3. Modify the files to fix the test case. That will take two separate >> seds: > > I'd go for option 3, as I did recently for the binutils' testcase that fails > under Glibc-2.10.1. Thanks for figuring out the fix! OK, I'll update the book. It was very time consuming to find the error and fix it because I ended up rebuilding the whole package several times. I've notified upstream of the problem and the fix. I can see why the problem was missed. In most cases the developer would already have the locale in their system. It was only in a chroot environment where locales are not installed does it show up. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: glibc-2.10.1 make check fails
Dan Nicholson wrote: > On Sun, May 24, 2009 at 10:51 PM, Bryan Kadzban > wrote: >> Bruce Dubbs wrote: >>> --enable-kernel=VERSION compile for compatibility with kernel not older than >>>VERSION >> Yes: abort any program at startup if the current kernel version is less >> than VERSION, and also remove any workarounds included in the glibc >> sources for kernels older than VERSION (if any). >> >>> but I found >>> http://www.mail-archive.com/arch-dev-pub...@archlinux.org/msg08016.html >>> >>> which says: The minimum kernel version required for glibc was bumped from >>> 2.6.16 to 2.6.18 >> That's an Arch decision (made by their maintainer), not something that >> applies to glibc itself. :-) See: >> >> http://repos.archlinux.org/viewvc.cgi/glibc/repos/core-x86_64/PKGBUILD?r1=36985&r2=39100 >> >> for the actual change in their PKGBUILD script. (The section labeled >> "line 62".) > > A more authoritative measure here would be to follow fedora since they > are the glibc maintainers. Unfortunately, there's no real rationale, > but their version is 2.6.18 made with this change: > > http://cvs.fedoraproject.org/viewvc/rpms/glibc/devel/glibc.spec?view=diff&r1=1.376&r2=1.377 > > Probably would be best to investigate why that is before making a > change like that. The reason I saw was so code didn't have to check for certain features at run time. The would be to make things easier for the programmers. 2.6.18 corresponds to RHEL 5 and is a compromise for backward compatibility and convenience. 2.6.18 was September 2006. Using 2.6.18 appears to potentially affect binaries built against kernels older than that and run on a LFS-6.5 or later system. I don't see where that would be an issue. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: glibc-2.10.1 make check fails
Gilles Espinasse wrote: > - Original Message - > From: "Bruce Dubbs" To: >> Using 2.6.18 appears to potentially affect binaries built against kernels >> older than that and run on a LFS-6.5 or later system. I don't see where >> that would be an issue. > No. The issue is that if you have a kernel running on the building machine > older than the version defined in --enable-kernel, building glibc will fail > with 'kernel too old message'. So --enable-kernel primary limit to wich > kernel version is needed to build LFS. So to be clear, if someone want to > build LFS from RHEL-5 or debian etch, 2.6.18 is fine. But on any older > kernel, glibc compilation will fail. > > At least that was I have seen before the switch to cross-compilation. From what I see, the consequence is what you describe, but the reason for the behavior is what I wrote. You've triggered a thought: using 2.6.18 will require a change to the Preface section "Host System Requirements", although it would be relatively easy for someone to back off to an earlier kernel just by specifying a different kernel in the configure line of glibc. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LFS-6.5 Status
http://wiki.linuxfromscratch.org/lfs/query?status=new&status=assigned&status=reopened&group=milestone&order=id This is a progress report on what remains for LFS-6.5: #1929Use 'make install', when it can work, instead of 'cp', when installing single files.bdubbs I haven't heard any feedback on this. Will mark as won't fix if I don't hear anything soon. #2326 Modifications to Preface gerard Some changes have been made. Waiting for final review to close. #2329 Zlib FPIC patch reopenedbdubbs I need some additional feedback on this. Robert has problems with passing -fPIC to the build of the libz static library. #2330 development build-logs bdubbs I've just finished building -dev by hand. I'll redo with jhalfs and upload the logs to the website. With gcc-4, the build times have changed (gcc testing is up to about 40 SBU). I'll also update the size/time info in packages.ent from the log. #2391 Util-Linux-NG-2.15 blocker matthew We are really waiting for the 2.16 release and possibly a new release of e2fsprogs to work this. #2398 Coreutils-7.4 fails 2 stty tests unassigned I could not duplicate this problem. I recommend closing, but Matt should do it. #2399 GCC-4.4.0 fails 7 tests unexpectedlyunassigned I could duplicate this, but it's a known common issue. I recommend closing, but Matt should do it. #2410 Inconsistencies in Chapter 5 glibc unassigned This is a text only change in an abbreviated discussion of locales. I'd fix it, but I don't know what should be said. I'm looking for feedback here. #2415 Revalidate need for patches and seds in Chapter 5 unassigned I created this ticket and should probably assign it to myself. #2417 Gettext autopoint.in fixunassigned Robert points to an upstream patch. This is a minor issue. I'll take it if someone else doesn't get it before the weekend. #2418 6.25. Grep-2.5.4 test errors unassigned The text doesn't match my results. I'd like to get confirmation on this one. Again, I'll take it if someone else doesn't get it before the weekend. #2419 gdbm sbu and disk usage values are missing from packages.ent bdubbs I'll fix this when I do #2330 = Selected tickets marked for 7.0 that could be done for 6.5 while we are waiting for Util-Linux-NG-2.16. #2092 Switch all text back from third person to second person pronouns gerard Some fixes have been made. We can probably promote this to 6.5 #2184Provide more information on kernel configuration unassigned I'll do this if I have time after the other tickets. I'm thinking that it should be written as a hint and then have the book point to the hint. Comments? #2337Kbd-1.15 doesn't map U+2010 to U+002d in lat1-16 font unassigned I'm thinking that a short hint be written to address this and a pointer be placed in the book to the pointer. Comments? #2409Evaluate "From Power Up To Bash Prompt" unassigned We may not have to make changes other than to say in the book that the info was written a while ago but is still relevant. Volunteers to evaluate this? #2411 Evaluate "LFS next to existing systems" hint. unassigned Same as #2409. Volunteers? #2413Chapter 5 - GCC Pass 2 - changing dynamic linker location unassigned Relatively straight forward simplification of instructions. I'll do it this weekend if no one else wants it. #2414Evaluate Optimization hint unassigned Same as #2409. Volunteers? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: glibc-2.10.1 make check fails
Dan Nicholson wrote: > On Tue, May 26, 2009 at 9:32 AM, Bruce Dubbs wrote: >> Dan Nicholson wrote: >> The reason I saw was so code didn't have to check for certain features at run >> time. The would be to make things easier for the programmers. 2.6.18 >> corresponds to RHEL 5 and is a compromise for backward compatibility and >> convenience. 2.6.18 was September 2006. > > This doesn't correspond to runtime checks that programmers do. It > refers to runtime checks done in glibc to enable compat paths when > necessary. By saying what your minimum kernel is x.y.z, then the > compat paths for kernel versions earlier than that will not be > compiled into libc. Glibc provides the same interfaces to programmers > regardless. > > If a programmer is trying to use a specific kernel feature (like > inotify), then they have to handle that in their code. Glibc's > --enable-kernel setting has no bearing on that. Thanks for the clarification. >> Using 2.6.18 appears to potentially affect binaries built against kernels >> older >> than that and run on a LFS-6.5 or later system. I don't see where that would >> be >> an issue. > > I don't think it affects binaries. It only affects what kernel you're > running. You can have an ancient binary, and so long as the binary > format and interfaces are still supported on the system you're > running, it should be fine. It sounds like you are agreeing with me. An ancient binary will not run if the support is not built into glibc. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-6.5 Status
Emmanuel Trillaud wrote: > I am currently translating some hints in french, including the > optimization one. I was planning to proposed a patch soon to update the > hint and I saw your status report on LFS 6.5. > >> #2414 Evaluate Optimization hint unassigned > here is some things that could be change : > * the hint seems to recommand the use of -O3 by default. I read some doc > (http://www.gentoo.org/doc/en/gcc-optimization.xml) which > recommands to not use -O3 with the 4.x series > * the links to the online gcc doc point to the doc of gcc 3.3.1 : this should > be > update > * the external link > (http://www.freehackers.org/gentoo/gccflags/flag_gcc3.html) > in no longer valid. It could be replace by : > http://en.gentoo-wiki.com/wiki/Safe_Cflags > * some minor clean up could be done too > > If you are interrested by my remarks, I can provide a patch. Yes, please. Patches are welcome. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-BOOK PDF generation
Gerard Beekmans wrote: > Hi, > > I just installed the missing pieces on the server to allow PDF > generation again (JDK, FOP and FAI). > > First attempt to render the PDF seems to have successful minus a few > warnings regarding missing fonts and an overflow problem in a paragraph. > > Generated PDF is here: > http://www.linuxfromscratch.org/~gerard/LFS-BOOK-20090526.pdf > > Have a look, see if you can spot any obvious issues. If it appears > decent the daily snapshots can include PDFs again. > > The warnings mentioned earlier on this first attempt are as follows. > > May 26, 2009 8:03:58 PM org.apache.fop.fonts.FontInfo notifyFontReplacement > WARNING: Font 'Symbol,normal,700' not found. Substituting with > 'Symbol,normal,400'. > > May 26, 2009 8:03:58 PM org.apache.fop.fonts.FontInfo notifyFontReplacement > WARNING: Font 'ZapfDingbats,normal,700' not found. Substituting with > 'ZapfDingbats,normal,400'. > > May 26, 2009 8:03:59 PM org.apache.fop.fonts.FontInfo notifyFontReplacement > WARNING: Font 'ZapfDingbats,italic,400' not found. Substituting with > 'ZapfDingbats,normal,400'. > > May 26, 2009 8:04:04 PM > org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm > updateData2 > WARNING: Line 2 of a paragraph overflows the available area by 43200mpt. > (fo:block, location: 1824/2298) I imagine that installing the correct fonts will get rid of the first three warnings, but I don't know how to do that or where to get the fonts for pdf. The may be standard fonts/locations, but I'm not sure. I looked for the overflow, but couldn't find it. I would have thought it might have been one of the boot or udev scripts, but I didn't spot the problem. You might look at the lfs-pdf.fo and see if you can get to block 1824. I think that 1pt == 1000mpt == 1/72 inch so we are looking at 43.2 pts or about a half inch. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-6.5 Status
Gerard Beekmans wrote: >> #2326Modifications to Preface gerard >> >> Some changes have been made. Waiting for final review to close. >> >> #2092 Switch all text back from third person to second person pronouns >> gerard >> >> Some fixes have been made. We can probably promote this to 6.5 >> >> > > Agreed on #2092. It's set to Milestone 6.5 now. > > I think I caught the bulk of the 3rd person edits. A few extra pairs of > eyes are always appreciated. > > The Preface is about done I think, but any additional suggestions are > welcome. If nothing else, a grammar check is welcome (ESL and all). I'll > assign that "From Power Up To Bash Prompt" ticket to myself as it fits > within the scope of the Preface. Gerard, I took the liberty of making several grammar/wording changes in the preface. If you are OK with them, I think you can close #2326. I've been going over the book for a couple of days now and no 3rd person text jumped out to me. We may be OK with #2092 also. We can always make quick changes as they get identified. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-BOOK PDF generation
Gerard Beekmans wrote: >> I looked for the overflow, but couldn't find it. I would have thought it >> might >> have been one of the boot or udev scripts, but I didn't spot the problem. >> You >> might look at the lfs-pdf.fo and see if you can get to block 1824. I think >> that >> 1pt == 1000mpt == 1/72 inch so we are looking at 43.2 pts or about a half >> inch. >> > > The blocks don't seem to be numbered nor one block per line. Anybody > feel like counting? It seems to me this issue is too long of a line in a > literal output type section. I'm not going to worry about it too much > right now. Maybe there ends up being an easy to way to track down the > exact location in an easy way. I'm sure there's a way. I just don't know > it yet. :) Can you send me the .fo file? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-6.5 Status
Gerard Beekmans wrote: >> #2326Modifications to Preface gerard >> >> Some changes have been made. Waiting for final review to close. >> >> #2092 Switch all text back from third person to second person pronouns >> gerard >> >> Some fixes have been made. We can probably promote this to 6.5 >> >> > > Agreed on #2092. It's set to Milestone 6.5 now. > > I think I caught the bulk of the 3rd person edits. A few extra pairs of > eyes are always appreciated. > > The Preface is about done I think, but any additional suggestions are > welcome. If nothing else, a grammar check is welcome (ESL and all). I'll > assign that "From Power Up To Bash Prompt" ticket to myself as it fits > within the scope of the Preface. Gerard, I took the liberty of making several grammar/wording changes in the preface. If you are OK with them, I think you can close #2326. I've been going over the book for a couple of days now and no 3rd person text jumped out to me. We may be OK with #2092 also. We can always make quick changes as they get identified. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-BOOK PDF generation
Gerard Beekmans wrote:
>> I looked for the overflow, but couldn't find it. I would have thought it
>> might
>> have been one of the boot or udev scripts, but I didn't spot the problem.
>> You
>> might look at the lfs-pdf.fo and see if you can get to block 1824. I think
>> that
>> 1pt == 1000mpt == 1/72 inch so we are looking at 43.2 pts or about a half
>> inch.
>>
>
> The blocks don't seem to be numbered nor one block per line. Anybody
> feel like counting? It seems to me this issue is too long of a line in a
> literal output type section. I'm not going to worry about it too much
> right now. Maybe there ends up being an easy to way to track down the
> exact location in an easy way. I'm sure there's a way. I just don't know
> it yet. :)
I think I found it. In the very last page of the index:
# /usr/include/{asm{,-generic},drm,linux,mtd, rdma,sound,video}/*.h:
Linux-2.6.29.4 API Headers
The first column overflows by quite a bit. It is specified in
chapter06/linux-headers.xml, line 87.
I tried running make pdf on quantum, but got:
/bin/sh: fop: command not found
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: LFS-BOOK PDF generation
Gerard Beekmans wrote:
>> I tried running make pdf on quantum, but got:
>>
>> /bin/sh: fop: command not found
>>
>
> I didn't add the JDK and FOP directories to the global $PATH yet.
>
> Add the appropriate lines to your .bash_profile or .bashrc:
>
> PATH=$PATH:/usr/fop
> export JAVA_HOME=/opt/jdk
> export ANT_HOME=/opt/ant
>
> and to .foprc
>
> FOP_HOME=/opt/fop
> FOP_OPTS="-Xmx2024m"
>
> (The last line per BLFS instructions and I just took the RAM amount as
> per "free -m" output to get started).
OK, its working now.
I still get the font warnings, but not the overflow.
=
--- chapter06/linux-headers.xml (revision 8929)
+++ chapter06/linux-headers.xml (working copy)
@@ -69,7 +69,7 @@
Installed headers
-
/usr/include/{asm{,-generic},drm,linux,mtd,rdma,sound,video}/*.h
+/usr/include/asm/*.h
@@ -79,13 +79,12 @@
-/usr/include/{asm{,-generic},drm,linux,mtd,rdma,sound,video}/*.h
+/usr/include/asm/*.h
The Linux API headers
-
-/usr/include/{asm{,-generic},drm,linux,mtd,
-rdma,sound,video}/*.h
+
+/usr/include/asm/*.h
===
Some lines are wrapped, but one or more of the 3 lines that have:
/usr/include/{asm{,-generic},drm,linux,mtd,rdma,sound,video}/*.h
are causing the problem. We can probably fix it by breaking that up into
multiple entries in the seglist item and multiple varlistentry items.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: LFS-BOOK PDF generation
Gerard Beekmans wrote:
>> I think I found it. In the very last page of the index:
>>
>> # /usr/include/{asm{,-generic},drm,linux,mtd, rdma,sound,video}/*.h:
>> Linux-2.6.29.4 API Headers
>>
> While I appreciate the way that's written, it's hardly readable and it
> does take a few careful looks to actually construct the final list of
> files in your head.
>
> Let's break that up into the individual components. It'll mean a few
> extra lines of text, but it will greatly enhance readability.
>
> Do you want to work on that Bruce or shall I? If you've already started
> work on reformatting it, I'll let you finish it off otherwise I'll
> tackle it tonight.
>
> Let me know.
Go for it. I've gost several other items working.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: LFS-BOOK PDF generation
Gerard Beekmans wrote: > May 26, 2009 8:03:58 PM org.apache.fop.fonts.FontInfo notifyFontReplacement > WARNING: Font 'Symbol,normal,700' not found. Substituting with > 'Symbol,normal,400'. > > May 26, 2009 8:03:58 PM org.apache.fop.fonts.FontInfo notifyFontReplacement > WARNING: Font 'ZapfDingbats,normal,700' not found. Substituting with > 'ZapfDingbats,normal,400'. > > May 26, 2009 8:03:59 PM org.apache.fop.fonts.FontInfo notifyFontReplacement > WARNING: Font 'ZapfDingbats,italic,400' not found. Substituting with > 'ZapfDingbats,normal,400'. I did some research on this and found: http://www.nabble.com/Adding-Verdana-font-in-Linux-and-registering-it-with-FOP-0.94-td19711056.html#a19722467 The relevant comment is: This is because there are not italic versions of the ZapfDingbats and Symbol fonts. DocBook specifies those fonts so that a fallback can be used for special characters, but this doesn’t work well with FOP. If your custom font contains glyphs for all the characters you use in your document, then you should have no problems. Verdana does contain glyphs for all the characters and punctuation marks commonly used in English, at any rate. If you use other special characters like in mathematics, watch unexpected ‘#’ in the output pdf: this is what FOP uses as an indication that it couldn’t find a glyph for the corresponding character. Looking at the dingbats, http://en.wikipedia.org/wiki/Dingbat, I don't see where italic or bold dingbats make sense. We can just ignore these warnings. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: glibc-2.10.1 make check fails
Trent Shea wrote: > On Sunday 24 May 2009 21:09:35 Trent Shea wrote: >> make[3]: *** [/sources/glibc-build/nptl/tst-mutex5.out] Error 1 >> make[3]: *** [/sources/glibc-build/nptl/tst-mutex9.out] Error 1 >> make[3]: *** [/sources/glibc-build/nptl/tst-mutex5a.out] Error 1 > > Alright, I believe that these errors are triggered when running a kernel > version greater than 2.6.28.10. > > For tst-mutex5, the attached diff shows where the test failure occurs. I've > tried increasing the Wait 2 seconds section, with no success. That's interesting. I don't see those errors, but perhaps that's because I'm building on an LFS-6.4 system with a 2.6.27.4 kernel. > Another note regarding the 2.6.29.4 kernel headers. When running make > headers_check there are many 'leaks' and 'extern's make no sense in > userspace' > messages, the 2.6.28.10 kernel does not produce these messages. Maybe an > explanation regarding these messages could be considered? I haven't seen these either. Are you building 6.5 on a 6.5 system? This seems to be a kernel/glibc interaction thing and beyond the scope of LFS. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
