Re: [DIY BUG] bash wants en_US locale
Jeremy Huntwork wrote: And to further clarify, an LFS machine as it currently is does *not* automatically use UTF-8. The changes to the LFS book are so that the LFS system *can* use UTF-8 properly if a user requires it. IMO, this is I'd like some clarification on one point then. IIRC, I read in a post by Alexander that the changes to the book made it so that ssh would no longer connect properly to non UTF-8 systems. In order to do that you had to run ssh through screen. This would be a *massive* inconvenience issue for me. Is this the case just by following the new book instructions, or is this only the case if you set your locale to a UTF-8 locale? -- Registered LFS User 6929 Registered Linux User 298182 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: error texinfo-4.8/info/terminal.c:236: undefined reference to `tgoto'
Andrejs Spunitis wrote: > /**/For automation LFS, I've writtten the script > accordnig to instruction from chapter 5 that: > http://www.dzti.edu.lv/isp-serv/a7/lfs-toolkit.txt > > For building I use LiveCD: > http://ftp.osuosl.org/pub/lfs-livecd/lfslivecd-x86-6.2-pre3.iso > > I've mounted /dev/sda4, then setup network and sshd, > copied needed src to /mnt/src and then run command > # nohup ./lfs-toolkit.sh & > > My hohup.out file can bee seen at the address: > http://www.dzti.edu.lv/isp-serv/a7/nohup.txt > > ERRORS: > /mnt/src/texinfo-4.8/info/terminal.c:236: undefined reference to > `tgoto' > /mnt/src/texinfo-4.8/info/terminal.c:236: undefined reference to > `tputs' > > and at the end of make textinfo: > collect2: ld returned 1 exit status > make[3]: *** [ginfo] Error 1 > make[3]: Leaving directory `/mnt/src/texinfo-4.8/info' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/mnt/src/texinfo-4.8/info' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/mnt/src/texinfo-4.8' > make: *** [all] Error 2 > > What is the problem? > > Please send support requests to lfs-support. -- Registered LFS User 6929 Registered Linux User 298182 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: error texinfo-4.8/info/terminal.c:236: undefined reference to `tgoto'
Matthew Burgess wrote: > And please trim your quotes! Nearly ~40 lines of quoted email to add a > 6-word sentence is ridiculous. My apologies to the list. I had just sent off a bunch of emails rapid fire and the previous one in this thread being the last one, I guess I wasn't paying too close attention. -- Registered LFS User 6929 Registered Linux User 298182 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Question about X-Org GCC.4 in regards to upgrading from LFS 6.1
Dan Winkler wrote: > Hello All I have a quick question. > > I have completed LFS 6.1 and would like to get Xorg installed This question is best asked to blfs-dev or blfs-support. The lfs-dev list is for development of the base LFS book only. -- Registered LFS User 6929 Registered Linux User 298182 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Proposal for new (sub)branches: (BSFS - HPFS - LLHFS)
Feldmeier Bernd wrote: > Hi All, > > As I followed this list a couple of month now, > I would like to make a proposal for the LFS branch. > 1) BSFS - Bootstrapping From Scratch sub-branch > 2) HPFS - Hotplugging From Scratch sub-branch > 3) LLHFS - Linux Libc Header From Scratch sub-branch I'll assume for the moment that you mean merely new testing branches and not whole new subprojects, as your naming scheme suggests. If in fact you mean whole new subprojects then, no offense, your plan is ridiculous for one and two. > ->1) All the toolchain problems could be solved there As for the toolchain, if everything goes as it usually does, I'm sure unstable will start testing gcc 4.1 and glibc 2.4 after the 6.2 (or 6.1.2 or whatever it will be called ) LFS book is released. An argument can be made for cutting a new branch in svn now for the testing of the new gcc and glibc, but personally I'd rather see the devs concentrate on the next release. > ->2) All HAL/Udev - hotplug problems could be solved there The Udev_update branch has been cooking for a while now and is already slated to be merged into the trunk. > ->3) All the great work in the llh project so far could be solved there Personally, I think creating a subproject for the libc headers only makes sense if the people working on them intend to release them, similar to how the llh people did. That poses whole new problems though, as then the lfs servers might end up experiencing llh-style traffic and would have to serve up lots of bandwidth for downloads of the headers (although I suppose the headers could be torrented to reduce the load). -- Registered LFS User 6929 Registered Linux User 298182 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
OT Re: Livecd Versioning
Thomas Trepl wrote: I personally build my boot-cd with something like -march=i686 -mtune=i686 just FYI, -march implies -mtune. using both is redundant. -- Registered LFS User 6929 Registered Linux User 298182 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Binutils failure in Chapter 5
Randy McMurchy wrote: It's my opinion that the current SVN (20050303) is rock solid and worthy of a release. I have a couple systems running it, without problems or issues that I've seen. Additionally, Anduin is running on a very similar platform (just a few packages are not up to the current revs, but the toolchain is the same). I won't go so far as to suggest a release, as I feel that kind of thing is better left to the devs, but I will back Randy's claim that current SVN makes a solid build. I just built SVN 20050302 last week and I've been unable to hose the system. Everything appears good. However, let me be thorough and list my deviations from the book even though some are fairly trivial: 1) Instead of Libol and Syslog-ng I build pcre and metalog 2) I compile grep with --enable-perl-regexp 3) I do not build gettext and I pass --disable-nls to whatever will take it 4) I use MSB's pkg-user system for package management 5) I use bash startup files from BLFS with a few modifications So perhaps my systems aren't the best test cases for the book, but I do follow the book fairly closely, and I agree with Randy that current SVN is looking good. -- Registered LFS User 6929 Registered Linux User 298182 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev testers required
Jim Gifford wrote: There was also to be a hold on udev util that was worked out also. Frankly, that's silly. There's no need to put a hold on upgrading udev until the new /etc/group is pushed out. Package upgrades should keep pressing forward. When the time comes that the new groups file is added, then a simple config change is needed to udev, a config file which you have already made and is ready to go. Package upgrades should continue as normal in SVN and when the new groups file gets implemented then the new udev config can be thrown in at the same time. It seems that simple to me, unless of course I'm missing something. -- Registered LFS User 6929 Registered Linux User 298182 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bootscripts SheBang
Matthias Berndt wrote: Greetings! Wouldn't it make sense to change the SheBang in the bootscripts from '#!/bin/sh' to '#!/bin/bash' because the scripts are not bourne shell compatible? I'm asking because I changed /bin/sh from /bin/bash to /bin/zsh and made a disaster. Please tell us the kind of errors you are getting. The bootscripts, I believe, are tested as working with bash and ash. -- Registered LFS User 6929 Registered Linux User 298182 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Wording for configuring perl in ch6
Andrew Benton wrote: I agree, but people tell me it's wrong to start sentences with "however" and "but" because they're linking words It's a perfectly legal sentence. In school, we used to call sentences that started like this "spoilers." I don't remember school a lot, but I do remember working on these sentences in English. We wouldn't have done exercises with them if it wasn't acceptable to use them. -- Registered LFS User 6929 Registered Linux User 298182 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Wording for configuring perl in ch6
Matthew Burgess wrote: Joel Miller wrote: We wouldn't have done exercises with them if it wasn't acceptable to use them. So are you telling me that all those Visual Basic exercises I did means it's actually acceptable to use in the real world? :) toucher -- Registered LFS User 6929 Registered Linux User 298182 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Ready for gcc-4 & cleaning up binutils source delete or not.
TheOldFellow wrote:
A bit of a disclaimer before I try to pick apart this script a little.
All internal politics discussions aside, I greatly respect Greg's
technical prowess, and my trying to make changes to a script by some one
who knows a lot more than me will probably break things. That said, here
is what I would change to stay in line with LFS.
LDFLAGS="-s"
The last time we explicity had the linker do stripping was LFS 4.x IIRC.
Unless there is good reason to have this flag, we should probably drop it.
TZ='Europe/London' # the right timezone
This, I think, needs an explanation before we use it in the build. The
only time thus far that we've needed to set TZ is to test one of the
packages (I forget which).
CONFIG_SITE=${HOME}/config.site # this obviates the need for many
# --prefix=/usr - where the gnu-autotools
# have been properly used.
cat > ~/config.site << "EOF"
test "$prefix" = NONE && prefix=/tools
test -z "$CFLAGS" && CFLAGS="-O2 -pipe"
test -z "$CXXFLAGS" && CXXFLAGS=${CFLAGS}
enable_nls=no
EOF
This is interesting and I didn't know you could do this. I'll play with
this in my next build. The thing is though, as much as my personal
builds use CFLAGS, CXXFLAGS, LDFLAGS, and --disable-nls, none of that is
done in the book. Taking those out leaves this as just setting the
prefix. Boils down to a judgement call by the editors I guess.
# Greg builds copies of bash, make and sed to be certain that all
the scripts work even if the host-distro is quite odd/old.
# Binutils pass1
#--
See LDFLAGS issue at the top.
# Gcc-4.x pass1
#--
make \
BOOT_LDFLAGS=${LDFLAGS} \
BOOT_CFLAGS="-O2 -pipe" \
STAGE1_CFLAGS="-pipe" \
LDFLAGS=${LDFLAGS} \
bootstrap
Again, the flags thing. Unless there is a technical reason to leave them
in, the book's policy thus far has been to not set CFLAGS, CXXFLAGS, and
LDFLAGS for the user.
# Adjust Toolchain
#-
I=`gcc -print-file-name=include`
rm -rfv ${I}/*
J=`gcc -print-file-name=install-tools`
cp -pv ${J}/include/* ${I}
cp -pv ${J}/gsyslimits.h ${I}/syslimits.h
# Comments: ${I} is the absolute name of the library dir 'include' that gcc
#would use when linking. ${J} is the same for 'install-tools'.
#So the script deletes the current contents of the 'include' dir,
#and copies the 'install-tools' version there instead.
As much as the comment here explains what it does in a physical sense, I
can already see that. What I don't see is the bigger picture of why this
is done. The README file tells me, I think, that the
install-tools/include/ directory is where the headers that were "fixed"
by the fixincludes process get put. Is the above scriplet similar or the
same to our fixincludes patch?
# GCC-4.x Pass 2
#-
sed -i.bak \
-e 's,\./fixinc\.sh,-c true,' \
-e '/^LIBGCC2_DEBUG/d' gcc/Makefile.in
Then again, the above sed looks more like the fixincludes patch as I
think it prevents the fixincludes process from running.
mkdir ../gcc-build
cd ../gcc-build
../gcc-4*/configure \
--with-local-prefix=/tools \
--enable-shared \
--enable-languages=c,c++ \
--enable-clocale=gnu \
--enable-threads=posix \
--enable-__cxa_atexit \
--disable-libstdcxx-pch
make LDFLAGS=${LDFLAGS}
make install
# Binutils Pass 2
#--
make LDFLAGS=${LDFLAGS}
LDFLAGS again.
#=
# CHROOT
#=
# Man-Pages
#---
rm -fv man1/{chgrp,chmod,chown,cp,dd,df,diff,dir,dircolors,du}.1
rm -fv man1/{install,ln,ls,mkdir,mkfifo,mknod,mv,rm,rmdir,touch,vdir}.1
rm -fv man3/getspnam.3 man5/passwd.5
Interesting approach. Rather than install the man-pages and have them
subsequently overwritten, simply prevent the man-pages versions from
ever being installed. I personally disagree, and use the man-pages
versions of the documents rather than the man pages provided by the
specific packages, but seeing as the book does the opposite this is
something the editors may want to consider even though it doesn't do
much to change the end result.
# Glibc-2.3.X
#
CFLAGS="-O3 -march=i686 -pipe" ../glibc-2.3.*/configure \
There is likely a reason that Greg decides to use different CFLAGS for
glibc then for all the other packages. We need an explanation for this
if we do it in the book. Of course, the book has been advocating the
build of glibc without CFLAGS for a while now, which further begs an
explanation. I personally think it's still a throwback from when
linuxthreads would bomb if you set CFLAGS. I personally have built glibc
many times with "-O2 -march=pentium4 -mmmx -msse -msse2 -mfpmath=sse
-fomit-frame-pointer -pipe" without issues. The -mfpmath=sse creates
iss
Re: news for newbies?
Tony Morgan wrote: As y'all know, I'm new here... well, mostly new. Well then allow me to welcome you to the community. Was wondering if someone could fill me in on this... What's the deal with cross-lfs? Ok, I know it's a book (or, really, a set of books) for people compiling LFS on a system other than the one it will be used on. At the moment cross-lfs is a set of scripts by the wonderful and talented Ryan Oliver that allow a user to build LFS by cross-compiling it. This, as you mentioned is necessary if you are building from one architecture but want to run the binaries on another architecture. There is also a book based on Ryan's scripts under development by Jim Gifford and others on the dev team. This book under development is expected to become version 7 of the LFS book. My understanding, from what I've read here, is that the reader will initially be presented with an option similar to this: Q: How will you be compiling LFS? A: I will be compiling LFS on [[choice #1]] to be used on [[choice #2]] Where [[choice #1]] will be, for example, a drop-down menu with choices "an x86 (aka IA32, Pentiums)", "an Alpha", "an x86-64 (aka IA64)", etc. And [[choice #2]] will be either the same, or perhaps the same with the extra option "the same machine". That's the current idea as I understand it. Through the magic of XML, an attempt will be made to present a book to the user based on their requirements. I don't do web development so maybe some one else can speak better to this part. Will cross-lfs eventually replace the standard LFS? So, and equivalent of the standard LFS (as it is today) would be choice1="x86", choice2="the same machine". There's been some recent discussion about this. The new cross-lfs book *might* totally replace the current LFS book if the aforementioned XML magic can be pulled off. Another idea brought up was simply to maintain two books, one for people cross building and one for people where the host and target system are the same. If cross-lfs is everything I've mentioned here, then it sounds like an exciting challenge to the dev team. If cross-lfs isn't going to cover "Compiling on the same machine it will be used on", then might i suggest such a thing here and now? I can see, however, that it may slow down progress, since to upgrade mypackage-2.3.8 to mypackage-2.4.0 would require thorough testing on a great many more machine combinations than previously needed. Anyway, sorry to ask questions that I'm sure everyone's sick of answering :/ Don't worry about asking questions. Believe me, there are lots of questions that come up on the -support list that I (and others?) grow tired of answering, but that's a whole other story. :) -- Registered LFS User 6929 Registered Linux User 298182 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: UTF8 nitpicks
Randy McMurchy wrote: Tushar Teredesai wrote these words on 01/09/06 12:19 CST: * 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. 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. -- Registered LFS User 6929 Registered Linux User 298182 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
RE: devel book, gcc 4.0.2 2nd pass fail
Wade Nelson wrote: > [EMAIL PROTECTED] /mnt/lfs/tools $ readelf -l a.out | grep ': /tools' > [Requesting program interpreter: /tools/lib/ld-linux-x86-64.so.2] > have been following devel book verbatim, except using --disable-multilib > for 1st & 2nd pass gcc compiles > > host system is: > emerge --info > Portage 2.0.51.22-r2 (default-linux/amd64/2005.1, gcc-3.4.3, > glibc-2.3.5-r0, 2.6.12-gentoo-r6 x86_64) Firstly, I'd like to tell you that we appreciate the detailed information. Not everyone who asks for help on theses lists gives all the information we may need in the first message. Secondly, given the host system and the fact that you are passing --disable-multilib as a configure argument, it would appear that you are trying to build a 64-bit only version of lfs. Jim Gifford and others have been playing with doing things like that over at cross lfs. You are probably going to want to go to http://www.linuxfromscratch.org/clfs/view/cross-lfs/x86_64-64/ and look at the Pure64 book for x86_64. -- Registered LFS User 6929 Registered Linux User 298182 <>-- 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
Jim Gifford wrote: > Tushar Teredesai wrote: > >> 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. >> >> >> > That is correct, I'm not going to even put this into cross-lfs until > those issues are resolved. There are so many of them. The net-fs > stuff, drivers not having uevent. Which as of today is in the works > for 2.6.16, which reminds me to update the todo list of cross-lfs. > I get tired of people saying I'm keeping everything secret of what I'm doing. I brought what I found to the masses now that it works properly, and now I'm getting harassed for it. Do I really deserve this treatment, I don't think so. I'm tired of this crap, especially from you Randy since your the only one who seems to have the problem with what I'm doing and what I have accomplished with Cross-LFS. I think it may be time to reinstate the lfs-hackers list, this thread is a really good example why. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page <>-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 2.6.15 Hotplugging/Coldplugging via udev
Jim Gifford wrote: > I get tired of people saying I'm keeping everything secret of what I'm > doing. I brought what I found to the masses now that it works properly, > and now I'm getting harassed for it. Do I really deserve this treatment, > I don't think so. I'm tired of this crap, especially from you Randy > since your the only one who seems to have the problem with what I'm > doing and what I have accomplished with Cross-LFS. > > I think it may be time to reinstate the lfs-hackers list, this thread is > a really good example why. Apologies for the previous email with no text. My hand slipped. I rarely post on these lists, but I have lurked them since the 3.x days. Back then device creation was considerably easier. I won't try to read tone into anyone's email, but I can say that few people posting seem to appreciate the strides Jim has made towards getting the new udev setup working. One should always ask questions so that the process can be refined, but this is still very much in a testing stage. AFAICT, no one is looking to commit this to the book right now. Jim appears to be calling for testers and in my experience, a testing setup is rarely pretty or pure. I personally would like to thank Jim for making the headway he has, and would like to apologise that I don't have a box I can experiment with right now so that I could help test this new setup. Having read this list for a long time, I too would like to see lfs-hackers reinstated where stuff can be thrown about and tested so that it can be refined before it is brought to this list where the tough questions of getting it in the right form for the book can be addressed. My $0.02. -- Registered LFS User 6929 Registered Linux User 298182 <>-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
