<OriansJ>and deesix I'll update the man pages for M2-Planet to reflect the recent changes <deesix>OriansJ, nice, that confirms my testing on armv6l (with override) so it seems we're still quite compatible here. <OriansJ>and with yt_'s previous testing of M2libc for AArch64 you made the painful M2libc migration complete deesix. Thank you for all of your help ^_^ <OriansJ>deesix: I was going to merge the knight and knight-posix migration later tonight <deesix>OriansJ, I mean, at least there's bootstrappable.h and test1000, right? <OriansJ>as I was doing finishing touches for the M2libc knight <deesix>OriansJ, about M2libs itself... I saw that fopen seems to open the file twice. Any reason for that or is just a leftover? <stikonas>fossy: hmm, it's a bit hard to split lines in kaem... <yt_>OriansJ: fantastic! and well done deesix; I only did the fun bit XD <OriansJ>deesix: you are right; I honestly forgot to delete 2 lines <OriansJ>I guess I'll fix that with my knight patch <deesix>Indeed, the examples of porting by yt_ helped a lot (to other side of the coin is that I had to skip here and there some parts already done). Thank you, yt_. <OriansJ>interestingly enough we can drop test/common_* when the M2libc migration is complete <deesix>OriansJ, that'd be great, but I expect some breakage in other projects using them. They will need to migrate to M2libc in that case. <yt_>OriansJ: don't the bootstrap scripts in mescc-tools-seed use the test/common_* files still? <deesix>... kaem, blynn-compiler; well, everything using M2-Planet. <fossy>I plan to move to m2libc once I am sure it is stable and have the time to migrate <deesix>fossy, nice README by the way, thanks. <OriansJ>deesix: well yes that is unfortunately the last bit of work for this weekend. <OriansJ>yt_: that is correct but fortunately I'll be doing that as part of my testing of --bootstrap-mode to ensure it is as smooth as possible this weekend. <deesix>OriansJ, are the bootstrappable.h functions just a rename away or we need to move arguments in some cases? <OriansJ>fossy: I was going to handle that migration transparently for you with the update of mescc-tools-seed <OriansJ>deesix: it should be a drop in replacement as they should just be copy implementations being duplicated around. <stikonas>fossy: I wonder if yacc misbehaves because of mes libc... <deesix>OriansJ, hmm, I don't think is just drop in. There're new names and I didn't see a compatibility layer (nor that I think that was the better plan). <fossy>OriansJ: I have some extra m2-planet tools custom written <deesix>OriansJ, for example (maybe the only one) strtoint() I think is some numerate_*. <stikonas>fossy: hmm, actually it's probably not mes libc. I tried tcc with glibc on my system <stikonas>"parser.y", line 67: fatal: redeclaration of precedence of $ <stikonas>on live-bootstrap I was getting "parser.y", line 67: fatal: redeclaration of precedence of <stikonas>fossy: maybe in the meantime, I'll resubmit first two commits as a separate PR... <deesix>OriansJ, +1 for using the new-style flags in the docs... --little-endian, --architecture, etc. I was planning to update the scripts during unification, and also remove --exec_enable. <OriansJ>deesix: I guess I am going to have to pay for those design mistakes too. <OriansJ>fossy: nice, I'd send you patches if I knew about them ^_^ <OriansJ>deesix: the next release of mescc-tools I am going to add a warn to stderr when the old flags are used that in 2 releases they will be removed and update it to warn of next release and then boom gone forever <deesix>OriansJ, perfect. By the way, the sha256 locale thing seems to be shell related instead, I'll point the logs to vagrant unless someone else do it before. <OriansJ>deesix: yes but fixable with a set environment variable <OriansJ>I wish there was a trivial solution to remove all localization behaviors form sha256sum <OriansJ>depending upon how annoying it is; we might just do a sha256sum program to add to mescc-tools so we can abandon ALL external tools in testing and development ***vup2 is now known as vup
<deesix>OriansJ, well... we're setting an envvar and it's not working. I would no workaround it setting another some other way. Any reason to not use the exit value? Is it standarized enough? <OriansJ>deesix: well numeric comparisons are a bashism <deesix>OriansJ, when I talk about "shell related", it seems to be splitting our 'LANG=C foo' lines (I guess you saw the channel log about it). <OriansJ>deesix: well if we do export LANG=C on a seperate line it it will apply to all following lines <OriansJ>and export variable=value is generally well supported (even in kaem) <deesix>OriansJ, well... given that we're calling the function in a subshell, I guess export LANG=C is an option. I was a bit worried about contaminating the caller. <deesix>Anyway, feels like a interesting "upstream" regression. If that's the case, I'd expect a fix from them soon. <OriansJ>in an ugly sort of fashion knight-native is going to behave more like on a posix but not really. <OriansJ>deesix: I don't think exports inside of scripts change the parent shell but I could be wrong and it would be trivial to test <OriansJ>deesix: yeah export doesn't survive outside of the shellscript itself, except to children processes <xentrac>as deesix points out, it doesn't even survive to the rest of the shellscript if you export in a (subshell) <OriansJ>xentrac: wait until you see the abomination before celebrating *shifty eyes* *xentrac celebrates the abomination <OriansJ>xentrac: it should be inherited by the subshell if properly export'd and not just variable=value on the same line <xentrac>yes, but if the subshell does the export itself, it won't affect the parent: (export FOO=37); echo $FOO <xentrac>and that's the case deesix is describing <OriansJ>xentrac: completely fair and correct <OriansJ>but fortunately not a case that should apply to any of the M2-Planet or mescc-tools tests <OriansJ>unless Debian's build process is fucked in ways I dare not imagine <OriansJ>as we are trying to do: export LANG=C and sha256sum proof on two seperate lines in the same shell script and trying to get the LOCALE specific failures to dis-the-fuck-appear. <xentrac>I mean. not that it exists. but that POSIX utilities' behavior depends on it by default <OriansJ>but maybe I just wished not to deal with unicode and localization problems while having to sort out the already difficult as is problem of bootstrapping GCC and the whole free world from a bootstrap seed that could fit in a twit <OriansJ>and that isn't even going to the having to design hardware, deal with lithography layouts and all the other hoops required before we are going to be done. <OriansJ>it isn't like I'll have to do the same work that the RISC-V team did for GCC support and the rest before anyone takes the Knight hardware seriously. Oh wait >.< yes I will and probably without an army of grad students to do the work for me. <xentrac>does Knight need to be taken seriously to succeed? <OriansJ>Which means we will have to do x86 or other well known architectures along the way. Otherwise people will just dismiss the stage0 work as having to depend on big as binary blobs of firmware and/or microcode. <OriansJ>xentrac: only if I don't want to deal with doing a bunch of x86 real-mode bootstrap work and build a kernel using cc_x86 <deesix>"""as we are trying to do: export LANG=C and sha256sum proof on two seperate lines""" My understanding was about doing the export in the function, but I see your plan now, OriansJ. <xentrac>hmm, I'm not sure those are the only two options ;) <OriansJ>deesix: yes and the function is only dealing with getting text from sha256sum which we can check <OriansJ>xentrac: I'd love an option where I don't spend 20 years having to justify every byte and transistor required to bootstrap Guix on a modern commercially available processor. <OriansJ>oh and more fun; I finally figured out the solution to my libre-x200 crashing when building rust-1.33.0 and it wasn't enable 128GB of swap (/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor set to powersave; it was overheating and the CPU simply turned off. I guess that is what I get for opted for the highest performance CPU they offered. <OriansJ>and M2libc with knight support is now officially up <OriansJ>know to checkout that the stdio.c tweak didn't break anything <OriansJ>fossy: better than not being able to build ffmpeg and mpv at all in Guix <OriansJ>xentrac: don't need an MMU for single tasking <OriansJ>just allocate all memory for the process and wait for it to finish <xentrac>either of those CPU designs would be a lot easier than Knight to target a compiler to, and to persuade people of the absence of backdoors in <fossy>OriansJ: how does that relate to powrtsave lol <xentrac>the second of the two is academically respectable <OriansJ>xentrac: yeah but how are they in regards to hand written assembly. <xentrac>pretty pleasant, though more verbose than a CISC <OriansJ>fossy: my libreboot'd x200 went up to 72.0°C while building rust-1.33.0 before shutting down hard. <OriansJ>xentrac: I guess I'll have to add wirth's CPU to the backlog of stage0 ports that I'll have to do. <OriansJ>fossy: well 72 was the last temp it recorded before crashing <OriansJ>So thermal runaway could have taken it much higher in a short period of time <OriansJ>but it doesn't really matter since it was polling at a 5 second period <OriansJ>so within 5 seconds of hitting 72°C it was shutdown completely <OriansJ>perhaps pausing the build process in Guix could have worked around that defect long enough for the CPU to cool down but powersave was available and it seems to work. <OriansJ>I guess the libreboot developers never thought anyone was going to do a crazy amount of builds with the highest end processor available for the x200 for days and days <xentrac>it's an option, it's not something you have to do <OriansJ>xentrac: building from source is something I *HAVE TO DO* <OriansJ>I'd be building the guix bootstrap binaries too if they were finally probably bootstrapped. <OriansJ>what person do you think spends time finding broken builds in Guix to report and in some cases provide work arounds when fixes are not likely because they don't want to rebuild the world to fix it. <xentrac>OriansJ: oh, yeah, building from source is <xentrac>but you don't have to do it on every possible platform, including academic teaching processors that have never been taped out <OriansJ>xentrac: or hope someone does the work for me <OriansJ>I'll still have to audit it but atleast that work is much easier <xentrac>yeah. did you check out Thacker's Verilog? <xentrac>"much easier" may not be a sufficiently strong term <OriansJ>xentrac: haven't had a chance to check yet. <OriansJ>problem is I know people are going to say verilog doesn't count because xxxMB of binaries needed to build the bitstream, etc <xentrac>OriansJ: sure, there could be backdoors in ISE Design Suite but there obviously aren't in Thacker's processor design! <OriansJ>looks like knight-native tests will have to wait until tomorrow but knight-posix is done <OriansJ>looks like savannah rejected bootstrap-seeds as part of Gnu Guix and they want me to do the gnueval@ route. Fun <civodul>OriansJ: gnueval@ is to make a project part of GNU <OriansJ>civodul: they will not take the binaries otherwise <OriansJ>So I guess it is what is required to move from having the root of Gnu Guix's trust off Microsoft servers. <OriansJ>So unless someone has another way to solve that problem, I guess I'll be going that route later today <stikonas>From questionaire: "Dependencies: nothing" <civodul>what are you trying to do on Savannah and/or GNU? <stikonas>civodul: OriansJ wants to move bootstrap seeds away from github to sanannah <stikonas>but savannah does not host non-GNU binaries <janneke>annoying, otoh it could give bootstrapping more visibility; could be worth it in the end <stikonas>in principle you can "make" bootstrap binaries with sed and xxd... <stikonas>if they don't want to host actual binaries... <civodul>just to be clear, when you write "bootstrap seeds", which seeds are we talking about? <civodul>ah ok, so it's different from what Guix uses <stikonas>well (this 2 binaries are for x86, repo contains seeds for some other arches too) <civodul>then, why don't we have them on ftp.gnu.org like the other seeds? <civodul>yup, definitely, but that's what i can help with :-) <civodul>if it's binary-looking source, it's source IMO <stikonas>civodul: it's both source and binary at the same time <civodul>perhaps that's what the Savannah folks need to understand <stikonas>and the other file is without comments, so basically binary <janneke>civodul: i should maybe have said: "i am proposing to use them ...", this is only on wip-full-source-bootstrap <stikonas>source to binary is basically: sed 's/[;#].*$//g' $input_file | xxd -r -p > $output_file <civodul>stikonas: in that case, you could perhaps have a Makefile that does that so that the binary itself doesn't need to be in the Git repo? <stikonas>well, that's what I was saying 15 minutes ago... <stikonas>"in principle you can "make" bootstrap binaries with sed and xxd..." <janneke>civodul: it would certainly need discussing; we could of course build hex0 and kaem in guix, and create our own %bootstrap-seeds, like we do for other bootstrap binaries <civodul>stikonas: oh sorry, i hadn't understood that <janneke>otoh, using a the same blesed seed that everyone uses, makes some sense too <stikonas>yeah, I think I wasn't clear enough there too... Especially if you are not always following this channel <civodul>i'm not always following any channel :-) <janneke>"<civodul> then, why don't we have them on ftp.gnu.org like the other seeds?", because it's wip; if we choose to use this bootstrap as is, we'll copy bootstrap-seeds-1.0.0.tar.gz from lilypond.org to ftp.gnu.org <civodul>janneke: yeah we can do that once the branch has been reviewed i guess <pder>janneke: I found and fixed an issue in mes-libc that was causing ls from coreutils to crash while working on live-bootstrap. The fix is in stdlib/qsort.c. Whats the best way to submit a patch? <janneke>pder: great; please send a mail to bug-mes@gnu.org <stikonas>pder: thanks! I guess once new mes can be pulled in you'll submit a patch for coreutils makefile? <pder>stikonas: yeah I will have the rest of the pieces together shortly which include updating the coreutils makefile and a small patch to ls.c <stikonas>and yesterday I tried bash after your patch, but still couldn't get interactive mode... <pder>In the mean time I was thinking of patching mes-libc in tcc-0.9.27.kaem right before libc is rebuilt. We can remove that patch later on. <pder>I dont think interactive mode for bash will work until readline is compiled. I didnt try to compile it because I noticed that guix disabled readline support in their build as well <janneke>stikonas: the early bash we use in guix also does not support interactive mode <pder>But you should be able to run scripts which will be more powerful than kaem <stikonas>anyway, once we have autotools, we can rebuild stuff a bit more properly... <stikonas>I guess at that point we'll be basically done :D <stikonas>gio: ping, any ideas regarding heirloom lex? <stikonas>somehow yacc fails to compile lex'es parser.y <gio>stikonas: Will check when I have time. Don't remember exactly if there were difficulties with that. <stikonas>oh, it actually works when I use my normal system tcc with glibc... <stikonas>so it's almost surely something to do with mec libc <stikonas>hmm, that probably means we should try to get musl... <pder>stikonas: do you know if our current tcc supports musl, or do we need a version more recent? <stikonas>but if I remember correctly we can try to patch it out <stikonas>anyway, building musl is not completely straightforward... <stikonas>pder: and the other possibility is to try to find out mes libc bug... <pder>I just rebuilt with tcc -g, then used gdb to find the location of the segfault <pder>is yacc crashing or just returning bad results? <stikonas>at least it failed to process .y file from lex <stikonas>I think it actually managed to process .y file for gnu flex... <pder>but tcc + glibc returns correct results? <stikonas>pder: yes, (that's tcc suplied by my distro) <stikonas>I'll also double check some compile flags ***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado
<stikonas>I extracted first 2 commits from yacc PR and then marked yacc as draft <stikonas>will need musl before yacc is functional <stikonas>fossy: well, I think yacc does something incorectly on mes libc <stikonas>it doesn't crash, just fails to parse.y file <stikonas>so yacc compiled with tcc/glibc on my normal distro is functional <stikonas>yacc compiled with the same version of tcc/mes c library is not <fossy>I might look at that today then <stikonas>(and yacc compiled by gio on musl was functional) <stikonas>so I'm not 100% sure but it looks likely <fossy>should be possible to check by stepping through with gdb <stikonas>fossy: oh, and I think I can't remove those backslash escapes in my PR... <stikonas>otherwise make thins it is CFLAGS=first_word some_target <fossy>" expands tokens afterwards iirc, ' dosent <stikonas>I have some patch/directory changes for that patch anyway <OriansJ>civodul: well technically half the repo is source and the second half is binaries that are generated from the source half. Requiring make, sed or xxd kinda defeats the purpose of bootstrap binaries. <OriansJ>also as we are talking about 101,802bytes for everything (only 4,415bytes of binaries [x86=357+737][AMD64=431+894] [AArch64=526+1470]) <OriansJ>So doing uncompressed releases for each architecture would be 1094, 1325 and 1996bytes respectively <OriansJ>doing xz compression for say the x86-only release would be 860bytes for the boot.tar.xz <pder>fossy and stikonas: I pushed a branch to my live-bootstrap repo that fixes ls. Note that I had to implement a fix in mes-libc. I chose to just overwrite qsort.c using cp in tcc-0.9.27.kaem until that fix is applied upstream. I cant use patch since it isnt available yet. <stikonas>in principle we have patch a bit later and can rebuild mes libc :) <stikonas>although, if it's going to reach upstream soon, it might not be worth it <pder>Or maybe we should fork mes and use our fork as the submodule remote? <stikonas>there are already too many different version of mes... <pder>I just overwrote stdlib/qsort.c before rebuilding libc.a the last time <stikonas>anyway, by the time bash is bootstrapped, janeke might merge that patch :) <OriansJ>proposal sent. Hopefully they like it