IRC channel logs

2021-11-17.log

back to list of logs

<lagash>stikonas: I was meaning Dasharo/whatever was behind the conference oriansj got booted from
<stikonas>well, I've no idea about that conference...
<stikonas>oriansj: maybe merge https://github.com/oriansj/stage0-posix/pull/68 ?
<oriansj>stikonas: reviewing now
<oriansj>well that is weird: https://paste.debian.net/1219791/
<oriansj>git fetch no problems; git push that
<oriansj>what are the odds github changed their ssh keys?
<pabs3>they added ed25519 host keys https://github.blog/2021-09-01-improving-git-protocol-security-github/
<pabs3>but that was a while ago
<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>wow
<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>looks like it
<opal>took a while
<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
<vagrantc>oh, missed the context
<vagrantc>yeah, that sucks
<stikonas>vagrantc: why wouldn't it uspport rv32 code?
<stikonas>is it that hard to add?
<vagrantc>stikonas: for the same reason it doesn't support powerpc code? ... it's a different architecture
<stikonas>vagrantc: rv32 is really similar
<stikonas>it's way closer than amd64 and x86
<stikonas>all the opcodes are the same
<vagrantc>true, but the extensions aren't necessarily there in hardware
<vagrantc>they *might* be, but you can't rely on it
<stikonas>well, maybe...
<gbrlwck> https://stackoverflow.com/questions/42225043/rv64-with-rv32-instructions-support
<stikonas>anyway, worth testing
<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>a few of them are here https://github.com/fosslinux/live-bootstrap/blob/master/sysa/run.kaem#L21
<stikonas>and rest starts here https://github.com/fosslinux/live-bootstrap/blob/master/sysa/mes/mes.kaem#L10
<gbrlwck>thanks!
<stikonas>gbrlwck: you can even try to get live-bootstrap to do this job, but then you would have to create mes-m2 tarball
<stikonas>and alias still says x86 https://github.com/fosslinux/live-bootstrap/blob/master/sysa/mes/mes.kaem#L43
***ChanServ sets mode: +o janneke_
<stikonas>oriansj: did you say you had a fix for get_machine --override crash?
<stikonas>or does it still need fixing
<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
<stikonas> https://github.com/oriansj/stage0-posix/pull/69
<vagrantc>any bootstrappability concerns with using "new" tar formats for source tarballs?
<vagrantc> https://www.gnu.org/software/tar/manual/html_section/Formats.html https://mgorny.pl/articles/portability-of-tar-features.html
***janneke_ is now known as janneke