Re: [lfs-dev] libnl
On Mon, 9 Jan 2012, Ken Moffat wrote:
On Sun, Jan 08, 2012 at 10:01:21PM -0600, Bruce Dubbs wrote:
4. I don't really like /etc for the /etc/libnl/{pktloc,classid} files.
that's not the kind of thing a user would change, especially with an
editor. I'd suggest /var/lib.
Why do you think users should expect to change anything in /etc ?
[...]
On a day-to-day basis, I don't edit anything in /etc.
Well, I'm not sure whether this was the original intention, but to me this
kind of distinction does make sense. Maybe not from the perspective of a
user of a *LFS system, but for a user of *LFS, i.e. a system
builder/maintainer. Whenever a system is not (yet) behaving the way I
want, I do consider changing files in /etc. I would hardly ever consider
changing files in /var/lib. Personally, I do not actually care about libnl
at all, but if those config files are not meant to be edited by people
other than libnl maintainers, I'd expect to find them in /var/lib instead
of polluting /etc...
Regards,
Uwe
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] libnl
On Tue, 10 Jan 2012, Ken Moffat wrote: OK. What sort of things do you change in /etc ? For me, mostly building desktops (with shared /home), the idea of having to tweak files in /etc to get it working properly is uncommon. For me, mostly maintaining kind of servers, pretty sure the majority of configuration tasks is within /etc: add sites/domains to apache, modify recipient_bccs or transports for postfix, add ssl certificates, add/modify users/groups/aliasses, tweak system-wide spamassassin rules, add devices to fstab, stuff like that. In an ideal world you may only have to change such things once - when you setup the system, e.g. setting up a hostname. But demands tend to change... And its a quite convenient to be able to say: well, something is not working the way it should (now) with lets say apache, OK, lets take a look at /etc/apache/*. And I appreciate _only_ finding stuff there, that I might potentially want to change. Regards, Uwe -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GCC-4.5.0 - Pass 2
Hi, On Fri, 16 Apr 2010, Bruce Dubbs wrote: Andrew Benton wrote: Googling on that suggests that the error is related to setting the -march CFLAG whilst using a cross. compiler. Google led me to this patch which solved the problem: diff -Naur glibc-2.11.1-orig/nptl/sysdeps/pthread/pt-initfini.c glibc-2.11.1/nptl/sysdeps/pthread/pt-initfini.c diff -Naur glibc-2.11.1-orig/sysdeps/unix/sysv/linux/i386/sysdep.h glibc-2.11.1/sysdeps/unix/sysv/linux/i386/sysdep.h Where did you find the patch Andy? Had the same problem last night and found the same solution. There were other attempts (just undeffing __i686) but this one is probably from www.eglibc.org/archives/patches/msg00073.html, at least I found it there, well, and ist the first Google hit for __i686 and pt-initfini Uwe -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An important typo in mpfr
On Tue, 17 Nov 2009, Bruce Dubbs wrote:
Jean-Philippe MENGUAL wrote:
The problem is the \ before {} (\{}). Not bug but to learn it's not
exact. The line should be: find . -name \*.html -type f -exec cp -v
{} /usr/share/doc/mpfr-mpfr-version; \;/userinput/screen
The . after find is also redundant.
Well, depending on the version of find... The one from (current) MacOS X
for example requires the '.' (there is no --version, but 'man' claims it
to be the BSD version and a superset of what IEEE 1003.1-2001 (POSIX.1)
defines). Therefore I'm voting for leaving that 'redundancy'.
Uwe
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: LiveCD Users
Hi, 1) What version of the CD do you use/have? Some 6.2-x, when I last needed one, about half a year ago. 2) What do you use the CD most for? booting a box where no working current Linux is installed, i.e. prior Linux installations are damaged, too old for a certain purpose or just not existing. 3) What are the most useful parts of the CD to you? Having a known good Linux installation that 1) enables me to start building LFS on a box without having to care about prerequisites like kernel versions on that box and 2) can be used as fallback OS in case anything went wrong (boot sector overwritten or something like that). 4) What is the most annoying or useless bits of the CD? I never examined what I did not use of it... Well, the sources are not that important to me, because I tend to use the most current (and externally stored) versions (and not the ones from the last LiveCD at hand) if I decide to play with LFS again. On the other hand: if there is enough space its convenient to have a good starting set of packages available at no extra cost. Most annoying is probably having to specify the same parameters (like keyboard layout) every time when booting. But I'm not sure either whether storing that somewhere on HD or giving the user a certain time to press a key to enter such info instead of using a default would be better. 5) What would you change/add/improve? For me, having a current always works solution is the main benefit, but I dont have any idea at the moment how that could be improved further. Uwe -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Various issues with the book
On Sat, 24 Feb 2007, Dan Nicholson wrote: On 2/24/07, Bryan Kadzban [EMAIL PROTECTED] wrote: OTOH, I don't know why most of these people think it's the CLFS package either -- are they doing a search on linux-headers and finding that package? Or are they doing something else that's pointing them there? I don't think any of these suggestions should be used unless they help fix the root of the user confusion -- and I don't know what that is for sure. This was the same reason I couldn't come up with anything. I'm worried that just putting the version number after Linux won't help people in this situation. But it'll have to do until an actual confused user suggests something different. Well, I'm not actually confused, but I think my view on that topic might be helpful nevertheless. In my case the unknown thing pointing to Jims headers is my memory. There was a time when those headers were the way to go to get sanitized headers. Since that time there is a connection (although no strong one any more) between the term linux-headers and the requirement to get a package with that name. The package is actively maintained, and accordingly my scripts that regularly harvest the web for new package version from the original sites still get new versions of it. I remember having thought months ago: didn't they want to use the headers provided by the kernel build target? Why is there still a page called linux-headers? A quick look into it ended that estonishment, the content is more than obvious. I think naming it linux-$version-headers would have prevented me from having to look into it, but I do not like version numbers in places were they are not required or appropriate. If there is the wish to rename it to avoid confusion I would vote for somethimg more descriptive just as in other cases that do things other than just installing a certain package. E.g. installinglinuxheaders. Uwe -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [LFS Trac] #1657: Chapter 5 Stripping Notes -- need updating to reflect current numbers
On Wed, 12 Apr 2006, Jeremy Huntwork wrote: This is all good stuff. But the question still is how crucial is this space to a by-the-book LFS build? Even if saving space on the partition is not crucial, there are a some reasons for me to clean up /tools anyway: /tools is intended to be a somehow minimal set of tools required to build chapter 6. Debugging symbols are not needed for that and man pages shouldnt be either. So I would at least like to see a chapter 5 stripping note telling me that I have unused stuff in /tools that can be removed. Furthermore I like to backup /tools, e.g. for reference or to start several chapter6 (-like) builds. Knowing about what can be removed from /tools is helpful for that too. Whats wrong with having a stripping note that can be skipped by people who do not want/need to clean up /tools? Uwe -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: KDE Installation
Hi, ./configure --prefix=$(kde-config --prefix) This way, you are essentially assured that the entire KDE installation will be in the correct prefix, even if someone later resumes installing KDE and forgets to set the $KDE_PREFIX. Hmm, here you may assume that the install is done in the command line by using copypaste from the book. No matter which way people build additional kde apps, I dont see the educational gain in having to set KDE_PREFIX instead of using kde-config --prefix. The later just avoids useless problems, because humans as well as scripts cannot falsely assume that KDE_PREFIX is set correctly. CU Uwe -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
