IRC channel logs

<Googulator>fossy: I'm seeing non-reproducible hashes for linux-4.9.10. Binary diffing reveals... timestamps.

<Googulator>Are we setting KBUILD_BUILD_TIMESTAMP?

<Googulator>OK, seems like KBUILD_BUILD_TIMESTAMP is not set, and indeed, never was - https://github.com/fosslinux/live-bootstrap/commit/e06a19f9e20dc4e3fe8084f03a00b8cf2bc9a6b4 is what exposed this problem (we're now building the Linux kernel as a proper package, so it gets checksummed now)

<fossy>oh - that is highly likely, i generated the checksums from a QEMU run and retested them with a chroot run but i don't think i had --build-kernels

<Googulator>Correct checksum is fd2264a08cbeeb28f3e2580cba174376a154c77b0ef6cbf67b55fd13c0987f52 after defining KBUILD_BUILD_TIMESTAMP=@0

<lrvick>On a totally fresh debian-13 machine, after some failed download attempts, I was able to build from stage0 to gcc13 with live-bootstrap. Will have to continue hunting down whatever edge cases cause the issues I filed that impact me when building from inside a debian qube.

<lrvick>But hey, I have a control case now at least.

<Googulator>fossy: Updated https://github.com/fosslinux/live-bootstrap/pull/361 and posted https://github.com/fosslinux/live-bootstrap/pull/366 for the kernel timestamp issue. Regular (one stage) bwrap now fully works with this, even with --build-kernels and without --update-checksums; for 3-stage bwrap, I've successfully completed stage 1, and am currently

<Googulator>running stage 2 with no issues so far.

<Googulator>good news: CI successful up to Linux kernel build (former sysa), and moved on to the "up to Python bootstrap" stage (former sysc1)

<Googulator>bad news: that 2nd stage failed due to network being unavailable and distfiles not being carried over (should be easy to fix)

<Googulator>pushed a fix for it

<matrix_bridge><Andrius Štikonas> lrvick: worth running diffoscope on good and bad autoconf output tarball

<stikonas>got something interesting "working" on UEFI. Unfortunately, afterwards it still completely crashes UEFI: https://stikonas.eu/files/bootstrap/posix.png

<stikonas> (https://git.stikonas.eu/andrius/stage0-uefi/src/branch/posix-runner/posix-runner/posix-runner.c)

<stikonas>hmm, no idea what can cause those crashes :(. They seemingly happen after short random time after return from syscall, sometimes only part of the text in my next function is printed. Strange...

<lrvick>Built live-bootstrap twice from 0 from fresh clones with chroot and confirmed matching hashes of 4f50d8f5e1f123a8e6d34dff1d5892f79d250f2fb5d7fa2a94cff1f2e8f9649c

<lrvick>now to replicate that in a container....

<Googulator>fossy: what's the time limit on GitHub CI passes?

<Googulator>2.5 hours?

<Googulator>pass2 is currently chugging along with the timer showing 2h 12m, I'm starting to get worried it will time out

<Googulator>of course, we can move Python bootstrap to pass3 if needed, and if that makes pass3 too long, my PR actually supports any number of passes, so creating a pass4 is trivial

<stikonas>Googulator: I think 4h

<stikonas>though this now says 6h https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration

<stikonas>maybe it was increased at some point

<Googulator>OK, pass 2 is successful - and pass 3 then did nothing, because it hits the same breakpoint as pass2

<stikonas>hmm, I'm getting a bit stuck with 64-bit syscalls. Maybe I should try to implement 32-bit. That might be more useful in the short term anyway (as live-bootstrap only runs till completion on x86)

<Googulator>the challenge with 32-bit syscalls is that you need to handle int 80h there

<Googulator>Does UEFI provide a way to install your own interrupt handler?

<stikonas>no idea...

<stikonas>but yeah, it's looking more complicated

<stikonas>maybe I'll stick to 64 bit mode

<stikonas>where I had some partial success

<stikonas>perhaps I should try to figure out how sysretq works (I'll need it later anyway for non "exit" syscalls)

IRC channel logs

2023-12-25.log