Comparison of Testing vs Unstable in preparation of eliminating the testing branch
Hey all! As a favor to Gerard, I sat down today and made a list of the differences between the unstable and testing branches of the LFS book, in preparation to eliminate Testing, as was proposed by G previously. Here's a list of all changes I can find currently: Build command differences: Chapter 5 - GCC Pass 1: Use of -B/usr/bin - workaround for an old problem, no longer really needed - was planned to be removed at some point in the future. Chapter 5 - Binutils Pass 2 and Chapter 6 Binutils: Testing does "make check", unstable does "make -k check" - the -k parameter is no longer needed, as all binutils tests are expected to pass with this version. Chapter 6 - Glibc: Additional command to unpack the linuxthreads tarball, which provides the man pages for the pthread libs. Chapter 6 - Zlib: Use of the --libdir option to configure, instead of moving libraries into their proper places. Chapter 6- Readline: Testing uses the display_wrap patch, Unstable uses the fixes patch (which incorporates the existing display_wrap patch, as well as other fixes from upstream). Also, Unstable uses the --libdir option to configure, while testing does not. Chapter 6 - Iproute2 Unstable uses a second patch - find_update - this is needed because newer version of findutils are more strict regarding command line syntax to find. Chapter 6 - Bash This is simply a note for future reference. Both Testing and Unstable use the fixes-1 patch, but there's a newer patchset available (fixes-3) with more upstream fixes to bash. Chapter 6 - Grub Command change to copy the stage files from /usr/lib instead of /usr/share in Unstable - necessary part of the upgrade from 0.95 to 0.96 Chapter 6 - Libol Removal of the --enable-shared parameter in unstable, still present in testing - Archaic confirms this is not necessary Chapter 7 - LFS-bootscripts Unstable no longer has make install-hotpulg and make install-syslog-ng directives - not needed with the 3.1.0 bootscripts package Chapter 7 - Linux Console configuration Some additional sample commands in testing Chapter 7 - Bash Shell Startup Files Some additional sample commands present in testing Chapter 8 - Kernel compilation Testing still has the sed command to ensure the kernel doesn't pass hotplug events on to userspace until it's ready to receive them Packages upgraded in Unstable but not testing: Glibc (Testing at 20041011 CVS, Unstable at 2.3.4 release - minor differences between the two packages (a single bugfix for mips provided to glibc devs by Jim Gifford) Expect (Testing at 5.42.1, Unstable at 5.43.0 Findutils (Testing at 4.2.3, Unstable at 4.2.17 Automake (Testing at 1.9.4, Unstable at 1.9.5) File (Testing at 4.12, Unstable at 4.13) Libtool (Testing at 1.5.10, Unstable at 1.5.14) E2fsprogs (Testing at 1.35, Unstable at 1.36) Grub (Testing at 0.95, Unstable at 0.96) Libol (Testing at 0.3.14, Unstable at 0.3.15) Syslog-ng (Testing at 1.6.5, Unstable at 1.6.6) LFS-Bootscripts (Testing at 2.2.3, Unstable at 3.1.0) And, that's it. It's possible I could have missed something, but that's all the differences I found checking between the two today. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Comparison of Testing vs Unstable in preparation of eliminating the testing branch
Gerard Beekmans wrote: On February 18, 2005 05:15 pm, Jeremy Utley wrote: As a favor to Gerard, I sat down today and made a list of the Thanks for the quick turn-around Jeremy and on such short notice too. It's appreciated. The reason is I would like to get this task done asap while the momentum is behind it, and while there's not much else going on that requires our immediate attention. Things tend to get swallowed up or overshadowed sometimes. Glad to help out - I had nothing else going on, and it didn't even take an hour to get it done - took a lot shorter than I expected. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: a typo in Version 6.1-testing-20050205
Gerard Beekmans wrote: On February 15, 2005 11:27 pm, [EMAIL PROTECTED] wrote: /configure --help mentions --with-selinux and not --enable-selinux --with and --enable are sometimes (often?) synonymous in configure scripts. Can somebody verify this and Bugzilla it if it's an actual issue and not something else? I'll be checking on this bug tomorrow. I have a FC3 partition already in place on my system, so I can find out what's what. Will open bugzilla entry if it does turn out to be a problem. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: problem with "make install" for Glibc-2.3.4 (test-installation.pl)
.sSweetMarie wrote: cannot find -lcidn collect2: ld returned 1 exit status This is the key in all of it. 2 things are possible: 1 - you used a different version of glibc in chapter 5 than in chapter 6 (a glibc that does not include the libcidn add-on in chapter 5) 2 - you specified --enable-add-ons=nptl in chapter 5, but just --enable-add-ons in chapter 6 The only way around it is to configure your chapter 6 glibc with --enable-add-ons=nptl, eliminating the libcidn functionality entirely. This won't provide any real issues, since libcidn is something relatively new, and not really used that much as of yet. HTH, -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: IPRoute2 free_error patch
Randy McMurchy wrote: Hi all, I noticed in the patches project there's a patch for IPRoute2 named free_error. There's a -1 and -2 version. Does anyone know if this patch is scheduled for inclusion in the book, or is it some sort of optional patch, to be used only if you encounter the error it fixes. TIA for any information you may have. If I remember that patch, the problem it fixes occurs on MIPS only - other archs I believe are not affected. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Module-Init-Tools-3.1
Randy McMurchy wrote: What do you mean a bother? For almost all the packages in the book that build in just a minute or two, it would take less than 5 minutes to update the build entities, installed programs and libraries in the book. This, IMHO, is a highly optimistic view. For each upgrade, and some packages have new releases on a pretty frequent basis, you have to perform a full build of the package, into a non-standard directory, measure the build sizes, compare the binaries installed with those on the current list, then research the function of each new binary, assuming information is available on what that binary does. Then, you have to properly edit the XML, validate it, ensure the new XML code renders into HTML properly, and finally commit it. This process is much more than the 5 minutes you suggest it should take. I don't see any need to omit it, because "it's a bother". Seems as though it's just part of the job. Then somebody doesn't have to go behind and do it all at one time in a time-crunch release it tomorrow mode. Well, lets look at it differently. Lets take, for example, a certain package that undergoes 10 upgrades thru a LFS release cycle. Assume 10 minutes for testing a build (without installation), updating the package version entity, testing rendering, and committing - and this is a highly optimistic time estimate. We'll also assume an extra 30 minutes for installing the package to a non-standard directory, validating all installed binaries/libraries, and researching any new binaries that may be present in the build. Taking this into account, if you update those parts of the XML only once, before release, then editorial staff has spent just a little over 2 hours on that single package thru the release cycle (10 upgrades x 10 minutes + 30 minutes checking prior to release = 130 minutes). Meanwhile, doing this for every one of the upgrades would be nearly 7 hours (10 upgrades x 40 minutes = 400 minutes). So, in this sample case, by waiting for release to edit these items, the editorial staff has been saved 270 minutes, or 3.5 man hours - and this is just for one package. And, as I said, and speaking from my own experience editing the book, these time estimates are highly optimistic - only the simplest of upgrades can be done in a 10 minute period, even without updating the build sizes/installed binaries parts of the XML. Holding the upgrade of these parts of the XML is simply a more efficient use of the editorial staff's time, especially when you consider the fact that anyone using the development version of LFS would logically be expected to know how to find out this information for themselves, as they are experienced LFS builders already. Of course, if it's that important to you, the LFS editorial staff always welcomes patches to the book's XML :) -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Syslog-NG (was: Re: Technical Excellence)
Randy McMurchy wrote: This I don't understand. I thought syslog-ng was the new syslog daemon of choice for LFS. If it goes away, what is destined to replace it? Gerard's post came as a shock to me as well, so I took the opprotunity to ask him about it on IRC, since he happened to be there at the time. Evidently some flaws have been found when syslog-ng is used in a "production" type enviornment, placing a lot more load on it than what most of us probably do. Archaic has more information, but to put it in general terms, syslog-ng's handling of the logging function can significantly delay action in some cases. I'm sure we'll here more on it soon. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Syslog-NG
Steve Crosby wrote: (Snipped excellent description of the issues) Steve - thank you very much for the clear, concise description - this is basically what I got from Gerard on IRC, but there's no way I could have worded it as well as you have. It is true that sysklogd was mostly removed out of LFS due to lack of maintainership, which, as pointed out by Jim and Steve, is no longer the case. Syslog-ng, at the time, seemed like a decent replacement, even with the need to incorporate the libol library. Given the circumstances, my personal opinion is that LFS should switch back as soon as possible, preferably before another release. I'm sure that Jim Gifford, as the hint maintainer for syslog-ng upon which our current book instructions are based, will continue to maintain that hint for those who wish to still use this package. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: lfs-bootscripts enhancement: alternate device for link up and ip/route assignment
Nathan Coulson wrote: I was wondering if that "Is the link up command" could be modified... I mean it sounds like we could create new networking devices on the fly, or have networking devices that are only up after special commands are done. Our current scripts would choke on that. Yep, I ran into this when I was trying to integrate my ham radio ax25 interfaces into the bootscripts - the ax0 interface is created on the fly by running a command "kissattach". If we could make it so there was an option to say "This interface is created on the fly" or something like that, then it would be a nice thing. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New linux release procedure
Matthew Burgess wrote: Folks, For those of you not following LKML, there's been a really really long thread regarding how the kernel development process can be adapted to improve the stability/quality of the 2.6.x kernels. The original thread starts at http://www.ussg.iu.edu/hypermail/linux/kernel/0503.0/0512.html, but the upshot of it all is the release of 2.6.11.1 announced at http://www.ussg.iu.edu/hypermail/linux/kernel/0503.0/1451.html. We had a short discussion a little while ago when the -as tree came into existence and now I think the time is right to go and use this not-quite-vanilla tree. There were some pretty big issues with the 2.6.11 kernel (e.g. keyboards on some Dell Laptops not working, etc.) so I think that using this stabilisation tree can only improve the quality of LFS. Thoughts and comments greatly appreciated. Cheers, Matt. I like this idea myself. I've hated the lack of a truly "stable" kernel release for quite some time, and it's always been a source of great frustration for me as an LFSer. I don't want to test kernels on my workstations or servers, I want them to be stable...and that's quite difficult with the way kernel development has been over the last few months - so I welcome this. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Binutils failure in Chapter 5
Bruce Dubbs wrote: What if binutils were just rebuilt using the same package, but leave the libraries unstripped? Because the problem is actually if libc.a has been stripped with buggy binutils, removing the TLS information from the library. The only resolution would be to completely recompile Glibc. I don't understand. LFS 6.0 uses 2.15.92.0.2. Is there a problem with LFS 6.0 or not? No, LFS 6.0 uses 2.15.91.0.2. See: http://lfs.osuosl.org/lfs/view/stable/chapter05/binutils-pass1.html The buggy strip was not fixed until 2.15.92.* HJL releases, IIRC. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Binutils failure in Chapter 5
Bruce Dubbs wrote: Jeremy Utley wrote: Because the problem is actually if libc.a has been stripped with buggy binutils, removing the TLS information from the library. The only resolution would be to completely recompile Glibc. I see. It's glibc that get corrupted. Would it be possible to download an unstripped LFS 6.0 version of libc.a and continue? I don't see why not, but IMHO, it's far easier to just build the Pass1's dynamic instead of static - it sidesteps libc.a completely (uses libc.so instead), and definately works - I've used that process myself when building from jhuntwork's LFS 6 cd, which exhibits this problem. This is also the solution we recommend to people on IRC who encounter this problem. The end result, as far as I can tell, is exactly the same, since the dynamic pass 1's linked against the host's glibc are overwritten by the dynamic pass 2's linked against our new glibc. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev testers required
Jim Gifford wrote: What's wrong with the one I did Matt, udev-config-2.rules. I made that after we agreed upon the changes?? The problem with the one you have proposed is we don't have all those extra groups. dialout, audio, video, floppy, tape. I will be doing the update to the new groups tonight with my hotplug stuff and I will revert back to udev-config-2.rules file. I thought it was agreed that we would not modify the groups in LFS until one of two things was in place: a) Text was ready to go into the LFS book to explain the changes in the groups, and what the user needs to do to get back the functionality they were used to or b) BLFS was ready to integrate the necessary changes into their book We really need to make sure one of these two things are in place before we drop all the groups from LFS - otherwise, we're going to end up with a lot of unhappy builders. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev testers required
Matthew Burgess wrote: Kevin P. Fleming wrote: But why does LFS-SVN need to wait on BLFS? BLFS is not based on LFS-SVN, it's based on LFS-6.0. Exactly, so if we go and remove all those users and groups that we don't think are required/desired on a base LFS system then it'll cause pain for those then installing packages from BLFS that require those users/groups to be present. Admittedly, the pain is minimal (a 'useradd' or 'groupadd' should be all that's needed) and any LFSer worth their salt should be able to figure out what's going on, but I thought this was the agreed approach. Except that it's not as simple as just a useradd or groupadd. There's also configuring udev so that the device nodes are set up properly to think about. I thought the whole idea behind removing the groups was to get educational text into the LFS book on how to set the system up more to your liking...when are we going to start discussing what's going to be in that text - that seems to me to be the next thing we need to do. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: cleanfs
Stef Bon wrote: Hello, after some unclean shutdowns of my computer, I saw that the openldap server (slapd) leaves some files in the /srv/ldap/run directory, which makes the startup script think that the server is already running. In this case it's about the files slapd.args and slapd.pid. Now isn't it the task of the cleanfs script to remove these files at startup, before any server is started. IT does now but in the pretty standard directories /tmp /var/lock /var/run Should this list be expanded with the directory /srv/ldap/run ? In general should this script look for several places other than the named standard directories because server are not in a standard place anymore in the system? (in /srv ) How do you think? Stef pid files should not be inside the /srv hierarchy. /var/run is the proper FHS-compliant place for these files to be located. This would definately be a problem with the BLFS installation instructions, not the cleanfs script, so you should probably take this to their list. Jeremy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Inconsistencies in the book and further notes
Edwin van Vliet wrote: Hi folks, Just finished yet another LFS installation (SVN), keeping as close to the instructions as I liked. This time I also kept some notes, for some things aren't very consistent throughout the book. Here they are: 1) I believe /var/lib/locate should be created in chapter 6.19, Findutils-4.2.20 Possible, but I don't see that it really matters one way or the other. I'm ambivalent regarding this. 2) The file /etc/inittab should be created somewhere in chapter 7 Definately not. /etc/inittab is the configuration file for sysvinit, so therefore it belongs with the sysvinit package. Our configuration file that we create is one that's appropriate to our bootscripts. If someone chooses to not use our bootscripts, and utilize another package instead, then it is their responsibility to make the necessary changes to the inittab file. 3) The udev rules file should not be downloaded from the website Please see the lfs-dev archives regarding this. This is planned for the future, but we must wait for BLFS to catch up and be ready to adjust their book for the changes we make in LFS, otherwise, a lot of system builders will be left out in the dark. 4) The directory /usr/share/misc must contain (a link to) the magic file Can you create a bugzilla item for this issue, and include a link to the FHS page that specifies this? -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Ready for gcc-4 & cleaning up binutils source delete or not.
TheOldFellow wrote: Fair comment. My earlier posts in LFS-Support in reply to an OP who was interested in gcc-4 had the links in. But thanks for repeating them. I'm attempting to stimulate some interest in moving LFS forwards. It won't be long before LFS is far beyond Greg's build process. Greg's still focusing on strictly x86 builds, LFS is on it's way to building on anything for anything with the integration of Ryan's cross-lfs scripts. I thing Greg's work deserves close examination - on more than the gcc-4 front. And it does work. I followed Greg's work for quite some time. There's flaws in there, and they've been discussed on the LFS lists previously. Another good way to find out the reasoning behind his choices is to look at the diy-linux-dev archives - very educational. His archives also expose the fact that DIY is him alone - it's not a community thing - for that reason alone, LFS is the better project, IMHO. J -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Ready for gcc-4 & cleaning up binutils source delete or not.
Matthew Burgess wrote: TheOldFellow wrote: However it's the LFS new technology gestation period that gets me down. And I only have i686 boxes :-( This isn't meant to sound as harsh as it's going to. But, if you don't like the length of time it takes to get new technology into LFS then post *patches* to the XML book sources, not scripts :) But there's still the lengthy community decision process to deal with before it makes it into rendered XML. That was the whole crux of the Unstable branch of LFS, so those of us who were interested in playing with that stuff could do so easily. Now that's gone :( And the simple fact is, GCC 4.0 is not quite yet ready for integration into the LFS book - it probably won't be until 4.0.3 or thereabouts. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Ready for gcc-4 & cleaning up binutils source delete or not.
TheOldFellow wrote: > >Yes, my intention was to show some alternatives and provoke a dicussion. > I do not propose that you just copy the script - the LFS aims are quite >different from Greg's - no reason you can't examine them for good ideas >though. > > With the new build process being worked on, Greg's stuff won't be able to give us a whole lot of good ideas. > >Good point. I accept that. There were two points that I wanted you to >take on board: 1) The dumpspecs/-specs= approach, even for gcc-3X. 2) >Getting rid of the 'keep binutils sources around' which so confuses the >newbies. > > > I haven't looked myself at the specs file issue yet, so I can't comment on that. The keeping of the binutils sources around will be gone with 7.0 with the cross-lfs process. If you like examining scripts for ideas, try taking a look at these: svn co svn://be-linux.org/cross-lfs/cross-lfs/trunk cross-lfs That's the subversion repository for Ryan's cross-lfs scripts, which is for the most part what LFS 7 will be based from. IIUC, Jim Gifford's already starting to work on getting them into XML form. Jim, care to update the list on the progress so far? As for myself, I'm anxious to see a LFS process that works properly for the bi-arch x86-64 toolchain :) Now that I have a 64-bit machine, I would really like to be able to get the most from it! -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gcc-4.0 branch created
Matthew Burgess wrote: Absolutely no changes are permitted on this branch that aren't directly related to the gcc-4.0 release. No backports of trunk fixes, no stylesheet fixups (sorry Manuel :) ), etc. The only things that I anticpate hitting this branch are dumpspecs stuff and patches for packages that aren't gcc-4.0 ready yet. Then what good, may I ask, is this having this branch, if the rest of the packages are not kept current to the book? Seems to me like it's a waste of a branch if it's not going to be kept up to date until gcc 4 makes it into our mainline book. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
was Re: dbus and hal
Matthew Burgess wrote: Jeremy Utley wrote: Randy - both of these are strictly cmmi installations - their configure scripts will pick up deps just fine. I can take a look for the deps for you guys, if you like. I started looking into this, but soon got distracted unfortunately. As you're probably already aware, Jeremy, hal & dbus rely on particular versions of each other to compile correctly. Basically hal-0.5.0 needs the latest dbus. However, gnome-vfs can use hal, but is incompatible with hal-0.5.0 (a patch is available somewhere though). Likewise, hal is heavily dependent on gnome, but only at runtime (hal-device-manager seems to want all of gnome and its python bindings installed in order to do anything!). Regards, Matt. You took my post out of context, but, of course, I should have altered the subject :) These comments were against Gaim/Xchat, which Randy had also brought up in his thread. -J- -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: gcc-4.0 branch created
Matthew Burgess wrote: Jeremy Utley wrote: Then what good, may I ask, is this having this branch, if the rest of the packages are not kept current to the book? Seems to me like it's a waste of a branch if it's not going to be kept up to date until gcc 4 makes it into our mainline book. Note how every other project handles branching and merging. Features are developed on separate branches, then merged with the ever progressing trunk. Consider what will happen with an 'svn diff' on the branch if we stick to the rules outlined above. Then compare that with the output of the same command on the branch if other checkins are allowed too. Now show me (given the latter) how you'd tell me exactly what changes are related to gcc-4.0 inclusion, and which aren't. Regards, Matt. But, how is someone who wants to use this branch to do so when the other packages are perhaps 2 or 3 months behind? That's my concern - if the other parts of the GCC 4.0 book are not kept up to date, then noone's going to want to build from that gcc 4.0 branch. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: gcc-4.0 branch created
Matthew Burgess wrote: Why is it going to take 2-3 months to get the book up to speed? The techniques for dealing with the specs file are already known. That just leaves documenting the patches required for our and BLFS' packages. Certainly not 2-3 months worth of effort methinks. Matt. Our book will come up to speed quite quickly, but BLFS will be much slower to come up to that level of support for GCC 4, and my understanding of what you posted was that LFS isn't going to merge gcc 4 into trunk until BLFS is ready for it. That's where the longer term comes into play. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Planning for Cross-LFS/Multi-Architecture 7.x Release
Randy McMurchy wrote: Please, Jim, for me and I'm sure there are others that want to know the same thing, can you explain *in a technical manner* how the toolchain could be any "cleaner"? A simple example will document this clearly. Take building LFS on a Fedora core release. In the past, we had issues with our chapter 5 glibc build picking up the presence of SE-Linux in Fedora core 3, which caused the chapter 5 glibc to also enable SE-Linux. But, once we got into chapter 6, it caused the glibc build to barf, because the headers for selinux were no longer present. This build process completely eliminates that situation. Anything that links to the host does NOT end up at all in the $LFS tree - the 2 packages which are linked to the host (cross-gcc and cross-binutils) are prefixed to the build user's home directory. HTH, -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Planning for Cross-LFS/Multi-Architecture 7.x Release
Randy McMurchy wrote: Jeremy Utley wrote these words on 04/18/05 23:14 CST: Randy McMurchy wrote: Please, Jim, for me and I'm sure there are others that want to know the same thing, can you explain *in a technical manner* how the toolchain could be any "cleaner"? A simple example will document this clearly. Take building LFS on a Fedora core release. In the past, we had issues with our chapter 5 glibc build picking up the presence of SE-Linux in Fedora core 3, which caused the chapter 5 glibc to also enable SE-Linux. But, once we got into chapter 6, it caused the glibc build to barf, because the headers for selinux were no longer present. This build process completely eliminates that situation. Anything that links to the host does NOT end up at all in the $LFS tree - the 2 packages which are linked to the host (cross-gcc and cross-binutils) are prefixed to the build user's home directory. Thanks for the input, Jeremy. Though I still don't understand how this relates to my question. My question is about the finished binaries. In the example you give above, it doesn't have anything to do with the finished product. It only has to do with failures *getting* to the final product. The final result of the binaries is immaterial, in this case. That issue exposed a flaw in our current build process, exposing that our host can still affect the build inside the chroot, even with the PLFS stuff that was developed for LFS 5. This is something that needs to be fixed. I realize that the process as Jim outlined eliminates problem hosts. But what about for hosts that can build without issues? The need to reboot and build from the console is an overwhelmingly big new difference. To the point that I would have to find a different build method than what Jim described. And that need only arises if you are building from a different arch from your host. For example - my current PPC machine is a terribly slow 120 Mhz 604 processor. Building current LFS 6 on that machine takes nearly a week of work to get done. What if I could build a large portion of that on my nice fast X86_64 machine? That would be a good thing. For you, the situation is different - you build strictly on x86-class machines - there would be no need for you to reboot, as was pointed out by Ryan. You could simply chroot into $LFS and continue on your way. There's a lot of plusses to this build, and very few downfalls, when you really sit down to think about it. Mentioning the need for the reboot was a good thing, but it's important to know WHY that becomes essential - because if we're building for a different arch, the binaries we create as part of the initial tools will not run on the host. If those binaries will run, there's absolutely no need to reboot. Hopefully this clarifies things. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Planning for Cross-LFS/Multi-Architecture 7.x Release
Randy McMurchy wrote: It does. But it is a far cry from the original post by Jim a few hours ago where the book will have *one* method of building, which includes rebooting into the 'tools' host. As long as there is provisions to build remotely, using a known good host, there is only positives to be gained from the new method. However, this isn't what was mentioned by Jim. I'm glad this discussion has come about. At least there is concern about building remotely out in the open. And by building remotely, this to me means being able to shell into a box and build LFS without rebooting. Oh believe me, Randy. I build remotely too (I have my server in the datacenter, plus my home server that I only have access to via SSH), and even if the default position of the book was to take the reboot method, the chroot method could easily be documented in a hints format. There wouldn't be so much deviation from the reboot method to the chroot method that documenting it as a hint wouldn't be feasible, and if it comes to that, I volunteer to write and maintain the hint. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Planning for Cross-LFS/Multi-Architecture 7.x Release
Bruce Dubbs wrote: My objection was to the comment that rebooting was mandatory. If instructions are given to give the user a choice and to explain the pros and cons, I do not object. As I mentioned, the WORST case scenario would be to provide a hints document outlining the process for using chroot when building for the same host, so that option will be guaranteed to be there. I would point out that most people think of a cross compile as changing architectures. That really only happens once. After the port to the new arctitecture, I think most would prefer to work in chroot environment. I know I certainly would. That depends on the speed of the machine. On my PPC machine, which is slow as a dog in compiling, I'd honestly prefer to get as much as possible done on my faster x86_64 machine, just to save time. BTW, I will need to do this eventually. My new box is an Intel 86_64 arctitecture so I will want to build it as a 64 bit system. I'm in the same boat. I got an X86_64-class machine 3 weeks ago, and so far, I've been living with the Gentoo x86_64 system on it. Since I knew it would probably at least be a month or more before the new build method is worked out, I've started trying to extract x86_64-specific build commands from Ryan's cross-lfs scripts. Once I've got them extracted, I'll put them up as an interim thing so that the people with this arch, who right now really can't build LFS because of the oddness of that arch, will be able to get something. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Planning for Cross-LFS/Multi-Architecture 7.x Release
Randy McMurchy wrote: Cool! But don't make it a hint, make it part of the book. :-) Ideally, yes, it should be in the book. However, if for some reason that's unfeasable, because of limitations in the XML or whatever the case may be, then my feeling is it could be easily written up as a hint format - it'd probably only be a 2 paragraph hint, something like: If you're building for a single machine, instead of rebooting as the book suggests, skip building packages a,b,c,d, and when instructed to reboot, execute the following command instead: chroot $LFS blah blah blah. A hint should be as simple as that - eliminate any packages from the initial tools that won't be needed because of the chroot, and instead of rebooting, chroot. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Cross-build testing
Just for a heads up to the rest of the community. Since one of the goals of the new cross-lfs stuff is to make a useable 64-bit build of LFS, and since I have a AMD64 machine with LOTS of empty hard drive space, I'm working on setting up partitions with each of the major 64-bit distributions installed to serve as a test-bed for our instructions. Currently, I have Gentoo 64-bit (which I'm using as my current workstation until we get our 64-bit stuff ready and useable), CentOS 4 64-bit (RHEL clone), and Ubuntu Hoary 64-bit. Looking for other suggestions as to 64-bit capable distros to test from, so if you know of more distro's which are currently 64-bit capable, and have ISO's available for download, drop me a line! My goal with this is to ensure our new stuff works when being built from each of the currently available 64-bit distributions. J -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UID/GID
Randy McMurchy wrote: Hi all, Discussion has turned to assigning UID's and GID's to specific users and groups. Is this really necessary? I know I won't follow any prescribed method of assigning UID/GID's as I have already a system I use. Should BLFS really be in the business of assigning UID's and GID's, or should that be best left to the builder, who is building his own system? Your distro, your rules. But we say do it this way. Shouldn't we leave it up to the builder to assign his UID/GID scheme? The problem is, if the book, as it is currently written, is followed, then system users & groups will be created as non-system. To bypass that, we need to assign them a UID/GID. So, the discussion comes to what UID/GID should we assign? I have my own system of doing so as well, so what? I can easily continue my own system, so can you. But, standardizing things for the book is not a bad thing. -J- -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Cross-LFS 5.10. Glibc-2.3.5 typo?
Erik-Jan wrote:
Jim Gifford wrote:
Erik-Jan wrote:
Hi there,
In cross-LFS, chapter 5.10 Glibc-2.3.5, configure, the book says:
--host=${LFS_HOST} --build=${LFS_TARGET}
Shouldn't that be the other way around?
--host=${LFS_TARGET} --build=${LFS_HOST}
From ./configure --help:
--build=BUILD configure for building on BUILD [guessed]
--host=HOST cross-compile to build programs to run on HOST
[BUILD]
Bye
Erik-Jan
glibc is backwards compared to the rest of the packages
Ehm yes, that's my point.
If you think about it, it's correct. You're building on the HOST, so
you use --build=$LFS_HOST...but the glibc is going to run on the TARGET,
so --host=$LFS_TARGET - it follows the documented way in glibc's
configure --help.
-J-
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: UID/GID
Archaic wrote:
On Sat, Apr 23, 2005 at 08:47:36AM -0700, Jeremy Utley wrote:
The problem is, if the book, as it is currently written, is followed,
then system users & groups will be created as non-system.
But that doesn't actually matter, it is merely an historical issue that
*may* have been relevant way back when, but also may have just been the
way things were done with no real affect on anything. I'm not sure. The
only UID that should *possibly* still be assumed is 0. There is no
actual difference in system behavior between UID 99 and UID 100 unless
someone knows of a horribly broken package out there that makes such
assumptions. It should be strictly a local policy issue.
Agreed. But, my feeling is that the BLFS book, which strives on
education, should provide a "best practices" type of situation, and
IMHO, best practices would be to assign low UID/GID's to system
users/groups, and to standardize the UID/GID in the book. Those of us
who do other things can always will always be free to alter to our own
practices. Since the change is a matter of adding -g {number} to
groupadd and -u {number} to useradd, it'll be a relatively simple
change, with little effect.
I can see both sides of the argument, but, given the number of
situations where trying to standardize the users/groups can help matters
(think NFS mounting), I personally think setting up a standard for
user/group numbering would be a good thing.
-J-
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: Ready for gcc-4 & cleaning up binutils source delete or not.
Greg Schafer wrote: Jeremy Utley wrote: Greg's still focusing on strictly x86 builds The key difference is that I only publish what I can test. Think about it. Your claims of LFS "support" for other arches up until now is bogus. But the multi-arch XML approach is a good move. Then my LFS 6.0 build which is currently installed on my PowerMac must be a fluke - Jim's LFS builds on his Cobalt MIPS machines the same. The book is written for x86, this is true, and because that's by far the most common platform, that's also by far the most heavily tested platform. But, that's not to say you can't build LFS on something else, and in most cases, with minimal adjustments to the build process. I followed Greg's work for quite some time. There's flaws in there, and they've been discussed on the LFS lists previously. Huh? I can point out so many more flaws in the current LFS build it ain't funny (some are already mentioned on my project's website). Face it, the plfs stuff was never finished properly, and the worst thing is, you're still publishing the half-assed version. It's a fact. And why is that? As I remember it, you were the one who pushed for incorporating PLFS into the book - why did you do that if it wasn't finished? And instead of finishing the job, you acted like Larry McVoy with BitKeeper - you took your ball and went home. I've seen you post a few suggestions for LFS onto our lists, and they were duly considered, and accepted or rejected upon their merits, just like any other contributor to the project. You're always welcome to make more suggestions here on LFS-Dev, and we'll be happy to consider them. But, if all you're going to do is come here and flame at other members of the LFS community, then, IMHO, you don't belong on this list. Remember, that's my opinion, I am NOT speaking for anyone other than myself here. Unless you have facts to back up your claims of "flaws in there", I can only assume you're back to your bad old trolling ways. Please act your age and don't go there. The facts to back up my statement are in the LFS-Dev archives for anyone who cares to go looking for them. I'm not going to rehash that here. My build achieves its current goals perfectly on x86. When I support other arches I will adjust accordingly. My build won't work on other arches because it's not meant to. And right there is my point. LFS is becoming more than just a simple X86 build. We have LFSers building on many varied arch's - PPC, PPC64, Sparc, MIPS, ARM, X86-64 are ones that spring to mind right off the top of my head. Rather than leave these people out in the cold, we've chosen to work with them. You could do the same, if you only wanted to, but DIY-Linux, again IMHO, speaking from someone who was on your lists for quite some time, was always about what's best for you, not what's best for a community of people. That probably makes your project a little easier for you, but it also limits the people who will want to be involved. I ask everyone reading this to keep in mind that when I post to these lists, I'm posting as MYSELF, a simple LFSer, nothing else. Only Gerard or Matthew have the right to speak for the project at large. J -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SATA disks and Chapter 8. Making the LFS System Bootable
Mark A. Nicolosi wrote: I think the book should mention something like "If you're computer has SCSI disks and you don't have any IDE disks, sda would be (hd0)." But made to fit better into the paragraph. Hope that makes sense ;-) Actually, the ideal way of finding out GRUB's terminology is to use the grub command shell's find command...i.e. find /boot/kernel-2.6.11.7 It will respond with the proper terminology for that particular partition - of course, if you use a separate boot partition, you would need to do: find /kernel-2.6.11.7 instead. HTH, J -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Successful Build of Cross-LFS
john wrote: Jeremy Huntwork wrote: My intention in making this (nowhere near finished!) rendered version of the book available is so that it will answer a few questions about what cross-lfs is and aims to be, making it possible for more to get involved or interested in the book, offer comments, suggestions, etc. I successfully built a 64bit LFS system for the x86_64 from a 32bit LFS 6ish i686 system running on the AMD64. I would like to volunteer to help with this if you need a hand. Was your build pure 64-bit, or was it a bi-arch toolchain. I could see where current cross-lfs would probably work for a pure 64-bit toolchain, with some modifications, even from a 32-bit host distro, but currently there's not enough there to provide a bi-arch toolchain. I'm willing to help with x86_64 builds as well, when something is ready. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: tst-oddstacklimit.out] Error 139
Peter Ennis wrote: Anyone seen this or similar? Should I ignore and continue? Running FC4T1 host I would not recommend FC4 for a build host at current, considering it has pre-release GCC4 code included in it, which causes known compilation issues with many packages. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross-lfs question
Marcus Singleton wrote: That's what I was thinking. I'm planning on using Ubuntu 64-bit, as it's the only one that will allow me to boot up from hard disk (NForce4 problems) unless you can suggest another OS that's predominantly 64bit and has nforce4 drivers. I have Ubuntu 64-bit, Gentoo 64-bit, CentOS 64bit, FC3 64-bit and FC4-test2 all installed on my Athlon 64 at home, which uses a NForce4 based motherboard (Asus A8N-SLI Deluxe) - all work beautifully. J -- 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
Matthew Burgess wrote: Folks, I'm proposing we stop tracking/using HJL's binutils. Here's my reasons: 1) It adds host dependencies of bison and flex 2) Recent bugs with HJL (stripping libc.a) have been hard to diagnose and fix 3) FSF recently released 2.16, bringing it back up to speed with modern features we were relying on HJL for. So, does anyone think we should still stick with HJL binutils, and if so, what are the compelling reasons for doing so? Thanks, Matt. Personally, I think LFS *should* go back to FSF binutils for the default book, unless and until there's a particular need for features present only in HJL's branch. However, I also think it might be useful to make a note in the book about the HJL branch - I know for me, I didn't know about it for a long time. -J- -- 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
Randy McMurchy wrote: Bruce Dubbs wrote these words on 05/15/05 18:42 CST: Matthew Burgess wrote: As for flex, it looks like the maintainers went AWOL again :( http://sourceforge.net/projects/lex/ currently lists 30 open bugs, and 11 submitted patches yet to be applied. Maybe it would be prudent to roll back to 2.5.4a? At least that one manages to get doxygen to compile successfully! I see that there have been no updates in over two years. It seems that the most recent version that doesn't break other software is the version we should be using. BLFS does not track all the packages that use flex (or any other LFS package), so figuring out all the packages that need it and putting them in the individual packages would be a major problem for us. Well, the version in LFS might have an issue with Doxygen (which is fixed by removing an unneeded file in the source tree), but are there any other issues with the current version of Flex that affects any other BLFS (or other) package? Flex 2.5.31 with the debian fixes patch works for nearly all of BLFS. There's also some more fixes to flex that might resolve the Doxygen problems. I would say we really should stick with 2.5.31 and the patches rather than revert back to being older then every distro out there. Just my .02 J -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: /dev/mouse symlink and the udev rules file [Was 'Re: r175 - trunk' in the li
Marty _ wrote: Good answer, never investigated udev to be quite honest, just thought it was another form of devfs from the guide. To add to your note, there isnt a difference between the two, ive just got so used to slackware's /dev style I couldnt handle the entire directory tree the devfs mount produces. Short story, udev is a user-space implementation of devfs. Long story, udev is configurable by the sysadmin to an extent not available with devfs, it tries to follow the "standard" linux device naming structure where at all possible (the default udev config file we provide aids in that a little), and it's not as susceptible to race conditions that were present in devfs (but is still vulnerable to some of them). BTW, in case you didn't know, the minute you install a 2.6 kernel into a Slackware 10.x system, you're using udev without even knowing it. -J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
