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). 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? 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. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
