Re: [lfs-dev] [blfs-dev] Andy Benton
On Wed, Aug 1, 2012 at 2:55 AM, Bruce Dubbs wrote: > With great sadness, I have to report the passing of Andy Benton. > This is really sad news. May God rest his soul in peace. -- Tushar Teredesai mailto:tus...@linuxfromscratch.org http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: coreutils instructions
On Fri, Mar 20, 2009 at 1:41 PM, Bruce Dubbs wrote: > I would really go the other way and make all the scripts start with > #!/bin/bash > and use the features of bash. When we use the lowest common denominator, we > prevent progress. If someone wants to use dash or another incomplete shell > as a > default, then they should customize the startup scripts too. Discussing whether to make bootscripts POSIX compliant or not is a discussion that we already had multiple times before with a decision to go for it. I don't think there is any need to rehash. BTW, debian devs would probably be offended if you called dash "incomplete". I think one of the debian devs had a blog on the speedup achieved by making their bootscripts use /bin/dash instead of /bin/bash. -- Tushar Teredesai mailto:tus...@linuxfromscratch.org http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Management
On Thu, Feb 12, 2009 at 4:16 PM, Randy McMurchy wrote: > > How do others handle the situation where directories are created by > a package during the package install, and then other packages install > other files in these directories? I don't consider directories when creating log files. After a package removal I use rmdir -p on the usual directories (/usr, /bin, ...) to remove all empty directories. If I need to keep a directory around even if there are no files in it, I add a dot file in that directory. -- Tushar Teredesai mailto:tus...@linuxfromscratch.org http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Sysroot based sane multilib toolchain build for LFS style builds [update]
On Wed, Dec 24, 2008 at 2:06 AM, Greg Schafer wrote: > A mainstream build method suitable for a project like LFS needs to be > simple, clean, robust and (sorry to be blunt) reasonably idiot-proof. I didn't know LFSers were idiots! Thanks. -- Tushar Teredesai mailto:tus...@linuxfromscratch.org http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: CLFS antics
On Wed, Dec 24, 2008 at 2:58 AM, Greg Schafer wrote: > I've seen some incredible stuff on the *LFS lists over the years but this > appears to be the most breathtaking act of arrogance I've ever witnessed. > > Here it is folks, living proof CLFS are competing directly against their > parent project. I'm utterly gobsmacked.. > > If the LFS project had any kind of leadership with any kind of backbone, > there'd be serious consequences for this kind of divisive behavior. > I still don't get it. Does the current LFS leadership get to decide what every project that ever "forked" from LFS can and cannot do? -- Tushar Teredesai mailto:tus...@linuxfromscratch.org http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Evolution of LFS
Hi: I am back:) For the past year or so I have been using Ubuntu Linux mainly because of lack of time. For the past month I have been updating my scripts to match the current LFS setup so that I can be a happy LFSer again. I recently received a question from a user who inquired why we did the things in LFS the way were are doing them now. That got me thinking that though not-so-old-timers like me know how LFS evolved over the years, new comers may not know about these. For example, how many folks remember that X, httpd, etc use to be part of LFS? I would like to suggest adding an appendix on "Evolution of LFS" in the book. The following is the short reply that I sent to the person. So it might be a good start on what to include in the book. A very good question:) I will propose that the details be added to the book. The initial versions of LFS were build exactly the way you mentioned. But LFS has been evolving since its initial release. The build methodology that you see now came about due to the shortcomings found in the previous versions. I will go over the changes briefly based on my memory (so it might be a bit off) but if you need detailed info, check out <http://archive.linuxfromscratch.org/lfs-museum/>. Initially, the executables that would be needed for a new LFS were built statically on the host system and then copied to the LFS partition in the appropriate locations. Then the system would be rebooted into LFS for installing the tool-chain and to install all the remaining packages (which would also overwrite the executables that were statically built on the host). The next evolution was to avoid the rebooting into LFS. So once the static executables were built in the LFS partition, instead of rebooting, chroot was used to build the base system. It was felt that installing executables in the LFS partition and then overwriting with the dynamically linked executables is "unclean". An approach suggested by MSB was used to install executables into a separate directory $LFS/static. At the same time, importance was placed on the dependencies instead of the mostly alphabetical approach in the previous versions. The above method still had occasional breakage when the glibc on the host was incompatible with the glibc that would be used for LFS. A new approach was designed by Greg Schafer and Ryan Oliver (known as Pure LFS) that introduced building a dynamically linked tool-chain in $LFS/tools. A concept known as ICA was also introduced (search the LFS lists for ICA for more info). This is essentially the current build methodology. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Fwd: LFS Script suggestion
A bug report that I received. -- Forwarded message -- From: Vic Kovacs <[EMAIL PROTECTED]> Date: Jan 28, 2007 6:20 AM Subject: LFS Script suggestion To: [EMAIL PROTECTED] Could I advocate adding a chmod to the script in http://www.linuxfromscratch.org/lfs/view/stable/prologue/hostreqs.html? My system won't run the script without it. . . cat > version-check.sh << "EOF"; chmod ugo+x version-check.sh #!/bin/bash # Simple script to list version numbers of critical development tools bash --version | head -n1 | cut -d" " -f2-4 echo -n "Binutils: "; ld --version | head -n1 | cut -d" " -f3-4 bzip2 --version 2>&1 < /dev/null | head -n1 | cut -d" " -f1,6- echo -n "Coreutils: "; chown --version | head -n1 | cut -d")" -f2 diff --version | head -n1 find --version | head -n1 gawk --version | head -n1 gcc --version | head -n1 /lib/libc.so.6 | head -n1 | cut -d" " -f1-7 grep --version | head -n1 gzip --version | head -n1 cat /proc/version | head -n1 | cut -d" " -f1-3,5-7 make --version | head -n1 patch --version | head -n1 sed --version | head -n1 tar --version | head -n1 EOF bash version-check.sh -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Autotools
On 12/7/06, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote: This is a formal request to either integrate Tushar's hint on installing multiple versions of autotools into the LFS book, or move autotools to BLFS and integrate the hint there. The rationale is that the current LFS SVN versions of autotools are incompatible with enough BLFS and BBLFS packages. E.g., popt and GRUB fail to build from source if patches are applied that require rerunning autotools. My views on the use of autotools in LFS is pretty clear, one just needs to read the introduction of the hint:) The book should include installation of multiple autotool versions. Additionally, it should be in BLFS where they can be represented with the proper dependency information when needed. For example: * popt -> Depends on autoconf-2.59 * autoconf-2.59 -> Depends on autoconf-wrapper-1.0 That way users only install it when some command in the book requires it or if they need a particular version for some development work outside the scope of the books. If somewhere down the line one of the LFS packages requires a particular version of autotools when building, it should be handled the way tcl/expect is handled in the book. Install only the required versions in /tools. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Outstanding issues for LFS-6.2
On 6/26/06, Matthew Burgess <[EMAIL PROTECTED]> wrote: Well, I'm happy to upgrade the toolchain on the understanding that this will set a 6.2 release back by at least another 6-8 weeks. It also means that all of the stabilisation work done by the BLFS team is more or less negated as they've been under the (until now) pretty safe assumption that the toolchain was pretty much set in stone. For that reason, I'd much prefer to release 6.2 a.s.a.p then have a release another 2 or 3 months down the line with an upgraded toolchain, assuming it can stabilise in that time. The LFS releases are not that frequent. The average gap between releases is 6-9 months. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Outstanding issues for LFS-6.2
The latest glibc and gcc releases are atleast 3 months old (which in terms of LFS timeline is a long time). What is the point in releasing a book that is obsolete even before it is published? I would vote for updating the book to glibc-2.4.x and gcc-4.1.x and then stablize that before releasing the next version. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Shell script to rebuild info files
On 6/20/06, Dan Nicholson <[EMAIL PROTECTED]> wrote: What do you guys think? I'm not closely attached to any details in the script. It's just what seemed reasonable to me. Just add a "cat ... EOF" to the commands that are in the current texinfo page. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: PROPOSAL -- new group to handle multi-project tasks
On 5/30/06, Gerard Beekmans <[EMAIL PROTECTED]> wrote: I believe the idea is actually a good one. If you look at the bigger picture, such a unbiased group can take on other tasks too down the road. In short, the current hierachy with you and Matt at the top to arbirtrate is insufficient because of politics. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bootscripts - Why combining is a bad thing
On 5/30/06, Randy McMurchy <[EMAIL PROTECTED]> wrote: How does LFS update their finished, released, perhaps in print, book to reflect that a new tarball is needed? One solution is to have all projects go into a release freeze at the same time (perhaps after branching) and then all projects make a simaltaneous release. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Separate book?
On 5/29/06, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote: The problem is not "how" (which is already dealt with), but "why". I.e., one could say that some sysfs attributes for SCSI devices are created after the uevent is sent. That's why we have the WAIT_FOR_SYSFS rule that waits for "ioerr_cnt". But it will be certainly better to show where exactly this takes place (i.e., the scsi_sysfs_add_sdev() function from drivers/scsi/scsi_sysfs.c). This function, in its very end, creates all sysfs attributes listed in the scsi_sysfs_sdev_attrs[] array. Upon examining the contents of that array, it is clearly seen that the "ioerr_cnt" is really the last attribute created. (IMO) LFS is for building a Linux system (distribution) not a Linux Kernel Internals Developers Guide. The information that you mention above is more suibtable in a "Udev Developers Guide". Most of the information that was mentioned at the start of the thread falls in the same category. Now don't get me wrong, I would personally be interested in that information, but it is not suitable for the LFS book. As Matt mentioned those would be suitable to be sent upstream or online magazines. We install glibc and configure the linker cache. We also mention that /lib and /usr/lib are automatically added to the linker path. But we don't point to the part of the code which does that since that is not relevant for us as system builders. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: OFFICIAL PROPOSAL.
On 5/29/06, Randy McMurchy <[EMAIL PROTECTED]> wrote: By my count there are 5 that indicated contrary. Most of those said to leave things they way they are. In fact, I believe (I'm not going back to check, so I could be wrong), all 5 are editors in the project as well. Including the project co-lead. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bootscripts merge? (Was: Summarize of Plan and changes)
On 5/28/06, Ag Hatzimanikas <[EMAIL PROTECTED]> wrote: Then let the CLFS team to contribute to the BLFS BOOK. One chapter with 6-8 pages I think there will be enough for the start. They can. That is why the wiki was created and links were added to the book for each individual package. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bootscripts merge? (Was: Summarize of Plan and changes)
On 5/28/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: Because udev is a new and somewhat complex technology and although the LFS editors (yourself and Archaic, at least) have made a good stab at understanding the process fully, it seems to me that none of the current editors have the time available to give udev what it really requires in order to understand it at the level we need. A separate project just for udev, led by Alexander, would likely give all of us just that. IMO, a better solution (rather than adding a new team to the mix) is to invite folks who undestand the complexities to be editors. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: OFFICIAL PROPOSAL.
On 5/28/06, Randy McMurchy <[EMAIL PROTECTED]> wrote: If only to solve a political disagreement, sort of like an arbitrator, then great, but the only disagreement I see is there are two factions that want "their" set of rules used. I don't see a need to form a team to create a third set of rules and *many other things* thrown in. If this team was to act as an arbitrator, and settle the Udev rules issue, then as I mentioned, great. But bestowing more responsibility beyond that, for things that are perfectly fine as they are, clouds the meaning to me. Well said. Why not have the new team create a common set of rules? After that the team would which part belongs to LFS, which belongs to CLFS and which to BLFS and then add those to the appropriate books and let the respective books maintain it from then on. Changes needed after that would then go thru the normal discussion route. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bootscripts merge? (Was: Summarize of Plan and changes)
On 5/26/06, Jim Gifford <[EMAIL PROTECTED]> wrote: > So what your saying is nothing should change, LFS and CLFS should have their own rules and bootscripts. No there should not be any duplication. LFS would have the base udev rules and bootscripts. CLFS, HLFS and BLFS would add to it with their unique modifications. The approach has worked nicely for the bootscripts, the same would work for udev rules. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bootscripts merge? (Was: Summarize of Plan and changes)
On 5/26/06, DJ Lucas <[EMAIL PROTECTED]> wrote: I am fine with merging the bootscripts if the community wants it. That is conditional on the ability to create an auto generated tarball (not a big deal). Also, the editors must have access to their respective directories under the bootscripts repo (same as the requirements for udev). Again, IIRC, it was not a big deal to make the post commit hook on the BLFS book's changed tarball date. I haven't seen the existing one, but an anonymous co and export (don't go mucking around in the repo directly) on belgarath each time the bootscripts date changes seems it'd work well. Syncing them between the books for a single tarball is where it would be difficult. Actually, even that shouldn't be bad. Only generate the tarball if it's not already there. I'm not sure, off the top of my head, how to handle changing the bootscripts date in the other two books. Now, when this was mentioned to me previously, I did not know that this included BLFS's scripts. This can present a problem for release cycle, unless we can be *very* sure that BLFS will not need to add another bootscript after LFS reaches release. Generating the official book tarball can be added to the LFS release checklist to minimize this possibility. The same goes for CLFS scripts, though they'll change less frequently. The scripts for CLFS are lfs-bootscripts + CLFS additions for additional hardware. As it is right now, changes that go into LFS must be duplicated in CLFS's repo, or a patchset kept current (and potentially the reverse). To me, that merge is a no-brainer. "Those who ignore history are bound to repeat it". Once upon a time LFS and BLFS bootscripts used to be part of the same package. They were split up for the reasons mentioned above. Unless LFS and dependent projects commit to coordinate their release cycles, having a common tarball for anything (and that includes udev rules) will be a problem. IMO, the best solution is the one suggested by Matt. LFS should contain the udev rules and bootscripts for LFS. All dependent projects should work off that base and release their own additions (or deletions in form of patches) - similar to how the bootscripts are currently handled. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Fwd: machine donation
Hi Guys: Jaap has a DEC Alpha 7305 for someone who is interested. Please see his message below and if interested contact him directly. Here is a link to HP's spec sheet <http://h18002.www1.hp.com/alphaserver/archive/7300/>. Have fun. Tushar. -- Forwarded message -- From: Jaap Struyk <[EMAIL PROTECTED]> Date: May 25, 2006 7:02 AM Subject: machine donation To: Tushar Teredesai <[EMAIL PROTECTED]> Hello Tushar, Sorry to mail to you directly but I'm not subscribed to any of the lfs lists anymore but maybe I have something of the teams interrest. I can get an DEC Alpha 7305 for free, if I don't take it it will be trown away, maybe someone in the lfs team wants it? Only problem is the transport, it weights 120kg. and has the size of a small fridge so shipping it isn't an option. Maybe you are willing to ask around? (or post it in the devel list, if someone is interested they can contact me at [EMAIL PROTECTED]) -- Groetjes Japie http://www.japie.deserver.nl -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Unifying the Udev Rules Packages
On 5/24/06, Randy McMurchy <[EMAIL PROTECTED]> wrote: Jim Gifford wrote these words on 05/24/06 00:19 CST: > Just let us know who you want to have full access, and those he only > need access to branches/lfs or branches/clfs. I can work offline with > you on this. Jim, you sure went to a lot of work without even getting approval from the Project Leaders. Best I can tell, neither the LFS nor BLFS project leaders have approved the plan, much less like it. Isn't that what cross-lfs is supposed to be;-) Cross == tangent. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Unifying the Udev Rules Packages
On 5/23/06, Matthew Burgess <[EMAIL PROTECTED]> wrote: I still think, from an organisational perspective, the rules belong in the LFS repository and that CLFS should add to those rules, either like BLFS does via 'cat'ting to additional files, or by providing additional rules files. +1. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Unifying the Udev Rules Packages - My final post on this matter
On 5/23/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: Jim Gifford wrote: > The bottom line is if it's Alex or Dan, it needs it's own repo. With > branches for LFS and CLFS, so if we make some changes, then Alex or Dan > can merge the changes in. > > On similar note I talked to DJ about this also, a separate repo for > bootscripts, with the same requirements will also need to be setup. I've never quite understood why BLFS and LFS kept their bootscripts separate. They could all be in one package with one Makefile that could handle every target. They used to be shared at the begining. Check the archives couple of years back on why they were separated. AFAIR, something to do with having to release a new version just for BLFS changes. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: libXvMCW
On 5/23/06, Randy McMurchy <[EMAIL PROTECTED]> wrote: Anyway, if it means I have to install XFree into a dummy directory just to get a log of the files installed, I'll spend the 25 minutes and do it every time there is a new release (every couple of years) if that's what it takes to keep it in the book. :-) It is not just about getting a list of installed files. Dependent packages should also compile and run when XFree86 is used. If there number of folks who will be prefer XFree86 over Xorg is minuscule, there is no point in having XFree86 in the book and it is better of as a hint maintained by someone who is *using* XFree86. From what I have read, none of the editors are using XFree86. Personally I would prefer having Xorg 7.1 in the book with individual pacakges and complete dependency information. I am nearing the end of my Xorg installation. Once I am past that I will start adding the information to the wiki. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers
On 3/8/06, Greg Schafer <[EMAIL PROTECTED]> wrote: > > Grrr, Gentoo is a convoluted mess.. That's why we have LFS:-) BTW, if you need some rudimentary scripts to make navigating thru the files easier, check out distro-tools at <http://linuxfromscratch.org/~tushar/downloads/>. I have an updated version on my workstation but it is inaccessible right now since I am in the middle of a "house move". -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers
On 3/8/06, Greg Schafer <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote: > > > Gentoo is using a script similar to the above script to sanitize the > > headers. > > Do you have a pointer? Thanks. > The kernel-2.eclass file at <http://www.gentoo.org/cgi-bin/viewcvs.cgi/eclass/?hideattic=1> has the gory details on how gentoo creates the headers. It has lot of extra functions since the same elcass is also used for kernel compilation. For details on how they use the functions from the elcass, refer to one of the build files in <http://www.gentoo.org/cgi-bin/viewcvs.cgi/sys-kernel/linux-headers/?hideattic=1>. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers
On 3/7/06, Jim Gifford <[EMAIL PROTECTED]> wrote: > A lot of you may have noticed the LLH kernel headers have not been > updated as promised. With that in mind, I decided to do some tests over > the past few days building LFS and CLFS with raw kernel headers. > Unfortunately the raw kernel headers are not enough, but with minor > modifications, they do work perfectly. I have tested 6 builds on 3 > different platforms, x86, Sparc, and MIPS. With no issues at all. I > created a small bash script that will create the headers. This script is > available at http://ftp.jg555.com/headers/headers. I like the idea of using raw (but sanitized) kernel headers. Gentoo is using a script similar to the above script to sanitize the headers. +1 for this. BTW, instead of writing to /tmp/new_header file, the script should probably write to $header.orig. The file in /tmp may exist and may not be owned by the user running the script. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [LFS Trac] #684: Must re-evaluate package order then document the rationale.
On 3/3/06, Dan Nicholson <[EMAIL PROTECTED]> wrote: > Nah, probably not for the book. In general, I don't mind adding stuff > to /tools. After getting bent over by gcc and glibc for multiple > hours, I don't see the harm in tossing one more tiny package on the > heap. But, in this case, I think a note should suffice. +1. For the book a note is sufficient. Though in my builds I do build autotools during Ch 5 just so that I don't have to modify my scripts if a patch comes up in the future that requires running the autotools. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: `backticks` or $(command) syntax
On 2/28/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
>
> Does anybody know right offhand if $(command) syntax is a bash-only
> thing?
>
I think it is bash only. Definitely not compatible with sh. On the
system at work:
$ uname -a
OSF1 server V5.1 2650 alpha
$ /bin/sh -c 'echo $(ls)'
/bin/sh: syntax error at line 1: `(' unexpected
--
Tushar Teredesai
mailto:[EMAIL PROTECTED]
http://www.linuxfromscratch.org/~tushar/
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: r7392 - in trunk/BOOK: . chapter01 chapter03
On 2/23/06, Tushar Teredesai <[EMAIL PROTECTED]> wrote: > On 2/23/06, Greg Schafer <[EMAIL PROTECTED]> wrote: > > Sigh.. even tho' jhalfs provides the facility to prevent this kind of > > damage, LFS unstable is still living up to its name :-( > > Isn't that the point of having a revision control system and an unstable > branch? > s/point of/reason for/ -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: r7392 - in trunk/BOOK: . chapter01 chapter03
On 2/23/06, Greg Schafer <[EMAIL PROTECTED]> wrote: > Sigh.. even tho' jhalfs provides the facility to prevent this kind of > damage, LFS unstable is still living up to its name :-( Isn't that the point of having a revision control system and an unstable branch? -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UTF8 nitpicks
On 1/9/06, Tushar Teredesai <[EMAIL PROTECTED]> wrote: > Some nitpicks related to the UTF-8 patch: > * /usr/bin/zsoelim from groff is overwritten by man-db (three cheers > for pkg-user hint:). > * Mention that users can choose the man package instead of man-db > (with a pointer to the man home-page/freshmeat-page). > * Mention that folks can choose gdbm instead of berkeley db with a > pointer to BLFS's gdbm page. > * The man-db page details on the two approaches to UTF8 - Redhat and > Debian. There should be an explaination on why the Redhat approach was > not considered for the book. Can someone fix this, especially the first point. The first one is easy, just remove the line "ln -sv soelim /usr/bin/zsoelim" from groff's page. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Alphabetical UTF-8 Build is ICA Verified
On 1/27/06, Ken Moffat <[EMAIL PROTECTED]> wrote: > > I guess clfs doesn't have this problem because it is using a newer > snapshot of glibc. Does that seem reasonable ? Greg once posted a reference to an upstream bug report. But I don't know whether it is fixed or not. One way to find out is build lfs with the snapshot:) -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Alphabetical UTF-8 Build is ICA Verified
On 1/27/06, Ken Moffat <[EMAIL PROTECTED]> wrote: > My script makes no explicit calls to ldconfig. > > Maybe one of the package does this. Try this to verify that it is indeed a problem with ldconfig. Compile readline as follows: ./configure --prefix=/tmp/readline make make install make install ls -l /tmp/readline/lib ldconfig -n /tmp/readline/lib ls -l /tmp/readline/lib -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Alphabetical UTF-8 Build is ICA Verified
On 1/27/06, Ken Moffat <[EMAIL PROTECTED]> wrote: > > On the non-alphabetic book, with utf8, I never managed to track down > why updating readline in place was leaving the symlinks pointing to > .old. FWIW clfs (ppc) was ok for that, so it must have been a problem > specific to the non-alphabetic build (and the clfs patches for readline > and bash didn't fix it). It may not have anything to do with readline at all. IMO, it is the same ldconfig bug that creates /usr/lib/libncurses.so.5 <http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2005-August/052567.html>. Do you have a ldconfig anywhere in your build script? If so replace it by ldconfig -X and retry. It *should* fix the incorrect symlink. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: r7306 - in trunk/BOOK: chapter01 chapter05 chapter06
On 1/26/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote: > > > > The dynamic linker path comes from gcc's specs file. You will need to > > edit that or add --dynamic-linker=/lib/ld-linux.so.2 to the above > > flags. > > It was still edited. That part never changed. Strange. I tried it the last time this topic came up. I was exactly at that point of my build when the discussion was on and hence tried lot of different things. The only thing different in my setup is I don't have /tools/, don't know if that affect the result. > > I never used the startfile_prefix before so I have no idea how it > > affects the build. Though I remember Greg saying long time back it was > > not recommended by upstream developers. > > That's a bit of a surprise. It's in the stable book, and LFS has been > using for quite a while now. > I didn't trust the startfile_prefix thing, hence the last time I built it, I used the toolchain instructions from DIY. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: r7306 - in trunk/BOOK: chapter01 chapter05 chapter06
On 1/26/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote: > > Why build something if you don't need to. ld --nostdlib -L/usr/lib > > -L/lib works? It is not an undocumented switch. > > No, not exactly. At least not from my tests. The -Wl,--verbose output > shows that it's still finding the ld-linux.so.2 in /tools, unless you > use the static ld, prepared to use /lib:/usr/lib The dynamic linker path comes from gcc's specs file. You will need to edit that or add --dynamic-linker=/lib/ld-linux.so.2 to the above flags. > > > The main purpose of the bug was that /tools should not be modified in > > any way once you are in chroot. > > Well, it is suggested now that a user tar up /tools and put it away at > the beginning of chapter 6, before any other edits are made to it. No, > it's not perfect, but it works. :) In that case there was no need to go thru all the changes. Just moving the text would have been enough. > I have no proof of the difference a wrapper makes or doesn't make. On > the other hand, Ryan is adament on the point that -B is not intended to > be used for finding libraries in general. This is especially the case > with multilib. Granted, LFS is not multilib, and with the arrival of > Cross-LFS, probably never will be. But, if we use the > *startfile_prefix_spec setting, as we did previously, we are more in > harmony with cross-lfs and the end result is the same. Also, it's one > setting in a sed and we don't need to be bothered with setting -L or -B > anywhere. I never used the startfile_prefix before so I have no idea how it affects the build. Though I remember Greg saying long time back it was not recommended by upstream developers. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: r7306 - in trunk/BOOK: chapter01 chapter05 chapter06
On 1/26/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > > 1) Do as DIY does and make a ld-new in chapter 5 binutils Why build something if you don't need to. ld --nostdlib -L/usr/lib -L/lib works? It is not an undocumented switch. > 3) Drop the wrapper script for gcc and instead of linking ld-new to > /usr/bin/ld (which relies on gcc finding the proper path) we move the > old ld out of the way and put the new static ld in its place. We also > create a hard link to /tools/bin/ld from /tools/$MACHTYPE/bin/ld The main purpose of the bug was that /tools should not be modified in any way once you are in chroot. I still don't understand the problem with using wrappers. They are an elegant way of executing the compiler and linker with the switches that we want. I don't agree with the "They are evil" statement. Yes, if it is overused, it can cause problems. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: r7306 - in trunk/BOOK: chapter01 chapter05 chapter06
On 1/26/06, Dan Nicholson <[EMAIL PROTECTED]> wrote: > How is the adjusted binutils being found? Is an adjusted binutils > being installed? If you're doing the DIY static ld to > /tools/bin/ld-new with symlink /usr/bin/ld -> /tools/bin/ld-new, then > it will not be used unless you have -B/usr/bin/. Correct. Sorry I missed that when I posted. It was in my wrapper script and is also in DIY. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: r7306 - in trunk/BOOK: chapter01 chapter05 chapter06
On 1/25/06, Greg Schafer <[EMAIL PROTECTED]> wrote: > Temporary wrapper scripts? Hmmm, these are interesting changes to say the > least. They look completely bogus. You actually tested this stuff before > committing? Where is the enhanced sanity check needed to verify this > crucial stage of the build method? > The wrapper scripts are doing the same thing you have in DIY. I don't know why you would call it bogus without testing? I did test out those changes during my last build around the same time I proposed them. I found the wrapper scripts useful when I was trying out different things with the toolchain to see how they the compiler and linker interact/affect with each other when some flags are changed. Also it allowed me to keep the /tools untouched in chroot phase. It also saved rebuilding ld with a LIB_PATH of /usr/lib:/lib. All win-win IMO. Though, I had assumed that the editors would have tested it out before putting it in the book. But as Jermey said, he thought all that had already been done. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UTF-8
On 1/20/06, Chris Staub <[EMAIL PROTECTED]> wrote: > > I don't think anyone is debating that they aren't being forced to use > UTF-8 locales. However, the issue is that if you never do use a UTF-8 > locale, then the UTF-8 code just sits there unnecessarily taking up > space. It isn't a question of whether it "works" - I *know* that > non-UTF-8 locales will work fine with UTF-8-enable LFS - it's that if > the extra disk space and memory being taking up is not needed, then it > shouldn't be there. Except for the bdb package (which most users may install down the line anyways), there is no extra space and memory being taken up. The various language man-pages and various locales are already being installed, the disk space is already taken up. Just check out the /usr/share/locale and /usr/share/man directories. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UTF-8
On 1/20/06, Jim Gifford <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote: > > On 1/20/06, Jim Gifford <[EMAIL PROTECTED]> wrote: > > > >> This discussion needs to happen on both lfs-dev and cross-lfs, everyone > >> in lfs-dev seems to want it, but people in cross-lfs don't need it. > >> That's why I started the thread on both lists. > >> > > > > Why the division? I thought cross-lfs was just a way of building LFS > > from arch X to arch Y but in all other respects it would be similar to > > LFS. The end result of the two books should not be different (unless > > it is absolutely warranted e.g. bootloaders). If I am build LFS and > > cross LFS with target architecture of x86, the installation should be > > identical. > > > > > That's the question. Why is there a division between the two different > communities, we got LFS that really wants it bad, and Cross-LFS where > they don't see a need for it. That's what I've been trying to figure out. > > My feelings are I'm willing to try utf-8, but I don't think it's > completely ready yet. I have an issue with Man-db and adding Berkeley > DB(I just hate the constant ABI changes). I also see a problem with the > new groff depending on netpbm (Alex did find a way around that.) > The point I am trying to make is that all *LFS folks are part of the same group. If some folks did not like UTF-8 compatibility (note that LFS did not move to UTF8 like Redhat but just because more usable by folks irrespective of which language they wanted their LFS installation to speak) they should have spoken when the discussions were active on lfs-dev. (Actualy, folks who don't like the change can still start a discussion on lfs-dev on removing UTF8 compatibility:) There was also a big discussion on lfs-dev w.r.t. choosing bdb/gdbm. I was for using gdbm instead of bdb and I spoke my mind at that time. Even if *all* BLFS editors wanted gdbm instead of bdb, BLFS still cannot choose to ignore the fact that bdb is in LFS and have to modify BLFS according to the change. Regarding UTF8 not being ready, it is still better than no UTF8 compatbility at all. And as the packages get better, so will the compatbility. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UTF-8
On 1/20/06, Jim Gifford <[EMAIL PROTECTED]> wrote: > This discussion needs to happen on both lfs-dev and cross-lfs, everyone > in lfs-dev seems to want it, but people in cross-lfs don't need it. > That's why I started the thread on both lists. Why the division? I thought cross-lfs was just a way of building LFS from arch X to arch Y but in all other respects it would be similar to LFS. The end result of the two books should not be different (unless it is absolutely warranted e.g. bootloaders). If I am build LFS and cross LFS with target architecture of x86, the installation should be identical. What if gcc-5 is released tomorrow and LFS upgrades to it but BLFS says - "We are a different project and no one on blfs-dev wants to upgrade to the new release so BLFS will just stick with gcc-4." The situation you are mentioning is quite similar. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Mozilla NSPR/NSS
On 1/19/06, Randy McMurchy <[EMAIL PROTECTED]> wrote: > > Recently we had a discussion about using the Mozilla NSPR/NSS package > as a stand-alone package for BLFS. This would allow Firefox, Thunderbird > and the Mozilla suite to share the system-installed copies of these > libraries and interface headers, as well as having them installed in > /usr for any other package (Evolution, Epiphany, etc) that may also > utilize them. > > It is now doable. /me scratches one thing off my to do list. Thanks:) -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: popt's debian patch
On 1/18/06, Randy McMurchy <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote these words on 01/18/06 01:45 CST: > > > Like Jermey said, you are expected to click on a link before commenting ;-) > > No, folks are expected to provide links to the actual thing, and > not just a tease. Keep in mind, you are trying to convince us to > change; making one do some research, typically isn't the best plan. > Providing some convincing text goes a lng way... Why should version upgrades need convincing? So if gcc-5.0 is released do you want a link to the tarball to really know that a new version has been released?! > > The library soname has not changed so I don't think there are any > > changes to the interface. > > Yeah, right. > > C'mon Tushar, provide something concrete. Saying you don't think > that the API/ABI hasn't changed because the soname didn't change > it purely just well... > > bullsh*t... I said *think* i.e. it is a judgement call based on my past experience. After all that is why sonames were created so that if there are any incompatibilities the developer could increment the soname without causing problems. Please don't argue for the sake of arguing. I am not suggesting some major change to the book, just a simple version upgrade. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: RFC: Implementing Trac [long]
On 1/18/06, Randy McMurchy <[EMAIL PROTECTED]> wrote: > > What bothers me the most now, and what everyone should consider, is > that the guy that is pushing this whole deal said earlier this > evening that he would like to start tomorrow with the conversion to > put this crap in production... I have only been skimming this thread but I *think* he is planning to upgrade subversion tomorrow, not move over everything to trac tomorrow. Also I believe he said if we run into problems with trac, we can hit the panic button and come back to where we are right now. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: ICA on LFS-svn
On 1/16/06, Ken Moffat <[EMAIL PROTECTED]> wrote: > > I was wrong in retracting, my LFS-svn results definitely show this for > all builds after the first. I can't yet see why the symlink is moving > (and I've spent twenty minutes looking at readline's shlib/Makefile and > support/shlib-install). Looks like an ldconfig issue: I tried the installation with --prefix=/tmp/readline. Here are the results. $ ls -l /tmp/readline/lib/ -rw-r--r-- 1 readline readline 91246 Jan 18 00:10 libhistory.a -rw-r--r-- 1 readline readline 91246 Jan 18 00:10 libhistory.old lrwxrwxrwx 1 readline readline 15 Jan 18 00:10 libhistory.so -> libhistory.so.5 lrwxrwxrwx 1 readline readline 17 Jan 18 00:10 libhistory.so.5 -> libhistory.so.5.1 -rw-r--r-- 1 readline readline 71340 Jan 18 00:10 libhistory.so.5.1 -rw-r--r-- 1 readline readline 71340 Jan 18 00:10 libhistory.so.5.1.old -rw-r--r-- 1 readline readline 618068 Jan 18 00:10 libreadline.a -rw-r--r-- 1 readline readline 618068 Jan 18 00:10 libreadline.old lrwxrwxrwx 1 readline readline 16 Jan 18 00:10 libreadline.so -> libreadline.so.5 lrwxrwxrwx 1 readline readline 18 Jan 18 00:10 libreadline.so.5 -> libreadline.so.5.1 -rw-r--r-- 1 readline readline 446391 Jan 18 00:10 libreadline.so.5.1 -rw-r--r-- 1 readline readline 446391 Jan 18 00:10 libreadline.so.5.1.old $ ldconfig -n /tmp/readline/lib/ $ ls -l /tmp/readline/lib/ -rw-r--r-- 1 readline readline 91246 Jan 18 00:10 libhistory.a -rw-r--r-- 1 readline readline 91246 Jan 18 00:10 libhistory.old lrwxrwxrwx 1 readline readline 15 Jan 18 00:10 libhistory.so -> libhistory.so.5 lrwxrwxrwx 1 readline readline 21 Jan 18 00:11 libhistory.so.5 -> libhistory.so.5.1.old -rw-r--r-- 1 readline readline 71340 Jan 18 00:10 libhistory.so.5.1 -rw-r--r-- 1 readline readline 71340 Jan 18 00:10 libhistory.so.5.1.old -rw-r--r-- 1 readline readline 618068 Jan 18 00:10 libreadline.a -rw-r--r-- 1 readline readline 618068 Jan 18 00:10 libreadline.old lrwxrwxrwx 1 readline readline 16 Jan 18 00:10 libreadline.so -> libreadline.so.5 lrwxrwxrwx 1 readline readline 22 Jan 18 00:11 libreadline.so.5 -> libreadline.so.5.1.old -rw-r--r-- 1 readline readline 446391 Jan 18 00:10 libreadline.so.5.1 -rw-r--r-- 1 readline readline 446391 Jan 18 00:10 libreadline.so.5.1.old Notice the change. Time for someone to submit a bug report to the glibc folks. IMO, the book should recommend that folks not run plain old ldconfig but use ldconfig -X so that links are not modified. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: ICA on LFS-svn
On 1/16/06, Ken Moffat <[EMAIL PROTECTED]> wrote: > libhistory.so.5 (symlink, points to .old after in-place rebuild) > libreadline.so.5 (ditto) Shouldn't the link point to the .so.5 library? I don't remember seeing that problem even when I used to upgrade in-place (I have been using the fakeroot approach for quite sometime so I don't know if this is a recent thing). -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Man-DB
On 1/15/06, Jim Gifford <[EMAIL PROTECTED]> wrote: > > 1 - Fedora - Man-db is no longer being maintained is not needed. > 2 - Debian - Simple to use that's why we do > 3 - Gentoo - Don't need it, don't waste your time. How does gentoo handle utf-8 man pages? > Found this page for man-db http://www.nongnu.org/man-db/. Followed the > link to a savannah page, noticed there has been no development on this > project since 11-2003. There may not be a release but the last cvs update was 5 weeks back. > Just an idea, couldn't we implimit man, with something like the bash > script from > http://www.eglug.org/node/1759 Unfortunately it does not support the wonderful man features such as MAN_PATH and automatic MAN_PATH based on PATH. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: A bit of -dev humor
On 1/12/06, Randy McMurchy <[EMAIL PROTECTED]> wrote: > Okay, so I'm a bit overzealous creating documentation. However, does > this borderline obsession? Depends on whether you actually read the documentation ;-) -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
RFE: linux kernel documentation
Since we already install additional documentation for other packages, it would be nice to also install the documentation included with the kernel: install -d /usr/share/doc/linux-2.6.15 && cp -r Documentation/* /usr/share/doc/linux-2.6.15 What say the group? -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: zlib patch
On 1/9/06, Dan Nicholson <[EMAIL PROTECTED]> wrote: > On 1/9/06, Tushar Teredesai <[EMAIL PROTECTED]> wrote: > > > > Building seperate shared and static object files is how most of the > > builds are performed. Forgetting to perform a make clean after > > builiding the shared lib can cause unwanted results. Gentoo's patch > > just brings zlib into compliance with the other packages out there:) > > I agree that I'd like that it built like a standard package, but I > think this would set a precedent in LFS to make patches that perform > major surgery on the build system. There already is:) Check out the bzip2 patch to install additional documentation. -- -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: PCRE
On 1/10/06, Jeremy Herbison <[EMAIL PROTECTED]> wrote: > > I understand that Readline was added to LFS because: > 1) Bash can use it vs. its bundled readline functions. > 2) Lots of BLFS packages can link to it. Readline was added mainly for reason 1. Rather than link in the internal readline statically, it made sense to use a system installed one and link to it dynamically to get the benefits of a shared library. > > I believe PCRE should be added to LFS because: > 1) Grep can use it vs. its bundled regex functions. > 2) Lots of BLFS packages can link to it. > > I, and I'm guessing many others, build PCRE right before Grep in > chapter 6. It doesn't seem to depend on anything else, it's UTF8 > compatible with current BLFS instructions, and seems fairly > trivial to add. Its also one of those essential libraries pretty > much everyone is going to install later anyhow. Just a thought. The executable pcregrep installed by pcre performs the same function that grep linked against pcre. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Dependencies LFS-BLFS (was Re: UTF8 nitpicks)
On 1/10/06, Dan Nicholson <[EMAIL PROTECTED]> wrote: > > Some policy would have to be made to prevent > packages like coreutils and gawk that would show up everywhere. Just > a thought. I guess BDB is the main one that bugs me. Ditto. For me, in the current LFS book, I would prefer BLFS mention dependencies to zlib, readline, db and perl. -- -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Static e2fsck
On 1/10/06, Dan Nicholson <[EMAIL PROTECTED]> wrote: > > Comments? > http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2002-January/022604.html :-) -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UTF8 nitpicks
On 1/9/06, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote: > > Some nitpicks related to the UTF-8 patch: > > * /usr/bin/zsoelim from groff is overwritten by man-db (three cheers > > for pkg-user hint:). > > Thanks for pointing out that the problem exists. What's your proposed > solution? Sed out installation of zsoelim from Groff Makefile? It is not part of groff, we make a symlink from zsoelim -> zsoelim. Probably the best thing to do would be to disable the symlink, but only if zsoelim from man-db is preferable to the soelim from groff. > > > * The man-db page details on the two approaches to UTF8 - Redhat and > > Debian. There should be an explaination on why the Redhat approach was > > not considered for the book. > > Let's discuss this. The explanation below is true, but unsuitable for > the book. Please reword. > > The RedHat approach has not been considered because: > > 1) RedHat doesn't have a bug-free implementation of their approach > (their Groff inserts spaces into the wrong place, e.g. after the first > letter of a word, as if there's some off-by-one error) > 2) RedHat approach means that manual pages can no longer be converted to > PostScript using a command as simple as "groff -Tps -mandoc >manpage.ps" > 3) RedHat approach doesn't work at all with non-UTF-8 locales > 4) RedHat approach would make BLFS adapt instructions for every package > that installs non-English manual pages, in order to convert them to UTF-8. Thanks for the details. I think a section in the introduction chapter regarding UTF8 sounds better for this info. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UTF8 nitpicks
On 1/9/06, Joel Miller <[EMAIL PROTECTED]> wrote: > > > > Additionally, IIRC, BLFS is no longer going to list BDB as a dependence > (i.e. they assume it will be installed). Thusly, it is not a good idea > to give the user the choice not to install it. Alas, and one more dependency information gone from the book forever:( -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UTF8 nitpicks
On 1/9/06, Randy McMurchy <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote these words on 01/09/06 12:19 CST: > > > * Mention that users can choose the man package instead of man-db > > (with a pointer to the man home-page/freshmeat-page). > > I can see this. But BDB still has to stay. See below. > > > > * Mention that folks can choose gdbm instead of berkeley db with a > > pointer to BLFS's gdbm page. > > The arpd daemon is already back in LFS. Dumping BDB means that the > IPRoute package installation would break. > Probably a note to add sed it out if bdb is not installed? -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Xorg 7.0
On 1/9/06, Andrew Benton <[EMAIL PROTECTED]> wrote: > Why is X installed into /usr/X11R6? It only makes sense to install > packages into their own folder to make it easy to remove them, but X is > such a fundamental application, doesn't it make more sense to install it > into /usr? Agreed, it should either be /usr (my preference) or /usr/X11R7 (the appropriate version). -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: zlib patch
On 1/9/06, Dan Nicholson <[EMAIL PROTECTED]> wrote: > > Tushar, I like what's in the patch, but I'm not a big fan of adding a > patch to drastically alter the build system. Building seperate shared and static object files is how most of the builds are performed. Forgetting to perform a make clean after builiding the shared lib can cause unwanted results. Gentoo's patch just brings zlib into compliance with the other packages out there:) -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
UTF8 nitpicks
Some nitpicks related to the UTF-8 patch: * /usr/bin/zsoelim from groff is overwritten by man-db (three cheers for pkg-user hint:). * Mention that users can choose the man package instead of man-db (with a pointer to the man home-page/freshmeat-page). * Mention that folks can choose gdbm instead of berkeley db with a pointer to BLFS's gdbm page. * The man-db page details on the two approaches to UTF8 - Redhat and Debian. There should be an explaination on why the Redhat approach was not considered for the book. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Xorg 7.0
On 1/9/06, Bruce Dubbs <[EMAIL PROTECTED]> wrote: > > xorg-modular has become the single most complicated package in blfs. I > just sent an email to the xorg-modular mailing list to see what plans > they may have for simplifying the build. The issue is not, of course, > CMMI, but the number of packages. At a minimum, they need to combine > packages like the aggregation used in KDE. > I hope they don't create meta-packages. Having indivudual packages is nice for upgrades. A big win when the next point release comes out and only 10 % of the 200 packages need recompiling. I wish KDE would break up the meta packages (actually Gentoo has already done it for them). Gentoo is moving from monolithic KDE to modular KDE:) -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: 2.6.15 Hotplugging/Coldplugging via udev
On 1/5/06, Ryan Oliver <[EMAIL PROTECTED]> wrote: > On Thu, 2006-01-05 at 18:20 -0700, Archaic wrote: > > People reading this list are expected to be > > interested in development otherwise there is no reason to read it. > > For base development of the book I agree. > > For banging on bleeding edge / proof of concept stuff which is either > not ready for prime time, or not wholly suitable to current LFS book > development, I disagree. I don't like the idea of having to monitor one more list to be abreast of the bleeding edge; I may not want to test it out, but still would like to see the fun that the bleeding edgers are having :) -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UTF-8 patch, this time with DB
On 1/5/06, Archaic <[EMAIL PROTECTED]> wrote: > > None here. Though I haven't had a chance to look at the patch. Too bad > so few have commented on any of this. Lot's of emails from a small > handful of people, but a wider community input sure would be nice. I am currently building an LFS with Alex's changes and his changes look good (atleast upto the point that my build has reached). -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 2.6.15 Hotplugging/Coldplugging via udev
On 1/5/06, Randy McMurchy <[EMAIL PROTECTED]> wrote: > > why would LFS consider doing a bunch of patching and such when it is > just a guess if this is what is going to be coming down the pipe in > just a couple of weeks with these new versions you mention? I don't think Jim is proposing adding the changes to LFS. The way I understood his post is that it is more for the bleeding edge guys so that they can play around with the new stuff till it hits the released versions of the packages. Similar to LFSers who play around with the toolchain cvs versions. Jim, correct me if I misunderstood the intent. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 2.6.15 Hotplugging/Coldplugging via udev
On 1/5/06, Chris Staub <[EMAIL PROTECTED]> wrote: > > Um, no, it's the hotplug folks that aren't updating (or, more > accurately, hotplug devs no longer seem to exist). The udev devs are > still actively maintaining and updating udev. (Based on previous posts to lfs-dev) I was under the impression that the udev and hotplug is maintained by the same team and that the hotplug package is being depracated and udev will be the new hotplug handler. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Essential Symlinks: Explainations
On 1/4/06, Greg Schafer <[EMAIL PROTECTED]> wrote: > > No. It's more complicated than that :-/ GCC also has a say in the library > search path too. This is why the startfile_prefix_spec hack to GCC makes > it (mostly) do the right thing. The directory is passed as a -L flag to the linker by gcc. Verified that by replacing /tools/bin/ld by a shell script. > 3. Find some other solution. DIY currently does some funky stuff with > specs and -L/usr/lib and -B/usr/lib/, which works fine for standard > x86 builds but is untested (by me at least) for multilib builds and > may not work there. I perfer this option. I would prefer making shell scripts /usr/bin/gcc (with a symlink from /usr/bin/cc) and /usr/bin/ld during the Ch 6 toolchain adjustment phase. The gcc script should call "exec /tools/bin/gcc -B/usr/lib $@" and /usr/bin/ld should call "exec /tools/bin/ld -nostdlib -L/usr/lib -L/lib $@". This way we also avoid the need to keep the binutils build dir around. > BTW, DIY uses a much enhanced series of sanity checks in the toolchain > readjustemnt step which would have caught this flaw immediately. In view > of the current situation, LFS may want to adopt something similar.. tho' > the DIY sanity checks are geared towards scripting and rely upon the exit > status of `grep'. LFS would therefore need to adjust and/or word it > appropriately. The sanity checks are good. For LFS, it would be OK to just add "cc dummy.c -Wl,--verbose 2>&1 | grep succeeded" and ask folks to check the output. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- 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 1/3/06, Dan Nicholson <[EMAIL PROTECTED]> wrote: > For evidence, here's a diff of the build logs between iter1 and iter2 for > bison: > > --- iter1/bison-2.1.log 2005-12-29 11:50:40.0 -0800 > +++ iter2/bison-2.1.log 2005-12-29 13:28:54.0 -0800 > @@ -79,8 +79,7 @@ > checking for yywrap in -lfl... yes > checking lex output file root... lex.yy > checking whether yytext is a pointer... yes > -checking for bison... no > -checking for byacc... no > +checking for bison... bison -y > checking for ranlib... ranlib > checking for gm4... no > checking for gnum4... no Some of the configure checks are not useful. That is the results don't get used during compilation and hence won't make a difference in ICA. There is a similar check in binutils. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UTF-8 patch updated, please reconsider
On 1/4/06, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote: > > I have updated the UTF-8 patch. The new version is available at: > > http://www.linuxfromscratch.org/~alexander/patches2/lfs_book-r7243-utf8-1.patch > > The rendered version is at: > > http://www.linuxfromscratch.org/~alexander/lfs-book/ Alexander: In the ncurses instructions, you use the INPUT method to force linking against the widec versions. Wouldn't it be easier to just use symlinks like we do for ncurses? Or is there a particular reason for choosing the INPUT method? -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
zlib patch
Sometime back I added a patch to the patches repository that adds -fPIC to the compiler flags when compiling shared library. Additionally it allows building the shared and static library in a single pass. See: <http://www.linuxfromscratch.org/patches/downloads/zlib/zlib-1.2.2-fPIC-1.patch>. Though the patch is for 1.2.2 it also applies to 1.2.3. The installation instructions are: ./configure --prefix=/usr --shared && make && make install Should the patch be added to the book? -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Essential Symlinks: Explainations
On 1/1/06, Greg Schafer <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote: > > > Additionally, the libgcc_s.so symlink is not needed. Only the > > libgcc_s.so.1 is needed so that glibc can dlopen that library (used in > > nptl). > > Are you sure? It found the libgcc_s in /tools/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../libgcc_s.so. > but ISTM that LFS Unstable has therefore regressed to linking Ch 6 > Binutils and GCC against the (wrong) Glibc in /tools! Luckily, there is > enough redundancy within the build method to make this fairly harmless.. > but it still doesn't escape that fact that it's just plain wrong. It > *WILL* bite in some scenarios eg: ICA will show up differences if you > happen to build different Glibc's in Ch 5 and Ch 6 (like I do in DIY - > non-optimized in temptools phase versus optimized in chroot phase). Confirmed. Though it did come as a surprise. When I tried the test that you mentioned, it found the glibc libraries in /tools/lib, not in /usr/lib. I checked the command that was passed to ld and there was no -L/tools/lib. so it should have just found the libs in /usr/lib and /lib (as per the LIB_PATH). -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Essential Symlinks: Explainations
On 12/31/05, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote: > > Additionally, the libgcc_s.so symlink is not needed. Only the > > libgcc_s.so.1 is needed so that glibc can dlopen that library (used in > > nptl). > > Used only in nptl testsuite :) Thanks. I was trying to remember why the symlink was added, knew it had something to do with nptl, but not the exact details. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Essential Symlinks: Explainations
The section <http://www.linuxfromscratch.org/lfs/view/development/chapter06/createfiles.html> creates the necessary symlinks but does not explain why they are needed. Additionally, the libgcc_s.so symlink is not needed. Only the libgcc_s.so.1 is needed so that glibc can dlopen that library (used in nptl). -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Management
On 12/29/05, Randy McMurchy <[EMAIL PROTECTED]> wrote: > > Yes, that is probably best. As has been said by everyone, package > management is something that needs to be implemented at the beginning > of Chapter 6 in LFS. I think everyone is in agreement there. Can someone bugzilla this so that it is not forgotten? > I believe it to be healthy to change one's mind and "come over to > the other side". I think so too. Welcome to the "other" side :) > Only problem is in BLFS, where some packages don't/won't work > with a fake root installation method. For the really troublesome packages (OpenOffice is one of those), there is always the install into /opt/ cop-out. Though, *all* packages can be installed into fakeroot since that is how the distros do it. It may be a bit convoluted, but it is doable. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Management
On 12/29/05, Randy McMurchy <[EMAIL PROTECTED]> wrote: > Jeremy Huntwork wrote these words on 12/29/05 11:25 CST: > > > > I think we need to bring something up in LFS. If a user decides he > > wants to use a package manager, he's not going to want to find out about > > his options *after* he's already built his core system and moved on to > > BLFS. The minute a user starts building packages that will be in the > > final system, he should be able to use a package manager, if he so > > desires. > > Agreed there. The beginning of Chapter 6 is where you'd want to do it. How about moving the entire package management section from BLFS to LFS? I don't remember why I added the page to BLFS and not to LFS. > > You realize, don't you, that this is exactly what I suggested earlier? > > You (and others) spoke out against it pretty strongly. > > Yes, I spoke out strongly against the package-user hint. And the fake root approach too :) -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
RFE: Mentioning optional dependencies
Hi: The subject says it all:) I would like to propose mentioning optional dependencies for packages that are installed in LFS. Since most of the packages are never mentioned in BLFS, the dependencies never get mentioned. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC: GDBM or Berkeley DB?
On 12/26/05, Archaic <[EMAIL PROTECTED]> wrote: > Please comment on this thread with your choice and the reasoning for > your choice. I prefer gdbm coz the bdb api keeps changing with every new release. An added benefit of gdbm is the small number of required dependencies. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- 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 12/23/05, Dan Nicholson <[EMAIL PROTECTED]> 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/ . One thing that looks strange. libstdc++.la and libsupc++.la both include references to /tools (for iteration 1 and iteration 2). I don't install the libtool archives so I am not sure if it is a new thing. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- 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 12/15/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > Anyone have a better suggestion and/or one that will help determine > library or run-time dependencies? For executable, I prefer strace. For libraries, I move all static libraries into /opt/static-libs/$pkg for each package. If a package errors out on a static library check, I add the corresponding dir to the LDFLAGS and note the dependency. For shared libs I use readelf. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- 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 12/15/05, Matthew Burgess <[EMAIL PROTECTED]> wrote: > weakly justified as "trust us, it Just Works". Hmmm, maybe if someone > could write up a "How to Perform ICA tests" hint we could point to that, Will this do? <http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2005-November/053989.html> :) -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: coreutils (tail, head)
On 12/15/05, Randy McMurchy <[EMAIL PROTECTED]> wrote: > > I think Jim's results are because he said he *updated* his copy > of coreutils from a previous version, which of course is not > really something we need to consider, because LFS/CLFS is built > on the concept of "from scratch". Strange! It would be interesting to find out why there is a difference. Technically, starting from a LFS host with coreutils-5.2.1 installed and installing coreutils-5.93 in /tools is also an update. > > Updating a version of a package is sort of something that only > experienced builders do, and not something that you will find > instructions in LFS/CLFS for. Not really, there are instructions for folks who are just upgrading packages. For example, <http://www.linuxfromscratch.org/lfs/view/development/chapter06/bzip2.html>. The "From Scratch" as I understand is from source :) -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Hint on installing autotools versions in parallel
On 12/11/05, Bruce Dubbs <[EMAIL PROTECTED]> wrote: > > Interesting hint. A couple of comments/suggestions: > > 1. The first two attachments seem to be the same. The first attachment is for autoconf-wrapper, the second for automake-wrapper. But the scripts are very similar. > 2. In the section where you say "For packages that..." it would be a > nice addition to add the package names that you know about where the > procedure applies. > I am guessing this comment is for the fakeroot hint. I did not want to add specific packages to the list since most of the package instructions are also in my build scripts. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- 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 12/11/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > > There are others, but they need to speak up. :/ I'm pretty sure Chris > Staub agrees with me as he's done the majority of work on this. I have a > feeling (though I could be wrong) that Greg Schafer agrees with me, > seeing as how he's the one that opened the bug. I agree with the reasons behind documenting the build order. I am for documenting all the dependencies so that the person who builds an LFS knows why Package A is built before Package B. I don't like the excuse "You the user should trust us the editors". But I thought that all this has already been discussed before and after discussion the project leads decided to create a branch for the changes and then merge the changes back to head after the results were tested. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: wvstreams: autoreconf
On 12/11/05, Randy McMurchy <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote these words on 12/11/05 02:08 CST: > > The instructions in the book for wvstreams apply a patch. This patch > > patches configure.ac and configure. If the diff for configure.ac is > > removed from the patch or a touch configure command is added after > > applying the patch, then there won't be any need to run autoreconf. > > If you're going to work on the WVStreams package, work on updating > to the newest version instead of worrying about older versions. > I don't install wvstreams. I went thru the patch when writing the autotools hint and noticed that the autoreconf command was not required at all. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Hint on installing autotools versions in parallel
On 12/10/05, Nico R. <[EMAIL PROTECTED]> wrote: > autoconf-2.13-race.patch uses /bin/mktemp, but on my system the mktemp > binary is in /usr/bin, and current LFS seems to put it there, too. On my system, it is in /bin. Will change the invocation to mktemp. Thanks for the report. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- 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 11/29/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > I think we really should look at including it sometime in the future, > whether it starts with a hint or a separate branch or whatever. Since there have been no indications in either direction from the project leads, I am assuming that using fakeroot approach will not be getting an official blessing at least in the near future:) For folks who would like to test out the fakeroot approach, I have put up a draft version of a hint at <http://linuxfromscratch.org/~tushar/tmp/fakeroot.txt>. Would appreciate comments. I have not included the details on each individual package in the hint since it would make it really long. The installation instructions for specific packages can be found in my build scripts at <http://linuxfromscratch.org/~tushar/>. Have fun fakerooting:) -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Hint on installing autotools versions in parallel
Hello: Finally, I have written a draft hint on installing multiple autotools version. I would appreciate your comments before I submit the hint. The hint and attachments are available at <http://linuxfromscratch.org/~tushar/tmp/>. Regards, Tushar. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- 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 11/30/05, DJ Lucas <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote: > > > > It will work for Ch 6 only as long as we are installing it inside > > chroot. But I meant more in terms of using it for package management. > > The above technique gave me the following problems: > > 1. When reinstalling glibc, it would not log some header files (I > > think stubs.h). Ditto for some man pages from other packages. > > This means that they were not re-installed...else the timestamp on the > file would have been updated. > Exactly. Some times headers are not installed if the destination file exists. I think I saw this in glibc, ncurses, and gdbm. Same thing for some symlinks. After a while it got too tiresome to keep double checking the log trying to weed out the false postives and accounting for false negatives. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- 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 11/30/05, Matthew Burgess <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote: > > > I found too many (for my comfort) false positives and false negatives > > with this method. > > Presumably because you were doing other things with the computer at the > same time? When run inside chroot in chapter 6, unless you're directly > fiddling with files (or installing multiple packages at the same time - > i.e. *not* following the book), then I can't possibly see what would > cause `find' to report inaccurate results. > It will work for Ch 6 only as long as we are installing it inside chroot. But I meant more in terms of using it for package management. The above technique gave me the following problems: 1. When reinstalling glibc, it would not log some header files (I think stubs.h). Ditto for some man pages from other packages. 2. For packages that modify a system wide config file (such as /etc/xml/catalog), the system wide config file would get logged in multiple packages. 3. In case a package overwrote a file from another package, it would log it in multiple places. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- 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 11/29/05, Dan Nicholson <[EMAIL PROTECTED]> wrote: > However, if the book's main intent IS to be a learning experience and > provide a high level of success for newbies, I think adding that > fakeroot approach adds too much complexity and chances for errors. To > see an example of what the fakeroot approach looks like in one of its > worst cases, consider coreutils or readline: > > http://www.diy-linux.org/x86-reference-build/chroot.html#c-coreutils > http://www.diy-linux.org/x86-reference-build/chroot.html#c-readline The only difference I see as compared to what is in LFS is the addition of $PM_DEST. If the envar is not set. I don't think it creates any chances for typos. In the worst case if the user forgets to set $PM_DEST, it would install stuff into / which is how LFS does it anyways. > other hand, I plan on using it in conjunction with package management. Yep, I do that. And frankly I found the fake root approach awesome and understand why most of the distros use it. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- 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 11/27/05, Tushar Teredesai <[EMAIL PROTECTED]> wrote: > There are multiple advantages that this offers compared to the current > way of installing directly into the final destination: Just thought of another advantage of the fake root method. If the package installation fails for some reason, we don't have an half installed package in the final destination. For example, when the user is building gcc in BLFS and he runs into a problem during make install. In that case he will have an half installed gcc on his final system. If he had installed it to a fake root, he can investigate the cause, fix it, remove the fake root and run the installation again. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- 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 11/28/05, Randy McMurchy <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote these words on 11/28/05 09:59 CST: > > On 11/28/05, Randy McMurchy <[EMAIL PROTECTED]> wrote: > >>If it isn't a trust thing, and you want to figure out what all is > >>being installed, then there are many, many ways to get that data. > > > > Yep, and DESTDIR being the easiest and recommended (in the READMEs) way. > > Not to argue, but for every package that *recommends* to use DESTDIR > I'll show you 10 that do not. Still waiting for examples :) -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- 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 11/29/05, Matthew Burgess <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote: > > > > Yep, and DESTDIR being the easiest and recommended (in the READMEs) way. > > I can't possibly agree with that. `touch timestamp && [book > instructions] && find / -newer timestamp` works fine for me, though > Randy will quickly point out I rarely actually crosscheck the results of > those commands with what's in the book :-) I found too many (for my comfort) false positives and false negatives with this method. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- 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 11/28/05, DJ Lucas <[EMAIL PROTECTED]> wrote: > Also, just to throw a bone in the mix, :-) there is no need to use > DESTDIR nowadays for a glibc upgrade as the libs are installed to a temp > file and then pivoted into the new location safely. In fact, glibc does > not recomend DESTDIR at all. 'install_root' is the alternate > installation prefix nowadays. I didn't look at the makefiles to see if > DESTDIR is still supported. DESTDIR is just the name I came up with since it is the var that is most frequently used. The proper name for this sort of package management would be fake root. Of course the variable for fake root is different for different pacakges. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- 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 11/28/05, Archaic <[EMAIL PROTECTED]> wrote: > On Mon, Nov 28, 2005 at 09:59:24AM -0600, Tushar Teredesai wrote: > > > > I have been using that approach and it is not as easy as that. > > Sometimes, we need to make sure that the destination dirs exist before > > installing (i.e. have some install -d before the make DESTDIR=.. > > install. > > Then I would suggest that you first write a hint, and only then should > it be considered for inclusion in the book. > For LFS, I don't need to:) Greg has already done that in DIY. Check it out at <http://www.diy-linux.org/x86-reference-build/chroot.html>. Search for mkdir on that page. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- 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 11/28/05, Randy McMurchy <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote these words on 11/28/05 09:59 CST: > > On 11/28/05, Randy McMurchy <[EMAIL PROTECTED]> wrote: > >>If it isn't a trust thing, and you want to figure out what all is > >>being installed, then there are many, many ways to get that data. > > > > Yep, and DESTDIR being the easiest and recommended (in the READMEs) way. > > Not to argue, but for every package that *recommends* to use DESTDIR > I'll show you 10 that do not. > BTW, this is the first I have heard of maintainers recommending *not* to use DESTDIR based approach since that is how packages are installed by most of the distros (including the source based ones like Gentoo). -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- 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 11/28/05, Randy McMurchy <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote these words on 11/28/05 09:59 CST: > > On 11/28/05, Randy McMurchy <[EMAIL PROTECTED]> wrote: > >>If it isn't a trust thing, and you want to figure out what all is > >>being installed, then there are many, many ways to get that data. > > > > Yep, and DESTDIR being the easiest and recommended (in the READMEs) way. > > Not to argue, but for every package that *recommends* to use DESTDIR > I'll show you 10 that do not. > Sorry, that should have been the INSTALL file, not the README. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- 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 11/28/05, Dan Nicholson <[EMAIL PROTECTED]> wrote: > > Actually, you have that a bit backwards. TT_PFX is the variable Greg > uses for /tools or whatever. You're thinking of PM_DEST, the variable > where the package manager root is set. So that's > > make DESTDIR=$PM_DEST install Thanks, I checked his scripts a long time back. Hence the lapse. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- 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 11/28/05, Randy McMurchy <[EMAIL PROTECTED]> wrote: > > Or, to look at it another way, folks that *do* want to use the DESTDIR > approach can simply add it to the instructions. :-) I have been using that approach and it is not as easy as that. Sometimes, we need to make sure that the destination dirs exist before installing (i.e. have some install -d before the make DESTDIR=.. install. > > Every package README shows the instructions as > > configure > make > make install > > Why do we want to make it different than the maintainer suggests? That is what the README says and as we know the documentation always lags:) As per the documentation we should having been using gcc-2.95 to compile the kernel for a long time after we stopped it:) Additionally, most of the distros do it the way that I mentioned for the technical reasons that I gave in my proposal. You do want to be able to upgrade glibc on a live system, right? :) > If you don't trust the maintainer to put what he says he is on your > disk, then use the DESTDIR, or some other method to ensure he is not > screwing you. I don't buy into all the reasons mentioned in the more_control... hint. But I like the concept. Though my proposal is not based on the reasons mentioned in the hint. I made the proposal because "what" is installed by the system is a core part of creating a distribution. > If it isn't a trust thing, and you want to figure out what all is > being installed, then there are many, many ways to get that data. Yep, and DESTDIR being the easiest and recommended (in the READMEs) way. -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
