***Server sets mode: +cnt
***edef_ is now known as edef
***xwvvvvwx- is now known as xwvvvvwx
***ericonr- is now known as ericonr
***deltab_ is now known as deltab
<pder>stikonas: thats great you were able to build gcc without needing autogen. what's --program-transform-name= doing? Also, is the tcc static inside array patch needed? <stikonas>pder: without it gcc is only installed as i386-unknown-linux-gnu-gcc <stikonas>tcc-static patch let's us to drop musl patch <stikonas>pder: somehow when I run configure in gcc subdirectory program-transform-name is preset... <stikonas>so it was either unsetting it or installing fixing missing gcc and cpp <pder>ah ok, very nice. Built ok for me in chroot, I am trying qemu <pder>I was thinking the tcc patch was related to bash <stikonas>and I think it's better to do it in compiler instead of special casing in compiled software <stikonas>and I think it's smaller than musl patch was <stikonas>anyway, with gcc I have more hope in building guile, but I think fossy already started looking at it <pder>Is guile the next milestone? If so, do we need newer binutils and possibly glibc? <stikonas>with gcc we can build newer software which tends to work alright with musl <pder>I tried out mihi's ppsyntax bootstrap and that worked nicely. hopefully our gcc version is new enough for guile 3.0.2 <pder>I believe I started looking at glibc 2.5 <pder>And it wanted slightly newer binutils <stikonas>and from the same time as binutils 2.14... <stikonas>anyway, we should be able to update binutils fairly easily <pder>Probably now, since you updated autoconf and automake <stikonas>2.71 is buildable but even modern distros don't ship use it yet <stikonas>I might be able to get newer automake (1.12 or newer) <pder>gcc 4.0.4 appears to be from 2007 and glibc 2.5 is from 2006- the most recent release before gcc <stikonas>althouth, maybe I should try to get newer automake first <stikonas>anyway, I think it will be much easier now <OriansJ`>well everything after GCC+Glibc is just a question of number of steps not a question of possibility. <gforce_d11977>stikonas: fossy: i'am a bit further regarding the missing pieces for dirglobs, the kernel symbol CONFIG_UID16=y is needed - after building an i386 kernel it is now stuck at step59: autom4te-2.59: cannot lock autom4te.cache/requests with mode 2 (perhaps you are running make -j on a lame NFS client?): Function not implemend <gforce_d11977>(but i know, that this is a kernel_knob also, just have to find it) <fossy><stikonas> anyway, with gcc I have more hope in building guile, but I think fossy already started looking at it <fossy>not made too much progress n rebase to real gcc is easy <gforce_d11977>bauen1: see message from 05:28: the symbol needed was CONFIG_UID16=y <gforce_d11977>also for future use: there are plenty of 386 machines out there with 128mb RAM (8 * 16mb 30-pin SIMM) <stikonas>bauen1: those changes to if are just syntax changes, aren't they? only last change is functional (remove /dev/console) <bauen1>stikonas: not quite, using an if instead of an && means that a failure of the test statement no longer stops the bootstrap <bauen1>stikonas: this way if /dev was already populated before the bootstrap started (user namespace with bind mounts) things won't break due to failure to test if /dev/null is a file (it won't be <bauen1>i still need to do a bit more testing before i can make a pr with my usernamespace setup (as currently the download / extraction clashes with --map-root-user of unshare) <stikonas>ok, I'll test that PR later in the evening <bauen1>maybe there's a way to keep them as one-liners, but it is easy to understand this way <stikonas>yeah, I don't mind if's just didn't realize return code is not the same <smartineng>Hello, is there any list of software showing what is bootstrappable and what is not? <bauen1>smartineng: not that i'm aware of, but you can consider everything in the live-bootstrap project to be bootstrappable from a linux kernel + a minimal binary <bauen1>or there for anything that can be build with just live-bootstrap as dependency <smartineng>bauen1: what about guix, do they have exactly the same base of software like live-bootstrap? <bauen1>smartineng: not yet, but i think the goals it for guix to be compiled from live-bootstrap, but there are still a few steps missing afaik (i think guile or whatever guix uses isn't quite solved yet, etc...) <stikonas>smartineng: guix has to depend on guile anyway <stikonas>there is some branch that makes guix use hex0 as a base, but it will still use guile for build orchestration <smartineng>stikonas: I remember from fosdem conf that they've riched some milestone in bootstrappability but I've never seen any official announcement about it yet <stikonas>where as live-bootstrap uses kaem-optional-seed (737 bytes on x86) for orchestration <stikonas>smartineng: yes, that's 357 byte hex0 plus guile (I guess at least 12 MB) <stikonas>guile is mostly used as a orchestration driver though, it shouldn't affect binaries <stikonas>smartineng: although, live-bootstrap goes further in other aspects too <stikonas>use of pre-generated files is not allowed in live-bootstrap <stikonas>so no pre-gen bison parsers, lexers, no running of pre-packaged configure scripts or pre-packaged Makefile.in's <stikonas>well, I guess the main difference is that guix started as normal distro and were working down towards bootsrappability <stikonas>where as live-bootstrap is bottoms up and no intention to be distro <stikonas>so live-bootstrap can have stricter standards <smartineng>stikonas: live-bootstrap theoretically could bootstrapp any linux distro <bauen1>i'm also quire interested in bootstrapping debian from live-bootstrap (once a new-ish version of gcc is available that can compile gcc 10), but haven't tried anything yet <stikonas>smartineng: it's not there yet, but it would be nice to bootstrap a few distros <stikonas>of course once you start bootstrapping distros, standards of what is pre-build will have to be relaxed, e.g. we are not fixing debian's packaging not to use pre-gen stuff <stikonas>but that is then up-to distro to care or not <bauen1>maybe you could get debian to move towards a non-cyclic dependency graph on architectures where live-bootstrap works <bauen1>that could probably make many things a lot easier e.g. for cross building <bauen1>i've downloaded my original copy of stow-2.2.2.tar.bz over https and it is pgp signed but i've been unable to find if it was signed with the right key, not sure what the standards are for this project <OriansJ`>smartineng: if you want bootstrapping without a kernel, stage0 exists to address that problem. <OriansJ`>have been made to work on BSDs as well (Ideally any POSIX kernel should work) <OriansJ`>porting to DOS and CPM just becomes a task of rewriting a 3 functions (read-byte, write-byte and malloc) which shouldn't be more than 20 assembly instructions per port <smartineng>OriansJ`: amazing and in general what is minimal hardware requirement for each stages? How it evolve during building bigger blocks? <smartineng>I have some FPGA dev board on my desk and I would like to play with it using your software <OriansJ`>smartineng: the hardware requirements for hex0 is an 8bit processor and (depending on instruction set) sub 300bytes of ROM and a single 4bits (RAM or Register) to store the first nibble when working. <OriansJ`>hex1 depending on the architecture needs support for 16 or 32bit registers and enough RAM to build the jump table of the program it is running. <OriansJ`>hex2 needs the ability work on 32bit values and enough ram to hold the jump table of the program it is processing. <OriansJ`>M0 can be done in an 8bit processor provided it has a large enough address space and RAM to store the DEFINEs it is applying. <OriansJ`>cc_* tends to need a 32bit register and enough RAM to store the entire program it is compiling and its generated output. <OriansJ`>M2-Planet tends to need a 32bit processor and 8-12MB of RAM to do cross-platform compiles <OriansJ`>mescc-tools tends to work just fine in 6-8MB of RAM. <OriansJ`>and then the memory requirements tend to grow towards 8GB for the various pieces used. <OriansJ`>but a 32bit or larger register size will be sufficient to bootstrap to the level required to cross-verify any other hardware architecture. <OriansJ`>as once one has M2-Planet+MesCC tools, the rest is just C code and a pinch of Assembly. ***ChanServ sets mode: +o rekado_
***bauen1_ is now known as bauen1
***Noisytoot is now known as []{}\|^`-
***[]{}\|^`- is now known as Noisytoot
***Noisytoot is now known as ||||||
***|||||| is now known as Guest7851
***Guest7851 is now known as Noisytoot
<pder>OriansJ: do you know if M2-Planet, M2libc and mescc-tools are in a state where it makes sense to update mescc-tools-seed? <pder>stikonas: setting archname and osvers to empty strings in sysa/perl-5.6.2/files/config.sh appears to fix the perl Errno.pm line 11 warning <pder>If you run perl -V there are still quite a few things undefined, but I am not sure it matters ***stikonas_ is now known as stikonas
***Noisytoot is now known as ihatecoronaandih
***ihatecoronaandih is now known as Noisytoot
<bauen1>do we demand chroot support of the seed kernel or only after we've build our own linux ? <bauen1>or rather do we have chroot in sysa or only in sysb ? ***lukedashjr is now known as luke-jr
<stikonas>bauen1: interestingly even after you PR, qemu has /dev/console <stikonas>I guess it's created dynamically at some point <stikonas>bauen1: as for chroot, I guess the plan is eventually everything from bash is on new kernel <stikonas>although, we need to build coreutils for chroot anyway <stikonas>and I'm not sure if that can be done with mes <stikonas>in which case you would have to wait for coreutils rebuild <bauen1>stikonas: have we built perl at that point ? because perl has a chroot function that could be used instead <stikonas>gef: I myself don't mind moving everything into a single "organization" on gitlab, but I guess we need to ask others too <bauen1>well upkg won't work until perl is build for now <stikonas>actually, there are just a couple of steps between coreutils rebuild and perl ***fosslinux is now known as fossy
<fossy><bauen1> do we demand chroot support of the seed kernel or only after we've build our own linux ? <fossy>we do not demand chroot support in the seed kernel <fossy>I also dont see where it would go <stikonas>fossy: I think bauen1 whats it for building packages in isolated environment <bauen1>fossy: mostly for building things in a chroot, something i'm experimenting right now <fossy>But I also dont see the utility of it <bauen1>but given how upkg currently uses stow so it requires perl (until i entertain the idea of rewriting stow in C) <fossy>We are in an environment where we know exactly what is what <stikonas>maybe something with bash is then easier? <stikonas>that would be available a bit earlier...\ <stikonas>I haven't thought much about "packaging" though... <bauen1>fossy: it's mostly so you can move pieces around more easily, you have a clear list of dependencies, and the build should only be influenced by those <fossy>bauen1: I guess it increases clarity to an extent. <bauen1>you can also enforce certain things like a matching SHA256 sums for every file in the package, can include all SHA256 sums of the dependencies in the resulting "pseudo package" etc... <bauen1>you can already do most of these things with helper.sh if you're careful <stikonas>yeah, automatic SHA256sums (or other hash) would be useful <stikonas>it's getting a bit harder to checksum stuff when we have multiple installed files <stikonas>yeah, helpers.sh can be indeed written to do that too <stikonas>well, automatic sha256sum and possibility to remove package <stikonas>but building with just required dependencies is probably easier with stow? <bauen1>i'm just using stow for now as writing fragile shell scripts isn't something i fancy, but it doesn't make use of many advanced features so a `find` and `ln` construct could probably do the job good enough <stikonas>although, it's not completely clear to me how will we start with dependencies <bauen1>stikonas: stow is just for symlinking all the things in the right place <stikonas>when we build first packages, there won't be any packages to include... <stikonas>we'll have to manually "define" stuff that was installed earlier <bauen1>but after that it should be smooth sailing <stikonas>that shouldn't be too hard since most of the early packages install few files <bauen1>oh and another aspect was making the bootstrap easier to develop for, then you can tar up parts of the package directory and start from the point where upkg can work and let it skip things it already has <bauen1>all in all upkg is just a glorified wrapper around stow, chroot, tar and a few other utilities <stikonas>and with gcc they will only grow longer because gcc is quite a bit slower than tcc <stikonas>unless we compile with -O0 but it's still slower than tcc <gef>stikonas: "builds are getting long" ... this is where using a bit of containers (during the development effort) would be of help: previously build images are cached and that saves time <bauen1>another reason why i'm asking about chroot, how about making sysa after sysb and chroot into it instead ? <stikonas>not sure if it's easy to do it via containers... <stikonas>we can't use Dockerfile inside bootstrap itself <bauen1>i mean we don#t have chroot in sysa before but that could be solved someway <gef>stikonas: "don't mind moving everything into a single organization on gitlab": not organization, rather group - and nothing really "moves", since that is just an extra service really <stikonas>well, I mean you need to move project from github to gitlab, don't you? <gef>stikonas: no need for that, you can mirror them! <stikonas>well, but gitlab's CI/CD is not suitable for live-bootstrap <gef>if qemu does it, `bootstrappable` should be able, too :) <stikonas>it's not a question of can it, but how fast <stikonas>if it can do it in 30hours, it's not good <stikonas>without kvm, qemu will run approximately 20 times slower <gef>we can have our own runners, use them as jump hosts to ssh or whatever, there is some freedom <gef>who provides the current VM? <stikonas>well, the alternative would be not to run qemu but run CI in chroot mode... 