<zv>in terms of (volunteer) developer time, where in the project would it best be spent? <stikonas>zv: hard to tell, there are a few somewhat different things, and you should pick what sounds fun <stikonas>zv: a lot depends on what programming languages you are comfortable with or want to learn <stikonas>I guess full source bootstrap of GCC is the biggest project and there are quite a few subprojects in it <stikonas>but some people are bootstrapping other languages <stikonas>zv: if you are interested in full source bootstrap, then we do have that for x86 but other arches are not working yet, so that's one option <Hagfish>and recipes for building distro images after gcc is available? is that something someone can pick up? <stikonas>another thing one can do is improve M2-Planet so that it can build mes a bit easier (now it can only build heavily simplified mes-m2 fork) <stikonas>Hagfish (cc zv): sure, one can try bootstrapping distro images <stikonas>or writing some minimal kernel in M2-Planet C subset <stikonas>or bootstrapping autogen (that's an evil task) <zv>I'd prefer to focus on C, shell, and asm. I have access to less-popular hardware (sparc, riscv, etc.) too, if anyone else needs that. <stikonas>actually, we'll probably skip bootstrappin autogen <stikonas>zv right now we have no sparc support at all <stikonas>so if you want to get involed in low level stuff, you could port stage0-posix to sparc <zv>also ppc32/ppc64. arm. you name it. is there any strong reason to focus on sparc aside from the fact that the T2 and earlier are "open" and available for download to FPGA? <stikonas>I did riscv64 up to mes-m2 step (but not mescc compiler) <stikonas>oh, also easy task is riscv32 port of stage0-posix <stikonas>in fact riscv32 might be easier and also useful in some home-made hardware <stikonas>as for shell, that's I guess live-bootstrap, a lot of it is written in bash <stikonas>so riscv32 might be not too hard because asm instructions are very similar to riscv64 (although you do need to adjust some stuff from 64 bits to 32 bits) <zv>I could de-bash live-bootstrap probably pretty quickly <stikonas>or if you focus on C, I guess M2-Planet... <stikonas>zv well, we only have bash bootstrapped there anyway <zv>ack. what are the current priorities with m2-planet? <stikonas>I recently did some improvements to preprocessor <stikonas>but I guess the goal is to make upstream mes easier to build <stikonas>(not necesserily everything, we can submit some simplifying patches to mes too) <stikonas>but the more we add to M2-Planet, the less patches we need to upstream <zv>that implies potentially more maintenance though <stikonas>and do not require any new arch-specific assembly codegen stuff <stikonas>basically it took more than 2 years to patch mes to mes-m2 to get it to build with M2-Planet <stikonas>and some of those patches I think would introduce more maintenance burden <zv>ok. I'll try to familiarize myself with the project better before jumping into anything. <stikonas>yeah, you can skip through some source code first <zv>thanks for the above discussion; it is helpful to know what to focus on. <stikonas>no problem, like I said a lot depends on choice of languages <stikonas>if e.g. you mentioned Scheme, some other projects might have been more appropriate... <zv>I'm fairly versatile but it's not my preference. <stikonas>same here, I'm not very familiar with scheme <stikonas>oh, another thing that oriansj mentioned is improving M2libc <stikonas>which is I guess mostly used by M2-planet... <stikonas>i.e. move some functions from mes libc to m2libc <zv>is m2libc intended to replace mes libc 100%? <stikonas>I guess it depends on what you want to build with M2-Planet <stikonas>anyway, that question might be better addressed to oriansj <zv>I'll comment after I've reviewed more. <oriansj>minor note match(argv[1], "-p") == TRUE can reduced down to just match(argv[1], "-p") as it only returns true or false, and == will only return true or false, so the comparison is redundant <oriansj>zx: well the only assembly work is on the lower end of the bootstrapping work (bootstrap-seeds, stage0-posix, and M2libc) after that everything is done in C or better. <oriansj>and we tend to suggest what work looks fun because sometimes it produces miracles for improving the bootstrap process. <oriansj>Also we encourage questions and clarifying anything that is not immediately clear (and try to update our documentation to improve that for all new people) <oriansj>stikonas: merged and thank you for taking care of merging in gbrlwck's mescc-tools-extra work <stikonas>hmm, that's true, === TRUE can be omitted <stikonas>I also merged somebody's else fix to kaem script <oriansj>but minor detail and something hopefully learned for the future. <oriansj>well I'll take a look and clean it up <oriansj>stikonas: thank you for letting me know, will review in 2 minutes <oriansj>and I tweaked mkdir to allow for mkdir foo -p bar baz and restrict the parent directory creation to be more behavior compatible with gnu mkdir <oriansj>Hagfish: I also enjoyed Dr Wheeler's post and that someone posted a link to sin.c in stage0. As this isn't something new for us but rather the reason for the restrictions on our root from the beginning. <zv>oriansj: in terms of documentation, I guess one question I have is who are the consumers of each repo? do people use these subprojects outside of bootstrappable? <oriansj>zv: at this point most of the repos are used internally. Only Live bootstrap and Guix produce the results outside of bootstrappable. <oriansj>for example bootstrap-seeds is only used by stage0-posix and stage0 (bare metal bootstrapping) <oriansj>stage0-posix uses M2libc, M2-Planet, mescc-tools and mescc-tools-extra to build the binaries needed by Gnu MES and Live-bootstrap. <oriansj>Gnu Mes is in live bootstrap for the bootstrapping of TCC and in Gnu Guix bootstrapping. <oriansj>and those are all of the major pieces inside of bootstrapping. <oriansj>aside from some custom work we need to do to solve bootstrapping issues in more standard tools. (all in live bootstrap, as Gnu Guix currently uses pregenerated files) <zv>how about in terms of automatic testing, CI, etc.? <oriansj>but I don't think anyone has taken that as something they wanted to do yet. <oriansj>So we might need to find a better way to do that for live-bootstrap. <oriansj>in short it is something we are willing to use but no one has taken the time to sort out all of the issues or implement the required setup bits <oriansj>possibly because they found other work more fun or more interesting. <oriansj>yeah compute time is rare and limited due to crypto abuse. I might just end up having to pay for CI for live-bootstrap in the long run <oriansj>hopefully find a FSF approved git CI provider. <oriansj>but it isn't at the top of my list to deal with it yet, so it is open for anyone to solve if they have an idea to solve it. <zv>do y'all need compute time? x86, x86_64, others? <oriansj>zv: well, people sanity checking is very useful. It helps keep us honest. <zv>we can take that out of band, but it would make sense to discuss or figure out if it it makes devs' lives easier <oriansj>zv: well all of the devs are here so it can certainly be discussed here. <oriansj>live-bootstrap is probably the big one for CI (fossy or stikonas feel free to correct me) and it indirectly also tests all of the major pieces up to GCC+Guile <oriansj>another area needing a person, is the battle testing of PowerPC support in mescc-tools (possibly help define/redefine M1 syntax) to enable it to become a future target for MesCC; adding new architecture ports is also very valuable and highly in demand because the amount of work involved. <zv>ok. I am a bit busy this week with work, but I should be more available after. I have POWER hardware and can make it available. <oriansj>also each new architecture M2-Planet supports and stage0-posix has, the higher the bar for any trusting trust attack to hide must be. <zv>on a scale of 1 to 10 where is sparc? <zv>in theory it can be brought up from FPGA which is cool; I don't have any available to me to test at the moment but could arrange to play with that later this year <oriansj>zv: well now that we added word based support to mescc-tools for RISC-V; adding any fixed length architecture should be just a matter of figuring out ELF-header (hopefully no curve balls like PowerPC had [you'll see it rather quick]) then making a few DEFINEs and encoding the immediates formats needed and done. (so a couple hours to a day of work) <oriansj>Then of course write a test using those DEFINEs and immediates (like hello world) so that if someone else breaks the arch the test will fail <oriansj>the stage0-posix work for a new architecture is 1-4 months depending how terrible the architecture is at bootstrapping. <oriansj>mescc-tools->M2-Planet+M2libc->stage0-posix is the suggested order for new architectures but you get a great deal of freedom if you take responsibility for an architecture. <oriansj>I'll help when I can if you get stuck and there are lots of examples to work from in other architectures. <oriansj>oh and not everyone lives in the same timezone (people literally from around the world), so feel comfortable posting whenever, the people up will respond if they have an answer or might flag the person who does when they next get online. ***robin__ is now known as robin
<nckx>kpcyrd: I manually renewed it for now. Thanks for noticing. <nckx>I guess I know whose messenger you were. <nckx>It's good to mention it in #guix. bootstrappable.org runs on a Guix machine, but don't ask me why it doesn't share the same certbot configuration… <gbrlwck>does mes-m2 build with our bootstrapping toolchain on x86(_64)? <gbrlwck>i see that #undef and #error unsupported in M2-Planet when building mes-m2; and though it completes compilation it doesn't run.. <stikonas>#undef is not done yet, I might do it next <stikonas>gbrlwck: mes-m2 builds on x86 but not on x86_64 <stikonas>it does need a bit of work to build on x86_64 (but less than for riscv64) <stikonas>some M2-Planet glue foe x86_64 is missing <stikonas>gbrlwck: by the way, things are quite slow on qemu-system-riscv64 with full emulation <stikonas>so much slower than qemu-user or real HW <stikonas>mes seems to not crash on startup either <stikonas>although, crashes on more complicated stuff (e.g. mescc compilation) <stikonas>or maybe not, it was wrong mescc file (untemplated) <gbrlwck>stikonas: you know: if you have stuff you want me to try, just tell me (with as exact instructions as necessary) <stikonas>I'll probably be mostly looking at m2-planet... <riv>hello, im rain1 i changed nick <stikonas>oriansj: #undef is now working, so mes-m2 compiles without preprocessor warnings in non-bootstrap mode <stikonas>oriansj: by the way, why are M1-0 and blood-elf-0 build using --bootstrap-mode? <stikonas>is there some problem in M0 and it fails to compile M1 files without --bootstrap-mode? <oriansj>stikonas: short version is it has to do with M0 <oriansj>although M2-Planet can build M1-0 and blood-elf-0 without bootstrap mode, M0 can't quite build the resulting output correctly. <oriansj>we could do some work to eliminate the --bootstrap-mode if there was a real benefit in mescc-tools for doing so <oriansj>(like 40ish minutes of work total for all architectures) <oriansj>I really need to add more tests for macro support <stikonas>yeah, that's true, we don't have macro tests yet... <stikonas>well, I guess it's fine to keep bootstrap mode... <stikonas>I was just not sure what's the reason...