***Noisytoot is now known as noisytoot[x]
***noisytoot[x] is now known as Noisytoot
<siraben>Is it possible to run live-bootstrap without KVM? <oriansj>siraben: you forgot to include bootstrappable <siraben>oriansj: yeah, I'll adjust that. Is there a publicly annoucement somewhere? <oriansj>siraben: just the majority vote from the develoeprs stating that we are leaving and now we are having the final vote to where the alternate is. <oriansj>and I'll be tallying those votes publicly Monday so that the final decision of the community is known and performed. Hence my encouragement for everyone who hasn't voted yet to do so as soon as possible. (and I do mean literally everyone on this channel) <siraben>have I voted? I think I sent it a few days ago <oriansj>vagrantc: well it is a public vote; so just irc <oriansj>just include the text "my vote" when posting a link to your vote. to make for easier searching from the logs as I collect the balots from the logs <vagrantc>oriansj: fwiw: libera: approve, oftc: approve, matrix: abstain <oriansj>vagrantc: not absolutely required, just done easy validation of the votes and to give people as much space to provide additional details if they do condition. <oriansj>vagrantc: yes it meets the minimal requirements of a vote. <Melg8>Is tcc - first problem on path of making live-bootstrap support more than just x86 architecture? <oriansj>Melg8: no the first problem on the path to bootstrapping is always mescc-tools and M2-Planet+M2libc. Then it is MesCC (assuming we get the M2libc conversion of Mes.c done) and then finallly it is TCC and GCC. <oriansj>As if stage0-posix can't build mes.c for running of MesCC to compile TCC. Live-bootstrap doesn't even get off the ground. <oriansj>Hence why mes-m2 conversion to M2libc is a priority for those who care about porting to more architectures. (GCC branch is where the work is being done) <Melg8>i mean - from mescc-tools-seed i saw AArch64 folder - i suppose that contains seeds for that arch? on what point (what program/tool) support of AArch64 stops? can M2-planet run on it? can Mes run on it? <oriansj>Melg8: the first stop is mes-m2 which currently only builds on x86 <Melg8>so guix no binaries builds are just for x86 too? <Melg8>okay, what you mean by "goal is the GCC branch"? <oriansj>Melg8: The GCC branch is to convert mes-m2 to use more C standard functions which are supported by M2libc <oriansj>However it appears some scheme code changes will also be needed to get it all working together. <oriansj>So the majority of the work will need to be done in scheme. <Melg8>sometimes my brain need pictures to handle this stuff) So M2libc - is it support anything other than x86? <Melg8>why it called gcc? what it has to do with gcc? <oriansj>Melg8: M2libc is the multi-architecture libc that M2-Planet can build with. <oriansj>It provides standard C functions like fputs and fgetc, etc. <oriansj>It is so close to C that if you can use standard GCC for development and testing without any changes and likely very few special cases <oriansj>So the problem is build mes-m2 with GCC and get MesCC to run on it <oriansj>Hence why the majority of the work remaining is scheme work. Left to any scheme programmer who cares to do it. <Melg8>so there is GNU Mes - from which mes-m2 were derived, with goal of making GNU Mes build with M2-Planet (which can run on multiple architectures?) <oriansj>Melg8: that is more of a question for janneke as that is his baby. <oriansj>But hopefully if we have a scheme programmer interested in portable MesCC, we can finish the M2libc porting work and bring MesCC to all of the architectures that M2libc supports <Melg8>I think it would be great to have somewhere a list of issues or in general - task in style of "If we have an X-skillset person, which could do Y, than we could solve Z issue) - because, how scheme programmer would know that here is cool thing just waiting for him to step up) <oriansj>Melg8: well collecting that list and maintaining it is a big problem in itself as that person would need to constantly be updated on the status of the various projects and their needs. <oriansj>It is extremely related to our major problem of needing better and more accurate documentation. <oriansj>Which updating for all the projects would be a major project in its own right. <oriansj>Melg8: I agree it is a major issue but for the longest time the goal was make a convincing case that bootstrapping from hex to GCC was even in theory possible (let alone proving it true) <ekaitz>oriansj: from my short experience from the project, I agree with Melg8, it's really hard to understand all the pieces <ekaitz>otoh, you are doing a great job guiding people throught the process <oriansj>ekaitz: it is also hard for me to know what needs to be written because it is all familiar to me. So we need someone who is fresh and needs help getting understanding collected. <Melg8>oriansj do you share goals with janneke - or your efforts with mes-m2 - are completely separate and in some sense is hard fork of mes? <ekaitz>well i'm fresh so I'll ask you questions until I get the whole picture :) <oriansj>Melg8: yes we share some goals and values. But 5 years of him working primarily in scheme and me working primarily in C and assembly, resulted in a few differences in method towards solution. But that is the strength of this community. <oriansj>if anything isn't completely clear, ask and we will be happy to provide you the full details. <Hagfish>i think it would be relatively light-weight to have people create "tickets" for what they think the possible future pieces of work are, and update the status on them as they start and complete them <Hagfish>but i don't know where that would be hosted that everyone would have access to, and i think the people doing the most work should have the most say on how much overhead they want to add <oriansj>Hagfish: well the list of feature requests could possibly be added by anyone. But ultimately only the developers should choose what they want to work on. <oriansj>But again we need someone to do the work to make such a process actually be useful and take the interest in keeping it working long term. <Melg8>where the root project/page/repo ? is there one? if we choose to use ticket system for documenting issues/ goals - on which project and in which host should they be? ( i mean there is github/savvanah/gitlab spread) + there are stage0/stage0-posix and so on. And where should go cross-project issues (which involve for example stage0/live-bootstrap <oriansj>Melg8: well currently that single location is this IRC channel. <oriansj>As all of the developers discuss here. Problems reported here get noticed and potentially fixed if they look worth the effort. <Melg8>yes, problem with that - that it's not categorized have no search by topic - only by keywords - and doesn't separate chatting/goals/opinions ) <oriansj>Melg8: well it would be possible to use #tags or something similiar to extract from the IRC logs themselves <oriansj>but that might require someone to find/create something to enable that workflow. <Melg8>do your projects hosts only on github? or there are other mirrors? <oriansj>Melg8: well I try to get them into savannah. Although the bootstrap-seeds are a bit of a problem in that goal. <siraben>Is it possible to run live-bootstrap without KVM? <siraben>Melg8: I tried that Nix command but I wasn't able to enable KVM since it was disabled on the cloud VM <oriansj>siraben: you mean in a standard chroot? yes that should be possible. <Melg8>after it created system a it could be run in host environment or in chroot or in qemu <Melg8>although as far as i know python script takes it to chroot or qemu and runs - there is no option to stop just to check what's in system a an do something with it <oriansj>Melg8: well every piece should be able to run natively. The encapulation is to prevent "cheating" in the bootstrap and to prevent one's environment from contaminating the builds. <siraben>oriansj: ah, how would I make it run in a chroot? <oriansj>siraben: it starts as a kaem script. So you just have kaem-optional-seed execute your script until it bootstraps kaem or bash (depending on your preference) <siraben>Could not access KVM kernel module: No such file or directory <siraben>qemu-system-x86_64: failed to initialize kvm: No such file or directory <siraben>the command was `python3 ./rootfs.py --kernel /nix/store/kg5wa8hww2g6zc03yas7llbzrbip4b5b-linux-4.4.267/bzImage --force_timestamps --tmpdir ./temp` <oriansj>siraben: that would be the creation of the root filesystem used in the running of the virtual machine. <siraben>Hm. Going to bed now but will attempt again tomorrow. <Melg8>siraben i guess it would be "python3 ./rootfs.py --chroot" <Melg8>or "python3 ./rootfs.py --chroot --force_timestamps --tmpdir ./temp"