IRC channel logs

<stikonas>pushed new M2-Planet changes into stage0-posix...

<stikonas>(lots of updates as you can see in the changelog: https://github.com/oriansj/stage0-posix/commit/142ba3acbb09cbf4717158a634e7b76bfb70b9e9)

<ekaitz>stikonas: you have the 17th line repeated in 26

<ekaitz>but looking very interesting!

<ekaitz>good job

<stikonas>ekaitz: well, these are different programs

<stikonas>both M2-Planet and M2-Mesoplanet had this change

<stikonas>well, lots of stuff was done by gtker

<fossy>stikonas: nothing against your just-now PR, but what behaviour were you seeing?

<fossy>i usually run my tests in interactive mode, and saw no problems...

<fossy>unless it only shows up in qemu?

<stikonas>hmm, I was running in bwrap mode

<stikonas>fossy: just --bwrap --interactive --update-checksums

<stikonas>somehow it was complaining that files are read only...

<stikonas>or something like that

<stikonas>so it was asking to confirm the removal

<stikonas>yeah, I was surprised too...

<stikonas>well, I just noticed this an hour or so ago

<fossy>hmm, ill merge for now, but i would like to investigate that a bit more

<fossy>it's very very weird that it only comes up with interactive

<fossy>^ wait can you confirm that it's only interactive mode?

<fossy>what's your underlying filesystem?

<stikonas>fossy: btrfs

<stikonas>well, I don't know if it's just interactive mode

<stikonas>I could try running earlier revision

<fossy>hmm, okay, will test a bit more here

<fossy>i think stagex people had some intersting behaviours with btrfs

<stikonas>it does happen on files that have now write permission though

<stikonas>and such were the files in PR you just merged

<stikonas>fossy: I don't see how --interactive can affect bwrap mode

<stikonas>well, I'm running now on older commit without --interactive

<stikonas>fossy: so I'm getting it in non-interactive mode too

<stikonas>the first one is in coreutils pass2: rm: remove write-protected regular file `src/false.c'?

<stikonas>and the command line was "./rootfs.py --external-sources --bwrap --mirror http://live-bootstrap.stikonas.eu/ --build-kernels"

<ekaitz>stikonas: did you see my message yesterday?

<ekaitz>or better said, today at 1am

<ekaitz>LOL

<stikonas>ekaitz: yes

<stikonas>I replied to you but you disconnected

<ekaitz>oh

<stikonas>it's for 2 different programs: M2-Planet and M2-Mesoplanet

<stikonas>both were adjusted

<ekaitz>oh i see

<ekaitz>btw, i passed the first round of nlnet for Mes speedup effort

<stikonas>by the way, those changes also include some fixes for risc-v that we saw last year (though unfortunately don't completely fix it)

<stikonas>oh nice

<ekaitz>the idea is to make it a bytecode interpreter

<ekaitz>so it is faster, but still small

<stikonas>remember those unxz crashe when built with M2-Planet, I've fixed one, those unfortunately it's not the only crash (but now it crashes just before the end rather than at the beginning)

<stikonas>ekaitz: well good luck

<ekaitz>:)

<stikonas>though in the meantime M2-Planet might also become more capable

<stikonas>maybe one day it can build tcc

<ekaitz>the idea is also to update mes with m2-planet's improvements

<stikonas>yeah, that might improve at least readability

<stikonas>fossy: by the way, I've just tried mes-m2 is now good enough to build tinycc

<stikonas>(at least if I pull in latest stage0-posix, haven't tried with current one)

<stikonas>I think for a long time we needed mes step in the middle (mes-m2->mes->tinycc) since direct build of mes-m2 -> tinycc was crashing

<stikonas>(ok, it already works with current live-bootstrap...)

<stikonas>fossy: so what do you think about skipping mes and using mes-m2?

<stikonas>I've tested it on x86 and amd64 and it worked in both cases

<stikonas>or should we keep building full mes?

IRC channel logs

2025-02-23.log