On 2020-10-02 19:55 -0400, Scott Andrews via blfs-support wrote: > On Fri, 02 Oct 2020 13:06:12 -0500 > DJ Lucas via blfs-support <[email protected]> > wrote: > > > On October 2, 2020 6:51:04 AM CDT, Scott Andrews via blfs-support > > <[email protected]> wrote: > > > On Thu, 1 Oct 2020 23:11:37 -0500 > > > DJ Lucas via blfs-support <[email protected]> > > > wrote: > > > > > > > On 10/1/2020 8:29 AM, Scott Andrews via blfs-support wrote: > > > > > In a clean install of LFS-9.0 in an overlayfs... > > > > Never mind a couple of days. Both issues are fixed in svn/git. I > > > > have > > > > > > > another minor group of changes added for lsbinstall, but lsbinstall > > > > will not be feature complete yet. I'll push a release with the fix > > > > over the weekend if I don't finish that work by Saturday. With your > > > > version of the scripts, your test case should work with only the > > > > mod 0 guard. I'll repeat here since it hasn't made it to the list > > > > yet. > > > > > > > > > > > > > > https://github.com/djlucas/LSB-Tools/commit/041b7f54cb483ae31646372dcbb802db17315ac5 > > > > > > > > > > > Still not sure why line 297, however. In 0.7 it should be line > > > > 327. > > > > > > I am building my system conform to LSB. I remove all the rc.d > > > directories and have rpm run install_initd. > > > This is from a config file that I use to build a spec file from, > > > then rpmbuild actually builds the package, then rpm installs it. > > > I have bash scripts that automates the entire process. I can then > > > build reproducible builds My process of building finds many errors > > > in LFS and BLFS, that I know will not be addressed so I don't post > > > them. Don't want the arguments > > > > > > > I'm confused. Does this patch somehow not fix your issue? You > > probably need to look at why the line numbers are incorrect (bad > > symlink to a previous version is my best guess), but that's not > > related to the problem at hand. > > I will generate a patch from git and apply it to see if it fixes the > issue. I will also test remove_initd to see if all the scripts can be > removed without error. That should work as well, I guess I'll see. > > I use to do programming for Kronos the time keeping folks, so I have a > way of rooting out the fleas in software packages. Now as to fixing > issues and posting a patch, should I also take the "LFS approach" I > didn't write the software at hand, "Your software, Your problems" (see > below, last paragraph).
Perhaps yes. There are at least two examples, glib logging level patch and coreutils i18n patch, in the book. The upstreams just don't like them. Then should I cry and say "you guys should take my patch or you are evil"? > Do you want me to continue to test this package or not? > > > > > BTW, it's perfectly fine to post workarounds for issues that you > > encounter, and even to ask for help when going beyond what the book > > covers, but the book is the book, and that's separate from your build > > project. It does not logically follow that every issue you encounter > > building in RPM is a problem with the book itself. Using a package > > manager is entirely different than building directly on target. I > > have around 100 changes from what is in the book that are simply not > > appropriate for the book at https://github.com/djlucas/LFS-Pacman/ > > for instance. We do account for some of the changes necessary. For > > example, lots of Gnome packages require post installation steps when > > using DESTDIR, and these are covered by notes in the book. I'm not > > sure I understand your frustrations above. You can, and should be > > encouraged to change whatever you need to change for your environment. > > > > I build my system(s) for what I need. When I uncover issues I report > until of late....... It seems as if no one here wants to deal with > fixes/errors. > > My post is about uncovering issues that are hidden by building in place. > Build the packages in a clean chroot, most here don't even know what > that means, let alone the benefits that it brings. > > The Xor build is absolutely horrid. I would help to rewrite that > section but being told your on your own one to many times has had a > negative affect, ie I got the message, I am not welcome here, just > shut up and leave, I "get it". > > Also in a lot of places files on the host system are simply > over written. When that happens you have zero idea where the true > problem resides as you don't even know what has just occurred. Nor can > you reproduce it. > > Another example, updating glibc, the book states that it is not > recommended/can't be done, That is simply not true. Maybe that is > true for a system that is built "in place" as in LFS, but it is simply > not true otherwise. I reinstall and update glibc quite frequently. > > The book in my opinion, is only good for a sequence and little more. > When I complete my new build sequence the book will not be relevant. > > I am also perplexed by the attitude of some here that the ARM platform > is simply not needed and not to be addressed. "We only do x86_64"! > You folks hereby missed the platform that many are using for learn from. > Why discount a platform that is used in many schools to teach computing. > Why not embrace it so people can learn and return work back into the > industry? What is the REAL goal of LFS? The status quo of alternative platforms, unfortunately, is almost totally "your software, your problems". Mainline kernel just doesn't work. The device vendors maintain their own kernel code and it never keeps up with the mainline (often stays at 5.4 or 4.18, I've even seen 2.6). If you complains, the vendor will just say "the system is running fine and who cares about the kernel version", or "don't messing around, use our distro". What can we do here? 1. Keep the vendor kernel and just build a user space. It's not Linux From Scratch, only "some GNU or non-GNU user space from scratch". After all "Linux" means the kernel, originally. 2. Pull the kernel source code from some stupid vendor repository, which is based on some ancient kernel release. Then we can't maintain a book as new packages may need new kernel features, and we may have to configure the kernel exactly same as the vendor. 3. Rebase the vendor's kernel changes to latest mainline kernel. I tried (on a very famous ARM board, and a not so famous MIPS board) but I just couldn't even make the kernel boot. Maybe I'm too stupid. 4. Don't care the hardware, just test the book with QEMU. Then what's the meaning of this unusable "port"? > So again it looks as if I am told to go it alone, I have lost count on > the number of times I have been told that. > > Lastly, when folks ask for help a good number of them are simply > told "Your distro, Your rules" That is completely unacceptable and > helps no one. As I stated last post...I know will not be addressed so I > don't post them, Don't want the arguments. -- Xi Ruoyao <[email protected]> School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
