IRC channel logs
2024-02-22.log
back to list of logs
<mid-kid><stikonas> mid-kid: isn't gentoo merge-usr too? <- it's a configuration option but not default <mid-kid>Sorry, just catching up on this channel now <mid-kid><Googulator> mid-kid: ICYMI: achieved Gentoo bootstrap based on your instructions on bare metal <mid-kid><Googulator> LiveGUI image building as we speak, as the ultimate verification of successful bootstrap <- I'm afraid LiveGUI might be using binaries for things like rust <mid-kid>It's kind of hard to disable prebuilts globally in gentoo <mid-kid>I manage with a small set of package.mask <mid-kid>The rust thing applies to any desktop profile in general <mid-kid>And I'm not sure to what extent it'd be possible to make catalyst use the ::gentoo-bootstrap repository <webczat>I have a question: I have a kernel + busybox running without anything else. what's the minimum things I need as a first step to go from this to a working compiler? I can transport data to this environment, but the main problem I seem to have is the lack of make. <mid-kid>Googulator: I'll go over your document and try to combine the documentation. Thanks a lot! <mid-kid>The changes are looking good so far. I kind of assumed downloading the distfiles on a separate machine though <stikonas>live-bootstrap can build everything from just binary seeds <stikonas>2. can be recreated easily if your busybox includes sed <mid-kid>you can probably use busybox tools to assemble hex0 <oriansj>well busybox can be used to create the binary seeds too <mid-kid>Googulator: Oh... You copied the LFS instructions into the document. I was trying to avoid that, lol <mid-kid>But I guess explicit is better than implicit <stikonas>you can eiter prepare live-bootstrap source dir outside your environment and just copy in sources in the required directory tree structure <stikonas>to large extend LFS instructions duplicate tools and compilers what we have in live-bootstrap <mid-kid>yeah LFS is superfluous in the gentoo bootstrap, given we cross-compile a compiler *yet again* later. <stikonas>perhaps bootstraping 32-bit Gentoo and using portage with crossdev is quicker though <mid-kid>It was just easier in terms of instructions <mid-kid>And I didn't feel like messing about too much. <mid-kid>There's a lot that can be improved here. <webczat>i actually think this bootstrap goes further than I intend. <webczat>like I start from a higher level, which is actual kernel+busybox+nothing <matrix_bridge><Andrius Štikonas> webczat: well, live-bootstrap can easily do less, kernel bootstrapping is optional <mid-kid>webczat: yeah, it's just that this bootstrap can start from any working kernel, really <mid-kid>there's maybe two steps you can skip when you have modern tools in the form of busybox... but it's too much trouble <webczat>also, i'm a lfs kind of user and lfs is generally done manually without helper scripts. <matrix_bridge><Andrius Štikonas> Well, you can follow those scripts manually <mid-kid>the broad strokes of M2-planet->mescc-tools->tcc->gcc4->etc are still necessary to follow if you don't have a compiler <webczat>i am not even fully certain I have to start from hex0 stage. my goal is nothing like the goals of this project, it's more about fun. <mid-kid>webczat: you kinda do have to start from hex0 if you want to compile M2-planet <webczat>also I am on x64. the kernel doesn't support 32 bits because I had a crazy idea to try to fit it in a floppy which I failed at. but it doesn't do 32 bit emulation <mid-kid>the only step you can skip is kaem, as you have a posix shell <stikonas>but you'll still need some kind of compiler and linker <mid-kid>I'm not sure to what extent the early bootstrap does 64bit <mid-kid>then yeah, start by building M2-Planet/mes-m2 and mescc from there <mid-kid>even if it's buggy maybe you can fix the bugs idk <mid-kid>then move up to tcc by following the live-bootstrap scripts <mid-kid>read steps/manifest and the individual scripts in steps/ <mid-kid>mes has its own libc that is used up to the point where musl can be compiled <webczat>initially I thought I could even start from tcc directly, but wanted to somehow compile some libc. <webczat>without make it's a no no for most normal libcs <mid-kid>how would you intend to compile tcc? <webczat>mid-kid: i assume some level of initial seeding. as said, I don't have comparable goals to this project, just fun, which makes some things less important. <webczat>stikonas: but I still don't have make. <mid-kid>make has its own bootstrap script, which works if you have a C compielr <stikonas>well, we build make using some manual script <webczat>if I start from tcc, i can't compile make without libc which I can't compile without make <stikonas>webczat: which is why you need to follow live-bootstrap <mid-kid>webczat: you might be able to break that loop with some "cc -o libc.o $(find . -name "*.c")" or similar <mid-kid>i.e. compiling the libc manually without make <mid-kid>both musl and mes-libc are simple enough to make that possible <webczat>stikonas: ik. I just mean, I cannot really directly start from tcc because of no libc. I would need a prior libc. the problem now is my kernel really does not support 32 bits so probably needs recompilation? <stikonas>yeah, we only have early bootstrap on x86 <mid-kid>This script builds the mes-libc manually <mid-kid>you can probably s/mescc/cc/ here and get a working libc.a <mid-kid>and this libc is good enough for make <webczat>will still look into whether I want to start from hex or from this one. except really having to recompile... <mid-kid>If you bring in any extra binary seeds, I just recommend starting from mes, built on another machine <mid-kid>everything surrounding the bootstrap uses that as a significant checkpoint <mid-kid>everything before it is assembly and reduced variants of c-like langs <mid-kid>and everything after it is tools that were developed outside of the context of bootstrappable.org <matrix_bridge><Andrius Štikonas> Stage0-posix is easy to run even without live-bootstrap <matrix_bridge><Andrius Štikonas> mes is the hard bit to run manually anyway <oriansj>webczat: well you have to decide what starting point you wish to use. (assembly, C compiler, etc) and from there many of the details become obvious <matrix_bridge><Andrius Štikonas> Early step are hard to develop but easy to run <mid-kid>mes is fine if you use the configure script <mid-kid>live-bootstrap does it manually due to lack of tools <mid-kid>I wonder if it's possible to get rust to not do a full 3-stage bootstrap for each version <mid-kid>I feel that would cut down a lot of the time in bootstrapping it <Googulator>mid-kid: I copied in the LFS instructions because it's not meant to remain just a document <Googulator>I intend to convert it into an actual shell script <Googulator>also, doesn't downloading binary packages need to be explicitly enabled? <matrix_bridge><Andrius Štikonas> Googulator: no, you need to add at least *-bin packages to package.mask <matrix_bridge><Andrius Štikonas> One are binary packages and the other are ebuilds that still download binary packages <ccx>They are usually installed into /opt btw; that's "vendor provided" binary. <ccx>As opposed to binary you compiled yourself. <matrix_bridge><Andrius Štikonas> But sometimes, e.g. ghc is controlled by USE flag <ccx>How did we get here? :] <Googulator>ccx: building a fully bootstrapped version of Gentoo live DVD <matrix_bridge><Andrius Štikonas> But there is then still stuff like ghc or some other languages <ccx>By definition you can't bootstrap -bin packages because those are binaries provided by third party. <Googulator>that's why I'm worried that it could be downloading -bin packages instead of actually bootstrapping <ccx>Are there even any virtuals that default to -bin? <Googulator>looks like it did pull in openjdk-bin and rust/bin <ccx>How do you plan to bootstrap those? <Googulator>I'll probably exclude those initially, hopefully it's not the whole system that depends on them <nimaje>not sure about the first version of openjdk, but all the others can be build by the previous version <nimaje>(maybe you can skip some openjdk versions) <oriansj>well we don't have Haskell bootstrapped yet; so a whole category of software can't yet be bootstrapped. <matrix_bridge><Andrius Štikonas> And build system insists on 2 stagė bootstrap <matrix_bridge><Andrius Štikonas> Also stuff like ocaml or some other languages wouldn't be using proper bootstrap, e.g. camlboot on gentoo <matrix_bridge><Andrius Štikonas> Googulator: maybe you can share that emerge list? <matrix_bridge><Andrius Štikonas> I might be able to spot if there is anything suspicious <mid-kid><Googulator> that's why I'm worried that it could be downloading -bin packages instead of actually bootstrapping <- If you built the LiveDVD without any hacks then you definitely pulled in at least rust-bin <mid-kid>The non-bin rust ebuild will download a binary rust stage0 unless USE=system-bootstrap is set <mid-kid>and USE=system-bootstrap requires that you already have rust, or rust-bin installed <mid-kid>Different languages work differently, trying to install dev-lang/go will install dev-lang/go-bootstrap as a dependency, which is a prebuilt version of go <mid-kid>Once dev-lang/go is finished building a depclean will cause the bootstrap to be removed <mid-kid>But unlike go, rust *is* a dependency for any desktop-related things, as it's required to build librsvg <mid-kid>There's also some sneaky ebuilds like dev-java/openjfx which downloads "gradle-<version>-bin.zip" to build the thing <mid-kid>You can't rely on gentoo ebuilds to not pull random prebuilts, basically <mid-kid>Now, I'm fairly certain that everything I described in my guide builds 100% without executable binaries (disregarding generated files like autoconf scripts). <mid-kid>And a stage3 on a default profile is clean too <mid-kid>I just can't guarantee anything else <mid-kid>Gentoo doesn't have very strict packaging policies like debian does <mid-kid>This is my non-exhaustive list of "bad" gentoo packages <mid-kid>true but I heard wildcards are slow and my portage config is already slow as is :) <mid-kid>I wish there was an official policy to name all binary packages -bin, even if there's no way it'll get a non-bin version <mid-kid>At some point vscodium got renamed from vscodium-bin to vscodium <matrix_bridge><Andrius Štikonas> There is a source build in overlay though <mid-kid>yeah, pf4public has great builds for electron apps <mid-kid>they're just a shining example of why electron packaging is impossible <mid-kid>the LICENSE field on www-client/chromium doesn't seem to reflect that <mid-kid>I do know that you need USE=eme-free on mozilla-based programs to avoid downloading openh264 binaries <mid-kid>(downloading them at runtime for DRM content, I mean) <matrix_bridge><Andrius Štikonas> Yeah, it doesn't there is a bug but everybody is scared to touch it... <matrix_bridge><Andrius Štikonas> Cause it will exclude chromium from default accept license choice <matrix_bridge><Andrius Štikonas> The one from pf4public is not affected... <mid-kid>It's not malicious or harmful so it doesn't worry me too much <mid-kid>though I understand it's not good for real software freedom <mid-kid>anyway, I wish most ::pf4public things would just go upstream <matrix_bridge><Andrius Štikonas> There are free unrar implementations though... <mid-kid>the only two I know are unrar itself and 7z, which just bundles unrar <mid-kid>>RAR and RAR 5.0 archives (with some limitations due to RAR's proprietary status) <mid-kid>rar is weird I prefer just not using it <mid-kid>haven't seen a rar file I cared about in ages <GoogulatorMobile>stikonas: what are the RAM & disk requirements for your Rust bootstrap overlay? <GoogulatorMobile>Unfortunately it's gonna be necessary if I want to build anything desktop <stikonas>GoogulatorMobile: it's mainly the first step tat needs a lot of RAM <GoogulatorMobile>My bootstrap system is a Socket 775 with DDR2, which is very close to the end of the 15-25 year window for trustable hardware <stikonas>hmm, maybe you could do with a bit less than 10 <stikonas>but definitely need to use single thread <stikonas>and it's basically impossible on 32-bit arch <GoogulatorMobile>& of course, no hope for NVMe... except maybe as a separate data-only drive <stikonas>though I think java might be still a bit broken <stikonas>due to hg.openjdk.org being down (I need to switch to github tags) <stikonas>GoogulatorMobile: also almost surely you need GCC 12 or older <stikonas>llvm version used in rust 1.54 probably needs patching for GCC13 <stikonas>that will cut down the chain length a lot <stikonas>but won't do anything to RAM or disk requirements