IRC channel logs

<nektro>just had to do the copy myself, was assuming it'd be automatic coming from other build systems

<fossy>:)

<stikonas>argh, I wanted to do one last force push

<stikonas>to remove extra newline

<stikonas>I'll just push directly

<stikonas>(not force of course)

<stikonas>ok, done

<fossy>oops, sorry about that haha

<fossy>yeah, i disabled force push to master

<fossy>so even if you tried by accident it wouldn't go through :P

<stikonas>fossy: I think a minor issue is here https://github.com/fosslinux/live-bootstrap/blob/master/sysa/run.sh#L235

<stikonas>should it be ${SOURCES}/after.kaem ?

<stikonas>yeah, we definitely want branch protection on master

<stikonas>just to prevent accidents

<stikonas>i.e. force pushing to origin instead of some other remote

<fossy>yes, relic that never updated

<stikonas>maybe just remove?

<stikonas>it's the last thing in sysa

<stikonas>so ram is no longer an issue

<stikonas>oh, actually there is still linux build

<stikonas>still, it works even without that thing

<stikonas>so probably unnecessary

<stikonas>fossy: any objections if I artificially add bin and lib symlinks to musl package?

<stikonas>that will allow to just unpack musl, unpack python and run "./lib/ld-musl-i386.so.1 ./bin/python3.11"

<stikonas>something like https://github.com/fosslinux/live-bootstrap/pull/229

<fossy>stikonas: remove is ok, won't matter at all once new kernel stuff implemented

<fossy>yeah i think that musl change is ok, it doesn't hurt

<stikonas>doras: is your live-bootstrap pipeline running in a VM?

<stikonas>I wonder if that might be the cause for more frequent autoconf/automake intermittent failures

<doras>Well... That's a good question. To my understanding it is, yes.

<stikonas>perhaps that the key to better reproducing it

<stikonas>I was trying to run it in a VM, once I hit it with automakt 1.15

<stikonas>then next run even automake 1.11 caused it

<fossy>stikonas: that's very interesting

<stikonas>so basically bwrap mode in a VM

<fossy>stikonas: hmm, i run qubes os on my main dev machine,so everything runs in a "vm", but that is Xen, rather than QEMU..

<fossy>and i've experienced it twice/probably 30 or so full builds in the last month

<fossy>(many more partial builds)

<fossy>(but those don't include automake 99% of the time)

<stikonas>I think that VM I was running on and getting failures is also Xen

<stikonas>again failure with automake 1.11

<stikonas>CDPATH="${ZSH_VERSION+.}:" && cd .. && autoconf-2.64

<stikonas>autom4te-2.64: cannot create autom4te.cache: No such file or directory

<stikonas>and running "make MAKEINFO=true" again caused the same failure once, but rerunning it once again suceeded

<stikonas>I guess autoconf 2.64 has race conditions

<stikonas>(make invokes autoreconf there)

<fossy>interesting

<stikonas>well, it's a race condition

<stikonas>so might be quite sensitive to specs and settings

<stikonas>at least on automake 1.11 it fails building amhello

<stikonas>which is completely useless for us

<stikonas>fossy: remove "doc" from SUBDIRS in top-level Makefile.am?

<fossy>no objections to that

<fossy>since that appears to be where the race condition is

<fossy>hopefully it doesn't surface anywhere else...

<fossy>might have to do a bit more testing

<stikonas>well, so far I've only seen in various versions of automake

<stikonas>1.11 and 1.15 I think

<oriansj>So build single threaded to eliminate race condition?

<nektro>just read https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst for the first time, really impressive work yall

<nektro>does M0 compile .M1 files?

<stikonas[m]>nektro: yes but with some limitations

<stikonas[m]>Only uppercase hex numbers are supported

<stikonas[m]>And only for native arch

<stikonas[m]>E.g. M0_x86 can't build for riscv

<nektro>ah okay, just wanted to double check

<nektro>didnt know if there was an M1 meant to be built by M0 instead

<nektro>oh i see that comes later

<stikonas[m]>M1 is just C version of M0 with a bit of extra features

<stikonas>better commnad line parsing, support for features needed by all architectures, etc...

<nektro>following live-bootstrap parts (but working on my own project of a package manager) i get https://bpa.st/raw/L255W

<nektro>not sure if that'd be a bug in M0 or hex2 from what ive read i think itd be M0, or im calling it wrong

<stikonas>nektro: yes, that's not correct

<stikonas>M0 is only macro assembler

<stikonas>you still need to link resulting file with hex2

<stikonas>nektro: just look at those kaem files in stage0

<stikonas>in principle we start here https://github.com/oriansj/stage0-posix/blob/master/kaem.amd64 but interesting stuff is in https://github.com/oriansj/stage0-posix-amd64/blob/2633ecf626c7ef932f4cad445a1963a1e9e94883/mescc-tools-mini-kaem.kaem

<nektro>thanks :)

<stikonas>nektro: we also have stage0 running on UEFI on amd64

<mihi>probably question for oriansj: Can you give some background about this line in M2-Planet's "weird string" detection logic? https://github.com/oriansj/M2-Planet/blob/ae48dbd6cb824f53d6dda1a374c8e475ea1845e9/cc_strings.c#L77 If I understand correctly, a string that contains whitespace followed by a colon is treated as "weird" (i.e. hex encoded in the M1 output). However, in M1's code (mescc-tools) I

<mihi>cannot find why this might not work. Tracing back history, the functionality (only after newline) was introduced in https://github.com/oriansj/M2-Planet/commit/280b2ade528b5cf9a45e2d33c2755063a240a35e which talks about »Fixed "\n:foo bug«.

<mihi>Is this related to one of the platform-specific M0 versions that confused a label inside a string literal?

<mihi>As it is, it does not cause any bugs (of course; you could always hex-encode all strings) - it just looks weird to me (no pun intended)

<stikonas>mihi: I guess try removing it and see if anything breaks

<mihi>in case the code is needed, it *would* have been buggy, though: It checks escaped whitespace but not escaped colons \x3A :)

<stikonas>there is also weird string code in cc_*

<stikonas>if you can get tid of that one, it would be even better

<stikonas>but I think I saw some strings were encoded by it

<mihi>I believe the "weird string" code as such is needed unless you make sure there are no "weird strings" in M2-Planet's source code.

<mihi>I was only surprised about that special case with whitespace and colon

<stikonas>e.g. blood-elf-0.M1 has ' 0A 3A 45 4C 46 5F 65 6E 64 0A 00'

IRC channel logs

2023-01-21.log