IRC channel logs
2022-12-17.log
back to list of logs
<Irvise_>Hi, would this be a "solution"/allowed for a bootstrap? <Irvise_>It is obviously not a great thing, and could be easily generated with another system. But manually writing that binary file shouldn't be that hard nor bad would it? <Irvise_>Btw, has the issue with CA-certs been fixed? I would like to try it once again <stikonas[m]>But keep in mind that in live-bootstrap we try to rebuild even all text files that were generated <oriansj>Irvise_: intern solutions are always ok if there is a plan in place to remove the need for them later. For example when MesCC got started it needed GCC to compile but there was a plan to just rewrite it in a lower language later (you can see that in janneke's first talk) and only later after much work was done was M2-planet ultimately what bootstrapped MesCC (a full 5 years later) <oriansj>so if you have a reasonable plan for removing that bootstrapping blob later down the road, it is fine as long as you are honest about it and with a known reasonable amount of work <oriansj>for example Live-bootstrap used to have to cheat between M2-Planet and Mes.c because M2-Planet just couldn't build Mes.c yet <oriansj>but the second janneke solved that last step, fossy incorporated <Irvise_>stikonas, oriansj: thanks. I think the binary could be easily generated with Mes, so that should not be an issue :) <Irvise_>One question. If I exit the bootstrap environment, is there a way for me to easily get back to it without having to rebuild everything? <stikonas[m]>I think live-bootstrap didn't go beyond mes when m2-planet couldn't build mes <stikonas[m]>Once it was possible, I think it was me who updated to mes-m2 and fossy added tcc <stikonas[m]>Irvise: you can't easily go back in, though there are a couple of things to help <stikonas[m]>rootfs.py has an option to preserve and not delete build env <stikonas[m]>And another option is to copy out built packages from /usr/src/repo and use preseed option of rootfs.py (but this is less tested) <oriansj>hmmm: sysc/distfiles/curl-7.83.0.tar.xz: FAILED <theruran>what's the bootstrapping story on Fortran? /cc Irvise_ <Irvise_>theruran: oh, that is a really good question. I think it is not problematic as most of the code in GCC is C++ and does not require a fortran toolchain to compile it. I remember compiling GCC with fortran and ada in NetBSD and Ada was the problematic one. <theruran>the author said it is art because it has no useful purpose xD <theruran>as a separate thought, I was wondering if Forth can be formally-verified ex post facto <fossy>apologies for my absence in the last week or so. i was planning to finish python bootstrap this last week however i got covid and was stuck in bed for a few days :| <fossy>stikonas, rickmasters: 1. both of you make very good points about tarball distribution and i am feeling that perhaps external downloading should be the default, at least for the time being. it is more difficult to justify network downloading when there is little-no network support early in the bootstrap, or if the bootstrap is being run regularly. i feel that the option should probably <fossy>remain however, as it adds some trust to obtaining sources since it occurs in the more trusted environment. but i'm not sure anymore it makes sense as a default. <fossy>we did consider committing tarballs to repo a while ago but it's not something git handles well at all. <stikonas>oh yes, covid is annoying, I had it once in August <stikonas>I'm actually a bit sick too but this time it's just a common cold which if far better than covid was <rickmasters>fossy: did you mean "should *not* be the default" in your first sentence? <stikonas>I think fossy agrees that we don't download sources every time while we are doing development <stikonas>fossy: by the way, are you going to bootstrap python with gcc 4.7.4? <stikonas>well, it might be possible to swap it with newer gcc later... <fossy>i know some of the older pythons do not actually build with new gcc <fossy>when i was testing outside of live-bootstrap python 3.3 segfaulted using my system's toolchain <stikonas>I was just thinking it might be nice to build newer shared musl after we build newer gcc <stikonas>that would allow us to drop ton of patches on top of gcc 4.7.4 <stikonas>but if it would cause problems with older python <fossy>what are your thoughts on musl vs glibc for the final system we drop the user into? <stikonas>I personally use glibc on my Linux system <stikonas>but I chose musl for live-bootstrap for its ease of build <fossy>same, i have a feeling bootstrapping distributions might be a bit easier for glibc <fossy>yes, logically, musl makes sense for where we have it <stikonas>I suspect once we are "done" with live-bootstrap, any distro bootstrapper would want to build stuff into new prefix <stikonas>fossy: by the way, what else do you want to see bootstrapped in live-bootstrap for now <stikonas>we are probably approaching what is considered binary seed for most distros <stikonas>we might want to upgrade some other stuff once more, e.g. binutils <stikonas>maybe once we have python and new GCC we should release version 1.0 and try to announce it a bit more <stikonas>and then we need to finish off kernel bootstrap, e.g. make it work with fiwix (which rickmasters is already working on) <oriansj>fossy: perhaps a repo that is just the tarballs; which shallow checkouts against which one can do <oriansj>which has the download script for the tarballs from upstream for improving trust <oriansj>and then live-bootstrap would only need a script which git clone --depth 1 's the repo and then copies over the files <oriansj>that way it becomes simple use DVD distribution of the tarballs (or honestly any file distribution method you trust) <oriansj>then live-bootstrap can just stop and tell the user they need to obtain the source tarballs and suggesting a couple different methods for doing so <fossy>stikonas: more recent GCC, binutils <fossy>at that point i feel like you could realistically use it as a starting point for LFS or something similar, so i'd be happy for a 1.0 at that point <oriansj>and would the LFS community be interested in helping to integrate the work? <oriansj>figured that would be a basic first step <duplexsystem>personally I'd use zpaq to compress src as it usually beats gzip by a factor of 2 for text <stikonas>duplexsystem: but that is not bootstrappable <oriansj>duplexsystem: fair enough but ungz can be built by M2-Planet <oriansj>but if you know of a unzpaq program that M2-Planet or MesCC or TCC can build, please let us know <stikonas>and also somebody would have to repackage tarballs <oriansj>and if it needs TCC, at that point we can build xz which does a very solid job <duplexsystem>ah true. it needs c++ but I could proabally write a one that works with m2 <stikonas>but bootrapping it without pregen files needs a fairly new autotools <stikonas>unless we try to write a manual makefile <stikonas>there are actually other ways to reduce amount of tarballs <stikonas>the simplest is to unify linux and linux-headers versions <stikonas>that will immediately cut 175 MB from download <sam_>you can always speak to us too :p <sam_>i'm certainly interested <stikonas>sam_: well, I'm also interested in bootstrapping gentoo from live-bootstrap <stikonas>but I haven't looked at it yet as it would be good to first get python and newer GCC in <stikonas>(and right now I have stage0-uefi to finish anyway) <oriansj>sam_: well do you think Live-bootstrap is close enough that they would be interested? <oriansj>as they may want portage bootstrapped first <stikonas>well, sam_ is already a gentoo dev, so in some sense even this channel is appropriate <oriansj>well sam_ what would increase the odds of gentoo incorporating Live-bootstrap? <oriansj>Linux from Scratch thus far seems very uninterested <sam_>I think #gentoo-toolchain is probably the best place, but maybe here for now <sam_>at first I'm interested in what integration looks like <stikonas>I suspect it might be some add-on on top of live-bootstrap <stikonas>i.e. like stage0-posix has after.kaem hook that live-bootstrap overrwrites with its build chain <stikonas>oriansj: to be honest I expected LSF people to be more familiar with the concept of bootstrapping <stikonas>before #bootstrappable community they were actually one of those who are closest to what we are doing