IRC channel logs

<vasi>Ah I just got that too, thanks for debugging!

<vasi>Also had a failure in skopeo: `open /dev/stdin: no such file or directory`. Let me get my kernel fixed first, and will look into that later

<vasi>heh, i also noticed discard was off

<vasi>Googulator: did you completely remove the "make iso" step from your gist?

<vasi>Using the new kernel config, I get errno -93 (EPROTONOSUPPORT) instead of libkcapi

<vasi>*for libkcapi

<vasi>What's the best way to debug a build? `make containerized-rpmbuild`?

<fossy>stikonas: libtcc.c:819, in tcc-0.9.27

<Googulator>vasi: looks like I screwed up the ccache removal and removed the whole "make iso" line, good catch

<Googulator>Updated the kconfig again, with more crypto options - if this doesn't help, please post your /root/azurelinux/build/logs/pkggen/rpmbuilding/libkcapi-1.5.0-2.azl3.src.rpm.log

<Googulator>vasi: looks like my build has concluded, with 2 package-level failures (libkcapi, skopeo), that may not even be relevant for image generation - for skopeo, I already have a fix (the symlinks /dev/stdin, /dev/stdout and /dev/stderr need to be manually created because we are using devtmpfs intead of udev/systemd)

<Googulator>libkcapi is probably trying to call some kernel crypto API that's still disabled in the kernel config

<Googulator>Currently running the image stage of the build, which however started a 2nd package build internally - probably to build a few additional packages that weren't included in the original package stage

<Googulator>After rebooting to new kernel with the latest config, and fixing those missing /dev symlinks, skopeo and libkcapi both built successfully - proceeding to image generation again

<Googulator>vasi: we have an initrd...

<Googulator>...and an ISO!

<[exa]>#selda

<[exa]>(oops sorry)

<vasi>Googulator: thanks for updates, will retry

<vasi>Googulator: is this the ccache error you got? https://gist.github.com/vasi/8cdbb9b39cc8b7c3f1b4b61463e3b80f

<Googulator>yeah, that's it - it's a complete red herring

<Googulator>it just happens to get printed before the cause of any actual error

<Googulator>so it looks like ccache is to blame

<vasi>yeah, it's just a warning i guess. but i don't understand why php-pear failed then

<vasi>lemme re-run the build and see if it happens again

<Googulator>did you check the build log for php-pear?

<Googulator>it's in build/logs/pkggen

<vasi>what i pasted is the entire log (from /root/azurelinux/build/logs/pkggen/rpmbuilding/php-pear-1.10.13-4.azl3.src.rpm.log)

<vasi>that's why i'm so confused, i'd expect it to have printed some sort of error instead of just...ending

<vasi>(fwiw, libkcapi and skopeo completed successfully, yay!)

<vasi>it reproduced, with a slightly longer long (added to the paste). but it doesn't really solve much, just looks like the previous broken build caused the next one to break

<vasi>(cuz it left a chroot without cleaning it up)

<vasi>huh it mysteriously succeeded the third time (after i deleted the chroot build #1 left around)

<vasi>and i got an ISO! hurray!

<vasi>Googulator: possibly stupid question, for the third stage (building on the target), why are we still using NO_TOOLCHAIN_CONTAINER? couldn't we just create a container without upstream at this point?

<vasi>i guess it doesn't matter very much, since it's just for the toolchain. but it'd be nice if after a certain point, commands on our bootstrapped target converge with normal instructions

<Googulator>It's because the container path is hardcoded to pull a prebuilt container and install prebuilt packages into it.

<Googulator>Also, I'm not sure our kernel is capable of hosting containers.

<vasi>Googulator: if we just created a container with the name they use in their `FROM` statement, i think docker/podman would just use that instead of pulling from a remote. i did that as part of the stagex bootstrap and it worked fine

IRC channel logs

2025-09-11.log