<bauen1>vagrantc: that is a very interesting question, and it should be extended to mis-compilation bugs too <bauen1>also i'm pretty sure you're not supposed to "use" debian/patches as a "git alternative" lol <bauen1>for the security bugs, it kind of depends, as long as you get a _correct_ bootstrap result, it _might_ not matter, especially since the source code "should" have been reviewed prior to being compiled and is therefor trusted input <bauen1>the only point where it could be dangerous is if it results in wrong code (introduces bugs in the result) or affects the tools used to inspect the source code before compile <bauen1>while it would be best to not have any bugs, they will happen, so it's probably best to engineer for them <bauen1>also i need to remember to investigate if it's possible to make e.g. an M2 binary that can run as hosted (with proper kernel) and standalone without too many source changes <bauen1>that could make the real stage-0 bootstrap simpler, if you can just carry over the compiler initially used to build your kernel and start stage-posix from it <bauen1>a bit more brain dump, so to avoid bugs, you could go a similiar approach like the math people go with SATs, build a very tiny, easily verifiable base that enforces certain properties, and do the complicated stuff in some complex code, when you have your result, plug it into your "verified" base use it to verify that your result is actually valid <bauen1>so basically stage-0 would be the minimum code that needs to be reviewd very well, but once you have a (basic) kernel you can use it to enforce certain properties (like no overwriting previous stages), then you don't need to review the remaining code for this particular issue => easier reviewing <bauen1>anyway i'll continue my thoughts tomorrow, it's already too late <stikonas>fossy: do you think I can create some shell script instead of after.kaem.run? <stikonas>I think the next tool I should try to build is gawk... <stikonas>provided that parser generator works on it ***senzilla_ is now known as senzilla
<stikonas>ok, I'll create run.sh and maybe move m4 there <stikonas>fossy: argh, I've just got skel.c:0: error: unrecognized character \x00 <stikonas>fossy: I think the solution would be to move flex after bash... <stikonas>fossy: so I think we'll need to start setting up pipes then... <stikonas>I wonder if I need to set up anything before I cna use it... <stikonas>hmm, in the maentime I think I'll rebase bash PR to just have bash <fossy>stikonas: nope, its just a kernel syscall <fossy>cool will merge within a few hours <fossy>yeah I cant even load it lmao <stikonas>let's not merge it until I sort that intermittent error <stikonas>well, we are definitely not reproducible :D <fossy>I plan to look at overall reproducibility after linux kernel <warren>has anyone looked into what it would take to make guix itself reproducible? ***stikonas_ is now known as stikonas
<stikonas>I wonder if catm breaks because it doesn't close files <stikonas>it seems like it just calls exit syscall <stikonas>OriansJ: Do you know if that might cause corruption? <stikonas>anyway, we have a workaround now... Start using bash and pipes <stikonas>pder: did you get ls working in the end? <stikonas>that should remove some of the boilerplate code that we write <OriansJ>stikonas: I can think of a thousand possible causes of corruption but failure to close files prior to exist isn't in them. Failing to fflush or in the case of catm reading past the list of args because you are using an old version <OriansJ>although I can't really look into that since I need to figure out the 30second delay between python3 knight.py and my web-browser. <stikonas>well, it's low priority and probably my fault anyway <OriansJ>I am more confused by cherrypy is returning seemingly randomly different numbers of bytes when the page is always the exact same number of bytes <OriansJ>well I feel stupid. I forgot to support &globals in M2-Planet <OriansJ>I have it for locals and arguments but not globals; how foolish of me. It bit me right in the ass. ***dongcarl5 is now known as dongcarl
<OriansJ>hmmmm, I guess I learned 1 additional reason for little endian being selected for over big endian. fgetc with a single byte is a few less instructions and no need for shift <OriansJ>so if you are doing a stupid function to just read one byte at a time little endian is a bit faster but if you are doing a big block of bytes, big endian ends up being faster. <fossy>aw, was hoping to avoid using net/ in linux kernel ***mephista is now known as spicy_icecream
<gforce_d11977>fossy: there is no way to compile without 'net'? is it really needed, or is it your wish to use it? <fossy>gforce_d11977: other things are highly integrated with it, many symbols are rquired <fossy>luckily its only ~20 more files <stikonas>fossy: we should probably add shellcheck linter to CI on live-bootstrap... <fossy>stikonas: we have it for rootfs.sh <fossy>i dont want to extend to kaem scripts <fossy>It will recommend bad things, as kaem is not shell compatible <stikonas>fossy: for kaem things yes... But now I think I'll be adding bash scripts... <stikonas>hmm, so I guess I can just add neeed scripts to .cirrus.yml <gforce_d11977>fossy: stikonas: maybe you can just write in 'kaem' a line like: bash -c '/foo/bar/build.sh' <stikonas>gforce_d11977: my plan is to just invoke new script and leave after.kaem.run file forever <stikonas>gforce_d11977: I have some draft PR but it's not finished ***pgreco_ is now known as pgreco
<Hagfish>kaem has been great, but it's cool to be at a stage with such a familiar environment as bash <stikonas>Hagfish: that's not my intended final commit message... <malina>Hagfish, makes me think of bye bye Kaom.. (poe), a game an old friend got me to try, after 10-15 years wihtout gaming :D <Hagfish>i didn't realise it was almost a meme, but yeah, i'm sure there's a more accurate commit message you can come up with <Hagfish>that's okay, i was just appreciating mal's tangential reference ***renopt_ is now known as renopt
<malina>I am a pro when nit comes to those tangents! <stikonas>tried to make it generic enough for it to work with various packages and minimal boilerplate code <pder>stikonas, that sounds great. thanks! <pder>I created a PR for ls that includes an additional step to patch mes-libc just a little bit ago <stikonas>I am only using it for m4 for now which is simple enough to not require any special steps, but build stages can be overriden in my proposal <stikonas>pder: your numbering change commit though will cause confllicts with my numbering changes... <stikonas>could have numbers in markdown in README.md if we want... I think they can be numbered automatically there <pder>I fixed up the patches for ls, rebased onto the latest and force pushed my branch <stikonas>I should also rebase my 2nd PR onto latest... <stikonas>fossy: slightly bad news (but hopefully we can find other way): yacc fails to build gawk parser