<gbrlwck>soooo... on RISCV i hit a "Checksum mismatch" exception (i guess relatively early). weird thing: the checksums displayed do not match, but the actually downloaded file's sha256sum does match the one in the SHA256SUMS.sources file... is python's sha256sum different from the other implementations? <fossy>live bootstrap dosent support riscv yet <fossy>oh, should work as a goer if you dont use kvm <gbrlwck>i know, i changed the arch test to `if args.arch not in ("x86", "riscv64")` and just gave it a go <fossy>yeah, none of rhe code has any support for it <fossy>but can you try nuking sources/? <gbrlwck>i disabled the checksum test for now <gbrlwck>i thought since compilation works up to mes-m2 i gave it a go :) <stikonas>gbrlwck: might be something changed in upstream tarballs <stikonas>and python's sha256 checksum should be the same <stikonas>although there was a bug earlier where python's downloader was not downloading whole file <stikonas>this was fixed but got accidentally reverted at some point when fossy was doing rebase but then fixed again <gbrlwck>but as i said, the checksum of the file correstponded to the entry in the checksums-file <stikonas>6f7cfc0ac6717afb6ba1f41b0da43a713ba0dd97dec1227e32effc12d79f08c1 ? <gbrlwck>i could actually build stage0 (and the extras); but i've disabled the tests <gbrlwck>but python said: Exception: Checksum mismatch: <gbrlwck>expected: 12cfa21abf618a274017d6b18e95fc6582519d7c08e2403e5c5772ccdd5b85f4 <gbrlwck>actual: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 <stikonas>that's not even the same checksum I have <gbrlwck>(i adjusted the output to see what did not match) <stikonas>hmm, 12cfa21abf618a274017d6b18e95fc6582519d7c08e2403e5c5772ccdd5b85f4 gnulib-d279bc.tar.gz <gbrlwck>so it somehow messed up to match checksum-lines with the corresponding files <stikonas>hmm, just tried with emptyh sources directory, no problems here <gbrlwck>i guess you're trying x86? this worked for me too <gbrlwck>ok, it is not about coreutils-8.32 after all <gbrlwck>gnulib-d279bc.tar.gz's entry doesn't match <gbrlwck>re-downloaded, now it seems to work :) <fossy>misleading error message maybe... will rake a look ***ChanServ sets mode: +o rekado_
<rekado_>stikonas: wow, I really don’t remember 25933! That’s when we had GCJ. <stikonas>yes, I saw... But that was my motivation of trying to build icedtea-7 directly <stikonas>if gcj could build it, I thought we should be able to do it with jamvm too <stikonas>as long as we get a slightly newer compiler <gbrlwck>fossy: not sure if that's necessary -- i was mislead by Python's stacktrace (which showed the "wrong" package followed by an ellipsis to indicate an array; i thought it was the package in question) <gbrlwck>but i guess i'll improve some more while trying to get riscv64 to work ***stikonas_ is now known as stikonas
<stikonas>it's something like f"Expected checksum is {expected}" rather than "Expected checksum is {}".format(expected) <stikonas>it's not a bit deal but let's be consistent <gbrlwck>so, live-bootstrap downloads mes twice: once to bootstrap mes with m2 (mes-m2) and then mes-0.23. this is for self-hosting mes? which are there major differences between the two? <stikonas>gbrlwck: one is mes-m2 cause that's the only thing we can build with M2-Planet <stikonas>although one could build self-hosting mes if we wanted (we actually did that before but it's a bit slow than building tcc directly) <stikonas>gbrlwck: the other mes is just latest mes release <stikonas>we want the latest C library there when we build tcc <stikonas>although, if I remember correctly, there are a few more bugfixes in unreleased master branch <stikonas>anyway, hopefully one day we can just build mes directly <gbrlwck>sooo, if i pull upstream mes-0.23 (or master branch) and merge it into my riscv64 branch i wouldn't need the both? i'll give it a try <stikonas>gbrlwck: you won't be able to easily merge upstream mes into mes-m2 <stikonas>and right now m2-planet can't compile it <gbrlwck>i only need the mescc part (if i understood you correctly) <stikonas>so basically right now we build M2-Planet -> mes-m2->tcc -> meslibc from mes <stikonas>so if you do M2-Planet -> mes-m2->tcc -> your patched mes libc then that should work <stikonas>but even mes libc has been somewhat simplified in mes-m2 (although not too much), so you might have to deal with merge conflicts <stikonas>but in any case, that's something that you'll have to do if you want to submit riscv changes upstream <stikonas>there are still quite a few features that M2-Planet does not support and upstream mes uses <stikonas>postfix/prefix increments/decrements, local structs (and accessing their members with dot operator), type casts and possibly more stuff <stikonas>maybe some of them we can avoid doing (e.g. type casts) and instead patch mes <stikonas>hopefully that will be upstreamable unlike mes-m2 <stikonas>oh there is also pointer arithmetic, but we can probably #typedef it in mes too <oriansj>well M2-Planet was an assembly prototype growing features over time; So it isn't expected to be a full C standards compiler but rather just enough C to make bootstrapping possible. <stikonas>well, that's understandable. I'm just saying it would be nice if we eventually converge in what M2-Planet supports and what upstream mes needs (could be both by improving M2-Planet and simplifying mes)