Re: [lfs-dev] No IRC on the new server
Guys, it seems to make sense to move this to Freenode as they have a large infrastructure that is quite stable, they have hosted parts of the project before, I'm still listed as a project contact on Freenode so it would take almost no time and effort to set up the channels the same, re-add the same people and just do a dns re-direct on irc.linuxfromscratch.org, much the same way ubuntu uses irc.ubuntu.org to point to freenode and gnome use irc.gnome.org to point to efnet. Gerard, I've sent you a mail on this. Matt (ikonia) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: /tools/bin/env: no such file or directory
Dominic Ringuet wrote: Simply reporting so nobody else wastes time on this. May be it could be added to the FAQ that describes this problem. if '/usr/lib/gcc/i686-pc-linux-gnu/specs' exists on the host system, the binaries compiled in chapter 5, even with the specs patch properly applied in gcc-pass2, will be linked to '/lib/ld-linux.so.2' and chroot will fail at the beginning of chapter 6 giving: '/tools/bin/env: no such file or directory' Simply ensure no host specs overrides the build in chapter 5. Dominic. I don't believe thats the case. I think its more reasonable to suggest that you have made a mistake adjusting the toolchains linker. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers
Jim Gifford 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. What I ask from the more advanced members of LFS and CLFS is to give them a try, comment on them. Would they be useful to use as a temporary alternative. a viable alternative, hard to maintain, or is it a waste of time? My testing has only been on the LFS and CLFS builds, if someone is interested in doing builds beyond these books and sharing their results with the community and myself, I personally would appreciate it. I'm only posting this because my results have been positive, and I think the community has a right to see what I've come up with in 18 hours that I've worked on this. I can confirm that against 2.6.15 headers, I've got sucessful builds on straight LFS32 and cross-lfs 32/64 x86 and Sparc 64. The headers where sanitisied using Jim's script. I should point out there reading up glibc2.4 there is potential for non-x86 archs loosing compatability due to glibc's additional archs maybe marked as "additional" and not mainstream, but thats a side issue. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Raw Kernel Headers
Another very minor point is trying to find a way to rip out all the __KERNEL__ portions That's what the "unifdef" tool in FreeBSD does. It also works in Linux. http://www.cs.cmu.edu/~ajw/public/dist/unifdef-1.0.tar.gz Note: Debian uses a CVS version for some reason, need to investigate. Note: this has all been discussed before. eg: http://linuxfromscratch.org/pipermail/lfs-dev/2003-October/039740.html I still think this whole issue is dangerous territory for non-programmers and I will not be supporting any of it. For starters, we need proper rationales for the choices made in Jim's sanitization script. Regards Greg Greg, I think Jim's efforts are just a stake in the ground and can be futher discussed or refined as required. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New LFS RElease?
The kernel is about to release 2.6.16 (they have been on 2.6.16-rc5 for about two weeks now) so we are quite a bit behind there. Yes, but any upgrade to the kernel will require a newer version of udev which is why the udev_update branch was created. If your considering the new 2.6.16 kernel as a justification to update, then surly the LLH / Raw headers should be a consideration, as moving everything else forward and keeping on the 2.6.12 headers seems a little odd. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: merging udev_update branch
Andrew Benton wrote: Bruce Dubbs wrote: I would really like to update glibc and gcc for 6.2. Otherwise we will be behind the power curve. We don't want to get multiple revisions behind on these. And there's the kernel headers issue to sort out too. Andy The kernel headers are not really ready for consideration for use at the moment as I see it, we've not even decided which way to go with headers, let alone got the header script to a point that could be considered stable. I'd leave the headers on the current revision for the next release. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS 6.2 toolchain versions
Archaic wrote:
Let me answer that with an example. gcc-4.0.x and mysql 5.0.{16,18,19}
produce problems.
I'd be interested in seeing the problems
[EMAIL PROTECTED]:~$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.2/configure --prefix=/usr
--libexecdir=/usr/lib --en able-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --
enable-languages=c,c++,objc
Thread model: posix
gcc version 4.0.2
[EMAIL PROTECTED]:~$ mysql -V
mysql Ver 14.12 Distrib 5.0.16, for pc-linux-gnu (i686) using readline 5.0
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Adding newer headers to llh (Was Re: merging udev_update branch)
Archaic wrote: I would like to hear from Jim and everyone working on the header project regarding this possibility: Find the headers that llh currently lacks that glibc-2.3.6 and linux-2.6.16.x both support and patch them into llh. The only thing that comes to mind is inotify support. Headers that have become drastically different are a concern, though, as that adds to the testing time. I've had excellent results with the headers produced by the headers script, really good, however bottom line is it still being developed (changes to the output headers are still happening), which as fast as it matures is still not really solid enough to start looking at a release. However as in your pervious message moving them into trunk could be a good idea. I've been using them for cross-builds for a while which it pretty much a constatnt trunk at the moment, and I've had few serious problems. Another issue is while these headers are progressing at an excellent speed - the direction / use of headers (what is LFS going to do for headers in the future) has not really been discussed properly yet. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Adding newer headers to llh (Was Re: merging udev_update branch)
Jim Gifford wrote: Another option here is to use the headers package I've been working with a lot of people. It compiles a base LFS and CLFS with no issues at all.http://ftp.jg555.com/headers/linux-headers-2.6.16.2.tar.bz2, or roll your own by using http://ftp.jg555.com/headers/headers. For the sake of the book and supporting users, surly we must release a "package" rather than encouraging users to create their own ? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Adding newer headers to llh (Was Re: merging udev_update branch)
Feldmeier Bernd wrote: Hi All, as for educational purpose I think I would be good to use an original kernel and then apply the header script. This shows that there is some magic around that stuff. Releasing "only" a package is only useful for advanced users I think. regards Bernd Surly thats back to front, building your own headers would be for advanced users who know and understand what they are doing - while a stock version for users getting to grips with the LFS project. This however highlights my point of support - with the availability of the headers script will come a.) users wanting to use their own headers because "its cool to use the latest headers" with no understanding of what they are doing b.) multiple platforms to support - eg system built from 2.6.15 2.6.16 and 2.6.17-rc2 headers - then couple that with users deviating from the book's package versions, well, it will just become unsupportable and not help LFS's reputation as a usable stable platform c.) people who contribute to LFS will be able to build headers earlier header versions and test earlier against packages for future release. With this in mind I feel it important to a.) Decide on a direction with the headers sooner rather than later b.) decide how to use this header work productivly and for the good of the project overall, not just inotify ;o) Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS needs a new server.
Bruce Dubbs wrote: This is a request for donations. The LFS server is creaking along poorly. It is a 750MHz/512MB Ram/2 x 9G SCSI system. It frequently has high load factors and out of memory problems. Right now, Gerard is funding the server hosting fees from the meager PayPal donations he receives and supplementing it with his personal funds. I am paying for anduin's fees. I am soliciting donations to the LFS Server Fund. We only need $1000 US. Please consider giving whatever you can afford. You can donate via PayPal: http://www.linuxfromscratch.org/contribute.html#donation If you don't want to (or can't) use PayPal please send a check directly to Gerard: Gerard Beekmans 911 Wilson Way Canmore, AB T1W 2Y8 Canada Thanks! -- Bruce Bruce, After speaking to Archaic, I understand your about $500 short of the new dell box. I think - through my business I maybe able to cover that, can you confirm how much you need. ta Matt (ikonia) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Users and Groups
Joe Ciccone wrote: I put this page together with the users and groups from LFS and BLFS. The only addition I made to this page is a users groups with a gid of 100. Anyone that wants to set something in stone, this would be a good place to start. http://www.linuxfromscratch.org/~jciccone/users.html Nice to see this on paper, but I am really not a fan of us pushing out the specfic UID/GID per user. While I appriciate that this has been discussed before, its been in use for a while in BLFS, perhaps now would be a reasonable time to review how its worked out, how change has/hasn;t effected it etc. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Rally the Troops LFS/BLFS/CLFS/Livecd too
Hi all, First of all, I have sent this mail to all lists, but I'd request that all responses happen on LFS-DEV to keep this thread (assuming it gets response) together and followable. Reading through threads in general there appears to be a little seperation and difference of opinion on a few key topics that affect all project potentially. I'm posting this thread to call out the topics I see underdiscussion (rightly or wrongly) and I ask that the response and hopefully discussion thread formed from this mail be limited to these topics, if this discussion brings up further topics lets make a note of them and but them to one side until we reach a reasonable conclusion on these topics, we can always start another thread to discuss them later. I also ask that 1.) if you've got no idea whats been discussed in these mails - don't comment, we don't need a "can I have wirless tools" style post 2.) for the purpose of reaching an end result and consensus we drop any "well steve doesn't do anything anyway ;o) " style comments, lets try to contain this discussion to just that, discussion 3.) Guilty as I am off this a lot of the time - lets trim our reponses to make the discussion easy to follow. Now I've laid down my request lets look at the topics, that in my mind are unclear and up for dicussion. 1.) Kernel Headers, yes you knew this was coming but its certainly worth talking about, a lots been said on this but its really still unclear of direction. I suppose the discussion should center around a.) Do we stick with LLH and pray it takes off again b.) work with Jim's methods of sanitizing our own headers c.) Look at what other distros are doing and try to work with them d.) A N other option 2.) Udev - This again has been a hot topic of many projects, but with LFS now dropping hotplug I feel it important ti discuss and clear up a few areas a.) Udev rules - how complete/incomplete should they be b.) which project cover which rules eg; lfs base only, blfs additional, clfs base+additional archs devices ? that sort of thing c.) what are the livecd doing with udev - removing hotplug ? what rules are they using ? etc d.) Should we all use the same rules lfs/livecd/cross-lfs/hlfs even ? e.) other topics aound udev 3.) users and group creation, I'm reluctant to touch on this again as I know its close to a few individuals hearts and a lot of time has been put into this, but due to the ude discussion I think its worth at least touching upon. a.) do we define uuid/gid for users in LFS - I don't think this is an option and has to be done b.) how does blfs address this, does it specify uid/gid per user, does it speficy users and let the user map the uid/gid - does it do nothing and just you need an "X" user with X permissions c.) how do the uid's/gid's tie in with udev rules ? for all projects d.) do all projects use a unifrorm set of uid/gids and if so -how to we acomplish this? e.) other uid/gid points On a final note, I know this has been said to individuals before, and I preach a lot about it, but I'm hoping that with this discussion there is a real potential to bring all the projects closer together and more "agreed" on the direction the overall project is taking, even if projects go their own ways on things, at least it will be understood that X is doing it different because of X + Y and perhaps we can start sharing across-project information better and work as a bigger group better. Apologies if this mail seems to spell out the obvious, but I'd really like to say it public and try to get a consensus where everyone working say "yes, I understand this is what we are all doing - even if I don't agree" thanks, Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Rally the Troops LFS/BLFS/CLFS/Livecd too
Bryan Kadzban wrote: steve crosby wrote: iptables is one such application - currently non functional with jim's script created headers, but have yet to identify why. I thought iptables required the "raw" kernel source anyway? Regardless, it's definitely one of the few Linux-specific programs. Its only purpose in life is to manage Linux's firewall; that makes it pretty much non-generic. ;-) Guys, I'm really dissapointed that this thread has turned into a "support" thread for certain products and arguments over specifics. The whole point of this thread was to discuss the options and directions of the whole projects not answer specific questions about certain header versions and what version of jims script was current. Really dissapointed that after such a good start it has been turned into a product support thread This just totally highlights one of the core reasons why this sort of discussion is impossible to make on a mail list in the public eye. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Rally the Troops LFS/BLFS/CLFS/Livecd too
steve crosby wrote: On 5/1/06, Bryan Kadzban <[EMAIL PROTECTED]> wrote: a setup. The sticking point would be programs that include linux/.h or asm/.h, if there are any. And it sounds like there are glibc alternatives to all of those headers anyway, so it would be the program that's broken. (Unless it's Linux-specific.) iptables is one such application - currently non functional with jim's script created headers, but have yet to identify why. -- -- - Steve Crosby Once again a totally pointless discussion about iptables and specific headers, What part of this threads topic was not clear ? I really wanted to get consensus at some level of the direction, problems, potential of the options presented to the LFS projects, and this has turned into a debate on iptables header usage, after I excpilitly called out not to focus on specific and if you wanted to to start another thread This mailing list is clearly not working, what is the point of trying to use this list to communicate with other developers when it is pretty clear that it is impossible to have a discussion on a topic despite clear requests to no do certain things, people still ignore it and carry on their own personal discussion. Frustrated and very dissapointed. Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Rally the Troops LFS/BLFS/CLFS/Livecd too
There's nothing at all wrong with the mailing list. It's just the inherent nature of a project that is spread out among group of volunteers that don't always have time to discuss properly - the medium used is to discuss isn't to blame. In fact, it's good that you brought this up here because even if discussion isn't happening as you like *now*, there is a public record of what was brought up and we can always return to it. Try to relax and be a bit more patient please. Gently nudging and reminding you'll find works better to extract more comments. As it is, I promise to look over your original request a bit more later today and comment where I feel I can. I think we are going to disagree here I'm pretty calm about this, and I've got not problem with patience, I was happy to wait for responses and dicussion to pick up, I am frustrated that I called out in detail how I didn't want this thread to turn out, and people just ignored it and went on their own discussions, even though I said "if you want to take this off topic in more detail either wait until we come closer to a conclusion or start a seperate thread as to not change the base dicussion of this thread" - I'm not annoyed by other or off topic dicussion I'm annoyed and frustrated that even when you spell it out clearly to try to get a topic moving people just go off on random tangents and ruin the thread, yes this thread is logged and can be refered to - but whats the good of refering to it when the topic is "what direction should the LFS projects go" and the content is "does iptables use raw headers" or "perhaps I should look at my mail list settings" etc etc. I shouldn't have to nudge or remind after only about 10 good mails that "keep on thread" people should have had read the mail and thought "yes there is no need for that single mail saying "lol" when the thread poster has taken a serious not to this mail and has specificly asked us to NOT do this. Its not often I post a serious thread on this mail list any more rather than chat things through with individuals as the ammount of noise and pointless contribution that for what should be a channel leading development ALWAYS takes over, but I gave this a shot in blind faith hoping that spelling out the requirments and goals clearly at the start would lead to a more productive thread. I was wrong and once again return to my belief that this mailing list is not working and needs to be moderated or subscription. I know this is against Gerards wishes and goal, but at the same time this thread just highlights how impossible it is to discuss a topic. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Rally the Troops LFS/BLFS/CLFS/Livecd too
Bruce Dubbs wrote: Matt Darcy wrote: I'm really dissapointed that this thread has turned into a "support" thread for certain products and arguments over specifics. The whole point of this thread was to discuss the options and directions of the whole projects not answer specific questions about certain header versions and what version of jims script was current. Maybe the problem is timing. As the devs are trying to narrow down the open issues for a release, they naturally converge on current issues. Perhaps you should try again after LFS-6.2 is released. -- Bruce Thats fine - I don't expect instant responses, I do expect people to read the mail and not respond with random topics and tangents after I've asked them not to, I'm not rushing for responses, but I am serious about quality of responses, hence why I went into so much detail about "not ruining the topic" Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Suggestions for the book
r3al1tych3ck wrote: Sorry Bruce. Not embarrassed here. It took almost half an hour to explain it in irc before because the hot headed people would not listen. Eventually they got it but are still to smug to do anything about it. SURE. I, you, or anyone can point to any ONE place in the book and say, "See, I told you so." The point is across the book it is not consistent. I'm going to come in at this point. I take issue with this, I took all your comments on board, and disagreed with most of them, however as beaker pointed out in the mail list link he sent and as Jim Gifford pointed out in the channel at the time, the books description of root / non-root useage was pretty spot on, however for the cross-lfs book we decided to add a comment at the top of one of the chapters explaining at this point you should be root just ot make it clear. At no point did we call anying is an idiot, or ignore your comments (hence why we are making a change to a pragraph) based on your input, no point did we say "you suck" and we are not hot headed (hence listening and acting on your feedback). In this mail R3, you are coming across as hot headed and presenting a very weak argument of why you should be listened to when people involved in the project are taking the time to respond to you. May I sugest that if you want to be taken seriously and not dissmissed as you appear to be from this mail thread you listen to whats being said and respond to it constructivly, perhaps lay off painting things one sided view as you have done our conversation in IRC. Regards, Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Suggestions for the book
Well, if you or the OP can provide definitive examples of where the book is inconsistent then I will gladly reword it. As it is, the introduction sections of each chapter are the only places where I am aware we inform you of what user you should be, and it is assumed that one reads that introductory material. Regards, Matt. Matt, The LFS book is fine in terms of wording, there is a slight room for improvment in the cross book due to the chroot/boot options and the lead into that. along with the chapter 4 setup process Its nothing major but if not read clearly first time around it could lead to confusion and its a little inconsistant, in some chapters we say "check you've got $LFS set" but in others we don't, so it can lead to confusion (just as an example) so the cross-book will be cleared up on this, but I don't see this minor problem in the LFS book due to its structure being less complex and optional. Matt -- 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
Jim Gifford wrote:
This is been a topic of many different discussions. A lot of people
have tried to convince both sides, but nothing has ever been settled.
It needs to be settled before this rift between projects gets any bigger.
We in CLFS have our udev rules. LFS has their udev rules. BLFS is
going to have their rules. Here is what I'm proposing.
Making a unified package of rules, with targets make install-lfs
and make install-clfs. Going through each of the rules and figure out
which are common and which are specific. If that won't work, still
have a unified package, but with LFS and CLFS rules in separate
folders. But keeping a unified package.
Development of the rules will need to submitted into a common svn,
that will need to be created.
Here are some of the notes of the changes I think will be needed.
Proposed Makefile Changes
install-common: {All rules that are common to both books}
install-specific-lfs: {All rules that are specific to LFS}
install-specific-clfs: {All rules that are specific to CLFS}
install-lfs: install-common install-specific-lfs
install-clfs: install common install-specific-clfs
Jim,
after all the discussion around the udev rules and the potential
problems, this solution seems to fit the bill closest to anything
discussed so far.
The road blockers I see, will be around package maintenance - someone is
going to have to control the package, and package size, eg: an LFS user
downloading the udev package will download the files for all projects,
as this is only a few K of text files I don't see it being a problem.
I'd personally like to see this idea/suggestion talked through is is a
good start in unifying parts of work across the projects.
Matt
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: cp foo{,.bak} not always supported
Ken Moffat wrote: > On Sun, Jun 01, 2008 at 06:19:03PM +0200, Gilles Espinasse wrote: > >> This was just to inform. >> You could require what you desire. >> >> For me, less requirement is better so we will adapt our scripts. >> I do not imagine I could make Ubuntu change something just to let IPCop >> compile ;-) >> >> Gilles >> >> > Hi Gilles, > > I've already sent a follow-up to my terse original reply - > unfortunately, my mail seems to have been a bit delayed this > afternoon. Again, thanks for your report. > > And no, I doubt any of us have any leverage on the weird things > that any of the distros do - that's one of the reasons for choosing > to build our own. > > > ĸen > The use of dash in Ubuntu is an issue for many things not just LFS. Ubuntu it's self it having problems making simple things like it's init scripts %100 dash due to shell limitations. Ubuntu does however have bash available. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Successful First Install - GCC-4.0.1
Dex wrote: Went pretty smoothly and completed in less than 24 hours despite recompiling gcc a number of times to play with different C/CXX flag settings. No matter what I tried I got errors on the math tests and ended up with -march=ahtIon-xp -O2 -pipe. I did note that a couple of packages were in *.bz2 format though the book said they were *.gz. Could that be because I downloaded the packages from the mirrors instead of the individual sites? I thought it was better to build gcc without optimisations ? Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
X86_64 Multi-lib cross-build glibc32/64 gcc4 __thread failure
Hi all,
There appears to be a problem with the cross-build gcc4 project. From
dicussions on this it appears to be a compatability issue with gcc4
which displays its self on different platforms in different ways.
I have been working on the x86 to x86_64 multi-lib version of this problem.
The basic issue appears to be after the use of the cross tools to build
what appears to be a sane tool chain, you progress onto building the
true system in multi-lib form. The first package is glibc 32 bit mode.
After applying the patches I issue configure to prep for the build
Half way down I get a failure that it can't find nptl.
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
configure: WARNING:
*** These auxiliary programs are missing or incompatible versions: autoconf
*** some features will be disabled.
*** Check the INSTALL file for required versions.
configure: error: compiler support for __thread is required
as you will see from the files attatched both the 32bit and 64bit libs
in the /tool dir, that gcc has been linked to have nptl support.
Glance through the attatched file and see if you have seen or have any
thoughts on this problem. I know of one other having the same problem on
the same platform.
I'm currently collecting his data.
Matt.
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
configure: WARNING:
*** These auxiliary programs are missing or incompatible versions: autoconf
*** some features will be disabled.
*** Check the INSTALL file for required versions.
configure: error: compiler support for __thread is required
*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} %{m32:--32}
*asm_debug:
%{gstabs*:--gstabs}%{!gstabs*:%{g*:--gdwarf2}}
*asm_final:
*asm_options:
%a %Y %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}
*invoke_as:
%{!S:-o %|.s |
as %(asm_options) %|.s %A }
*cpp:
%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
*cpp_options:
%(cpp_unique_options) %1 %{m*} %{std*&ansi&trigraphs} %{W*&pedantic*} %{w}
%{f*} %{g*:%{!g0:%{!fno-working-directory:-fworking-directory}}} %{O*} %{undef}
%{save-temps:-fpch-preprocess}
*cpp_debug_options:
%{d*}
*cpp_unique_options:
%{C|CC:%{!E:%eGCC does not support -C or -CC without -E}} %{!Q:-quiet}
%{nostdinc*} %{C} %{CC} %{v} %{I*&F*} %{P} %I %{MD:-MD %{!o:%b.d}%{o*:%.d%*}}
%{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*} %{MG} %{MP} %{MQ*} %{MT*}
%{!E:%{!M:%{!MM:%{MD|MMD:%{o*:-MQ %*} %{remap} %{g3:-dD} %{H} %C
%{D*&U*&A*} %{i*} %Z %i %{fmudflap:-D_MUDFLAP -include mf-runtime.h}
%{fmudflapth:-D_MUDFLAP -D_MUDFLAPTH -include mf-runtime.h} %{E|M|MM:%W{o*}}
*trad_capable_cpp:
cc1 -E %{traditional|ftraditional|traditional-cpp:-traditional-cpp}
*cc1:
%(cc1_cpu) %{profile:-p}
*cc1_options:
%{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}} %1
%{!Q:-quiet} -dumpbase %B %{d*} %{m*} %{a*} %{c|S:%{o*:-auxbase-strip
%*}%{!o*:-auxbase %b}}%{!c:%{!S:-auxbase %b}} %{g*} %{O*} %{W*&pedantic*} %{w}
%{std*&ansi&trigraphs} %{v:-version} %{pg:-p} %{p} %{f*} %{undef}
%{Qn:-fno-ident} %{--help:--help} %{--target-help:--target-help}
%{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}} %{fsyntax-only:-o %j} %{-param*}
%{fmudflap|fmudflapth:-fno-builtin -fno-merge-constants}
*cc1plus:
*link_gcc_c_sequence:
%{static:--start-group} %G %L %{static:--end-group}%{!static:%G}
*endfile:
%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s
*link:
%{!static:--eh-frame-hdr} %{!m32:-m elf_x86_64} %{m32:-m elf_i386}
%{shared:-shared} %{!shared: %{!static: %{rdynamic:-export-dynamic}
%{m32:%{!dynamic-linker:-dynamic-linker /tools/lib/ld-linux.so.2}}
%{!m32:%{!dynamic-linker:-dynamic-linker /tools/lib64/ld-linux-x86-64.so.2}}}
%{static:-static}}
*lib:
%{pthread:-lpthread}%{shared:-lc}%{!shared:%{mieee-fp:-lieee}
%{profile:-lc_p}%{!profile:-lc}}
*mfwrap:
%{static: %{fmudflap|fmudflapth: --wrap=malloc --wrap=free --wrap=calloc
--wrap=realloc --wrap=mmap --wrap=munmap --wrap=alloca} %{fmudflapth:
--wrap=pthread_create --wrap=pthread_join --wrap=pthread_exit}}
%{fmudflap|fmudflapth: --wrap=main}
*mflib:
%{fmudflap|fmudflapth: -export-dynamic}
*libgcc:
%{static|static-libgcc:-lgcc
-lgcc_eh}%{!static:%{!static-libgcc:%{!shared-libgcc:-lgcc --as-needed -lgcc_s
--no-as-needed}%{shared-libgcc:-lgcc_s%{!shared: -lgcc
*startfile:
%{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}crti.o%s
%{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}
*switches_need_spaces:
*cross_compile:
0
*version:
4.0.1
*multilib:
. !m64 !m32;64:../lib64 m64 !m32;32:../lib !m64 m32;
*multilib_defaults:
m64
*multilib_extra:
*multilib_matches:
m64 m64;m32 m32;
*multilib_exclusions:
*multilib_options:
m64/m32
*linker:
collect2
*link_libgcc:
%D
*md_exec_pref
Re: RFC - Cross-LFS Future
Jim Gifford wrote: One of things I've been mulling over is maybe have cross-lfs just build the toolchains, but the rest of the stuff, currently the temp-system and final-system of Cross-LFS, could be the future LFS book that supports multiple architectures. I'll put my comments in now that I'm on a working machine. I'm putting my X behinds Jims proposal, pretty much for the exact reason he outlined in it, almost to the letter. I feel that as a seperate project the cross-build process will benifit the straight LFS project and vice a versa in finding bugs/incompatabilies/new features maybe ? I jus think it opens doors, and on serious issues puts double the brain power/resources/testing behind it. I think as long as information is shared in a two way street after a short learning period the two groups will see massive benifits. Also as a good few people will work/have interest in both projects it will really open more possabilities and ideas. There seems to be a concern that in time the cross-process will replace the straight build process. I can't see it myself unless there is a real lead towards this. If I'm building a 32bit x86 host for example, its easier for me to stick the live CD in and build it straight, if I have a sun box running, solaris 64 bit, its easier for me to build LFS 64 straight. Granted I'll probably cross-build a few things for the sake of it for interests sake, as cross-building has found some really unusual bugs, which the LFS community are aware of and I think will be usefull in the next LFS release or dev book, but as a whole straight architecture building shouldn't go away unless the LFS project decideds that cross-building is the way to go. I'm backing this all the way, I think it will be a real benifit for all, and help keep things clear. Matt -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.25/102 - Release Date: 14/09/2005 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: broken link for "Glibc TLS Patch" in cross-sparc64
Frans Verstegen wrote: Hello everyone The following link is broken in the cross-sparc64 and cross-sparc64-multilib books Glibc TLS Patch - 4 KB: http://www.linuxfromscratch.org/patches/downloads/glibc/glibc-20050919-sparc64_tls-1.patch Frans ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com works fine for me Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross-compile to sparc64 glibc-configure problem
Frans Verstegen wrote: When following the "Version 7.0-cross-lfs-20050926-Sparc64" I get the following error in configuring glibc in "5.8.1. Installation of Glibc" (...) checking for long double... no checking size of long double... 0 running configure fragment for sysdeps/sparc/sparc64/elf checking for sparc64 TLS support... no checking for sparc64 ld WDISP22 handling... ok running configure fragment for libidn/sysdeps/unix running configure fragment for nptl/sysdeps/unix/sysv/linux running configure fragment for nptl/sysdeps/pthread checking for forced unwind support... no configure: error: forced unwind support is required The MultiLib version of the cross-lfs-20050926-Sparc64-MultiLib states that for the 64bit libs : For NPTL enabled systems we will need to add the following lines to config.cache: echo "libc_cv_forced_unwind=yes" > config.cache echo "libc_cv_c_cleanup=yes" >> config.cache When I apply this config.cache fix to the "cross-lfs-20050926-Sparc64" branch, the configure process ends without error. However, I do need to add the -C flag to configure in order to get the config.cache file picked up. Not being a cross-compile specialist (yet :-), I'm not sure whether I'm heading in the right direction. Frans yes you'll need the -C flag to pick up the cache file, or --with-cache option for configure. I'll check this in the book now. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
all the verbose output - LFS for dummies now ?
Guys, could someone explain the driver behind all the -v flags on pretty much every command within the LFS dev/testing releases. every command now seems ot have -v output. mkdir/chmod/chown etc etc. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: all the verbose output - LFS for dummies now ?
Andrew Benton wrote: Matt Darcy wrote: Guys, could someone explain the driver behind all the -v flags on pretty much every command within the LFS dev/testing releases. every command now seems ot have -v output. mkdir/chmod/chown etc etc. http://linuxfromscratch.org/pipermail/lfs-dev/2005-July/052417.html ahh, I away from the lists at that time. thanks for the link. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: User lfs is more than optional.
John Miller wrote: Andrew Benton wrote: William Zhou wrote: I have been using LFS for more than a year's time and it is great. One of my friend started LFS several days ago and got an error when adjusting the toolchain( 5.7 ). The problem was that the gcc specs path was pointed to the host's one. It took me me a while to figure out that he ignored the creation of user lfs and thus the ~/.bashrc is not created. The PATH enviourment does not even includes /tools/bin. Most of us follows the book's recommendation and never had this problem. But I believe the creation of LFS should be stated to be mandatory, or at least make this clear. I agree with your point about setting up the environment (it is essential) but on the specific point about creating the user lfs, I disagree. For a while now (six months or so) I've been doing my builds creating the temporary tools as myself, the user andy. However, I always go through the steps of creating ~/.bashrc and ~/.bash_profile and sourcing them, just like the book says. That creates the correct environment, not the username. Andy If I can just give you my opinion based on my short experience, creating the user LFS is a recommandation and not an obligation, because all the book can be done exactly without this single command. Everything can be done as root without any change (even if, of course, it's not *recommanded* due to the risks of mistake), and the final system would be as good as if built with lfs user. Regards G. Moko As someone somewhat past the novice stage, around 2 years with Linux, a little less trying LFS, I thought I might add my two cents. I too have deviated from the book, but I have heard over and over on this these lists, and its probably in the book too, that you deviate from the book at your own risk. I have done so after going "by the book" several times and got a little adventuresome. If the book does not flat out say this, I know its somewhere, there are no guarantees once you deviate. I understood that from day one of finding the LFS site. Yes LFS is "Your distro, your rules" but the book gives you a stable platform that is know to work if you want to modify it, again, at your own risk. So in my opinion, *all* of the instructions in the book are obligatory. My two cents. At what point does it say creation of the LFS user (or an additional user) is optional ? If someone is not aware enough to know that they will need to create a profile for the user building LFS with certain environmental variables set, then they should follow the book line by line. I don't see why the book should have to cater for a.) people who choose not to read the text carefully enough b.) people who deviate away from the book without a good understanding of LFS. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Typo lf-dev SVN-20051118
all, Chapter 6.50 module init-tools-3.1 the command tar -xvf ../module-init-tools-testsuite-3.1.tar.bz2 --strip-path=1 should be tar jxvf ../module-init-tools-testsuite-3.1.tar.bz2 --strip-path=1 The strip option is also questionable on certain versions of tar on platforms. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Typo lf-dev SVN-20051118
M.Canales.es wrote: El Domingo, 20 de Noviembre de 2005 15:01, Matt Darcy escribió: should be tar jxvf ../module-init-tools-testsuite-3.1.tar.bz2 --strip-path=1 The strip option is also questionable on certain versions of tar on platforms. Not. When issuing that command the tar binary used must be the one in /tools/bin, that we know that support the sintax used in the book. The --strip option was an aside though - to which your %100 correct this HAS to be the one in /tools, as your building for the final system. That didn't click into place in my head, my fault. However the missing j option for untaring needs updating. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Typo lf-dev SVN-20051118
Jeremy Huntwork wrote: Matt Darcy wrote: However the missing j option for untaring needs updating. Again, we're using the tar in /tools at this time which we know is tar-1.15.1. Try that version on a tar.bz2 or tar.gz without the -j or -z and see what happens. ;) -- JH uncompressing a file with bzip2 compression using tar 1.15.1 built in /tools failed for me. From what you guys have both said, I'm assuming you expected it to add the j option on its own ? strange that its failing for me. I'll investigate. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Typo lf-dev SVN-20051118
Jeremy Huntwork wrote:
Matt Darcy wrote:
uncompressing a file with bzip2 compression using tar 1.15.1 built in
/tools failed for me.
From what you guys have both said, I'm assuming you expected it to
add the j option on its own ?
For tar >= 1.15.x all you should need to do on compressed tarballs is:
'tar -xf file.tar.{bz2,gz}'
tar can now automatically discover the compression type and decompress
it appropriately.
--
JH
I read this too, however its not working for me, I need to check this out.
thanks for the clarity though
Matt
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: User IDs and Group IDs
Bruce Dubbs wrote: Jim Gifford wrote: Here's what's bugging me about this whole hardcoding of UIDS. Here is the page from the BLFS book Name UG exim31 31 postfix 32 32 postdrop33 sendmail 34 mail34 I think we all agree these are mail servers. So why can'ts exim, postfix, and sendmail user UID 31. Why do they have to have separate UID's. Why not just say mailservers are UID of 31 and GID of 31. I thought about that. The problem with a group of users with the same uid/gid is that a user testing different mail servers has to change the uid/gid every time he changes which program he is using/testing. That, IMO, should be avoided. I also chose to keep all the mail related numbers close together and when possible set gid=uid for a given package. What is the big deal? Why do you need the specific uids/gids 32, 33, and 34? -- Bruce Bruce, as a side thought to make it more generic how about having all mail server programs run with the user "mserver" with uid/gid 32/33 (just for an example) that way average joe won't have a problem and anyone with a little more insite can change this as they see appropriate. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Unsupported Distro List - an open question
Hi all, I believe this has been discussed before, but after reading a post on lfs-chat recently and some pretty frustring issues within the support IRC channels, I thought I'd post this open question. Should there be an "unsupported distro" page in the book. eg: the slamd64 distro is totally unsable without some pretty massive changes to it, thats the only way I could get it to build anything LFS-ish. The problems with redhats gcc4 (intially) cause major pain, issues with suses 9.X 64 distro's handling of multi-lib with gcc caused pain. These are just a few recent examples that sping to mind. What are peoples thoughts on having an "unsupported" or "known bug" page within in each book - or on each projects page something along there lines of These distros are known to not be compatible/stable to build an LFS relelase slamd64 These distros are know to have minor issues that cause addational steps to build LFS Fedora Core 4 Suse 9.3 AMD64 Yes, this would be a pain to keep maintained (although I don't think too much effort if the contributors/projects work together and keep each other informed) Yes, should we really have to provide this information Yes, this is probably over kill. However the average level of experience of people trying LFS is falling in a big way (first exposure to linux for example) and an additional bit of information (assuming they read the book - which most don't) may prove helpful. I'm not saying "lets do this" I'm canvasing for thoughts on this. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: More Control and Pkg Man [was: Post LFS-6.1.1 plans]
Just in case anyone is interested, I've put the coddled HTML, as it was a few days ago, here: http://www.lancs.ac.uk/~kevin/LFS-SVN-051107-kmb.html Basically, as rendered at my end, commands from LFS that I no longer needed to follow are tagged with a RED background to the parts and commands I added in have a LIGHT-BLUE background. All of this pretty much applies from Chapter 6 onwards. This helped me see what was LFS and what wasn't as well as making it easier to check any misaligment when patching agaist newer vesrions of the book. By the way, I can well appreciate (even before reading the follow-up/fall-out to the original posting !) that the approach is not for everyone but I have since followed it through into the BLFS stage of building a system at home and, other than moving the package user home directories across to /usr/local/src after creation, it seems to be working well. As to Jeremy Huntwork's "playful" suggestion that the concepts be adopted into LFS proper, I'd probably side with the -1 people, however, it does strike me that some of the issues "More Control and ..." raises might well provide some useful additional commentary to the core LFS storyline. Hello Kev, I'm not sure I see what you've done. you just appear to have put "su $package_name_user" infront of each package build - and changed nothing else. Have I missed the point ? Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Unsupported Distro List - an open question
Are there really enough distros that won't build lfs (other than the ones that are just too old and ones that don't meet other basic criteria) to justify creating a such a list? We already have FAQ entries for a couple of problematic distros...just add more to the FAQ as needed... Very fair point, its an open questoin -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Post LFS-6.1.1 plans
Dan Nicholson wrote: On 11/24/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: So. I had been thinking it would be nice if LFS and BLFS adopted (some of) this approach. Again, I fully recognize that this is new ground in a way and that many people will think, "it is a hint and should stay a hint", but, IMHO, there are many techniques employed here that a default LFS user could learn from and benefit by. As Matt has already said, LFS creates a base usable linux system with the minimum tool set to boot. A base system. I don't see a packagement tool - and certainly not the suggest tool as a bare minimum or as a good base for an update. LFS works as it is, it calls out at the start of the book what it will build, I don't see a need to move this to include more tools like a propritary package managment system. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Hand holding (Was: Re: Post LFS-6.1.1 plans)
Archaic wrote: On Sat, Nov 26, 2005 at 09:56:05PM -0600, Bruce Dubbs wrote: IOW, I think the level of the book is just right. Please, Bruce, do not take offense at this, but the only posts I've seen from you in lfs-support this year are 2 in August and they were both release announcements. Also, I never see you in #lfs-support. I know you are busy, but those 2 places are the only real guage of the level of the book. And this pot will call itself black, too, because you won't see any posts from me, either, as I really can't stand it anymore. As I have time, I support things in the various IRC channels (though usually only see them when someone specifically calls my attention to it). I, and many others who have no problem sorting out legitimate errors (which sometimes even leads to FAQ entries or book changes), have steadily gained a disdain for people asking questions with absolutely no prerequisite knowledge of linux. They don't read the links, or they can't understand them. However, our book is so easy that they can continue on only to be stopped early and post a flurry of support requests. This was not prevalent back in 2000. And from my perspective, neither was flaming, but rather an un-coddled response to the realities of the situation. Without being rude, some people just need to be told they aren't ready for LFS until they gain the requisite knowledge, though this scenario wouldn't even be prevalent if the book avoided holding their hands. Case in point is a particular person who spammed the lfs, blfs, and livecd support lists for several weeks. Coddling doesn't work. In your class you have the power to teach them what you will. The book can be your basis, but I'm sure it isn't the majority of what you teach. The finer points should be what we focus on, not the requisite points. All IMO, of course, and I know some people will think I'm completely off my rocker. So be it. It doesn't change the fact that linux newbs too readily come to lfs. Best post of the year by a long shot ! this has been my point for a long time now, the book is simple and straight forward to follow, yet people do not read it, refuse to read it. They ask for support when they have never used linux before - depsite the requiremtns at the start of the book. The IRC support channel is excellent for supporting legitimate help requests and I've find it very satisfying to work through problems to a resolution with people, however the channel is flooded with people who don't follow the book or ask questions like "how do I copy of a file" or "what do I do with the tar files" etc. Its all very well saying "ignore these people" but its very hard to ignore them when they are interupting people with genuine problems, or when other people with no idea whats going on jump in and try to help them "try applying random patch $a" or "put your sources in /var/tmp" or "chmod -R 777 / - that works for me" the changes don't need to be made to the book, but the way LFS is supported. This has been a drum I've been banging for a while. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Hand holding (Was: Re: Post LFS-6.1.1 plans)
Gueven Bay wrote: Hi dear LFS devs, I am one of the - I think - many silent readers of LFS-dev. Normally I only read to gain insight how you develop (or better: write) the book but now I want to write some words here. I can understand that some of you are "not amused" of beginners who want to dive deep (into Linux) in their first day by using LFS. I know you do that what you do because it is a hobby for you and maybe some uses this "own distro" for some productive work. But you have to understand that in these days many out there see a chance in using Linux. Maybe they have no work at this time and searching for a workplace. Maybe they just want to make their skillset broader. Maybe they have a product and it should run on/with Linux now. So they come to LFS. Why? Because everywhere in forums or MLs you can read that to learn the mechanics of distributions you should make your own with this magical tome "LFS". So they come and annoy you. But this is also a chance. And this is what I want to say: Unfortunately the open-source projects -at least many of them- have not a "university" where new users can study this project. Some forums or some MLs/IRC channels only for guiding new users through the "product" of the project. This "university" for LFS would some (virtual) place where new users get to know every step through the book. They can ask questions about every step in it. Then there should be also some place where new but in someway advanced users can work through the writing and developing the book. The run on Linux and on many other Open Source projects are fortunate. And in my opinion THE source of knowledge about distributions - a central product in the Open Source scene - is LFS. Take the chance and "make" your own LFS devs by showing new users the ins and outs about this book. The ways how to write new sections about packages not handled in it and so on. And they get later the work of teaching new devs. I think with this way: You can make the book more and more a right technical text for hackers-so that you don´t have to write hundreds of pages of explanations- and because of the "university" there would be a place where new hackers are "born". I think that this would make this (already) great project more famous than you can imagine ;-) Ahh, there is maybe a question in your head now: What is the diff between our lfs-users and this "university". Now, all these *-users - not only here but also in other projects - are run by developers of this project who read/post at the side of their development task and some other new or advanced users of this project. But the "university" would be run by a developer who makes his whole task the teaching of new possible developers. Regards Gueven Bay __ Any intersting mail - but I don't see it as a valid point. If you are learning about engines - you don't dive in and take a ferrari engine to bits first If you are learning to cook, you don't cook a 5 course first class meal as your first attempt If you are Learning to fly - you don't go up in a 747 first If you want to learn linux - you don't start with LFS - LFS does not teach you linux - it explains how to put a working system together. In all of my examples above, If you went to Ferrari and said "I know nothing about engines but I'm trying to put a ferrari engine together" If you went to Gordon Ramsey and said "I've never cooked but want to cook a 5 star meal" If you went to Boeing and said "I've never flown a plain but fancy trying a 747 out" You would get told "sorry - this isn't the right approache try $X $Y $Z then when your read come back and we'll sort you out" this isn't true in LFS - we teach people how ot use ls, cp, touch, and even cover problems with peoples own distros, eg: fixing the gcc4 in Fedora. Do you think its fair that the people who work with LFS should have to deal and support with this level of ability every day ? think about it before suggesting LFS as an excellent project to "lean linux" from. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Post LFS-6.1.1 plans
Bryan Kadzban wrote: Matt Darcy wrote: LFS works as it is, it calls out at the start of the book what it will build, I don't see a need to move this to include more tools like a propritary package managment system. If there's one thing MSB's hint *isn't*, it's proprietary. Full sources for everything are supplied. (Most of what the hint uses is already installed on your system.) Not that I'm saying the hint as-is should go into the book (and as has been said many, many times before in this discussion: *NOBODY* is saying that!), or even that parts of it should go into the book (I haven't decided what I think about that yet). Just that this particular reason not to put it in -- it being supposedly proprietary -- is wrong. (People have already also pointed out that this suggestion was *NOT* about a package manager. It was about people learning where files were getting put, which of them were being installed setuid root, etc., etc.) I didn't mean propritary as in "source unavailable" I meant it as this is a package managment technique for LFS only, no other distro uses tihs technique. You point on it not being about a package manager is taken - and was taken when Jeremy said it, however people kept talking about it as an inclusion for future developments, and I feel it appropriate to make my thoughts on this know. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Post LFS-6.1.1 plans
Ag Hatzim wrote: Matthew Burgess([EMAIL PROTECTED])@Thu, Nov 24, 2005 at 09:44:29PM +: Hi Matthew. If anyone wants any other features included now's the time to get those requests in. I would like to propose to put reiserfsprogs,wget (with a note to rebuild wget from blfs,for those who would like support for encrypted http,which requires openssl) and maybe a text browser e.g lynx,into the book. With Best Regards. Agathoklis. wget/openssl are not part of a base linux system, they are additional options extras which are part of BLFS. The reiser FS tools is an interesting thought though. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Post LFS-6.1.1 plans
Andrew Benton wrote: Ag Hatzim wrote: I would like to propose to put reiserfsprogs,wget (with a note to rebuild wget from blfs,for those who would like support for encrypted http,which requires openssl) and maybe a text browser e.g lynx,into the book. +1 for wget Andy pussy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Post LFS-6.1.1 plans
Matt Darcy wrote: Andrew Benton wrote: Ag Hatzim wrote: I would like to propose to put reiserfsprogs,wget (with a note to rebuild wget from blfs,for those who would like support for encrypted http,which requires openssl) and maybe a text browser e.g lynx,into the book. +1 for wget Andy pussy sorry - that was meant to go to andrew direct - not the list tounge in cheek Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Experimental ELFS (Was: Re: More control...hint integration discussion)
Ag Hatzim wrote: Jeremy Huntwork([EMAIL PROTECTED])@Tue, Nov 29, 2005 at 12:32:59PM -0500: Snip 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. Ok lets give an end to these eternals debates (although i have to admit,are quite enjoyable :)),and lets create an experimental branch. The new branch will be dedicated to research and with emphasis to the various techniques that already mentioned to these endless threads. The new branch will have to be indepented from the LFS book,but with the clear purpose to implement any interesting/succesfull techniques later on into the LFS book. Three examples. a.The alphabetical-order branch is quite interesting,because it gives the chance to the people who came in a later stage to the LFS projects,to learn the how and why the book builds the packages with the way it does today,and quite probably to re-evaluate the package order. b.Destdir approach. c.Better intergration with jhalfs. On top of that,will give to some (with a tendency to sadomaxism :),me included) people the chance to deviate from the book and to experinment,hence the branch title. Ofcource there will be no support questions,and i know that might be quite temptable for some to follow... With Best Regards. Agathoklis. so you mean the lfs-development book then.. -- 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
Ah, yes. The Ultimate Question of Life, the Universe and Everything LFS.
I personally think it's more than just building a minimal working
system, and I think there are others that will agree with me there. That
should be shown by the fact that there are and continue to be such
packages as perl, auto{make, conf}, vim and readline in the base LFS
book. (This wasn't meant to start a discussion about whether or not
those packages should be there - we've done that already.)
--
JH
The answer is 42
Matt
--
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
Kev Buckley wrote:
Ah, yes. The Ultimate Question of Life, the Universe and Everything LFS.
I personally think it's more than just building a minimal working
system, and I think there are others that will agree with me there. That
should be shown by the fact that there are and continue to be such
packages as perl, auto{make, conf}, vim and readline in the base LFS
book. (This wasn't meant to start a discussion about whether or not
those packages should be there - we've done that already.)
--
JH
The answer is 42
Matt
Surely 57 - that being the number of package users created when
installing the current SVN of LFS (though I'm including
LFS_Bootscripts and the kernel as "packages" there )
Then again, maybe it is 56: because you don't really need to install
Berkeley DB (so to get arpd from IPRoute2) at the LFS stage of system
building ?
Not a hitchhikers guide to the galaxy fan ?
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: :: why not include Linux-Libc-Headers 2.6.12 + glibc 2.35 in LFS 6.1.1
Bernd Feldmeier wrote: Hi to all, sorry but as I know this release is bug fix release, but this stuff has nothing to do with the of any glibc/kernel stable versions. I think we should upgrade to these stable versions before releasing ... so we should use latest versions e.g. binutils 2.16.1 + kernel 2.6.14.x + glibc 2.3.5 ... please respond regards so - you've just said you know what this is a point release and that it is only a bug fix release, yet you still want to upgrade to the later versions of core products ?? why ? what driver do you have behind this ? here's a thought - you do it, then if it doesn't work, you support it. If you have put any research into the lists or the projects lfs/blfs/clfs (maybe hlfs) you'd know you can't just mix pacakges and get a stable system Best of look with your upgrades - and don't let me know if it doesn't work. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Using Linux-Libc-Headers-2.6.x.y + latest kernel version (e.g. 2. 6.14.x)
Mark Rosenstand wrote: On Wed, 2005-11-30 at 07:46 -0800, Dan Nicholson wrote: On 11/30/05, Feldmeier Bernd <[EMAIL PROTECTED]> wrote: Hello guys, I created a LFS 6.1.1 test system. But is there a problem if I use the latest kernel version ? Because Using Linux-Libc-Headers version and latest kernel version differs? It's perfectly fine as far as I know. Every major distro does it. In fact one of the main reasons to install l-l-h is so the glibc you installed will always have a known set of headers to interface with the kernel. All that happens is that your glibc can't use the new kernel features that come up, but other applications that are aware of them can. For instance, 2.6.14 includes something called FUSE (File Systems in Userspace) which allows ordinary users to mount various filesystems in userspace (I'm bungling the description). Anyway, my l-l-h headers are 2.6.12.0, but I updated the kernel to 2.6.14.2 and used the FUSE interface to my heart's content. Just an example. And I run a dovecot IMAP server without inotify-support on a inotify-enabled Linux 2.6.14 machine because it couldn't find And what is your experience with this ? Do you find that inotify works/is picked up by dovecot ? or do you find its just a feature that is enabled in the kernel, that is not picked up by applications. I'm interested Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Using Linux-Libc-Headers-2.6.x.y + latest kernel version (e.g. 2. 6.14.x)
Mark Rosenstand wrote: Matt Darcy wrote: Mark Rosenstand wrote: And I run a dovecot IMAP server without inotify-support on a inotify-enabled Linux 2.6.14 machine because it couldn't find And what is your experience with this ? Do you find that inotify works/is picked up by dovecot ? or do you find its just a feature that is enabled in the kernel, that is not picked up by applications. I'm interested I thought the "because" part made it pretty clear :) I would like it to use inotify, but it doesn't because the headers are too old. I never really understood why most (all?) distributors choose to use kernel headers that doesn't match the running kernel. got you - your right the because did make it clear to be fair. Just wanted there to be no confusdion that it wasn't built with inotify, nor could it use inotify. Matt -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New Project Leader for ALFS
Nice to see you back and %150 fully up to speed, the latest Livecd is pretty nice, and the fact that your managing your time better (as this mail shows), means you'll probably be around for longer. Nice to see your keeping things in balance and not afraid to give a few things up Nice ! Matt Jeremy Huntwork wrote: Hey All, Some time ago I stepped down from ALFS, (intending to leave LFS entirely, but that's another story) and left ALFS Leadership to Thomas Pegg. This was done suddenly and without fair warning to Thomas or the community. After discussing this again with Thomas he has agreed to continue as project leader for ALFS and I think he will do a great job there. He has been with the project for a substantial period of time now, and has been one of the few regularly active contributors to ALFS. He knows the project inside and out. This change should give the project a bit more stability and organization. Also it will free me to contribute to ALFS in my spare time without the stress of two projects to lead in addition to my personal responsibilities. So this post is just to inform the community of the change and make it more official. Congratulations Thomas! -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Book News Server entry
All, I recently updated the cross-lfs book to remove reference to the news servers, I left the fact in that they used to exist and no longer do to make it clear they where shut down intentionally. can I suggest that other project devs to the same in their books Matt -- 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chaps, can we put a little prespective on this. Its a dev-list, a development process has been put forward to the list for fun/evaluation/testing/feedback, this is not in lfs or cross-lfsyet, Matts done work on this also which I tested in the earlier stages of his work. Try the package, comment on it, don't try the package ignore it - its an option thats being presented. take a step back - re-evaluate whats going on here, and hit reply. Matt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDvX5kacXT1Pr2NdERAj4NAKDG0zJYS7R1xtM2Qo6vcHGkhqspqQCg0PSX 1jPuc8ghfQo4BuujSBqmYCY= =DjMj -END PGP SIGNATURE- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
