Re: 64-bit LFS
On Thu, 31 Mar 2005, Bruce Dubbs wrote: I just got a new system for testing LFS builds. It is a Intel 3.2GHz P4 system with EM64T technology. It came with RH Enterprise 3.0 for AMD64 and EM64T preinstalled. 8-D I'm not really sure what the EM64T technology does, except Googling around seems to indicate that there is something about allowing more than 4G memory (32 address bits?). uname -a gives: Linux lfs5 2.4.21-15.EL #1 SMP Thu Apr 22 00:09:47 EDT 2004 x86_64 x86_64 x86_64 GNU/Linux I believe there may be internal kernel differences in _how_ things work, particularly for addressing high memory, but with any recent 2.6 kernel it should just work. Linuxhardware did a comparison back in February: http://www.linuxhardware.org/article.pl?sid=05/02/24/1747228 Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.1 release branch
On Fri, 1 Apr 2005, Matthew Burgess wrote: Matthew Burgess wrote: Until then, you'll have to wait until I render the book and post a link to it :) OK, it's now rendered and available at http://www.linuxfromscratch.org/lfs/view/testing/. Regards, Matt. Curse you, Red Baron! I've been doing a manual build on my K6 for most of this week, using svn-20050321 but with llh-2.6.11.2. I'd got to the latter part of chapter 6 (file), so it looked as if upgrading the book for the rest of it should be ok. e2fsprogs-1.37 fails `make check' (copied by hand from the other screen) make[1]: Entering directory `/usr/src/e2fsprogs-1.37/build/lib/e2p' LD tst_ostype In file included from ../../../lib/e2p/ostype.c:10: ../../../lib/e2p/e2p.h:5:28: ext2fs/ext2_fs.h: No such file or directory followed by a warning that struct ext2_super_block is declared inside parameter list and parse errors at __u32 and then EXT2_OS_LITES undeclared (par for the course for a missing file, I guess). Gotta go out now, this is just a preliminary heads-up. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.1 release branch
On Sat, 2 Apr 2005, Matthew Burgess wrote: Ken Moffat wrote: On Sat, 2 Apr 2005, Matthew Burgess wrote: So that's why I never saw it. I simply don't have the time or resources to do a full rebuild every time a package gets upgraded. Hmm, now I've seen your comment that you hadn't built it all. On the contrary, my comment said that I *did* build e2fsprogs-1.37 and *did* run 'make check' on it. My build environment was such that the bug wasn't triggered though. I meant your comment in the earlier mail when you announced the branch. If I'd noted that at the time, I would have been less surprised. gcc-4 shouldn't pose too many problems - it's just a package upgrade albeit with slightly wider effects than most other upgrades. multi-arch and cross-lfs will pose more of a problem with regard to testing on those hosts and targets, but that is up to those with such hardware to deal with IMNSHO. It's gcc-4 that scares me for the first two or three months (looking at the bigger BLFS picture more than LFS). Some packages will be actively maintained and just need upgrading, some won't have any problems, but I worry how many other old but useful packages will break. But then, I still don't understand why we moved on from egcs-2.91.66 ;) Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Boring statistics [ was Re: 6.1 release branch ]
On Fri, 1 Apr 2005, Matthew Burgess wrote: PS: SBUs, disk usage and package tarball size reports would be most welcome, from anyone with the necessary scripts to record them. I think the upgraded packages should be pretty accurate, but I've not done a full system build with them yet, so I don't think all stats are up-to-date. These usage (assumed maximum, i.e. generally space used after installing and before blowing away the source) and SBU figures are from a manual build on i586 (I had so much trouble with 6.0 I decided to walk myself through it this time before trying to update my scripts). This is a somewhat slow box ( 1 SBU = 18m25.2 ), with a slow disk, and using a sort of LFS-5.1 host (gcc-3.3.5, binutils-2.14.90.0.8). Worth spelling this out because a small change in the absolute SBU can change some of these values (e.g. pass 2 binutils is actually an exact 1.35 SBU here, rounded to 1.4). Also, of course, some changes on the host might change what gets built and tested in chapter 5 (e.g. missing makeinfo). Looking at the old packages in the book, I begin to think that chapter 5 space and time include running all tests, but chapter 6 don't! Needless to say, my chapter 5 only had the essentials, but chapter 6 had all the tests. My figures are all without CFLAGS, CXXFLAGS, LDFLAGS. We seem to have some inconsistencies creeping in to the presentation - from memory, LFS SBUs should have a resolution of 0.1 SBU and a minimum of 0.1 (I know BLFS goes for a finer resolution now, although I don't believe the figures are that repeatable even on an unloaded box). Also, I think the policy for space used is tenths of a megabyte between 1.0 MB and 10 MB, then whole megabytes - I can't remember what was agreed for packages taking less than a MB. No figures for tarball sizes, mine aren't all in the .bz2 format. Also, no figures for the kernel compile. I've put these all in one sequence, even those where I agree with the book, to make this easier to relate to the book. And I start to wish I hadn't started this, even just putting the data into this mail is time consuming. Anyone for trivial|quick|average|long (times) and tiny|small|average|big|glibc (space) ? Of course, somebody would still have to periodically time and measure to make sure packages were still in the correct category :-( Chapter 5 binutils pass 1 obviously 1.0 SBU, 200 MB here (book 194 MB) gcc pass 1 no comment on space, I used the full tarball, but only 3.9 SBU here, book suggests 4.4 (maybe it hasn't changed since static linking ?) linux-libc-headers-2.6.11.2 obviously 0.1 SBU, 27 MB (book 22 MB) glibc-2.3.4 without locales so only 5.3 SBU 304 MB, you may wish to include the time for some or all locales in the book. tcl-8.4.9 - tried the tests, but I can still only get up to 0.5 SBU (0.3 without), book has 0.9 SBU. Agree 23 MB. expect-5.43.0 (0.1 SBU, 4.0 MB - agree) dejagnu-1.4.4 0.1 SBU fairly obviously, but only 6.1 MB (book 8.6 MB) - like many of these differences, it isn't really worth sweating this, the space is immaterial, but it does make me wonder about some of these figures :) gcc-3.4.3 pass 2 - ok, I used a full tarball, which might add a slight overhead if it goes into directories then finds nothing to do, (although that doesn't seem to show up in pass 1), but mine took 17.1 SBU including the tests. binutils-2.15.94.0.2.2 with tests 1.4 SBU here (I'm not arguing against 1.5), space 144 MB (book 108 MB). gawk-3.1.4 0.2 SBU and 17 MB - agree. coreutils-5.2.1 - my figures are 0.5 SBU and 55 MB, I guess the book includes the tests. bzip2-1.0.3 0.1 SBU and 4.0 MB - book says 2.5 MB. gzip-1.3.5 0.1 SBU and 2.1 MB which is below the book's 2.5 MB. diffutils-2.8.1 0.1 SBU and 5.9 MB (book has 7.5 MB). findutils-4.2.20 I have 0.1 SBU and 8.7 MB, maybe the book includes time for the tests, but its 7.6 MB is low. make-3.80 0.1 SBU and 7.6 MB (book 0.2 and 8.8, again perhaps related to running tests). grep-2.5.1a without tests 0.1 SBU, 4.8 MB (book 0.1, 5.8 - might be related to running tests, but inconsistent with my chapter 6) sed-4.1.4 0.1 SBU, 6.1 MB (book 0.2, 5.2 - maybe the size is from a previous version) gettext-0.14.3 without tests 0.8 SBU, 62 MB (book 0.5 SBU, 55 MB) ncurses-5.4 0.5 SBU, 27 MB (book 0.7, 26) - again, one of hte not very important discrepancies patch-2.5.4 0.1 SBU, 1.5 MB (0.1, 1.9) ditto tar-1.15.1 without tests 0.2 SBU 13 MB (book 10 MB) texinfo-4.8 without tests 0.2 SBU and 16 MB - agree bash-3.0 without tests 0.3 SBU and 21 MB - book longer and bigger, maybe the tests m4 : I used 1.4.2 because that was in the book when this build started bison-2.0 without tests 0.1 SBU and 10.0 MB (book 0.6 and 10.6 - my chapter 6 figures imply 0.8 and 10.2 with tests) flex-2.5.31 without tests 0.1 SBU and 7.9 MB (book 0.6 and 10.6, possibly a dup of the bison values) util-linux-2.12q 0.1 SBU and 9 MB (book 0.2 and 16 MB) perl-5.8.6 0.5 SBU and 80 MB (book 0.8 and 74 MB)
Re: Planning for Cross-LFS/Multi-Architecture 7.x Release
On Mon, 18 Apr 2005, Randy McMurchy wrote: SSL/SSH != minimalistic I realize your suggestion Jim is a concession to a serious drawback in the new methodology, but just in the hour or so since you posted you message, there been talk of adding SSS, SSL, Lynx and GPM to core LFS (not all mentioned by you, Jim) What's next? nfs-utils ? (all my source is on an nfs mount). Cross-compiling is a very educational experience, for those few who manage to complete it (I've cross-compiled kernels, cross-compiling a full system is more than an order of magnitude harder). But building in an absolutely-minimal new system is very much a hair shirt experience - do it if you have to, but it isn't something to seek out. Some of us have enough problems just getting our new systems to boot, forcing everybody to reboot into a super-lean system to build the real system would limit participation. Multi-Architecture good. Cross-building painful. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Copyright policy on patches
On Sun, 8 May 2005, Jeremy Huntwork wrote: Could someone throw me a cluebat here? I've found a patch that is needed for the sparc architecture and kbd-1.12 (Build fails with: kbdrate.c:167: error: structure has no member named `period') The patch I've found is placed under two licenses it seems. How do we usually handle something like this? Here's the patch header: # --- T2-COPYRIGHT-NOTE-BEGIN --- # This copyright note is auto-generated by ./scripts/Create-CopyPatch. # # T2 SDE: package/.../kbd/kbdrate-sparc.patch # Copyright (C) 2004 - 2005 The T2 SDE Project # Copyright (C) 1998 - 2004 ROCK Linux Project # # More information can be found in the files COPYING and README. I've no experience of T2, but Rock seem to add copyrights for 'infrastructure' they generate, e.g. descriptions of what stuff does. This is not a problem in itself, they have a right to assert ownership for whatever they contribute. It's the _license_ of the copyright (e.g. bsd, gpl, lgpl, mit, other) that matters. Occasionally, people try to add inappropriate terms, but you would need to look at the details to determine that. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Use of Variables in Cross-LFS
On Fri, 13 May 2005, Jeremy Huntwork wrote: Ken Moffat wrote: In my opinion, put it all in variables - the sparc page has '-m32' exposed to the reader without an explanation (although it might be explained on another page). Put it all in variables, and explain them at the beginning, then just use them. The explanatory text for the cross-lfs is still coming. We still have a lot of work to do in that area. At the moment, we're just focusing on getting the commands straight, however, point taken. No worries. I'm attempting a slightly different multilib build (i686 LFS-6.1 to build x86_64 kernel, then boot that and hopefully build the rest much as the 6.1 book will) and I'm still tweaking the options in the first part (64-bit binutils and c compiler) so that I don't include [i] too many [/i] bogosities in my instructions. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Use of Variables in Cross-LFS
On Fri, 13 May 2005, Jim Gifford wrote: Ken that's one of the things we are going to do after we get the builds working is go through every page and add more text or less text to give the reader a better understanding. We would welcome your input on this. I'll be happy to contribute, but I've got to understand how the new stuff fits together first. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
On Sat, 14 May 2005, M.Canales.es wrote: El Sábado, 14 de Mayo de 2005 01:42, Archaic escribió: Lastly, IMHO the combo HOST != TARGET only is usefull in two cases: To build a full system (with X, servers, etc...) in a fast machine that will be later instaled in a slow machine. Or to build a minimal system to can boot a machine that have no system instaled yet. But in that case you must have physical acces, then you can use also a BooCD to boot the machine and to install LFS using HOST=TARGET. I think I've got a third - machines that can run a 32-bit or a 64-bit system (i.e. x86_64 or ppc64) that are currently running 32-bit (i686 or ppc). It's easy enough to install current 32-bit LFS on them, upgrading to multilib should be educational (I'm trying at the moment, learning a lot about the toolchain so far, but a very long way from completing). Specifically, I'm hoping to build a 64-bit kernel (done that part), then use that with the 32-bit userspace to build the multilib. Or do you propose that those of us moving to 'fatter' machines should rely on new boot CDs ? Of course, even if you agree that this is a valid way of building, it may be better as a hint. To some extent, that probably depends on how much the process differs from a multilib linux host building a new multilib LFS for itself. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
On Sat, 14 May 2005, M.Canales.es wrote: Don't miss the point of this thread: Is there realy some case where you must to build the packages up to reboot in one machine (the HOST) and then to copy that temp system to other machine (the TARGET) to build the final system? Ah, I misunderstood the usage of 'HOST' and 'TARGET' here. I am indeed running it all on the 'TARGET'. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Move back to FSF binutils
On Sun, 15 May 2005, Matthew Burgess wrote: So, does anyone think we should still stick with HJL binutils, and if so, what are the compelling reasons for doing so? I will be less than surprised if the multi-architecture book has to use HJL for some architectures, in the past HJL has always been the way to get the new features/fixes. Meanwhile, use whatever you like, provided it works. Those of us who disagree can yet again diverge from the book ;) Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Use of Entities in the cross-lfs book
On Tue, 21 Jun 2005, Jim Gifford wrote: The one thing I'm not sure on is if the SBU's will be the same on the different architectures, as far as the build size goes, it should be the same except for one package which is gcc, since we have a 32bit ABI build, 32/64 ABI build, and 32/n32/64 ABI build. My guess is that outside the toolchain, SBUs will be broadly in line, partly because many packages fall into the minimum SBU is 0.1. However, that is ignoring the time to run test suites (yes, I realise cross-lfs cannot run test suites in what we now call chapter 5) which seems to be the new consensus (and in practice, it's often the test suites which take the time, both in LFS and BLFS). In the toolchain, I expect everything to vary greatly (e.g. I assume a multilib binutils creates a library to process both architectures, so I expect it to take longer). But these are things I'm trying to find out at this time. I have a script that I have been working on that will calculate the build disk usage. So far they are all within a few K of each other, but I need others to validate the findings, once I feel the scripts are working properly. Ah, more joy of scripts ;) I deviate by symlinking /etc/mtab to proc for chroot, then it's just repeatedly df -k with a grep for something identifying the relevant filesystem (/mnt/lfs, rootfs, whatever), and repeat before the untarring, after installing, and after cleaning up. Of course, any logs had better be on a different fs (mount --bind) and I think cross-lfs builds host tools in ~/ which doesn't always lend itself to accurate space calculations in a running system. (growing logs if /home is on same fs as /, or just general output from users/processes) Fun! I'll surprised if glibc sizes are similar for many different architectures. Going back as far as LFS-5.0, glibc on ppc (32) always used to be considerably bigger than the x86 figures in the book, because all ppc instructions are the same length. Is/are the cross-lfs book(s) being regularly rendered in html yet ? I'm on a trial run of (LFS-6.1/BLFS-6) x86_64 blfs at the moment following a very broken hack on Ryan's scripts, but I expect to have another go at building x86_64 from i686 next week. At the moment I'm in the infinite number of monkeys with typewriters stage, but one day I might crack it. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Book for 6.1-pre1: a few miscellaneous nits
On Wed, 6 Jul 2005, Bernard Leak wrote: Dear List, I present a few nits I have picked out of the hair of blfs-6.1-pre1 (the book): LFS, not blfs. The word is programme. Yes, it really is, unless you are writing American. It is a curiosity of the LFS book that it's not instantly obvious whether it's written in American English or not. The use of alternative suggests that it isn't mid-American, though it could still be from darkest New England. On the other hand, you have stabilized rather than stabilised. For the rest of us: Program is merely an American (mis-)spelling, adopted by people who failed to know better. Grim determination to believe that there *must* be a justification for what one finds oneself doing can lead people into odd places. Washing- machines have programmes; VCRs have programmes; why is a computer different? Likewise with disk and disc, though disk has slightly better claims as a once-unobjectionable spelling now discarded. As somebody who used to program for a living, the normal usage in Britain is 'program' for a piece of software, programmes for the BBC. You may not like it, but that's how it is. Similarly, disk is the common term nowadays for magnetic storage. And if push comes to shove, I assume Canadian usage will be the preferred model ;) Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
/mnt/lfs/dev and 6.1-pre
Should I expect /mnt/lfs/dev to be busy when I come to shut down after building 6.1-pre2 (in an xterm, if it matters) ? Nothing showed in lsof or fuser, and I was able to remount r/o. Maybe this isn't new and I've just not noticed before ? Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: /mnt/lfs/dev and 6.1-pre
On Thu, 7 Jul 2005, Matthew Burgess wrote: Ken Moffat wrote: Should I expect /mnt/lfs/dev to be busy when I come to shut down after building 6.1-pre2 (in an xterm, if it matters) ? Not if you were using the version specified in that book. Later versions kick off a daemon, which one has to kill prior to unmounting. I can't think what else might cause this though, sorry. Matt. Heh, I wouldn't dare to use later versions than are in the LFS book ;) Thanks anyway. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Coreutils installation, and some minor grammar issues
On Thu, 7 Jul 2005, Chris Staub wrote: The coreutils installation page (in both Chapters 5 and 6) strongly recommends adding DEFAULT_POSIX2_VERSION=199209 to the configure command. I've installed lfs several times over the last couple of months without that, and never had a problem. It is possible that it may still be needed in chapter 6 (since that is the version that will be used for the final system, and who knows what will be installed...) but for chapter 5 it might not be needed. Obviously some further testing should be done to verify this (all I know is it works fine on my own system) but I just thought I'd mention it. Question: have you built QT on any of these installs ? For several months I was unable to build QT on the aggravational platform I was using. Eventually, came time for a fresh install on one of my other boxen, and same problem. Tracked it down to a typo in my scripts for DEFAULT_POSIX2_VERSION (DEFAULT_POSIXZ_VERSION) in chapter 5 - chapter 6 had been built correctly. From memory, somebody on a support list pointed out that this setting from chapter 5 affects the chapter 6 toolchain. This was with whichever versions of QT were appropriate to kde-3.3 and perhaps kde-3.2. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Roadmap
On Mon, 25 Jul 2005, Matthew Burgess wrote: LFS-6.2: This will just be an incremental release, further stabilising our already proven PLFS-based build method. GCC-3.4.x combined with Glibc-2.3.5 seems pretty robust, and adding binutils-2.16.1 to the mix should further solidify that. Obviously, other packages will also be upgraded wherever possible (i.e. where shadow *isn't* broken, and up to a point where udev doesn't inflict an initrd on us!). But what does 6.2 bring to the party ? A nice straightforward version upgrade in two or three months' time (which will help accustome people to more frequent releases), but I don't see anything to attract people to test it. Now, I'm one of the people who hates rushing into new versions and new methods, so part of me thinks good, time to stabilise the more interesting developments, but most people here want to be nearer the bleeding edge. Or should I be reading this as let BLFS have more time to prepare for gcc-4 and multiple architectures ? Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Roadmap
On Mon, 25 Jul 2005, GN wrote: On Monday 25 July 2005 12:36, Matthew Burgess wrote: A number of people have emailed me privately, and its also come up on the list recently, so here's my thoughts on what could/should be going on in LFS land. Yes, I know it's taken me far too long to ditch my Release Manager hat and don my Project Manager/Planner hat, but still.. LFS-6.2: [...] kernel 2.6.12 would be nice. Given timescales, I imagine 2.6.13 will be out. But seriously, what do you see in 2.6.12 that isn't there in 2.6.11 ? LFS-7.0: [...] Incorporate Wifi. I know this can be tricky, but one can only wish. Regards, SeattleGaucho Well, if that's not BLFS, I don't know what is ;) Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Roadmap
On Tue, 26 Jul 2005, TheOldFellow wrote: OK, we have some i18n 8-bit users, but multibyte? I see some names than might be Chinese on the list occasionally. I imagine some of our german-speaking users might prefer to use utf. I often see posts (not necessarily on lfs lists) where there are obviously multiple bytes for some of the characters in .sig files. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
glibc test hangs (6.1 cross-build)
I've definitely got a strangeness in my current build scripts for pure64 x86_64 from i686. First time I built it, running make check on target glibc hung in inet tests. Looking at it, I discovered I had omitted the fix_test patch. Applied that, tests completed. This time, I'm trying to get rid of a lot of bogosities that crept in, and clean up the remaining stuff that wants to use lib64. Again, glibc hung at this point. I've killed it, and also a tcltest that was apparently still running (had that too the first time, but didn't notice until the end of the build), and now glibc has sailed through the testsuite. Anybody else seen anything like this ? Any clue-bats ? Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: glibc test hangs (6.1 cross-build)
On Tue, 26 Jul 2005, Ryan Oliver wrote: Indeed I have seen this a couple of times... From (possibly faulty) memory I recall noticing it in chroot builds (which for convenience is predominately what I have done of late...) will check my logs and get back to you... Thanks, I'll appreciate that. This _is_ a chroot (cross-built from i686 userspace with a 64-bit kernel). Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Change r6572 Roadmap
On Fri, 29 Jul 2005, Jim Gifford wrote: In my book patching GCC should only be done when neccessary, to me there had to be a better solution. Hi Jim, Applying that remark to a different context, I guess that means you'll be dead against lib|lib32 (instead of lib64|lib), or indeed pure64 just using lib, for x86_64 because they require seds or patches to gcc ? Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Remaining 6.1 bugs
On Sat, 30 Jul 2005, Bruce Dubbs wrote: This is a list of the remaining 6.1 bugs that need package updates: Bug Package Assigned to 1350 Kerberos 1369 Tidy Randy 1430 LIBPCAP 1443 Firefox 1444 Thunderbird Richard 1475 Ethereal Randy - Bruce, I take it you're going to ignore 1485 that I raised yesterday ? And still on the subject of security, it appears that fetchmail is now being maintained from http://fetchmail.berlios.de who have a 6.2.5.2 release to address CAN-2005-2335. See e.g. http://www.securityfocus.com/archive/1/406497/30/60/threaded No doubt there are other known vulnerabilities in the book, but in the absence of a list of packages/status I'm *slowly* trying to review them. I'm sorry this doesn't fit nicely with preparation for a release, but that is the nature of vulnerabilities. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: stupid newbie question
On Sat, 30 Jul 2005, Jaap Struyk wrote: Op za 30-07-2005, om 17:19 schreef Jaap Struyk: What the 2 have in common is: asm operand 1 probably doesn't match constraints and impossible constraint in `asm' Both modules build fine on a clean kernel, but the errors don't make sence to me. Buth they do now, maybe I reacted a bit to quikcly (sorry) but the answer is something wrong in the book. (or missing) The kernel is compiled with: make CC=gcc -no-pie -fno-stack-protector-all but according to the hlfs book modules are build and installed with: make modules_install This seemed odd, if the kernel needs those options the modules probebly want them too, so I added CC=gcc -no-pie -fno-stack-protector-all to the build off both ivtv and nvidia and they compiled without a glitch... Maybe something off value to add to the book. For in-kernel modules in 2.6, they are actually built during 'make', the modules_install target only installs them. Therefore, the switches _do_ get used when the module is built. External modules are obviously different (they can't be built when the kernel is built), and the book needs to point out what you've reported. /me suppresses the thought that proprietary modules and hardened systems may not go together well. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
zlib symlink from /usr
This is prompted by upgrading zlib to 1.2.3 (thanks to Matt for the heads up). Everything in my system using a shared libz is linked against libz.so.1 (good), but we persist in offering packages a symlink from /usr/lib/libz.so to /usr/lib/libz.so.1.2.3 [ png bit me when I overlooked that in my scripts ]. Should this symlink not point to /lib/libz.so.1 (itself a symlink, but updated by zlib whenever it is installed) ? Alternatively, is the symlink from /usr/lib totally unnecessary ? Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Chapter 5 GCC nit
On Mon, 1 Aug 2005, Randy McMurchy wrote: Hi all, A minor nit I noticed in the Chapter 5 GCC instructions (all versions): Noted in the SBU times between Pass 1 and Pass 2 is that they seem to be reversed. Pass 1 is shown to be 4.4 SBU and Pass 2 is 11.0. Shouldn't these be the other way around? My experience is that bootstrapping Pass 1 takes significantly longer than simply building in Pass 2 (Pass 2 includes c++ notwithstanding). I did not factor in the test suite as the SBU times don't reflect they are being run. Huh ? 11 SBU for pass 1 ? I admit that my timings include the testsuite for pass 2, but for 6.1 on i686 I've got gcc-3.4.3 pass 1 596 seconds, 4.3 SBU gcc-3.4.3 pass 2 2075 seconds, 14.9 SBU Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Upcoming util-linux
On Wed, 3 Aug 2005, steve crosby wrote: Just a heads up - util-linux 2.13 will remove several items, as per the following changelog entry for pre1 Changes: GNU autoconf/automake/libtool are now used for building. schedutils were added. Support for curses implementations other than ncurses was removed. The arch, passwd, rescuept, and setfdprm programs were removed. mkminix-0.1/ was removed. Misc fixes and documentation updates were made. A translation was added for the vi locale. The translations for the ca, de, fi, fr, it, nl, ru, and tr locales were updated. This may impact some apps that use arch in their configure stage (I know at least perl used arch at some stage) Thanks for the heads-up Steve. I know my scripts use arch to decide on architecture-specific variations, but a quick look at the man page says it's equivalent to 'uname -m' so shouldn't be a big deal anywhere. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-stable, errata and new packages
On Mon, 8 Aug 2005, Torsten Vollmann wrote: Hi Folks. I think of this because I want to run a stable LFS on my main system but if a package is updated and put into LFS-trunk I'm always wondering if it could be applied to LFS-stable, too, or if it would mix up the build process because the developers have changed something. So what I mean is: It would be nice to have a page in addition to the errata-page stating something like this: updated package safe to apply to LFS-stable instructions foo-x.y.z yes ba-a.b.cno Hi Torsten, I think you're overlooking a couple of things - editors upgrade packages and do any testing them with the current book. Nobody, AFAIK, is testing package updates against the last stable book, other than to fix identified problems and vulnerabilities. Even then, changes might still introduce unexpected results. - the svn book is by definition unstable. Sometimes, it can take days, or weeks, for the problem to show up (e.g. past issues with bison and strip) and the fix might be to revert the version. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: System clock hastening
On Mon, 8 Aug 2005, Matthew Burgess wrote: Jens Olav Nygaard wrote: My system clock seems to gain an extra five minutes per hour, snip Any ideas? Yep, I just use ntp (see BLFS). My hardware clock seems to gain even when the system is switched off! I have a bootscript that syncs the clock to an ntp server at bootup, ntpd runs whilst the box is up, and the hardware clock is set to the same time as the software clock on shutdown. My desktops are both using ntp against a local server with similar constraints on the hwclock. Every boot shows a difference - usually less than a second if I'm rebooting to try a new kernel or whatever, sometimes a bit longer if that box has been powered off. That's just the way it works, unless somebody knows differently. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Working towards 6.1 final
On Tue, 9 Aug 2005, Ken Moffat wrote: I plan to look at dhcpcd in a few minutes Well, the good news is it seems to be maintained again (a 2.0.0 version at berlios.de incorporating recent patches from debian and gentoo). The bad news is the layout of the source has been tidied up, moving the files around and apparently changing the build method. I guess this is now svn stuff rather than 6.1. Sorry for the noise. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Security patches
Hi, One of the things I've started spending more time on recently is trying to ensure my systems are patched against known problems. [ Ah, the good old days when I only had a handful of applications to worry about ]. Most of the packages I'm trying to monitor are not in the LFS book, but a few of them are. First in line is bzip2 with the CAN-2005-0758 vulnerability (same vulnerability as zgrep - if a user can be persuaded to run bzgrep on a number of files in an untrusted directory which contain specially crafted file names, arbitrary commands can be invoked with the permissions of the user - think sed commands). AFAIK, there is no publically-accessible development branch of bzip to monitor for their response. I've picked a patch out of fedora (modified to change the interpreter to /bin/bash instead of /bin/sh because of bash-specific pattern replacements) and people who don't read lfs-security can find it at (watch for line wrap) http://www.kenmoffat.uklinux.net/patches/bzip2-1.0.3-bzgrep_security-1.patch This vulnerability should be low risk for most of us, but I think it's the sort of thing that ought to be applied. The question is, what do other people, particularly LFS editors, think ? Should there be a severity threshold, and less critical patches need to be discussed on this list, or should I just go ahead and commit ? Do people think the patches need to be reviewed for apparent correctness, or is the opinion of one editor that a patch looks reasonable sufficient ? ( The first patch agaisnt this vulnerability that I found was from ubuntu, but although they correctly identified the need to use /bin/bash I think they went overboard on the backslashes and made the first part do nothing). Is there a tradeoff to be made between patching as soon as we mere mortals find out about new vulnerabilities (mainstream distros get to participate on non-disclosure lists, so they can create the patches) and reviewing what we put into the book ? Opinions ? Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Security patches
On Tue, 16 Aug 2005, Archaic wrote:
On Tue, Aug 16, 2005 at 09:47:06PM +0100, Ken Moffat wrote:
This vulnerability should be low risk for most of us, but I think it's
the sort of thing that ought to be applied.
Agreed.
Hmm, I think I should have checked the patches list before starting
this thread, it's already been committed. Thanks, Jim.
The question is, what do other people, particularly LFS editors,
think? Should there be a severity threshold, and less critical
patches need to be discussed on this list, or should I just go ahead
and commit ?
Well, most things should be mentioned even if there is no discussion
needed. It at least gives the OP the chance to layout the problem and
the relevant URL's (ensure {b,}lfs-dev and lfs-support are sent the
email for the sake of those who don't follow all the lists). If the
patch is tested and known to not break something obvious, then by all
means commit it (testing branches and other specialty branches may have
more specific guidelines).
If people don't want to follow -security, I don't think spamming the
support lists will help.
If it breaks something subtly, that would hopefully be found as more
people build trunk and BLFS, which also implies that the closer to a
release we get, the more rigorously the editor should test *before*
committing. At the very minimum of testing is to create a test case and
trigger the vuln in the non-patched software then try with the patched
software instead of taking some distro's word that said patch works
(they've been wrong before).
All IMO.
And in terms of post-release errata, I suppose I have to swear by
everything I hold holy that it works and fixes the vulnerability. Or
maybe just swear on the grave of my AmigaOne. Well, I don't have the
right mindset to fully concoct an exploit, but in this case the patch
prevented a contrived filename from running 'exit' so I'm more or less
OK this time. But more generally, that is a very high standard.
Do people think the patches need to be reviewed for apparent
correctness, or is the opinion of one editor that a patch looks
reasonable sufficient ?
Well, we do have the opportunity to review the commit message. :)
If we're subscribed to -patches.
Anyway, thanks for the comments. I'll add it to the errata for stable
in the morning, then announce it on -security.
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Shared library permissions
On Mon, 22 Aug 2005, Matthew Burgess wrote:
Hi folks.
Does anyone know why shared libraries need the execute bit set on them? My
most recent build (gcc4-based) has most[1] *.so files installed with 755
permissions. As it's so consistent, I'm assuming there is a reason for them
to be executable. Thanks to Tarek Ghaleb and Andrew Benton for highlighting
the issue [2].
[1] Exceptions being: /lib/libproc-3.2.5.so (555), /usr/lib/libc.so (644),
/usr/lib/libpthread.so (644), /usr/lib/preloadable_libintl.so (644), and
Perl's modules (555)
/usr/lib/lib{c,pthread}.so aren't libraries, they are ld scripts.
Ken
--
das eine Mal als Trag?die, das andere Mal als Farce--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: 7.0-cross-lfs-20050818-x86_64 section 10.3 glibc installation
On Sat, 20 Aug 2005, Ken Moffat wrote: On Fri, 19 Aug 2005, Jim Gifford wrote: Ken, Ryan, Doug, and others Do we need to make a change here for the pure64 build, or is further testing needed? Well, I've got through this part now, using 20050821, building pure64 from my own pure64. The ldd problem that bit Doug didn't affect me (and my RTLDLIST has /lib/ld-linux.so.2 and /lib/ld-linux-x86-64.so.2). Unfortunately, it looks as if glibc decided not to respect --libdir=/lib for me - all the libraries went into /lib64 which caused binutils' configure-libiberty to fail with the misleading if you want to cross compile message. Actually, that's not true - /usr/lib has libc.a, the crt stuff, gconv/ plus a load of .so files which turn out to be symlinks to /lib64. But all of the shared objects are in /lib64 and /lib is empty. So --libdir seems to affect the libraries that would ordinarily go into /usr/lib* but not the libraries that go into lib*. I'm puzzled, Doug appeared to have got past this because he queried the gcc instructions. I think he said he'd be away this week, so I'm not waiting for an answer. I think that one of my patches used to hack this, but I'll take a more detailed look at glibc to see if it's amenable to other means of putting this stuff in /lib. That will be after I've started over (this time I'll take a backup before installing libc). Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 7.0-cross-lfs-20050818-x86_64 section 10.3 glibc installation
On Tue, 23 Aug 2005, Ken Moffat wrote: Sack-cloth and ashes time. I missed the slibdir=/lib part. Since LFS is all about learning, anybody like to point me to a HOWTO on learning to read what the book says, rather than what I think it says ? Thanks for the clue, Jim. So, now I'll confirm Doug's problem :-( CC=gcc /usr/bin/perl scripts/test-installation.pl /building/glibc-build/ /usr/bin/ldd: line 167: /lib/ld-linux.so.2: No such file or directory ldd: /lib/ld-linux.so.2 exited with unknown exit code (127) ldd execution failed at scripts/test-installation.pl line 182. make[1]: *** [install] Error 1 make[1]: Leaving directory `/building/glibc-2.3.5' make: *** [install] Error 2 Apparently, the script thinks this is a multilib build. Strange that without the slibdir=/lib it must have been happy not to test the 32-bit stuff. Ken -- das eine Mal als Trag?die, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 7.0-cross-lfs-20050818-x86_64 section 10.3 glibc installation
On Wed, 24 Aug 2005, Ken Moffat wrote:
On Tue, 23 Aug 2005, Jim Gifford wrote:
No problems Ken. But what do you think of my reasoning on the error about
the different symlink names for ld?
At the moment, that sounds plausible (I've just posted about the perl script
bailing out). I used to have a --disable-multilib in my scripts, I don't
know that it ever did any good, but I'll try that before trying to grok the
perl.
Ken
As I suspected, --disable-multilib is ignored. For the moment, I've
taken the easy way out and gone with the attached patch which I think
was originally from the debian amd64 list, via Tooley's site. Replaces
the slibdir= for x86_64-64 only.
What I don't understand is why this works - I imagine that the
nonexistent lib32/ld-linux.so.2 would be as equally problematic as the
non-existent lib/ld-linux.so.2 for test-installation.pl, but it seems to
cope (got through binutils this time, so I'll leave it overnight)
Comments on using this patch, anybody ?
Ken
--
das eine Mal als Trag?die, das andere Mal als Farce
diff -Naur -i glibc-2.3.4.orig/sysdeps/unix/sysv/linux/configure
glibc-2.3.4/sysdeps/unix/sysv/linux/configure
--- glibc-2.3.4.orig/sysdeps/unix/sysv/linux/configure 2004-07-06
06:13:42.0 +0200
+++ glibc-2.3.4/sysdeps/unix/sysv/linux/configure 2005-02-08
15:31:40.0 +0100
@@ -226,7 +226,7 @@
/usr | /usr/)
# 64-bit libraries on bi-arch platforms go in /lib64 instead of /lib
case $machine in
- sparc/sparc64 | x86_64 | powerpc/powerpc64 | s390/s390-64 | \
+ sparc/sparc64 | powerpc/powerpc64 | s390/s390-64 | \
mips/mips64/n64/* )
libc_cv_slibdir=/lib64
if test $libdir = '${exec_prefix}/lib'; then
diff -Naur -i glibc-2.3.4.orig/sysdeps/unix/sysv/linux/configure.in
glibc-2.3.4/sysdeps/unix/sysv/linux/configure.in
--- glibc-2.3.4.orig/sysdeps/unix/sysv/linux/configure.in 2004-07-06
06:11:40.0 +0200
+++ glibc-2.3.4/sysdeps/unix/sysv/linux/configure.in2005-02-08
15:31:40.0 +0100
@@ -161,7 +161,7 @@
/usr | /usr/)
# 64-bit libraries on bi-arch platforms go in /lib64 instead of /lib
case $machine in
- sparc/sparc64 | x86_64 | powerpc/powerpc64 | s390/s390-64 | \
+ sparc/sparc64 | powerpc/powerpc64 | s390/s390-64 | \
mips/mips64/n64/* )
libc_cv_slibdir=/lib64
if test $libdir = '${exec_prefix}/lib'; then
diff -Naur -i glibc-2.3.4.orig/sysdeps/unix/sysv/linux/i386/ldconfig.h
glibc-2.3.4/sysdeps/unix/sysv/linux/i386/ldconfig.h
--- glibc-2.3.4.orig/sysdeps/unix/sysv/linux/i386/ldconfig.h2001-07-06
06:56:16.0 +0200
+++ glibc-2.3.4/sysdeps/unix/sysv/linux/i386/ldconfig.h 2005-02-08
15:32:07.0 +0100
@@ -19,7 +19,7 @@
#include sysdeps/generic/ldconfig.h
#define SYSDEP_KNOWN_INTERPRETER_NAMES \
- { /lib/ld-linux.so.1, FLAG_ELF_LIBC5 },
+ { /lib32/ld-linux.so.1, FLAG_ELF_LIBC5 },
#define SYSDEP_KNOWN_LIBRARY_NAMES \
{ libc.so.5, FLAG_ELF_LIBC5 }, \
{ libm.so.5, FLAG_ELF_LIBC5 },
diff -Naur -i glibc-2.3.4.orig/sysdeps/unix/sysv/linux/x86_64/ldconfig.h
glibc-2.3.4/sysdeps/unix/sysv/linux/x86_64/ldconfig.h
--- glibc-2.3.4.orig/sysdeps/unix/sysv/linux/x86_64/ldconfig.h 2002-04-22
13:51:40.0 +0200
+++ glibc-2.3.4/sysdeps/unix/sysv/linux/x86_64/ldconfig.h 2005-02-08
15:31:40.0 +0100
@@ -19,8 +19,8 @@
#include sysdeps/generic/ldconfig.h
#define SYSDEP_KNOWN_INTERPRETER_NAMES \
- { /lib/ld-linux.so.2, FLAG_ELF_LIBC6 }, \
- { /lib64/ld-linux-x86-64.so.2, FLAG_ELF_LIBC6 },
+ { /lib32/ld-linux.so.2, FLAG_ELF_LIBC6 }, \
+ { /lib/ld-linux-x86-64.so.2, FLAG_ELF_LIBC6 },
#define SYSDEP_KNOWN_LIBRARY_NAMES \
{ libc.so.6, FLAG_ELF_LIBC6 }, \
{ libm.so.6, FLAG_ELF_LIBC6 },
diff -Naur -i glibc-2.3.4.orig/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
glibc-2.3.4/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
--- glibc-2.3.4.orig/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
2002-04-08 13:14:01.0 +0200
+++ glibc-2.3.4/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed 2005-02-08
15:31:40.0 +0100
@@ -1,3 +1,3 @@
/LD_TRACE_LOADED_OBJECTS=1/a\
add_env=$add_env LD_LIBRARY_VERSION=\\$verify_out
-s_^\(RTLDLIST=\)\(.*lib\)\(\|64\)\(/[^/]*\)\(-x86-64\)\(\.so\.[0-9.]*\)[
]*$_\1\2\4\6 \264\4\5\6_
+s_^\(RTLDLIST=\)\(.*lib\)\(\|64\)\(/[^/]*\)\(-x86-64\)\(\.so\.[0-9.]*\)[
]*$_\1\2\4\6 \2\4\5\6_
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Firefox and profile locking: Chapter 2
On Wed, 24 Aug 2005, Randy McMurchy wrote:
[cc'd to BLFS-Dev from BLFS-Support]
Archaic wrote these words on 06/25/05 12:01 CST:
[snip what is already instructions in the book]
make -C browser/installer
cd dist
mv firefox /opt/firefox-${version}
ln -sf /opt/firefox-${version} /opt/firefox
ln -sf /opt/firefox/firefox /usr/bin
Archaic, you are the man!
Please folks, comment on this as I would like to implement immediately.
We'd really need a compelling reason why we don't change the existing
instructions to use Archaic's method.
In general, I'm all in favour of a version of firefox that works
less-badly.
But, I like having multiple browsers so that I can look at different
things on different desktops. Epiphany works with the book's current
instructions, with a different set of instructions the .pc files didn't
get installed (and they pointed to /usr/local), nor did necessary
headers. Does this variation install headers, or will I also have to
build mozilla for the headers ?
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Datapoint, x86_64-64
Test results from a pure64 build (gawk was still 3.1.4, although I doubt that makes a difference here). This is just intended as an initial marker, for binutils the book expects no errors - maybe we'll change that if people confirm these results. This build was from an LFS-6.1 pure64 host. Most packages in the new system have no failures showing up in their testsuites. Gcc (3.4.4) had 13 unexpected errors (g++ and libstdc++ were ok), glibc was fine. binutils7 failures in the ld tests, 5 in bootstrap, 2 in cdtest (as before) findutils 54 unexpected failures, they all seem to be /bin/echo No such file or directory (but, /bin/echo works fine and is linked normally - I've not seen this before) gettext Continues to crap out in the rpath tests (6 of 46 fail) and doesn't go on to do the real part of the test suite. This has happened with every version of gettext after 0.14.1. Translations seem to work, e.g. setting LC_ALL to fr_FR or de_DE and running dumpe2fs on an extended fs. perl5 failures (new, LFS-6.1-with-errata from i686 was ok) Ken -- das eine Mal als Trag?die, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Pushing UTF-8 support into LFS
On Thu, 1 Sep 2005, Matthew Burgess wrote: Or, to address both of those points, make it LFS-patches policy to simply reject any patch that hasn't been submitted upstream! :) Matt. OK, so we can drop most of the lfs-specific patches for starters. And what happens when we do send something upstream and get no response, or it gets rejected ? Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Expected glibc test failures with gcc4 ?
A question for all of the people champing at the bit to get gcc4 into the mainline book - does *anybody* see glibc passing the maths tests (float, double, ifloat, idouble) in chapter 6 ? If they pass for you, what CPU ? I've got a reasonably new AMD processor (San Diego athlon64, slumming along as an i686) and no optimizations. Somebody referred in passing to these failures back in July, but otherwise the archives seem silent. Now, I'm not going to get too worked up about failures in glibc math tests (unless it's accompanied by weirdnesses when I run applications), but if this failure is common then I think we should indicate that we expect tests to fail. Alternatively, maybe the tests fail on certain recent processors, or maybe my scripts are broken ? Ken -- das eine Mal als Trag?die, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: cannot boot
On Sat, 3 Sep 2005, David Ciecierski wrote:
It most certainly does have to be selected.
Yeah, my sys runs like a charm with it :-) Just a small question: with grsec
every mount and unmount produces a few lines of text saying who is
{,u}mounting something. Can that be turned off? I mean, it's not much use cos
mount is not suid root on my box and as it's a server noone is expected to
mount anything really... So it just clutters the display when booting ;-)
I assume you still want this logged in syslog, which reduces the
problem to just another example of syslog writes all over my console
(common in LFS, but only with certain kernels and certain hardware).
On my boxes I limit the console to only logging warnings or worse (if
my documentation is correct ;) with
sed -i 's/\(loadproc klogd\)/\1 -c 4/' /etc/rc.d/init.d/sysklogd
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Expected glibc test failures with gcc4 ?
On Sun, 4 Sep 2005, Greg Schafer wrote: There is a patch available to fix most of the failures, but not all: http://sources.redhat.com/ml/libc-hacker/2005-03/msg00067.html http://sources.redhat.com/ml/glibc-cvs/2005-q2/msg00239.html There is also available a dubious workaround: http://www.diy-linux.org/pipermail/diy-linux-dev/2005-June/000550.html Regards Greg Thanks, Greg. I'll try to take a look at these tomorrow. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
gcc4 - proposed changes to glibc check
So everybody on i686 can expect *some* failures in the glibc math tests with gcc-4. I've got the patch from Drepper's (whoops, from _Mr_ Drepper's) commit (thanks, Greg) which solves half of the failures. Looking at fedora4, even with their ability to selectively pick fixes from CVS they use 'make -k check'. I don't have a problem with that, (gcc has failures, so do some versions of binutils on some platforms), but the book's current wording expects no failures in the normal case: |Important | |In this section, the test suite for Glibc is considered critical. Do |not skip it under any circumstance. | |Test the results: | |make check - we then go on to talk about the reasons why some people will see failures and say |In general, the Glibc test suite is always expected to pass. I propose to change this to something like (i) add the patch - 2 failures in the math tests are better than 4 failures. (ii) change the command to make -k check glibc-check-log 21 ; grep Error glibc-check-log (iii) add an explanation: On i686 you can expect to see failures in the test-double and test-idouble math tests with gcc4, as well as an expected (ignored) failure in posix/annexc. These failures in the math tests appear to be harmless. (iv) reword the text after this. The Glibc test suite is highly dependent on certain functions of the host system, in particular the kernel. In certain circumstances, some failures are unavoidable. This is a list of the most common issues: (remove In general, the Glibc test suite is always expected to pass. However,) * The math tests sometimes fail in other tests when running on systems where the CPU is not a relatively new genuine Intel or authentic AMD. Certain optimization settings are also known to be a factor here. ( add in other tests) ( continue as now with reference to gettext) The drawback to telling our users to log this is that the log takes 2.2MB. In context, I don't think that is significant (although I would appreciate a reminder of _which_ version of the locales we should be measuring : full or minimal ?). Dislikes ? Objections ? Responses of but it all passes on my pentium-plus ? Better wording ? Ken -- das eine Mal als Trag?die, das andere Mal als Farce-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gcc4 - proposed changes to glibc check
On Mon, 5 Sep 2005, Randy McMurchy wrote: Randy McMurchy wrote these words on 09/05/05 11:10 CST: Good work, Ken. FWIW, I think that the SBU and disk space should include building all locales. Here are my figures. [EMAIL PROTECTED]: ~/build/Build-System/Installed-System/glibc-2.3.5 cat sbu.time 15.31 SBU [EMAIL PROTECTED]: ~/build/Build-System/Installed-System/glibc-2.3.5 cat diskspace.used 517484 KB Above is Chapter 6 build. All locales built. In chapter 5, I don't build the locales or run the tests. Here are the numbers I get: Thanks, I'm only really concerned about chapter 6 at the moment. I seem to remember somebody (Alexander, perhaps) suggesting that the correct method is to install the required locales, which for me equates to the minimal locales. I'll go with all locales if that turns out to be the official recommendation. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gcc4 - proposed changes to glibc check
On Tue, 6 Sep 2005, Alexander E. Patrakov wrote: Ken Moffat wrote: Thanks, I'm only really concerned about chapter 6 at the moment. I seem to remember somebody (Alexander, perhaps) suggesting that the correct method is to install the required locales, which for me equates to the minimal locales. I'll go with all locales if that turns out to be the official recommendation. I did recommend installing only wanted locales, but that's a workaround for BLFS bug. The bug is that GDM chooses (not well supported) UTF-8 locales in preference to non-UTF-8 ones if one selects a non-default language on the login screen. Since there will be a branch that adds some patches to address UTF-8 problems, this will become a non-issue for that branch. Thanks for the clarification. I'll build with all locales. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Error in chapter 6.14
On Thu, 8 Sep 2005, Olivier Seubert wrote: Yeah, you asked this on -support yesterday, and I replied that the config.log you need to look at is in the libstdc++-v3 directory. If you didn't seem my response, it should be in the archives. Please take this back to lfs-support. Ken -- das eine Mal als Trag?die, das andere Mal als Farce-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: X86_64 Multi-lib cross-build glibc32/64 gcc4 __thread failure
On Thu, 8 Sep 2005, Jeremy Huntwork wrote: Jim Gifford wrote: Interesting!! So either GCC is not compiling Glibc with NPTL correctly, or we have a GCC 4.0.1 issue. Matt Darcy is trying the Currently GLIBC snapshot. If the snapshot works well, we should seriously consider using that in the current gcc4 branch instead of the patches in place now. That's heading back to pick a /random/ snapshot every few weeks and test it. The snapshots are provided as an easy way for people to sync up to glibc CVS head (see the README in the directory). I'm not objecting to patches from glibc CVS to fix specific problems, just against trying to use the whole bleeding edge. I remember the testing for the glibc snapshots in 5.1. x86 native builds were stable for months, other architectures took a lot longer. These binutils and glibc problems seem to be gcc4, or gcc4 plus cross-compiling, issues. I don't know about binutils, but for glibc I'm guessing that another manipulation of configparms or whatever it's called might be the fix (libc_cv_gcc___thread=yes). But that's just my initial guess, I haven't been saving config.log so I don't know if this is on the right lines. Ken -- das eine Mal als Trag?die, das andere Mal als Farce-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GCC-4 Update(2)
On Wed, 7 Sep 2005, Randy McMurchy wrote: Here's a current list of packages known to compile using GCC-4. The list is updated as I go (automated). Build scripts for any of the packages you see on this list are available upon request. http://www.linuxfromscratch.org/~randy/installed_packages.txt A few additions: general BLFS gnet-2.0.7 gtkspell-2.0.10 pan-0.14.2 psutils-p17 (untested) scrollkeeper-0.3.14 taglib-1.3.1 transcode [1.0.0] - needs libmpeg2 aka mpeg2dec-0.4.0b vorbis-tools-1.0.1 xine-lib-1.1.0 xine-ui-0.99.4 xscreensaver-4.21 gnome epiphany-1.6.2 gdm-2.8.0.1 ggv-2.8.4 gnome-doc-utils-0.2.0 gnome-keyring-0.4.2 gnome-vfs-2.10.1 gnumeric-1.4.3 gpdf-2.10.0 gucharmap-1.4.3 libbonoboui-2.8.1 libcroco-0.6.0 libglade-2.5.1 libgnome-2.10.0 libgnomecanvas-2.10.0 libgnomeui-2.10.0 libgnomeprint-2.10.3 libgnomeprintui-2.10.2 libgsf-1.12.0 libgtkhtml-2.6.3 librsvg-2.9.5 yelp-2.6.5 kde kdegraphics-3.4.2 kdemultimedia-3.4.2 kdepim-3.4.2 kdeutils-3.4.2 non-blfs dcraw (20050707) gutenprint-5.0.0-rc1 (compiles fine, but escputil doesn't recognise my printer, same with -beta4, looks like this might be a gcc4 problem) mpg123-pre0.59s + gentoo patches ufraw-0.4 EOE excepted. Ken -- das eine Mal als Trag?die, das andere Mal als Farce-- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [RFC] Udev configuration changes
On Tue, 13 Sep 2005, Matthew Burgess wrote: Like I said in the original RFC, udev *will* still create nodes for *all* device it finds, regardless of the existence or otherwise of a rule in its configuration files. It just means that where a rule doesn't exist for the device, it will be given the following ownership/permissions: root:root 0660. And the benefit of this part of the proposal is ? Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
On Thu, 15 Sep 2005, Jim Gifford wrote: Jeremy Huntwork wrote: That seems to be the natural course to follow. I would like to see some of the goals/guiding principles of Cross-LFS layed out, too though. For example, how closely does it follow LFS and decisions made there, like package versions, etc? Depending on the outcome of this topic, I was going to design decision chart of how cross-lfs will base it's decisions. Which will have all the criteria of how we will do things. Heh, I've long wanted LFS to deal with more platforms, so although I dislike cross-building when it isn't strictly necessary, and living on the bleeding edge, I've got to go with this. Looking forward to the decision chart. Ken -- das eine Mal als Trag?die, das andere Mal als Farce-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
On Thu, 15 Sep 2005, M.Canales.es wrote: If that will meant that Cross-LFS will be focused on pure cross-build techniques and scenarios, i.e. it assumes that host-triplet != target-triplet, thus no chroot way to build the final system, focusing the normal LFS book on host-triplet = target-triplet builds (not only for x86, but also for other archs, primarily x86_64) using the chroot way, then I support the proposal. Hmm, I didn't see that in the proposal. From my POV, if Cross-LFS is restricted to host != target the number of likely users will be cut dramatically. More to the point, I've seen no sign of willingness to (re-)admit other architectures to the normal LFS book (it used to have a ppc version, but that was before my time). I'll clarify my earlier posting - I want to run on x86_64 (ideally with lib and lib32, but I haven't started looking at that yet) and ppc at the moment, my interest in i686 is not great (it builds, it runs, it's a boring architecture). Until Jim posted, the only game in town offering that was Cross-LFS. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: This is the end
On Tue, 20 Sep 2005, Jeremy Huntwork wrote: Thanks again - I've enjoyed it immensely. Thanks for all you've done, maybe we'll see you back one day. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Cross-LFS questions
Two questions: (i) Is there still a public rendering of this book ? I went to the website to check if I'd borked something in my editing but couldn't find any mention of Cross-LFS. Perhaps it's part of the restructuring. (/me suppresses a thought that editors on non-projects have a tendency to become non-persons :) (ii) For anybody who has built a pure64 system without chrooting using the if you are going to boot route, should we _really_ be installing e2fsprogs into /tools/lib64 ? This sounds broken, but maybe I'm overlooking something. Ken -- das eine Mal als Trag?die, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross LFS Status
On Fri, 30 Sep 2005, Jim Gifford wrote: We are currently trying to stablize the Cross-LFS book. Any thoughts on a package freeze for existing packages, particularly glibc ? (That is, freeze versions unless it becomes clear that a different version will solve problems). I'm preparing to start some fresh builds (x86, x86_64-64, x86_64 on the same machine), hopefully tomorrow, but if we upgrade glibc each week my test results will be worthless by the time I have them ;) Outstanding Issues PPC Yaboot The only issue I've noticed is the errors in the list of files to install into /boot (/me admits to still not getting around to correcting this). Anything else ? Pure64 Builds Bootloaders, what to do, suggestions welcomed, Biggest concerns Silo and Grub lack of ability to be compiled as 64 Bit. -- Programmers welcome!! For x86_64-64 lilo compiles and works now, or at least it did last time I checked. Book Update the earilier chapters of the book to reflect cross-compiling Add all missing configuration lines Any thoughts on what to do about space/time measurements ? I'm not a big fan of SBUs, but (at least on non-cross) they have some element of repeatability if people don't get too finicky with how precisely they measure them. I think Manuel had a suggestion about what to use as an approximate SBU when building the final system if this was a true cross-build. Maybe we could have SBUs for the first part, and NBUs (native build units) for the temp tools and final system. I'm fairly sure that the space used in the first part of the build will depend on both the host and the target (e.g. ppc32 instructions are all 32 bits, and building glibc back in the days of LFS-5.0 took a lot more space on ppc than on x86). Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross LFS
On Sat, 1 Oct 2005, Jim Gifford wrote:
Manuel and LFS-dev,
I have been thinking about this for a few days. Cross-LFS has two
different options in it, boot and chroot. Boot is a complete reboot and
chroot is like the standard LFS book. Talking with various people, an idea
popped into my mind. Having two separate books, Cross-LFS with the
cross-tools and boot section and a version of the old Multi-Arch LFS book
which would have the cross-tools section remove and utilizing the chroot
section.
Actually, to get to x86_64 from x86 I take a slightly different path -
cross-compile from x86, cross-compile a non-modular kernel [ because the
x86 modutils are going to be used ], reboot to the new kernel (64-bit
kernel, i686 userspace) and then chroot.
The only downfall I see of this idea, is the book rendering issues. Is it
possible just to render the complete book as it is now, and then make new
index pages with the sections listed as above?
There is a slight difficulty with starting at binutils in Contructing a
Temporary System - we only build binutils and gcc once and we don't
build glibc at all ;) Realistically, the multi-arch book would need
sections added. Also, we're using ${LFS_TARGET}-gcc and friends - it
doesn't feel right to specify LFS_TARGET in a native build, and there
are config.cache things that are only needed in a cross-compile.
What type of modifications would we need to do accomplish this?
Would LFS benefit from this? (I say yes)
Please express your thoughts and even pose questions.
I'm all in favour of extending the platforms that people can reliably
use for LFS, but I don't see tangible gains - as I read your proposal,
there would be two books with a common source. Users might be attracted
by not having to cross-compile, but equally they might think that issues
in cross-lfs were unrelated to their multi-arch lfs.
I'm also a little worried that rendering the book will become unwieldy.
It already strains my patience ;)
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Cross LFS
On Sun, 2 Oct 2005, M.Canales.es wrote: If you are rendering/validating all book each time that you made a little change in the sources, yes, the process is very long. But if the change you made only affect some archs, you can validate/render only that books (for example, mips ands mips64) adding ARCH=mips mips64 to the make command. OK, thanks for that tip. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gcc4 and glibc-2.3.x
On Sun, 2 Oct 2005, Andrew Benton wrote: Ken Moffat wrote: Well, the snapshot in cross-lfs is surprisingly good, but in general trying to follow glibc CVS is a full-time job for anybody who cares about more than just x86. I haven't built x86 on cross-lfs yet, but if the c++-types-check is a new failure, that would be another reason why trying to follow glibc cvs is often a bad idea (irrespective of whether it's the code or the test program that now fails). Well I was going to write back and disagree. That test failure was fixed and last weekend after updating glibc it was back to just the usual maths test-double and test-idouble failures. But then with this week's glibc, I didn't get as far as the tests in chapter 6. At the end of chapter 5, configuring perl hangs like so patching file hints/linux.sh Hunk #1 succeeded at 52 with fuzz 1 (offset 1 line). Hunk #2 succeeded at 314 (offset 32 lines). sh Configure -ds -e -Dprefix=/tools -Dstatic_ext=IO Fcntl POSIX And there it hangs...ctrl-c won't bring the prompt back. It's not using the cpu. Normally the next line is `First let's make sure your kit is complete. Checking...' so presumably it's getting stuck doing that Weird. I've now successfully built cross-lfs for x86 twice using glibc-20050926 (first time from x86_64-64, second from itself) and looked in detail at the results. I've got to rebuild at least once more to try to understand test failures in autofoo (possibly, the coreutils patch for udev fixed these), but that version of gcc works for me. The only new error was a glibc test failure in wcsmbs/mbrtowc2. The times to build some of the packages varied greatly on the two runs - perhaps related to how long the testsuites take to run, e.g. when waiting for things. I don't have any audio, or indeed a full desktop, on that box, but it certainly looks promising. Were you using glibc-20050926, or glibc-2.3-20050926 ? Oh, and did you definitely include the bash avoid_WCONTINUED patch ? Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: My status
On Mon, 3 Oct 2005, Jeremy Huntwork wrote: Hello All, Hi Jeremy, I was pleased to see you back. I'm disappointed that not everyone viewed your useful contributions in the same way. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gcc4 and glibc-2.3.x
On Mon, 3 Oct 2005, Andrew Benton wrote: Ken Moffat wrote: Were you using glibc-20050926, or glibc-2.3-20050926 ? Oh, and did you definitely include the bash avoid_WCONTINUED patch ? I started with glibc-20050912 and I've been updating it with cvs every Sunday (I know how to have fun on my day off..). Yes, I definitely used the bash avoid_WCONTINUED patch. I was really just posting all that to reinforce what you were saying about how we should be careful picking which glibc tarball we build from. Ah, my mistake. FWIW, I'm starting to believe that the elapsed-time variations in my tests were caused by allowing xscreensaver to run. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Cross-LFS findutils problem.
I've been trying to understand why the findutils testsuites were failing in Cross-LFS. The first problem (the xargs suite) could be fixed by adding a /bin/echo symlink (we were using /tools/bin/echo when the test ran, and the xargs tests were rewritten for 4.2.25 - if no action is specified for xargs, /bin/echo is the default). However, completing the xargs tests without failure meant the locate tests then tried to run - to cut a long story short, these tests all work if coreutils has been installed in the final system. I ran builds with our then current order, and with coreutils moved (to where it is in LFS) and compared the results, expecting to find a binary was different. In fact, the binaries were all identical (except for the normal variation in a little of the libc++ stuff), but I discovered that the installed updatedb differed. Updatedb is a script. With the build order rearranged, it references /usr/bin/sort. With the old build order, it references /tools/bin/sort which obviously only works when /tools is available. Fixed in r6968, users of previous builds should edit /usr/bin/updatedb and edit the several sort=/tools/bin/sort lines. Ken -- das eine Mal als Trag?die, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] LFS-6.1.1
On Sat, 8 Oct 2005, Jeremy Huntwork wrote: I hadn't meant cut a branch from trunk and call it 'stable' - that would require a lot more testing. I meant take the current 'stable' book and do whatever minimally needs to be done to fix each bug and re-release. It really would be a 6.1.1 in that way. I haven't been paying a lot of attention to this thread, but I thought somebody mentioned a glibc upgrade to 2.3.5 ? Now, that version worked fine for me (but then, so did 2.3.4, and even openssh on x86), but I don't think it's been tested in the context of BLFS-stable ? Sure, we all used it with gcc-3.4.4, but BLFS-dev has moved on to gcc-4. If somebody cuts a 6.1.1 branch with glibc-2.3.5 and gcc-3.4.4, that all needs to be tested. If we're only talking about is incorporating the stuff in the errata, that's a different matter. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] LFS-6.1.1
On Tue, 11 Oct 2005, Alexander E. Patrakov wrote: It is not an issue in the ssh itself. Testcase: gcc -o test -ldl test.c rm -rf /tmp/foobar; mkdir /tmp/foobar ./test Dug out the patch from the libc-hacker archives, but I had to apply it by hand, I think the line numbers changed a bit too much for patch to figure it out. Can you confirm this is what you want put in, and can I stick your name in the 'submitted by' ? I was thinking of calling it glibc-2.3.4-open_path_segfault-1.patch. My understanding from what Jakub put in the posting is that this only applies if the standard directories are empty, e.g. in a chroot. Ken Submitted By: Date: 2005-10-14 Initial Package Version: 3.3.4 Upstream Status: From glibc-cvs Origin: http://sources.redhat.com/ml/libc-hacker/2005-02/msg5.html Applied by hand and rediffed by Ken Moffat. Description: Avoid segfault if open_path doesn't find any of the standard search directories. 2005-01-07 Jakub Jelinek [EMAIL PROTECTED] * elf/dl-load.c (open_path): If rtld_search_dirs is in RELRO segment, avoid writing to it if none of the standard search directories exist. diff -Naurp glibc-2.3.4.orig/elf/dl-load.c glibc-2.3.4/elf/dl-load.c --- glibc-2.3.4.orig/elf/dl-load.c 2004-12-12 20:49:28.0 + +++ glibc-2.3.4/elf/dl-load.c 2005-10-14 00:03:55.0 +0100 @@ -1788,6 +1788,11 @@ open_path (const char *name, size_t name must not be freed using the general free() in libc. */ if (sps-malloced) free (sps-dirs); +#ifdef HAVE_Z_RELRO + /* rtld_search_dirs is attribute_relro, therefore avoid writing +into it. */ + if (sps != rtld_search_dirs) +#endif sps-dirs = (void *) -1; } -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] LFS-6.1.1
On Fri, 14 Oct 2005, Jeremy Huntwork wrote: This one applied fine with an offset, built correctly and is running smoothly. Openssh-4.2p1 also built on the same system and running well. In that case, I'd rather go with yours (I think there is a possibility that my rejection was caused by an error in my attempt to strip out the htmlisation of what I saved from firefox, but anyway yours has been tested). Do you want to add a heading and commit it ? Ken -- das eine Mal als Trag?die, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: kbd - sparc
On Mon, 17 Oct 2005, jaca wrote: Hello I've obtained the following errorc while compiling Kbd-1.12 gcc -c -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -DDATADIR=\/usr/share /kbd\ kbdrate.c kbdrate.c: In function 'KIOCSRATE_ioctl_ok': kbdrate.c:167: error: 'struct kbd_rate' has no member named 'period' also the patch: patch -Np1 -i ../kbd-1.12-sparc_kbdrate-1.patch has been rejected: root:/sources/kbd-1.12$ patch -Np1 -i ../kbd-1.12-sparc_kbdrate-1.patch patching file src/psffontop.c Reversed (or previously applied) patch detected! Skipping patch. You've got the wrong patch! src/psffontop.c is in the gcc4_fixes patch, the sparc_kbdrate patch alters src/kbdrate.c to use kbdrate_s.rate. Ken -- das eine Mal als Trag?die, das andere Mal als Farce-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross-LFS multilib - perl, glibc tests
On Wed, 19 Oct 2005, Ken Moffat wrote: For the temporary tools, I'm guessing we could just build a 32-bit perl (assuming any 64-bit testsuites will NOT produce perl modules). Progress update: Using the 20051017 glibc snapshot and ONLY a 32-bit perl in test-tools, the 64-bit glibc testsuite ALL passes on x86_64 (so, somebody has at last fixed something in wcsmbs), gcc-4.0.2 has one g++ failure, binutils all passes. Everything else passed except for lang-gawk in 64-bit gettext (test skipped in 32-bit!) and the 32-bit glibc tests which still fail all over the place for me. I'm totally baffled by the glibc-32 test failures, but so far I haven't worked out how to see any error messages other than the 'invalid character' messages for catgets/de and the 'cannot run on the de_DE.UTF-8' localemake messages. Not quite there in the final-system - discarded fedora's defines for /usr/lib/perl5 (vendor, etc), they seem to force it ALL to go into /usr/lib. With just the fedora patch and a define for -Dlibpth, I've got everything installed in /usr/lib64 and the output of perl -V is almost correct (it shows libc as /lib/libc-2.3.90.so which is decidedly 32-bit). Ken -- das eine Mal als Trag?die, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross-LFS multilib - perl
On Thu, 20 Oct 2005, Ryan Oliver wrote: example patch for x86_64 lib64 attached (rename it to something appropriate) Thanks, I'll play with one of those later. Just thought I'd pipe up here... what use is there having both 32 and 64bit modules created if you are only going to be able to use either a 32 or 64bit perl? That was going to be later question, after I got my lib64 install to do the right thing. Indeed, if you attempt to build 32bit modules down the track with a 64bit perl they wont get used (if the above fix is implemented) or will not work (if they are installed to the same location as the 64bit ones). Also you will pickup the wrong install locations from the 64bit perl, pick up wrong library paths to use etc, run perl Makefile.PL on any additional module and you'll see what I mean... You need to keep both perl binaries. I have been using a binary wrapper to be able to host two versions of perl/python/whatever you want, by renaming the perl binary to perl-32 or perl-64 and creating a perl - wrapper_binary symlink. The wrapper checks an environment variable then runs the appropriate perl binary. (NOTE: wrapper has to be a binary, not a shell wrapper, or else perl scripts break when invoked). OK, thanks. I saw your wrapper script before, but didn't understand it. I've got wrapper.c now, will have to take a look at this. Ken -- das eine Mal als Trag?die, das andere Mal als Farce-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: curious almost circular install
pOn Thu, 20 Oct 2005, Doug Ronne wrote: But now the cvs emacs requires texinfo, which I had been leaving off my temporary tools. So I guess I have to install texinfo to install emacs to install gettext but texinfo requires gettext! wee!!! Don't you lose the info pages from gcc if you don't have a working texinfo when you build gcc for the final system ? Ken -- das eine Mal als Trag?die, das andere Mal als Farce-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Version 7.0-cross-lfs-20051023-x86_64
On Mon, 24 Oct 2005, Duncan Webb wrote:
Hi all,
Just build the boot stages of Version 7.0-cross-lfs-20051023-x86_64 from a
LFS 6.1 (32-bit) system. I've noticed a few small errors that I would like to
report.
5.4. Build Variables
Following the commands will set LFS_TARGET to i686-pc-linux-gnu, which works
until building glibc. Changing LFS_TARGET to x86_64-pc-linux-gnu allowed me
to complete the build.
The book (5.3) says:
| Now you will need to set the target triplet for the target
| architecure. You can do this by running the same command as above,
| just running it on the target machine. If you can't run the command on
| the target machine, you can use the table at the bottom of this page.
What's the problem ?
7.10. Creating the passwd, group, and log Files
The cat commands are missing ${LFS} so it tries to write to the root.
7.16. LFS-Bootscripts-3.2.2
Should include a block to set-up ${LFS}/etc/sysconfig/clock because the boot
reports an error when running the clock script.
Thanks, I've addressed these in r7078 although no doubt my wording
about the clock script can be improved.
One minor points
A few of the instructions in chapter 6 say something like:
echo am_cv_func_working_getline=yes config.cache
CC=${CC} ${BUILD64} ./configure ...
wouldn't it be better to say:
echo am_cv_func_working_getline=yes config.cache
because if the configure has already been run then the cache file should be
truncated.
I've assumed that _some_ architectures already write to config.cache in
these cases, but I haven't looked too deeply (the aim is to keep the
text common between the different architectures, so e.g. the
multilib/foo-64.xml will include chunks from common/foo.xml). Maybe
there is a better way to set it out ? - obviously just 'config.cache'
would do it in all cases where it is needed, but it would look clunky.
Ken
--
das eine Mal als Trag?die, das andere Mal als Farce--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Version 7.0-cross-lfs-20051023-x86_64
On Mon, 24 Oct 2005, Duncan Webb wrote:
wouldn't it be better to say:
echo am_cv_func_working_getline=yes config.cache
because if the configure has already been run then the cache file should
be truncated.
I've assumed that _some_ architectures already write to config.cache in
these cases, but I haven't looked too deeply (the aim is to keep the text
common between the different architectures, so e.g. the multilib/foo-64.xml
will include chunks from common/foo.xml). Maybe there is a better way to
set it out ? - obviously just 'config.cache' would do it in all cases
where it is needed, but it would look clunky.
Wouldn't think that it would make any difference which architecture you use
there shouldn't be a config.cache until either one in initialised as
described or configure has been run once.
I'll rephrase - I think that an arch I don't have (probably sparc, or
mips, or just one of their variants) has *already* echoed something into
config.cache before adding the am_cv_func_working_getline. Therefore,
for that arch the is necessary. This only causes you a problem if
you rebuild, or retry after an error, without deleting the source/build
directories.
9.4. Expect-5.43.0
I think the configure line should be:
CC=gcc ${BUILD64} ./configure --prefix=/tools --with-tcl=/tools/lib \
--with-tclinclude=$TCLPATH --with-x=no
because the tools have not yet been built to default to 64bit.
No, in the previous section where you build tcl you should have used a
sed on Makefile.in to force lib64, and also passed --libdir=/tools/lib64.
But please read the rest of my reply!
10.3. Glibc-20050926
Got an error during make check, did make install and then make check again,
the check had no error after the install, odd behaviour.
Your *next* point, and the absence of 32-bit in this package name,
make me think you've switched to pure64 (x86_64-64) AFTER following the
multilib book in the initial chapters. Perhaps, you came back to it and
mixed the different architectures ?
FWIW, in 20050926 64-bit I see *an* error (in wcsmbs, from memory - my
logs are on another box). Haven't tried running check after installing
the 64-bit libc, but the error seems to have gone in last week's
snapshot. For 32-bit libc I'm getting a mass of errors in make check,
but nobody else has commented on them, so it could be an error in my
buildscripts.
Hope this helps
10.5. Binutils-2.16.1
I'm getting there errors which running check, any idea what I should do?
Running /sources/binutils-2.16.1/ld/testsuite/ld-bootstrap/bootstrap.exp ...
FAIL: bootstrap
FAIL: bootstrap with strip
FAIL: bootstrap with --traditional-format
FAIL: bootstrap with --no-keep-memory
FAIL: bootstrap with --relax
Running /sources/binutils-2.16.1/ld/testsuite/ld-cdtest/cdtest.exp ...
FAIL: cdtest
FAIL: cdtest with -Ur
In pure64 (at least for x86_64-64) this seems normal. I spent an
hour or two looking at the ld test suites last week after confirming
that multilib passes all of the binutils tests, but so far I haven't
even identified what is failing, or why.
Hopefully, I won't offend you when I say that you need to follow ONE
architecture (multilib, or pure64) at a time, and when I point out that
pure64 on amd64 works reasonably well _except_ for grub, and that
multilib x86_64 has some issues with perl (see Ryan's reply to me last
week on this list).
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Version 7.0-cross-lfs-20051023-x86_64
On Tue, 25 Oct 2005, Duncan Webb wrote:
Ken Moffat wrote:
On Mon, 24 Oct 2005, Duncan Webb wrote:
9.4. Expect-5.43.0
I think the configure line should be:
CC=gcc ${BUILD64} ./configure --prefix=/tools --with-tcl=/tools/lib \
--with-tclinclude=$TCLPATH --with-x=no
because the tools have not yet been built to default to 64bit.
No, in the previous section where you build tcl you should have used a sed
on Makefile.in to force lib64, and also passed --libdir=/tools/lib64.
But please read the rest of my reply!
There is no sed nor --libdir=/tools/lib64 in the pure64 book in chapter 9.
Constructing a Temporary Tools in the pure book.
OK, in that case, I was misled by the x86_64 subject. Apologies. Ah,
I see, you are objecting to the missing ${BUILD64}. My take on this is
that we've built a 64-bit-only compiler in pure64 (/tools/bin/gcc).
Ken
--
das eine Mal als Trag?die, das andere Mal als Farce--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [OT] Strace
On Tue, 25 Oct 2005, Duncan Webb wrote: I know this is off topic, so don't shout at me... I was trying to build strace-4.5.12 under x86_64 but it has compilation problems. Attached is a patch, taken from gentoo that fixes there. Regards, Duncan Blimey, it's a bit big, isn't it ;) I've got a somewhat shorter patch http://www.kenmoffat.uklinux.net/patches/strace-4.5.12-quota_fixes-1.patch - can't remember if I've tested it on x86_64-64 (thought I had, but maybe not), it's to address the problem caused by using a glibc snapshot which knows about the second version of LINUX_QUOTA_VERSION. I haven't submitted mine to patches@ because strace was tagged for 4.5.13, so I'm expecting it to be released soon. Does x86_64 have other problems with strace ? My rule of thumb for Beyond-Cross-LFS, at the moment, is to mention issues on blfs-support. Ken -- das eine Mal als Trag?die, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [OT] Strace
On Wed, 26 Oct 2005, Duncan Webb wrote: Ken Moffat wrote: My rule of thumb for Beyond-Cross-LFS, at the moment, is to mention issues on blfs-support. Are you thinking of a dedicated Cross-LFS mailing list? Not my call. But we are talking about strace which is a BLFS package (in the sense of normally built after LFS is completed) - indeed, it's even referenced in the 'Other Programming Tools' page. Realistically, the problems specific to different architectures for BLFS packages are a tiny part of the overall story. I think moving non-x86-BLFS to a separate list would not help anyone. Ken -- das eine Mal als Trag?die, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Perl - Cross-LFS Multilib
On Thu, 27 Oct 2005, Alexander E. Patrakov wrote: Jim Gifford wrote: Translated for Cross-LFS would be. -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 \ -Dprivlib=/usr/lib/perl5/5.8.7 \ -Dsitelib=/usr/lib/perl5/site_perl/5.8.7 \ -Dvendorlib=/usr/lib/perl5/vendor_perl/5.8.7 \ -Darchlib=/usr/lib/perl5/5.8.7/x86_64-linux What bothers me is that there's no vendor_perl directory in the stock LFS installation. I agree with the rest for multilib. Apart from that, this has two deficiencies in my view: (i) our 64-bit perl installs in /usr/lib instead of /usr/lib64, as do all subsequent modules (tested with XML-Parser, which finds libexpat from /usr/lib64, but installs its own (64-bit) Expat.so under /usr/lib/perl5. (ii) the defines for privlib, sitelib, vendorlib, archlib do not affect what, or where, perl itself installs and therefore I regard them as unnecessary additions. I agree that a 64-bit perl seems to be adequate on multilib (I'm sure somebody will find an exotic 32-bit chroot example that needs a 32-bit perl, but for normal use I'm happy unless anybody responds to my earlier post on -chat). Will reply, hopefully in a couple of hours, with a comparison of what gets installed using Ryan's Configure patch with a 64-bit-only perl. Note that perl -V continues to show libc as /lib/libc-2.3.90.so in all of these variations, which looks messy but perhaps won't cause too many problems down the line [ I'd still prefer to fix that, but my current spells are too weak ]. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Perl - Cross-LFS Multilib
(Adding Jim back to the CC) On Thu, 27 Oct 2005, Ken Moffat wrote: Apart from that, this has two deficiencies in my view: (i) our 64-bit perl installs in /usr/lib instead of /usr/lib64, as do all subsequent modules (tested with XML-Parser, which finds libexpat from /usr/lib64, but installs its own (64-bit) Expat.so under /usr/lib/perl5. (ii) the defines for privlib, sitelib, vendorlib, archlib do not affect what, or where, perl itself installs and therefore I regard them as unnecessary additions. I agree that a 64-bit perl seems to be adequate on multilib (I'm sure somebody will find an exotic 32-bit chroot example that needs a 32-bit perl, but for normal use I'm happy unless anybody responds to my earlier post on -chat). OK, using Ryan's patch from last week plus the installstyle echo, with only a 64-bit perl, everything is in /usr/lib64/perl5 and XML-Parser installs into /usr/lib64/perl5/site_perl. Looks good, apart from the libc=/lib/ issue in 'perl -V'. In all cases, the perl and XML-Parser testsuites completed ok. Ken -- das eine Mal als Trag?die, das andere Mal als Farce-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Perl - Cross-LFS Multilib
On Thu, 27 Oct 2005, Thomas Pegg wrote: On Thu, 2005-10-27 at 21:35 +0100, Ken Moffat wrote: OK, using Ryan's patch from last week plus the installstyle echo, with only a 64-bit perl, everything is in /usr/lib64/perl5 and XML-Parser installs into /usr/lib64/perl5/site_perl. Looks good, apart from the libc=/lib/ issue in 'perl -V'. I think I may have a found a solution for that, I used a patch (attached below) that's a variation on the current libc patch, the main differences being that I dropped the last hunk of the patch it's only needed for the tools version of perl. It does set libc properly (partial output of perl -V below. I also used the -Dlibpth Jim posted earlier so perl doesn't set it to just /usr/local/lib. Thanks. I was going to say it didn't work for me (tried something similar last night, but ./perl -V still showed /lib), but your output persuaded me to retry : 'make install' does something to perl - before make install, ./perl -V shows libc=/lib, after make install both ./perl -V and perl -V now show libc=/lib64. Finding that out is less painful than trying to work out what libpth is used for in Configure, so I'm very grateful. A little more testing to do (rewind to before perl, make a clean install, test a little), then I'll put my editing hat on. Ken -- das eine Mal als Trag?die, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross X86_64 Question /usr/lib64
On Fri, 28 Oct 2005, Duncan Webb wrote: Question is: 1) should a symlink from /usr/lib to /usr/lib64 be created in the section Creating Directories in chapters 7 8 I agree that xorg is a BLFS support issue and that deals with case 2. Case 1 is a bit like /usr/man link to /usr/share/man, which is a LFS cross issue. That's why I posted it here. Should be fixed by building X.org with the correct #defines. AFAIK, only X is affected - nothing else should need /usr/lib64 on a pure64 system. No doubt there are some minority applications out there that also think x86_64 must use /usr/lib64, patch them if you come across them. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-Bootscripts-3.2.1 setclock
On Thu, 3 Nov 2005, Duncan Webb wrote: What I don't understand is why anybody would have a problem syncing the hardware clock to the system clock at reboot/power off. After all the system clock is synced to the hardware clock at boot. In that case, please search the lfs archives and warm yourself by the heat of the discussion. A classic case for your distro, your rules. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Progress of the build order changes
On Sat, 12 Nov 2005, Matthew Burgess wrote: Jeremy Huntwork wrote: Anyway, the results of the farce run are in my homedir: http://linuxfromscratch.org/~jhuntwork/farce-results A question for Ken, then. What's the difference between: 2 files differed as expected and 1 files differed as they normally do i.e. why can't they be put in the same category? Cheers, Matt. differed as expected are files _I_ expect to differ,(fstab, group, hosts, shadow, bootloader conf, logs (for root - normal user might not be able to read these, so they will be ignored), pids, and a few other things, all listed in the expected function. Provided people agree with my rationale, these can safely be ignored. Bear in mind that my can it build itself process is : build system one, boot it, (get filelist), (perhaps build X and desktop apps), build system two on a different partition. differed as they normally do have a question mark over them. They get flagged as predictable FAIL in the output. Identified in function 'failure', so far limited to libstdc++, libsupc++ and also lynx, ncftp, lsof, sshd, traceroute which are blfs but nevertheless things I build before I reboot. I don't know why these differ. The diffs of these are in farce-extras, and not at all enlightening. These have usually differed since I first took an interest in trying to compare builds. Anything else shows as an unexpected FAIL: and really needs to be investigated. Depending on what you build before running filelist, you mmight get other things with a date/time/kernel version that slips through the regexes - that's the real reason for the output in farce-extras. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Progress of the build order changes
On Sat, 12 Nov 2005, Jeremy Huntwork wrote: Chris Staub wrote: I just found a problem. I tried building arts and got this... Here's another uncleanness: e2fsprogs and libtool hardcode the path of sed into installed scripts. /usr/bin/mk_cmds (from e2fsprogs) and /usr/bin/libtool both have /tools/bin/sed as hard-coded as the command to use for sed. Will fix shortly. -- JH Heh, I was just about to revisit your earlier posting and ask about libtool. The difference in bison might be worrying, or it might be nothing (maybe even another candidate for differs as they usually do) - anything interesting in farce-extras, or is it just impenetrable binary data ? Also autoupdate - it's a script, so the diff in farce-extras should at least be readable ;) In passing, it's interesting that every package and its dog hardcode the sed path into scripts - that was one of the findutils problems with the earlier cross-lfs build order. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Progress of the build order changes
On Sun, 13 Nov 2005, Ken Moffat wrote: Heh, I was just about to revisit your earlier posting and ask about libtool. The difference in bison might be worrying, or it might be nothing (maybe even another candidate for differs as they usually do) - anything interesting in farce-extras, or is it just impenetrable binary data ? Also autoupdate - it's a script, so the diff in farce-extras should at least be readable ;) In passing, it's interesting that every package and its dog hardcode the sed path into scripts - that was one of the findutils problems with the earlier cross-lfs build order. Hit 'send' too soon, I also meant to say that the man pages only in one build look like some perl(?) package that only got built in one system (if that's the case, it's an example of you have to interpret the results), and that it *ought* to be possible to run farce against a live system (it's designed for it, doing a test this afternoon of / and a hacked copy of it, I was surprised to find mail and /etc/issue showing differences, both from fcron jobs). OTOH, if you do run it on a live system and it trashes it, that's a bug ;) Ken -- das eine Mal als Trag?die, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: grub
On Sun, 13 Nov 2005, Alexander E. Patrakov wrote: Matthew Burgess wrote: Richard A Downing wrote: Is LILO still maintained? Your comments here worry me a lot about the competence of the team writing grub2. Looks like it is - http://home.san.rr.com/johninsd/pub/linux/lilo. The only advantage that I can see from Grub2 over Grub Legacy is it's usable on PPC, x86-64, x86-32 (I think) which means that cross-lfs has fewer bootloaders to worry about. I don't think LILO targets anything other than x86-32, and I'm not sure of its current build requirements. LILO needs only bin86 beyond what the book provides. Also there's a patch for LILO but not for the other bootloaders that allows booting from devices managed by non-standard partitioning schemes such as LVM2. Since my /dev/hda is managed by LVM2, I won't look at anything except LILO. LILO also works on x86_64-64 (bin86 needs a patch, but that should be in the next bin86 release). Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: TLS Fix for 6.1.1
On Sun, 20 Nov 2005, Matthew Burgess wrote: DJ Lucas wrote: Sorry it's so last minute with release scheduled in 6 days, but I'd suggest testing this patch for inclusion in 6.1.1. I have tested and verified only on 2.3.5. I don't have time to test this myself, so I'm going to have to ask someone else to do a full 6.1.1-pre1 build without the patch and ensure the bug this fixes can be triggered. If so, I'll add the patch (assuming further testing shows the patch does indeed fix the problem). Looking at the gentoo, debian, and blfs references, this seems to be triggered by (a) nvidia drivers, or (b) gnome (versions/items not specified), or (c) xmms (1.2.8? debian version) without libmikmod2, or (d) some OOo issue. From here, trying to trigger the bug looks like searching for a needle in a haystack. The xmms debian version is way before anything we'd use, so is this really an nvidia bug, or is the OOo problem not related to nvidia binary drivers? Personally, I've not seen any problems with xmms (1.2.10) or xine that sound like this bug, even on my 6.1 systems. Ken -- das eine Mal als Trag?die, das andere Mal als Farce-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: TLS Fix for 6.1.1
On Sun, 20 Nov 2005, Archaic wrote: On Sun, Nov 20, 2005 at 09:56:28PM +, Ken Moffat wrote: Personally, I've not seen any problems with xmms (1.2.10) or xine that sound like this bug, even on my 6.1 systems. It is a glibc bug, not nvidia, xmms, xine, or OOo. Read the debian bug report mentioned elsewhere by DJ for the location of the test code to trigger it. Ok, so the order in which libraries are loaded, together with a missing library, can trigger an assertion failure in glibc. Doctor, it hurts when I delete this library which has other libraries depending on it. -- das eine Mal als Trag?die, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: User IDs and Group IDs
On Tue, 22 Nov 2005, Matthew Burgess wrote: Jeremy Huntwork wrote: 1) Are those specific headers for that version necessary? Wouldn't the current ones work? Well, they work for me (I've been running 2.6.14 for a while now). However, I'd imagine that if the kernel gets a new feature (e.g. iNotify) but we don't install the userspace headers for it then any userspace utilities will be unable to take advantage of that feature. Seems a plausible problem, we can address it when somebody gets bitten by it. Meanwhile, 2.6.14 works fine for me too (except for .config issues on one of my non-modular builds) and I'll be desperate to move to a newer udev (for the powerpc arch changes in 2.6.15-rc) once I've got a usable build on my latest box. I don't profess to understand most of the kernel vulnerabilities, but aren't kernels 2.6.14 all officially vulnerable to something or other ? Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
coreutils tests as user dummy
I'm running into problems with the src/su dummy -c make
RUN_EXPENSIVE_TESTS=yes check tests on a new architecture - it's
telling me that user dummy doesn't exist with both 5.92 and 5.93, but
5.2.1 passes without errors.
Looking at my notes and scripts, this is the first time I've tried
either of the 5.9x versions of coreutils. So, can anybody confirm that
the testsuite works for them with coreutils-5.9{2,3} please ?
Ken
--
das eine Mal als Trag?die, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: coreutils tests as user dummy
On Tue, 22 Nov 2005, Matthew Burgess wrote: Yep, I ran into the same issue. Testing suggested that the /etc/passwd entry for users you want to `su' to need a home dir. I therefore changed the creation of the dummy user to: echo dummy:x:1000:1000::/root:/bin/bash /etc/passwd Have you updated your scripts to reflect the SVN upgrade of coreutils (http://websvn.linuxfromscratch.org/diff.php?repname=LFSpath=%2Ftrunk%2FBOOK%2Fchapter06%2Fcoreutils.xmlrev=7098sc=0 should give you a decent overview of what's needed by the new version)? Regards, Matt. Doh, my local copy of the book includes that, but everybody already knows I can't read (or, more accurately, I can't spot differences in text if I think it matches). Thanks. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: OT: simplify CLFS [WAS: Re: User IDs and Group IDs]
On Tue, 22 Nov 2005, Jeremy Huntwork wrote: This is a bit off-topic, but this discussion has triggered another thought. With CLFS at some point (whether you decide to chroot or boot) you're going to be building the remainder of the book natively. At that point does CLFS really need to maintain separate instructions on how to do that? In short, do they need to ever worry about UID/GID etc? We could chop off that entire section in CLFS and point users to chapter 6 of LFS to finish up their native build. My experience with the pure64 hint (which was pretty close to LFS-6.1, no biarch or triarch considerations, and the same toolchain) suggests that it's pretty awkward to produce a meaningful precis like this. Certainly, multilib variants are not going to fit nicely into that framework IMHO. Look at it another way - here's a book, but at the tenth chapter we tell you to read a different book, starting at its sixth chapter, but still paying attention to the following list of variations. It doesn't feel complete, and it doesn't read well. (the list of variations will occasionally be required patches or seds, sometimes a reminder to build more than once, sometimes a note of more failures in testsuites, sometimes a reminder to use a different version of glibc, sometimes different/extra required tools [ at least until grub3 plays its music whilst reading every known type of filesystem :-P ]) Ken -- das eine Mal als Trag?die, das andere Mal als Farce-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: More control...hint integration discussion
On Tue, 29 Nov 2005, Randy McMurchy wrote: Though I've never seen a situation where I 'ran into a problem during make install', I suppose it could happen. Just wait till you move to a multilib machine ;) Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bzip2 binary
On Sat, 19 Nov 2005, go moko wrote: Hello Just a question: During the installation of Bzip2, why does the book use the bzip2-shared binary, instead of the bzip2 binary installed by the 'make install' command? The README of Bzip2 indicates that the bzip2 binary is better and recommand it. Regards G. Moko Sorry for the late reply to this. As far as I can see, the developer has two reasons for this stated preference - (i) the shared program is not tested. Well, maybe somebody ought to fix the testsuite (attached, but unlike the non-shared version this test isn't run automatically). But, does anybody else care if bzip2 gets tested ? (ii) the shared version is slower (on platforms like x86 which lack an adequate number of registers). This doesn't seem compelling to me - if speed was that important, we'd still be using gcc-2.95.3. For decompressing, the difference is not significant. On my duron (1GHz, but PC100 memory, and a bit underpowered now) I used both versions of bzip2 with -dc to take gcc-4.0.2.tar.bz2 (on an nfs mount) and write it to a local file. That box is running an LFS-6.1 toolchain. Three runs of each, 58 seconds using bzip2, 58 to 61 seconds with the shared version (variation 4%). If you compress a big dataset, then yes, the differences are more significant. Using a 186M tarball from a partial system build, with a sync before each test and two runs of each, user time varied from 3m32 (non-shared) to 3m52 (shared) which is about 9.5% slower. So, if you reguarly compress large files with bzip2 on x86, you might want to consider using the non-shared version to use a bit less time. For most people, and for people using fast processors with fast memory, it probably isn't worth using the non-shared version of bzip2. Ken -- das eine Mal als Tragödie, das andere Mal als Farce Submitted By: Ken Moffat ken at linuxfromscratch.org Date: 2005-12-03 Initial Package Version: 1.0.3 Upstream Status: not submitted Origin: self Description: Copied from the non-shared Makefile so that the shared version can be tested. --- bzip2-1.0.3/Makefile-libbz2_so.orig 2005-12-03 14:17:21.0 + +++ bzip2-1.0.3/Makefile-libbz2_so 2005-12-03 14:24:23.0 + @@ -42,3 +42,21 @@ $(CC) $(CFLAGS) -c decompress.c bzlib.o: bzlib.c $(CC) $(CFLAGS) -c bzlib.c + +check: test +test: bzip2-shared + @cat words1 + ./bzip2-shared -1 sample1.ref sample1.rb2 + ./bzip2-shared -2 sample2.ref sample2.rb2 + ./bzip2-shared -3 sample3.ref sample3.rb2 + ./bzip2-shared -d sample1.bz2 sample1.tst + ./bzip2-shared -d sample2.bz2 sample2.tst + ./bzip2-shared -ds sample3.bz2 sample3.tst + cmp sample1.bz2 sample1.rb2 + cmp sample2.bz2 sample2.rb2 + cmp sample3.bz2 sample3.rb2 + cmp sample1.tst sample1.ref + cmp sample2.tst sample2.ref + cmp sample3.tst sample3.ref + @cat words3 + -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bzip2 binary
On Sat, 3 Dec 2005, go moko wrote: After your remarks, I've done another test on my new 64 bits system. This time, I've quite exactly the same time for compressing and decompressing a 600Mo archive (OOo, for the example) with the shared and the partially-static version, with options -9 (maximum compression). Well, x86_64 *doesn't* lack an adequate number of registers. That's actually its main benefit for many of us, but thanks for confirming it. Ken -- das eine Mal als Trag?die, das andere Mal als Farce-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Alphabetical branch status report (LONG)
On Thu, 15 Dec 2005, Jeremy Huntwork wrote: Ken's Farce is probably good enough for our needs. However I did take a brief look at Greg's scripts and he does a couple of other interesting things, such as de-compressing all .gz files and un-archiving all .a files before running the comparison. Yeah, gzipped files contain a timestamp - farce does a cmp of the data after the stamp, it just seemed more interesting than decompressing. I'm hopeful that the .a archives are adequately processed now (my fix to make the testar function work again). Also, as I mentioned earlier in this thread, talking with Ryan set me on a little bit of a purity path. One thing he suggested, however, which I'm finding hard to put faith in at this point. He mentioned the purity of the build is shown, in part, by being able to build on old and broken hosts, ie, RH 6.2. I can see his point, in that it shows we've broken from that environment and have built ourselves a robust and sane toolchain. However, current LFS has requirements far above RH 6.2, such as a host with a 2.6 kernel because of the step up to NPTL. Also, (at least with RH 6.0; I don't have 6.2) the version of 'make' is too old to even parse the 2.6 kernel's make system. So, to really break free from such an environment, we'd have to first build a sane set of gnu-tools on it. Unless I'm missing something, I don't see how showing purity by building on such old hosts at this time has merit. Interesting comments, I hadn't thought about that. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Alphabetical branch status report (LONG)
On Fri, 16 Dec 2005, Ken Moffat wrote: On Thu, 15 Dec 2005, Jeremy Huntwork wrote: Ken's Farce is probably good enough for our needs. However I did take a brief look at Greg's scripts and he does a couple of other interesting things, such as de-compressing all .gz files and un-archiving all .a files before running the comparison. Yeah, gzipped files contain a timestamp - farce does a cmp of the data after the stamp, it just seemed more interesting than decompressing. I'm hopeful that the .a archives are adequately processed now (my fix to make the testar function work again). Forgot to add - thanks for the comment, I'm hopeful that farce will mostly answer the comparison question, but there is an amount of policy in it, particularly the list of files which are allowed to differ - I'm happy with these, but if it gets wider usage people may want to disagree about some of these. -- das eine Mal als Trag?die, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Alphabetical branch status report (LONG)
On Thu, 15 Dec 2005, Dan Nicholson wrote: It sounds like Ken's scripts do a great job of doing the comparison. What I like about Greg's scripts is deciding what's being compared. 1. The build automatically loops to the beginning, skipping the first few stages: create symlinks, create devices, mount file systems, create directories, etc. for all but the first iteration. That's my prime objection to Greg's method - we always tell people fbbg, but the comparison takes a shortcut. 2. For all stages he stops short of installing many of the custom configuration files like /etc/profile, /etc/fstab, etc. Keeps the building environment consistent. This is what I like better than what Ken's tool does. I'm not sure how it removes the variables of kernel, modules, env vars, etc. Useful, if all you want to do is test it. For me, knowing that a new build boots (and therefore has enough of blfs for me to use it, e.g. dhcp, nfs, ssh) is always a good sign. These files are what I called 'policy' earlier. If you want to use similar buildscripts to only install certain files, or a script to sed the lists of files to compare, farce won't complain. Kernel modules might match, or they might differ, or not be present. I'm trying not to be prescriptive in how farce is used - if these do differ, I expect the builder will know why, and therefore recognise that they changed the .config, or the kernel version. The compressed bzImage is a different matter - I skip that because compiling the same source at a different time will change the date/time which is in the text, and therefore the size of the compressed file can change. I'm unclear what changing environment variables is likely to do to an LFS build ? In practice, either the environment is created during the build (e.g. new .bashrc), or a builder probably has a standard pre-existing environment. For the kernel, apart from not trying to look at differences in bzImage/vmlinuz I just change known kernel version formats into tokens in my infamous regexes. For example, lots of the perl files are actually text telling you the kernel version and date/time when it was compiled. Change these to tokens for known format permutations and you don't lose any information. Yes, if you decide to start building in a different locale, this might alter what goes into the text, and perhaps put it into a different format - if that happens, farce should give you enough information to see which formats changed. Most of this should be reasonably clear from looking at the code (it's only two scripts), although the perl regexes are probably a hard slog when you first meet them. 3. Copies only the necessary files to a temporary location immediately after the build completes. This is more trivial, but it safeguards you against accidentally making an unalterable change on your system later. That _is_ an advantage - lesstif from blfs overwrites a man page from perl (not checked recently, but it used to), which I only noticed when I compared a full system against the minimal system it had built. With farce you can compare as little, or as much, as you wish (subject to adding to expected differences for new file types such as Python code, and new regexes) - it doesn't need a full build, it should be usable for arbitrary packages, and you can use your own buildscripts. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Alphabetical branch status report (LONG)
On Thu, 15 Dec 2005, Dan Nicholson wrote: That's my prime objection to Greg's method - we always tell people fbbg, but the comparison takes a shortcut. Right, but for the purposes of testing, the environment should be as consistent as possible. That's standard procedure for running a test in any field. And why would you recreate the devices, directories and symlinks if you were still in the chroot? Setting up a test environment is different than putting your system in a production running state. Not recreating devices, directories, symlinks is not the issue - in a regular build the final system is built from a temporary system. For a normal upgrade, the old LFS has to be good enough to build a new temp system, so that was how I began. Greg made a decision on what he wanted to test, I made a different decision. As for booting, you're going to probably change your environment drastically, and that would invalidate the test. If you did a binary diff and found two files to be different, would you be confident enough to tell me that the difference was caused by the building method and not by the altered environment? Or vice versa? I'm not following this, perhaps the 'environment' is throwing me - all I'm interested in are the results of the build - logs, devices, config files are variable data. Programs, libraries, even scripts are not expected to change once installed. Please remember that I've not trained as a tester, only as a programmer and analyst. I'm unclear what changing environment variables is likely to do to an LFS build ? In practice, either the environment is created during the build (e.g. new .bashrc), or a builder probably has a standard pre-existing environment. How about LC_ALL? Creation of /etc/profile in LFS dictates you to set it to your locale, but for the build we've used LC_ALL=C (or POSIX). I don't have an /etc/profile. My LC_ALL is set in my buildscripts, I don't see how the fact that a regular user will have a different LC_ALL alters what is in the files he is comparing. I have no objections to farce. It sounds like you've put a lot of effort into seeing what happens to the files in a second build. I'm arguing for keeping a sane test environment. We all know that LFS builds and boots. This tests the quality of the build, and that test is separate from the two previous questions. Actually, I don't mind if people do object to farce, I'm not overly pleased with it, but it's better than what I had before. Purity was not my major concern when I started trying to improve my analysis of the results - in an average week, two or three unrelated packages are upgraded. As a tester and now as an editor, I need to know that it does indeed still build and boot (and ideally, to know that it builds the parts of blfs I care about - remember bison?). As somebody interested in kernel development, I try to test -rc kernels to make sure the features I use haven't been damaged. To optimise my time, I aim to test everything together because mostly there *aren't* issues (and to be honest, testing the kernels is actually more important). People trained in formal testing are welcome to use their professional techniques. Me, I'm just a journeyman, I pick what I think are appropriate tools for what seems important to me. The main feature of my builds is that something will differ from the instructions in the book (e.g. my last pair of multilib builds used different bzip2 and vim instructions between the builds, and were built with a test kernel). People here who understand the details of Greg's ICA should be encouraged to apply it to LFS builds. Maybe someone has been doing that, and we're just lucky that no problems have showed up for them to comment on, but my assumption is that ICA is poorly understood in lfs circles. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Alphabetical branch status report (LONG)
On Thu, 15 Dec 2005, Ken Moffat wrote: I seem to recall that in repeated standard LFS i686 builds, these same binaries can in fact differ, without anybody ever quite knowing why - this is why Greg's ICA, at least last time I looked, did -three- builds to compare which bytes always differed. Actually, Greg was told it was because of anonymous namespaces - thread at http://gcc.gnu.org/ml/gcc/2003-08/msg00468.html Ken -- das eine Mal als Trag?die, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Alphabetical branch status report (LONG)
On Fri, 16 Dec 2005, Dan Nicholson wrote: On 12/16/05, Ken Moffat [EMAIL PROTECTED] wrote: snip everything Ken, I seemed to have offended you and I'm sorry that happened. I really don't mean to bad mouth the way you've tested or the tool you've created to assist. I was only arguing the case for doing ICA for the sake of testing the purity of the LFS build. I never meant to imply that you should have been testing this way or that any results you'd gotten we're worthless. Dan, what did I say that makes you think I'm hurt ? I haven't been offended by your comments, and I hope mine weren't offensive to you, I certainly didn't intend that. I welcome an opportunity to discuss testing, and I intended to further the discussion. As I said, I'm not overly happy with farce, but it seems to assist _my_ testing. OK, I've stated my opinion in this thread a few times. I'm getting out of the way. -- Dan Please continue to contribute to the discussion. Ken -- das eine Mal als Trag?die, das andere Mal als Farce-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Alphabetical branch status report (LONG)
On Fri, 16 Dec 2005, Dan Nicholson wrote: On 12/16/05, Ken Moffat [EMAIL PROTECTED] wrote: Just seemed that you were taking offense to my suggestions or you assumed I was taking shots at your tool. If not, then that's good because I didn't mean either. Great As pertains to the testing, I downloaded farce finally and had a look. I like it a lot, and I think it handles the comparison well. In Greg's scripts the comparison is not as detailed; this automates a lot of what I believe he does manually. So, that's very cool. I'm not sure I'll trust the regex replacements until I see it in action, but that doesn't stop me from manually doing the diffs on the files themselves. Not trusting the regexes until you've diffed is good. Maybe farce could generate even more output, to also show what the regexes changed (at the moment the detailed output is only for things that still came up as different). I'll need to think about that. Now, I will still argue about how best to set up the test environment. I'm not a professional tester or analyst either, but it seems common sense to me to minimize the number of variables when hunting down a problem. I agree that it is necessary to reduce the number of variables once a problem has appeared. For this reason, I agree with Greg's decision to stop short of installing all of the configuration files and immediately rebuild while still in the chroot. You mentioned setting LC_ALL in your build scripts. What if someone else doesn't? Are their results reliable? If LC_ALL isn't set correctly, then the results may well not be reliable. But, I'd expect that to show in build or testsuite failures. You sound like you've done the recursive build a number of times and anticipate these differences in farce. I'd rather nip that one in the bud and just keep the same environment. Not exactly a recursive build: if a system builds itself again, to my satisfaction, and builds (once) the parts of blfs I care about, I regard it as ok. The recursive build is, or was, based on three builds to identify which files always differed. I settle for a rebuild. FWIW, this is the method I'll be taking. I'm gonna start hammering out builds on Christmas. I'll be out of town for a week, so there's nothing but spare cycles. Dedication, using all that drinking time ;) 1. Build Ch.5 and Ch. 6. Copy important contents of / to temporary location. I could probably do this with filelist, but I'll still copy anyway. This includes /boot, /bin, /etc, /lib, /opt, /sbin, /usr and /var. Filelist only creates a list of which files exist (for a user, exist and can be read, I think). If you're going to build in-place, you'll HAVE TO copy them somewhere (a tarball will do, but you need the disk space for two trees, or systems, at a time when farce is run, plus a few MB for the results [ diffs of binaries can be big ]. 2. Iterate Ch. 6. Start Ch. 6 at the beginning, ignoring the symlink, device, directory creation and the fs mount since these have already been done. Copy / to another temporary location using the same directories as in 1. Repeat 2 if desired to a predefined number of iterations. *Note: 1 and 2 are ripped from gsbuild. You could probably add Ch. 7 and Ch. 8, but I already explained my interest in minimizing the test environment. 4. Run farce on the temporary locations from the earlier stages. 5. Ponder the exact time in my life when I became a huge geek. Iterate. LOL One last thing. As for running ICA, I think this is only a name. I only use it because most what I know about recursive building comes from reading stuff Greg's done, and that's what he calls it. We're both talking about the same thing as to seeing whether the build can recreate itself. I think the only difference I can see is how to set up the testing environment. We can call it something else if that helps. ICA is Greg's name, AFAIK he had rather a lot to do with it so he gets to name it. If somebody understands it enough, and cares enough, to use it and report back to us, that's great. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: ICA
On Sun, 18 Dec 2005, Jeremy Huntwork wrote: There are 4 lines that, to me, stand out: unexpected FAIL: /usr/bin/libtool is different unexpected FAIL: /usr/bin/vim differs after stripping and processing unexpected FAIL: /usr/include/c++/4.0.2/i686-pc-linux-gnu/bits/stdc++.h.gch/O0g.gch is different unexpected FAIL: /usr/include/c++/4.0.2/i686-pc-linux-gnu/bits/stdc++.h.gch/O2g.gch is different The libtool is easy to explain, the differences in that amount to a different hostname used for each build. It contains a line like this: # Libtool was configured on host lfslivecd My hostname changed on the two builds - one was done on the livecd and the second, I rebooted into the new system and built on that. hmm, I haven't allowed for the hostname changing between builds, and I'm not sure that I can - almost anything might be a hostname. I guess that is probably also true for Config_heavy.pl (hostname appears as part of the target system in that one). there are also a few things which suggest differences in the config files for the bootscripts, missing files, but they don't look likely to be important. The vim one puzzles me a bit. :/ Also, I'm hoping that the stdc++.h.gch differences are due to the randomness that Ken and Greg talked about. I think vim might be more of this c++ randomness, your report makes me think I've seen this in the dim and distant past, but not recently. OTOH, I haven't done any comparison of x86 vim-6.4 builds. The stdc++.h.gch is new to me, I guess this must be one of the precompiled headers. Possibly I've missed building these in the past. I can't start an x86 build for a few days, so don't expect me to confirm this any time soon. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bash testsuite should not be run as root
On Fri, 23 Dec 2005, Greg Schafer wrote: On Wed, 21 Dec 2005 11:34:22 -0800, Jim Gifford wrote: I posted a solution in lfs-support. Here is it In my testing with Cross-LFS, I have found that this works echo dummy1:x:1000: /etc/group echo dummy:x:1000:1000:::/bin/bash /etc/passwd cd tests su dummy -c sh run-all sed -i '/dummy/d' /etc/passwd /etc/group rm /tmp/* That won't work for LFS. `su' is provided by Shadow which comes after Bash. Note also that installation of `su' from Coreutils is suppressed. Regards Greg Greg, 'su' from /tools. Neither CLFS nor LFS suppress this in the first build of coreutils. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-Alphabetical ICA/Farce Results
On Fri, 23 Dec 2005, Dan Nicholson wrote: I haven't done any research yet, but I'm attaching the ICA report for 1v2. With the exception of farce-extras (too big to move around), you can see the results in http://students.washington.edu/dbnichol/lfs/ . I'm going out of town in the morning, so I probably can't do any research till the new year. I'd appreciate any comments people have. Hi Dan, I've been attempting to run an ICA on my CLFS ppc builds (CLFS from 20051214, but modified to also build a minimal 64-bit toolchain in /opt/kgcc because the cpu is a G5). So, my observations have very little to do with the alphabetical branch per-se. My process (build twice, boot second build, then go back to first build and rebuild on top of the second build with /tools no longer used) has highlighted an error in my original two builds which I need to try to understand (module-init-tools in /usr/local, the last two builds were correct!). There are other things in my results that I don't yet understand, and it looks like I'll need to _not_ boot a system before running ICA on it - Dan may reply 'told you so!' if he wishes ;) My method did show that 'man' will compile against lynx if lynx is already installed (bummer) - should we be building lynx, and then man, in LFS ? Or would BLFS like to add 'man' with a dependency on 'lynx' (heh, I can guess the answer to that) ? Oh, and *some* examinations of ar archives in farce were broken again [ not sure if this showed, other than in the runtime error messages ] - fixed in farce-001-4 which is now available. Anyway, you have differences in mkfs - ok for me, but my fsck.ext2 (and its other names) differed. bison, perl, vim - for me, these differ between my second and third builds, but not for my third and fourth, nor for the first and second - I guess this is the whole point of ICA and the build will be assumed guilty unless an explanation can be produced. Needs investigation. nscd - ok for me sundry .gch files - none of these files on ppc, I guess they must be those precompiled headers. No opinion (either on why they differ, or on whether clfs ppc ought to have them). libstdc++.a and libsupc++.a - the anonymous namespaces. [ Note that farce is content to match the corresponding .so files by running 'strip --strip-all' - maybe that is hiding more than it should.] locale-archive - I only see this differing when it is updated in place! (that is, in ICA). The size for me with 'ls -l' is unchanged, so I'm not particularly worried, seems to be a feature of reinstalling locales in-situ. Possibly, a useful ICA run should never install locales (since there is no 'expect', so it won't be running testsuites). Thanks for doing this analysis. Ken -- das eine Mal als Trag?die, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
