<lagash>stikonas: I was meaning Dasharo/whatever was behind the conference oriansj got booted from <stikonas>well, I've no idea about that conference... <oriansj>git fetch no problems; git push that <oriansj>what are the odds github changed their ssh keys? <oriansj>but it does match the new key that I am seeing <oriansj>thank you pabs3 for finding that blog post and sharing <pabs3>it came up on #debian-til (OFTC) recently <oriansj>so stikonas your riscv32bit work has been merged <oriansj>well it looks like the UpdateHostKeys isn't in ssh until version 8.7 and Debian is only on 8.4p1 Debian-5 <pabs3>Debian bookworm/sid have 1:8.7p1-2 <oriansj>took 5 days of fuzzing but 1 new segfault has been found. patch will be up shortly <Hagfish>i don't know whether to be impressed that the process can find such a well-hidden issue, or worried that even 5 days isn't enough to catch them all <oriansj>Hagfish: well the goal isn't for M2-Planet to be 100% bug free nor crashproof but rather minimize the number of problems the users may have using it for bootstrapping. And Segfaults are a UI bug <opal>oriansj pabs3 theyre finally using that ed25519 key? <oriansj>well November 16th was the scheduled removal day of legacy keys <oriansj>So if I was on a newer version of ssh, then I probably wouldn't even see it <Hagfish>that's a good point. i guess M2-Planet can be thought of as a pure function, and the only relevant class of bug is whether it produces the wrong output for a given input ***ChanServ sets mode: +o janneke
***ChanServ sets mode: +o janneke
***ChanServ sets mode: +o janneke
<gbrlwck>oriansj: Open Source Firmware people do not care about bootstrappability? how odd <stikonas>gbrlwck: btw, maybe you can try riscv32 files on real HW? <stikonas>now stage0-posix has hex0, hex1, catm, hex2 and M0 <vagrantc>a lot of embedded development pretty much comes down to "does it work at all -> ship it! ... what's the next project? ..." which doesn't leave a lot of incentive for doing things "properly" <gbrlwck>stikonas: i sure can -- given that it is supposed to work on RV64 <vagrantc>rv64 hardware doesn't necessarily support rv32 code <gbrlwck>vagrantc: i guess so, but kicking somebody off a discussion because they mention bootstrappability <stikonas>vagrantc: why wouldn't it uspport rv32 code? <vagrantc>stikonas: for the same reason it doesn't support powerpc code? ... it's a different architecture <vagrantc>true, but the extensions aren't necessarily there in hardware <vagrantc>they *might* be, but you can't rely on it <gbrlwck>i ported crt1.c (and the others in mes-m2/lib/linux/riscv64-mes-mescc) to RV64, how do i compile/create/copy/generate (actually, whatever it takes) libmescc.a? <stikonas>gbrlwck: maybe follow live-bootstrap steps <stikonas>you can see what env variables have to be defined <stikonas>gbrlwck: you can even try to get live-bootstrap to do this job, but then you would have to create mes-m2 tarball ***ChanServ sets mode: +o janneke_
<stikonas>oriansj: did you say you had a fix for get_machine --override crash? <stikonas>in the meantime I found a crash in all M0's <stikonas>I guess it wouldn't affect real programs, but they crash on just definitions file <vagrantc>any bootstrappability concerns with using "new" tar formats for source tarballs? ***janneke_ is now known as janneke