IRC channel logs

2021-04-30.log

back to list of logs

<OriansJ>gforce_de1977: you should know by now, nothing here happens automagically; there is always another person putting in the work that we all benefit from. Now adding sys_sync to M2libc is simple for all architectures and if you need me to add it, I can certainly add it to my list of work to do.
<gforce_d11977>stikonas: OriansJ: sorry, with "automagically" I did not mean you have to do it, but that I can add it to libc and LIBC does the work 8-)
<gforce_d11977>stikonas: you are right, our bash is compiled against musl, so i have to source-patch it there...
<gforce_d11977>sorry, when reading https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst I can see, that our bash2.05 is compiled with MESlibc, so I bet it makes more sense to add a forced syscall_sync() there, stikonas: what is your opinion? another idea is the recompile bash2.05 with musl to rule that out...
<stikonas>gforce_d11977: only the sedond bash is compiled against musl
<stikonas>first one is mes libc
<stikonas>gforce_d11977: you can try to recombile bash with musl
<stikonas>but doing that is not trivial
<stikonas>well, as a quick check you can build it using pre-shipped configure script
<stikonas>and see if it helps
<stikonas>but if you want to properly rebuild bash, I'm afraid a lot of defines (CPPFLAGS) will have to be changed when moving from mes libc to musl
<gforce_d11977>stikonas: are we using only bash2.05 or are we later run the scripts with bash5.x? maybe we can just build+use bash5.x earlier?
<stikonas>gforce_d11977: bash 5 is much harder to build...
<stikonas>and we always use latest compiled bash at the moment
<stikonas>so once bash 5 is compiled, we switch to it
<stikonas>anyway, we need to build soem bash with mes libc
<stikonas>because we use it to configure musl build
<stikonas>but if you want to rebuild bash 2.05b with musl immediately after that, I think that's fine
<stikonas>but that's non-trivial amount of work
<gforce_d11977>stikonas: i'am puzzled: is the maybe-exisiting-sync-problem in musl or meslibc? or maybe in bash itself?
<stikonas>gforce_d11977: we don't know where
<stikonas>and it's only there under memory pressure...
<stikonas>so it might even be in more than one place
<gforce_d11977>under memory pressure? we have parallel execution and more than enough mem. why are you thinking this?
<gforce_d11977>"no parallel execution"
<stikonas>well, my guess was that's because you see it with minikernel VM much more often. I thought VM in minikernel coniguration is 4 GB of RAM?
<stikonas>or do you allocate more
<stikonas>oh, actually, on i386 more wouldn't really help
<stikonas>well, as a first step I suggest rebuilding bash with musl
<stikonas>and see if it helps
<stikonas>you can just try running ./configure; make; make install for a quick test
<gforce_d11977>stikonas: we are limit to 4gig with 386, but really: that is more than enough. i will build a vm which will prove that by printing memavailable to stdout, give me some time
<stikonas>well, I have no idea how much memory we are using...
<stikonas>I know that packed tarballs are actually not that much, maybe 120 MiB or so
<stikonas>unpacked and build files might much larger, but maybe we can clean them up if we want to reduce RAM usage
<stikonas>at least after coreutils once we have rm
<stikonas>gforce_d11977: 4gigs wouldn't be enough to bootstrap rust though. Although, I don't think we'll do that in live-bootstrap
<OriansJ>stikonas: one needs pae support to build rust and that is 586+pae or later
<stikonas>mrustc needs like 10 gigs of RAM...
<OriansJ>but more than 4GB is usuable on 486 but not per process.
<stikonas>well, strictly speaking it's GCC that needs 10 gig of RAM
<stikonas>well, there you need per process
<OriansJ>yeah memory requirements for bootstrapping kinda explode after M2-Planet.
<stikonas>well, without mes, you can still go quite far...
<stikonas>tcc does not need much
<OriansJ>hex0 => 362bytes of RAM; hex1 => 1KB of RAM; hex2 => 42KB+input_file_size of RAM; M1 => 40KB+input_file_size of RAM; cc_* => 16KB+input_file_size of RAM; M2-Planet => 192KB+input_file_size of RAM
<OriansJ>So everything up to that point could be done in 1MB of RAM;
<OriansJ>then MesCC needs 4GB if I remember correctly.
***ChanServ sets mode: +o rekado_
<stikonas>here mescc uses significantly less than 4 GB
<OriansJ>stikonas: well I stand corrected. It is good to hear that bar dropped.
<OriansJ>oh and I slapped a ungzip wrapper on puff and removed the need for setjmp and longjmp and foo.bar but it isn't fully M2-Planet compatible yet: https://paste.debian.net/1195853/
<OriansJ>So assuming good luck, I'll have ungz.c M2-Planet+M2libc ready this weekend or if bad luck by next weekend.
<stikonas>I'm away this weekend, so won't do anything bootstrapping related...
<stikonas>I wonder how fossy's perl is progressing. Although he is probably busy with exams...
<OriansJ>stikonas: I'm hoping you have a great time. Relax and enjoy yourself ^_^
<stikonas>yeah, just going for some hiking. It's long weekend here
<OriansJ>nice
<fossy>stikonas: pring that today. Although you guessed correctly exams are coming upon me :(
<stikonas>well, finish your exams first :)
<stikonas>perl can wait