Re: [lfs-dev] Future for LFS
On Sat, 13 Jun 2020 Pierre Labastie wrote: > the problem is not lfs, but blfs. There are around 750 packages in > there. If those packages are all updated twice a year (some have > much more frequent updates...), it makes 4 updates per day, 7/7. > Updates mean: get the source, check it is right (gpg signatures, > whatever), update size and md5. Build and test it, analyze and > restart when something gets wrong (very often, the instructions for > one version have to be changed for the next one), measure and update > sbu and disk usage, do a "DESTDIR" install to check new installed or > not installed files and dirs. Update the xml, publish. Also check > that dependent packages still build (not always done, actually, but > it means that full builds of blfs must be run from times to > times). Most of this cannot be automated because of the diversity in > upstream sources and build systems. I don't think all the above is necessary for ARM-BLFS. Judging from Pi-LFS most packages should build without special adjustments. There is no difference in the source package location, MD5 sum and dependencies. There is little need for a separately measured SBU. So for most packages I think that stating that the instructions have been tested on ARM in addition to x86-32 and x86-64 and are known to work would suffice. A dependency matrix for BLFS and some amount of build automation would be nice. The 750 packages are not equally important; there should be some mechanism to determine which ones have priority. By the way translation is a different story. One person has been working on translating LFS and BLFS into Japanese and he says he can't keep up with BLFS. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Why is the /toolchain symlink on the host system even needed?
Is there any problem with making a new directory at the filesystem base level? In theory there could be a distribution which already has a /tool directory. But I have never heard of that. What alternatives are there to /tool ? If /tool is so abhored, why not try /usr/local instead ? What happens when you do that? The /usr/local directory must be empty for this to work and you shouldn't do anything other than build LFS on this system. But if you dislike /tool , it should be worth a try. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] A straightforward makefile example for the uninitiated
The greatest surprise I got from my recent survey is that many programmers do not have experience with "make." Come to think of it, this may well be the case considering the great popularity of scripting languages. This made me think: which package of the 70 or so which comprise LFS has a makefile which would serve as good reference for someone starting to study "make" and makefiles? Perhaps gzip? -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] LFS lecture in Osaka: survey result
I thank all of you who have given me advice on this. According to the event organizers, 280 people came to the event held in central Osaka on January 26. 14 attended my lecture on LFS and 12 responded to my questionnaire. Here is a summary of the replies I got: - 1. Why are you interested in LFS? (multiple choice) (1) To learn about the internals of the operating system :12 (2) Necessary for work :0 (3) Want a flexible system :1 (4) Want a fast system :2 (5) To learn about package build conventions (configure, make) :1 (6) Other (please describe in detail) :0 2. What operating system / distribution do you regularly use for development? ... 3. Are you familiar with "make"? (1) Know little or nothing about it :5 (2) Use for project build, using makefile provided by the project leader :3 (3) Have written my own makefiles :4 (4) Can handle advanced features (nested makefiles, conditionals, etc.) :0 4. Are you familiar with the following sequence? ./configure make (make check) make install (1) Never done it :1 (2) Done it once or twice :6 (3) Done it many times :0 (4) Have tweaked configure options :2 (5) Have modified the makefile :2 (6) Both (4) and (5) :1 5. Have you ever compiled the Linux kernel by yourself? (1) Never tried it :9 (2) Attempted without success :2 (3) Succeeded once or twice :1 (4) Succeeded many times; confident :0 6. Much documentation necessary for package build is in English only. Is the lack of Japanese documentations a problem? (1) Can't build packages because of this :4 (2) Sometimes a problem :4 (3) Seldom a problem :1 (*) No answer :2 7. Did you know that the project management method widely used in industry originated in Bell Labs? (1) Did know :2 (2) Learned that in a previous lecture by the same speaker :2 (3) Did not know :8 8. Do you plan to try building Linux From Scratch? (1) Would like to try :7 (2) Would like to try after some more study :5 (3) Never in a lifetime :0 -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] LFS lecture in Osaka
I will talk about LFS on January 25th (Japan time, Saturday) in an open source event at Osaka. There are a many topics to cover. I find it unfortunate that there is not enough time to discuss kernel compilation in detail. As I stated in an earlier post, a major shortcoming in the LFS Book is that it says nothing about project management. Building LFS is a significant project and without basic management skills, one is not likely to succeed. Another way to see this is that if one does succeed, it means that he has management skills which may be worth mentioning in a career resume. I plan to distribute a short questionnaire to attendants. The following are the questions that I would like to ask. If anyone subscribed to the list has suggestions, I'd like to hear. I'll post a digest of the answers around next week. 1. Why are you interested in LFS? (1) To learn about the internals of the operating system (2) Necessary for work (embedded system, IoT, etc.) (3) As a personal challenge: to prove that I can get this done (4) Need a customized system (with what characteristics?) (5) other 2. What operating system / distribution do you regularly use for development? If you use more than one, please list them in descending order based on actual usage. 3. Are you familiar with the following sequence? ./configure make (make check) make install 4. Have you ever compiled the Linux kernel by yourself? (1) Never tried (2) Attempted without success (3) Succeeded at least once but not yet confident (4) Succeeded many times; confident 5. Do you think that a successful LFS build is within reach, given your current computing skills? If you feel that LFS is beyond your skills, can you describe what your shortcomings are? -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Debian 10.2 install changes LFS kernel entry in grub.cfg
Pierre Labastie a ecrit: > I do have multiboot with debian, and grub-mkconfig works OK: if you > put an entry in /boot/grub/grub.cfg with a "linux" > line, the "linux" line is copied verbatim to debian's grub.cfg. > Note that this supposes you do not have a separate boot > partition. If you do, you have to manually maintain grub.cfg, and > prevent debian from running grub-mkconfig. Thank you. I happen to use a separate boot partition. grub-mkconfig is version 2.02+dfsg1-20 -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Debian 10.2 install changes LFS kernel entry in grub.cfg
Recently I installed Debian 10.2 on a computer with both LFS and older Debian versions. The installer automatically produced a new grub.cfg in which LFS is listed as "unknown Linux distribution." To my great surprise the listed kernel was changed to the new kernel that comes with Debian 10.2. This had never happened in the past. I haven't checked but I believe that grub-mkconfig is responsible for this. The Debian kernel does not work with LFS because CONFIG_DEVTMPFS (maintain a devtmpfs filesystem to mount at /dev) is not set. There may be other issues. LFS may boot, but you may not have enough functionality to edit /boot/grub/grub.cfg . I don't know whether there should be some words of caution in the Book on installing other systems on the same computer after LFS. This issue is not directly related to building LFS so probably it has no place in the Book. On the other hand, many of us run multi-boot systems which means many people are going to go through this. To avoid the issue the obvious solution would be to use the custom install option of the Debian installer and skip the Grub set-up phase. However, it seems custom install is not as thoroughly tested as default install. I have encountered numerous problems with custom install and have decided not to use it. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Two versions of Ghostscript
Kevin Buckley wrote: > 1) Use of the term "GPL Ghostscript" in the LFS Book > In the BLFS Book, the package section title is just > "ghostscript-9.27", with a lower-case "g" and no "GPL", > and although the term "GPL Ghostscript" is used within > the section, there's no note as to why it's referred to > as "GPL Ghostscript". As I understand there are two versions of Ghostscript available from Artifex Software, the current maintainer. I can imagine that the original author of the BLFS page felt the need to distinguish between the two. It appears that you can't tell the difference from just the release number. I don't know what the differences are for I have never used the commercial version. https://www.ghostscript.com/doc/current/Readme.htm#Two_Ghostscripts https://en.wikipedia.org/wiki/Ghostscript#History -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS lecture in Tokyo
The session was well attended. There is interest in LFS in Japan, but not many people have tried it yet. I thank Mr. Jean-Marc Pigeon. I pointed out in my lecture that one reason for doing LFS is to learn about standard build practices. A Japanese translation of LFS version 8.4 is available. The translator, Mr. Matsuyama says he cannot fully keep up with BLFS. This page should be updated: http://www.linuxfromscratch.org/lfs/read.html -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] LFS lecture in Tokyo
I will talk about LFS on Saturday (Japan time) in an event for open source developers. The LFS Book has been translated into Japanese, but from what I have heard, it is not widely known. Initially I suggested the lecture title "LFS: The Operation System Built Entirely From Source Code" to the event organizers, but they said that those attending wouldn't recognize "LFS" and ordered me to change that to "Linux From Scratch". Those who have heard of LFS are likely to regard it a distant goal, something desirable but hard to achieve, a lofty dream. I will speak on the merits of LFS, how the build process works and prerequisite skills. Because I think consider a major shortcoming of the current LFS Book is failure to discuss project management, I plan to make it clear that you need project management skills to succeed in building a working system and tell the audience what those skills are. I will also briefly discuss disk partitioning, /etc/fstab and GRUB setup which tend to be largely automated in the installers of major distributions these days. If you have any advice for me please let me know. Thank you. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Chapter 5 stripping segmentation fault
> If you log in as lfs, the PATH is set in .bashrc, that is, after bash > has been launched. So, unless you have set PATH in the init scripts of > the host to something beginning with /tools/bin, the bash running for > lfs is the host bash (in /bin/bash). Of course, /tools/bin/bash will > be run if you type "bash" as user lfs. But the book never instructs to > do that. Thank you. The initial shell of any user including the lfs user is determined by the last field in /etc/passwd. This shell should be effective throughout Chapter 5. I used sed to extract commands from the html file for the "Stripping" section and put the results in a file and executed it as a shell script. Obviously a new instance of /tools/bin/bash is launched to accomplish this. I did this because I wanted an accurate record of commands executed during the build process. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Chapter 5 stripping segmentation fault
While constructing LFS v.8.4 I encountered a segmentation fault in Chapter 5 Section 35 "Stripping." I understand why this happened. I built up to Section 34, logged out and logged in as lfs again. PATH found the newly compiled and installed bash in /tools/bin and I ended up trying to strip a running program: /tools/bin/bash . Though I haven't tried, I expect the same problem with LFS 8.5 . If you construct LFS in one sitting as the book instructs, the host system shell would be the one running at the end of Chapter 5 and this does not happen. Chapter 2 Section 3 says: 2.3. Building LFS in Stages LFS is designed to be built in one session. That is, the instructions assume that the system will not be shut down during the process. So if someone shuts down the system at any point, he is deviating from the book and might encounter problems. Chapter 2 Section 3 lists what to watch out for but this particular issue is not mentioned. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Am I supposed to set some CFLAGS to build LFS ?
An explanation of why optimization is required to build Glibc appears in the official FAQ. Frequently Asked Questions about the GNU C Library https://sourceware.org/glibc/wiki/FAQ Question 1-12 Why do I get: #error "glibc cannot be compiled without optimization", when trying to compile GNU libc with GNU CC? --- The Glibc developers say that inlining must be enforced in certain circumstances to cope with situations that are peculiar to Glibc. I believe that it is not quite accurate to describe this as an optimization issue. The goal of optimization is better performance. A very smart compiler may figure out that inlining a certain function does not lead to a performance gain and make it an independent, standard function, overriding the intent of the programmer stated by "inline". My guess is that GCC does not do this, but there is no guarantee. If inlining must be enforced, the right way to do it is by setting a compiler option that does just that where it is necessary. Using "-O2" for that effect is not sound. I frequently override the default CFLAGS and provide my own, but not when building Glibc. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Am I supposed to set some CFLAGS to build LFS ?
Many years ago I discovered that Glibc does not build with "gcc -O0" while conducting some experiments. If I remember correctly LFS was around version 5.1 or so at that time. The Glibc in LFS v.5.1 is version 2.3.3. I consulted my good friend Richard of Free Software Foundation. He conveyed my message to the Glibc developers. Their response was that the developers "consider -O2 the standard". Thus this message: # error "glibc cannot be compiled without optimization" My memory is sketchy but I recall that a certain form of inlined functions was a problem. I do not think that code that relies on optimization is a good idea. It is bad for portability and security. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Sanity checks for LFS
In September 2018 there was some discussion on sanity checks for LFS on this list. I see that lists has been uploaded to linuxfromscratch.org. http://anduin.linuxfromscratch.org/~bdubbs/sanity.html Many thanks for providing the lists. I'd like to ask whether it has been made visible to LFS Book readers. I can't see a link to the above page in LFS 8.3. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
