<stikonas[m]>bauen1: sounds good. Probably we should remove all implicit conflicts/overwrites but that should help with an immediate issue <oriansj>I guess I missed that when doing that release ***genr8eofl_ is now known as genr8eofl
<fossy>dash is not easy to build, correct <fossy>stikonas[m]: that is good, this is what we want, regarding being able to run live-bootstrap without rootfs.py <fossy>stikonas[m]: about xbps file conflicts, i believe it will error out, but i'll check that in a moment <fossy>i nearly have my improvements ready, but i'm running into qemu disk space issues... trying to diagnose the source <stikonas[m]>fossy: what kind of improvements? Just tryingbti think what might be going wrong in terms of space <stikonas[m]>Command1 then empty line command1 exit code and then immediately command2 <Irvise>The command is touch mus-config.h && tcc -c s7.c -I. && tcc -o repl repl.c s7.o -lm -I. -ldl && ./repl <Irvise>I am pointing this out because it could be interesting to see if TCC 0.9.26 could compile it, or maybe wait for the muslc TCC. <Irvise>Oh, sorry, it works without -ldl. And it just links to -lm because it uses a few mathematical functions. So I theorise that it could be built at step 6. <Irvise>I would like to try that out, brb. <stikonas[m]>Possibly, although by then I think we only need something like gash <Irvise>"By carefully avoiding some features, the shell now runs on Mes with <Irvise>at least some built-ins working." That is quite some progress if you ask me :) <Irvise>I just saw that M2 planet does not have the maths libraries :/ Though the required mathematical functions could be implemented in code using some simple algorithms. <Irvise>And I have not been paying much attention in these past months, why gash so soon? That is a large improvement since I last was here. <stikonas[m]>Heirloom-tools is CDDL and incompatible with meslibc <Irvise>Maybe it is now the wip-gash branch? It is the only active one... <Irvise>(btw, my question is regarding the documentation, not the actual work that has/is being done) :) <oriansj>Irvise: M2-Planet would never have math libraries because it is a C compiler not a C library; M2libc can certainly have math libraries as soon as someone adds them (Although lack of floating point support in M2-Planet might be an issue) <Irvise>S7 seems to require a few more libraries, so it is probably better to try after muslc. I will keep testing. <Irvise>(after all, this is just my capriciousness) <bauen1>stikonas[m]: yes, it worked the bootstrap finished without issues <bauen1>and there is everything necessary to build dpkg from source, so that leaves compiling gcc/g++ a bit to get to a good enough version for debian <oriansj>???but perhaps adding \n\n after the exit status might help it be lesss confusing??? <janneke>hmm stage0-posix/makefile still has PACKAGE = mescc-tools-seed *janneke runs make dist PACKAGE=stage0-posix <janneke>and for best stage0-posix bootstrappability, m2-planet needs its capitalisation *janneke runs make dist PACKAGE=M2-Planet <civodul>janneke: oh oh! sounds like there's good stuff coming? :-) *janneke is "rebasing" / rewriting wip-full-source-bootstrap onto core-updates <janneke>the imminent (cough) release of mes-0,24 can now be built with M2-Planet for x86 and arm <janneke>successfully built /gnu/store/dhjh3c5hhlphzqxyw3mlfc2gi8wahrfc-stage0-posix-1.4.drv *janneke still got some 40 odd commits to clean-up <stikonas[m]>Latest unreleased M2-Planet has some additional goodies, e.g. preprocessor, compound operators (+=, etc...), char ** arrays <janneke>stikonas[m]: tbh, i never fully understood this mes-m2 thing <janneke>yeah, we may want to look at those features after the release <janneke>yeah, i know; i helped a couple of times ;) <janneke>but i do know oriansj put *a lot* of work in the fork, initially <janneke>some routes we try just are a dead end... <stikonas[m]>I suspect it got moved to another repo to speed up merging <stikonas[m]>Anyway, if m2-planet can build mes 0.24 then we just kill mes-m2 <stikonas[m]>oriansj: double \n is fine but maybe we can put it behind more verbose flag? <stikonas[m]>janneke: it might also be nice to include kaem scripts to build mes into repo <stikonas[m]>And optionally kaem scripts to build libc and maybe rebuild mes with mescc? <stikonas[m]>Although if we get gash working, latter is less important <stikonas[m]>Btw kaem is now also more capable, it supports if, elif and aliases <oriansj>stikonas: perhaps --show-exit-codes ?? <janneke>stikonas[m]: there's currently kaem.run, which builds mes-m2 <stikonas[m]>bauen1: I'll review once I'm back home, either tomorrow or soon after <stikonas[m]>Exit codes are very useful for development, but for casual user maybe a bit too verbose <stikonas[m]>oriansj: maybe you should also get new stage0-posix and M2-* releases out? <stikonas[m]>If we are going to have new mes soon, it might be a good idea to release lower stuff first <oriansj>sure i can do that; there certainly be a good bit of work since the last release <oriansj>now comes the interesting problem: last M2-Planet release was v1.9.0; so should we do v1.10.0 or v1.A.0 (in the hex counting sense or is that too non-standard?) <stikonas[m]>Strings in version number are likely to break comparisons in some package managers <oriansj>I'll go with 1.10.0 as we are not close to v2.0.0 sort of functionality yet <oriansj>well we don't to update the submodule for M2libc in M2-Planet because it can change any/all of the checksums without any functional change <oriansj>but when there is something important (like a new architecture being added) it is updated <oriansj>also stage0-posix shouldn't be using the M2libc inside of M2-Planet anyway <oriansj>(I don't want M2-Planet + M2libc versions to be too closely coupled together if possible) <oriansj>as M2-Planet should work with every release of M2libc released prior to that M2-Planet release <oriansj>and most M2libc releases after as well (excluding the case of new architectures or major new functionality) <oriansj>so that the people using M2-Planet can opt for any M2libc (or compatible libc) that they want and it'll behave the way they want. <oriansj>the big problem/project that remains is the harmonization of MesCC and M2-Planet/M2libc M1 assembly DEFINEs <oriansj>(but it is a problem that could be solved by literally anyone [one architecture at a time]) <oriansj>((just update M2libc to the standard M1, then update M2-Planet to use that new M2libc commit and update the output strings to match)) <oriansj>but I guess that remains a non-issue until MesCC decides to support M2libc <oriansj>although we probably should update stage0-posix's readme to reference live-bootstrap instead of saying "when mes-m2 is finished" as the ultimate goal of bootstrapping to GCC is done (and so is the bootstrap to guile which is a sweet extra) <stikonas[m]>Also Readme in stage0-posix still refers to mescc-tools-seed <oriansj>yeah I probably should fix that prior to the release