IRC channel logs

2021-02-04.log

back to list of logs

<OriansJ>siraben: I'll review your pull request later tonight after I finish moving knight-native to M2libc
<OriansJ>siraben: your pull has been merged.
<OriansJ>and to delete a javascript file from talk_notes so github stops sending me crap updates about how it has vulnerable dependencies.
<siraben>OriansJ: I think you can disable those updates
<siraben>Thanks
<gforce_d11977>stikonas: fossy: WOW! + congratulations, we have musl+tcc0.9.27 - https://cirrus-ci.com/task/5738565666603008
<gforce_d11977>(i do now a local build an check the binaries...)
<fossy>stikonas[m]: i am midly confused about flex-2.5.11
<fossy>what is main2.mk
<fossy>and is main.mk even used
<gforce_d11977>fossy: can not find these files, where is your flex-2.5.11 from? (i just downloaded from http://download.nust.na/pub2/openpkg1/sources/DST/flex/)
<stikonas[m]>fossy, I initially wrote it to rebuild itself but then added newer flex, I'm considering removing it in my flex 2.6.4 work
<stikonas[m]>main.mk is the one used
<stikonas[m]>main does bootstrap and 1st pass
<stikonas[m]>Main2 would be uses for 2nd pass if we want to build unpatched lex
<stikonas[m]>But locally, I have already removed that
<stikonas[m]>In my flex 2.6.4 work
<stikonas[m]>I'm also looking at moving m4 after musl, the we can drop that patch but I got linking errors, so need to investigate more
<fossy>ah, ok..
<fossy>please do remove one and clean that up in flex 2.6.4, tis rather confusing
<gforce_d11977>stikonas: fossy: i'am sorry, there is still something wrong: is a local built on i386: http://intercity-vpn.de/bootstrap-stikonas-branch-musel-2dcf471a1e150175aa9ed35cf8fbe79820cec9e3.txt
<gforce_d11977>(maybe it's a RAM issue, i will repeat an report)
<stikonas[m]>Hmm, never hit it here
<stikonas[m]>Maybe because the binary overwrites itself... I'll replace it with install
<gforce_d11977>stikonas[m]: it *is* a lowram-issue, i'am pretty sure, my QEMU used only 1G, will fix and repeat, sorry
<stikonas[m]>Oh ok
<stikonas[m]>Yeah, we need more ram, especially as we add more sources
<gforce_d11977>(ok, qemu runs again, uploads to some URL... - i'am AWK, cu later)
<gforce_d11977>(ok, qemu runs again, uploads to same URL... - i'am AWK, cu later)
<marusich>dftxbs3e, dongcarl, the issue is fixed. However, I think coreutils-final doesn't build; I'll probably open a report about that one next..
<marusich>I lied. It just built for me fine.
<marusich>I'm sure something else won't build... If you find something that is broken, please open a bug report about it so we can track which commits fix which problems, etc.
<stikonas>fossy: so I think musl is ready to merge?
<stikonas>CI has now passed
<stikonas>your other PR I think is good to go too
<gforce_d11977>stikonas: fossy: here in i386 QEMU it fails: http://intercity-vpn.de/bootstrap-stikonas-branch-musel-2dcf471a1e150175aa9ed35cf8fbe79820cec9e3.txt
<gforce_d11977>i can fire a x86_64 QEMU to see if this changes something, shouldt i?
<stikonas>yeah, test with x86_64...
<stikonas>it migth be some of the patching that we do...
<gforce_d11977>ok, will do
<gforce_d11977>(new log at: http://intercity-vpn.de/bootstrap-stikonas-branch-musel-2dcf471a1e150175aa9ed35cf8fbe79820cec9e3-x86_64.txt)
***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado
<stikonas>gforce_d11977: still failed on x86_64...
<stikonas>something is strange with your setup
<stikonas>but I guess you'll have to investigate since only you can reproduce it
<stikonas>hard to do anything without reproducer
<gforce_d11977>stikonas: this is just "./rootfs minikernel" - but i will look deeper and report.
<stikonas>oh, maybe due to minikernel...
<stikonas>well, this patch is a bit rough https://github.com/fosslinux/live-bootstrap/blob/master/sysa/musl-1.1.24/patches/fenv.patch but I don't know if it might be causing it
<gforce_d11977>stikonas: i have no idea what can be missing in the kernel...? let me dig a little bit
<stikonas>I thought we wouldn't use floating exceptions...
<stikonas>oh, it might be that musl has more requirements on kernel
<stikonas>and your minikernel is now insufficient...
<stikonas>at this stage in the bootstrap I think we'll not be running bootstrap kernel anymore once kernels are sorted out
<gforce_d11977>i will make a 'defconfig' x86_64 kernel and check
<gforce_d11977>shit, it works: http://intercity-vpn.de/bootstrap-stikonas-branch-musel-2dcf471a1e150175aa9ed35cf8fbe79820cec9e3-x86_64-defconfig.txt
<gforce_d11977>now i have to find the CONFIG_SYMBOL which makes that happen
<stikonas>ok, so musl requires more stuff from the kernel...
<stikonas>well, start with error message...
<stikonas>sys_siglist stub
<gforce_d11977>(i make progress finding to additional needed KERNEL_CONFIG_SYMBOLS, but the time needed for a compile-run-cycle is really, arrgggg!)
<Hagfish> https://github.com/signalapp/Signal-TLS-Proxy/issues/6 "Signal-TLS-Proxy/nginx-relay/Dockerfile sets up an nginx server by downloading unauthenticated code"
<stikonas>flex 2.6.4 https://github.com/fosslinux/live-bootstrap/pull/29
<stikonas>fossy: ^^
<stikonas>oh, m4-1.4.4 also builds and unlike 1.4 it doesn't need patch...
<stikonas>let's update it. It's also 10 years newer
<Hagfish>nice
<stikonas>I couldn't get m4 working with musl though, something strange is going on with alloca. I was able to solve same problem in grep...
<stikonas>but doesn't matter, we can build it with mes libc
<stikonas>hmm, now bison is left...
<stikonas>hopefully it works
<stikonas>that's the final component in flex/bison bringup
<stikonas>argh, bison is also struggling with that "alloca" symbol...
<stikonas>ok, it worked after tweaking cflags