IRC channel logs
2025-09-05.log
back to list of logs
<vasi>let me know if you make any progress, i can retry the bootstrap tonight <Googulator>vasi: made some changes to the Go bootstrap, the final Go build is now 64-bit - you might want to retry with this new Go <Googulator>also, make sure you clean up azurelinux/build/toolchain after a toolchain build failure, otherwise residual garbage can get in the way <vasi>yeah i've been doing a `git clean -fxd :/` after <vasi>Googulator: you need a `git submodule update --init` for pcre2 <vasi>Also we still need PKG_CONFIG_PATH for qemu <vasi>You have the notes about "Source files must made available via one of:", is that telling me to do something manual? I don't really know what SRPM_URL_LIST would be here <vasi>It looks like without making any manual changes and just running your command, SRPMs are being packed up, so maybe it's fine? <Googulator>no, those notes were copied from the Azure Linux documentation <vasi>I also notice that during the build, every tdnf command goes really slow, with messages like `Failed to synchronize cache for repo 'Azure Linux Official Base 3.0 x86_64'` <vasi>I'm not sure why it's trying to sync those if we have DISABLE_UPSTREAM_REPOS=y, or why it's timing out <Googulator>I noticed that too - it appears to be a bug in the Azure Linux build system, in a code path that's skipped when the host is also Azure Linux of the same version. The Go source code executes "tdnf makecache" in the chroot with repos.yum.d configured to access the official MS upstream repos *before* it adds /etc/resolv.conf to the chroot. I <Googulator>intentionally didn't fix that, out of fear that it could cause upstream binaries to be pulled in if the network access worked. <Googulator>On an Azure Linux host, the host's already synchronized cache is copied into the chroot instead at the very beginning, and "tdnf makecache" is never called inside the chroot. <Googulator>Also, _after_ adding resolv.conf, a local repository containing already built packages is added to the chroot, and then makecache is called again, which is why the build is able to proceed after all the upstream access attempts time out. <vasi>Anyhow, the good news is that so far it's running well, without any changes from your doc except PKG_CONFIG_PATH for qemu, and submodules for pcre2 <Googulator>vasi: This might work for the slowness: comment out the line "build_rpm_in_chroot_no_install azurelinux-repos" in toolkit/scripts/toolchain/build_official_toolchain_rpms.sh; this way, the official repos will not be added to the worker chroot image, and the initial "tdnf makecache" will be dummy. <Googulator>...I take that back - that doesn't work. Instead, you need to skip *installing* the azurelinux-repos packages in toolkit/tools/pkggen/worker/create_worker_chroot.sh <Googulator>vasi: pushed a new commit to 3.0-bootstrap to hopefully fix the slow tdnf issue <vasi>First run of ISO failed on a bunch of packages. I think it maybe just ran out of disk, woops! <vasi>Googulator: for the new build change to 3.0-bootstrap, do i have to rebuild my toolchain? <vasi>oh looks like probably not, cool <Googulator>For disk space, 128GB is *barely* enough if you clean up the build directories for prerequisites before doing the ISO build <Googulator>vasi: BTW, copypaste error in gentoo-scratch: "sudo mount -t devtmpfs devtmpfs dev/pts" is certainly not correct, should be "sudo mount -t devpts devpts dev/pts" <vasi>Googulator: hmm, when i try to build the iso now, i get an error <vasi>Importing Azure Linux GPG keys. <vasi>Importing GPG key: /etc/pki/rpm-gpg/MICROSOFT-RPM-GPG-KEY <vasi>error: /etc/pki/rpm-gpg/MICROSOFT-RPM-GPG-KEY: import read failed(2). <vasi>make: *** [/root/azurelinux/toolkit/scripts/chroot.mk:45: /root/azurelinux/build/worker/worker_chroot.tar.gz] Error 1 <vasi>i'm not sure why it's doing this now, and wasn't before <Googulator>because we no longer install the Azure Linux upstream repo metapackages, the GPG key for those repos is also excluded - but then some script tries to use it unconditionally <Googulator>it's toolkit/tools/pkggen/worker/create_worker_chroot.sh <vasi>i mean, i'm confused why we even have the azurelinux-repos-shared package installed, given we skipped everything containing 'azurelinux-repos' <Googulator>it's trying to find the GPG key found in that package, and failing <stikonas>janneke: turns out that option needed to build unpatched tcc is only in new tcc <vasi>Googulator: no i think something else is going on here <vasi># chroot /root/azurelinux/build/worker/worker_chroot rpm -qa | grep azurelinux <vasi>azurelinux-rpm-macros-3.0-7.azl3.noarch <vasi>azurelinux-check-macros-3.0-7.azl3.noarch <vasi>azurelinux-repos-shared-3.0-5.azl3.noarch <vasi>azurelinux-repos-3.0-5.azl3.noarch <vasi>it looks like we're skipping _installing_ the package, but still setting up the RPM db for it!? <vasi>eg: `Adding RPM DB entry to worker chroot 87%: azurelinux-repos-shared-3.0-5.azl3.noarch.rpm` <Googulator>They are parts of the toolchain, so they become parts of the toolchain repo <Googulator>toolchain needs to be shared between bootstrap and non-bootstrap builds <stikonas>Googulator: speaking of new tcc, not sure if you saw but somebody might have managed to bootstrap tcc mob directly from mescc, and possibly on x86_64 too <stikonas>so perhaps we'll manage to unlock live-bootstrap on x86_64 <vasi>But your patch to the create_worker_chroot.sh only filters packages container 'azurelinux-repos' from the first of these two steps <vasi>so we're creating the chroot in a really weird state, where it _believes_ certain packages are installed, but their files are actually not there <vasi>Working well so far. Build is a lot faster now