Sorry for the poor formatting, yes it was wrong release numbers it suppose to be gcc 9.2.0 and glibc-2.30.9000 and learning experience and relying on official releases totally make sense. I was thinking maybe there could be some CI way to track healthy upcoming releases but I can see it is not an easy task to do it through branches with release tags. Thanks Burak
2019-12-18 11:42 GMT+01:00, Ken Moffat via lfs-dev <[email protected]>: > On Wed, Dec 18, 2019 at 10:01:56AM +0100, burak sarac via lfs-dev wrote: >> Hello All, >> First of all thank you for the LFS! and your efforts, it is a great >> adventure and learning path. I just wanted to inform you that I start >> scripting build steps and located here >> https://github.com/qunixorg/scripts. Also cloned all possible repos >> under this user https://github.com/qunixorg to not create overhead on >> savannah, even some git submodules. I dont know how you do your builds >> also I am not sure if it will be help in any case, but I can say most >> of branches built on master head without problem. But still for some >> of them I had to checkout specific branch mentioned on LFS book (i.e. >> binutils 2.25 or gcc 33.9000). I simply added qunix-v0.0.1 tag to >> stable builds so each script look for this tag (exported by user >> before running scripts). For updating those repos I have added >> qunix-source-upstream tag with the details of upstream so i could >> automate in the future. I didnt count but I believe around 85% of >> repos has upstream rest needs to be handled manually. Also some repos >> required running bootstrap which needed additional autoconf, libtool >> etc... installation. I am on the chroot part now, you might notice I >> have used different variable names but I am waiting to finish all >> scripts (I believe until new year:)) then I will add header to all >> files in one shot mentioning its a copy of lfs and redirecting to lfs >> book. Only different issue I had, on binutils step 2 I had to add >> -fPIC flag to make it compile. Do you think its ok to add or I messed >> up somewhere? > > Please use whitespace in your emails - apart from the greeting and a > short line where your link to your scripts did not fit, the above is > a solid chunk of more than 20 lines, which makes it impossible to > parse. > > But a few comments: > > 1. Problems with building LFS mostly belong on lfs-support. This > list is for development of the book, so problems specific to LFS-svn > sometimes belong here. > > 2. We build using the tarballs and patches mentioned in the book. > No need to clone repos. In the rare cases where an upstream lacks a > release with fixes (all in BLFS, I think) we make a tarball. > > 3. I'm guessing that your references to binutils 2.25 and gcc > 33.9000 are typos. Some of the one-line commit summaries in parts > of your binutils tree are certainly more recent than 2.25. But > cloning master branches is often a bad idea for LFS - we prefer > releases. > > 4. Finally, the biggest learning experience when creating scripts to > build packages is when you discover that things do not always run > smoothly. Trapping errors is the key. And sharing build scripts > for something on this scale before they work encourages other people > to follow what may turn out to be a broken approach. > > ĸen > -- > We've all got both light and dark inside of us. > What matters is the part we choose to act on. > -- Sirius Black > -- > http://lists.linuxfromscratch.org/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
