IRC channel logs
2025-09-06.log
back to list of logs
<stikonas>hopefully gtker can fix it much quicker now <vasi>Googulator: Do you know where the parallelism is coming from in `make iso`? We're not setting MAKEFLAGS or passing -j <vasi>Oh nm, it's the CONCURRENT_PACKAGE_BUILDS make variable, which defaults to zero (meaning nproc) <fossy>stikonas: ooh, do you have a link or anything about bootstrapping tcc mob dierctly from mescc <stikonas>fossy: it was an email forwarded, I can link the repo but note that there we'll need to upstream it, it's not upstream quality yet <stikonas>janneke commited the end result of mes tree into one giant megapatch <fossy>that's not very nice for version history <stikonas>no, that will be just temp branch for testing <stikonas>that's why I said it will all need upstreaming <stikonas>janneke: by the way, don't know if you saw but I've now root caused M2-Planet 1.13.1 -> mes 0.27.1 miscompilation with (system* "true") <fossy>oh, that is a much smaller diff than i was expecting <stikonas>janneke: high bits are coming from uninitialized variable <stikonas>fossy: yeah, even with current tinycc, apparently some of that float stuff is not needed <fossy>stikonas: well that is quite good then! <fossy>cautiously optimistic about this! <stikonas>at some point we had like 6 builds, then I think I reduced it to 3 or so, but we need even less <stikonas>but I think we might need to start worrying about nyacc upgrade <stikonas>and that at the moment uses Googulator's fork <stikonas>and possibly some of the functions defined in that patch are now in mes too <stikonas>string-every, vector-fold and F_OK seem to be available in mes now <stikonas>seems fine to me though, but probably needs a run with your pregen file scanner... <Googulator>vasi: looks like there's unfortunately good reason for upstream repo deifinitions getting pulled into the build environment even in DISABLE_UPSTREAM_REPOS='y' mode <Googulator>many SPECs don't correctly declare their "provides" lists <Googulator>e.g. python-sphinx_rtd_theme.spec BuildRequires "font(fontawesome)" <Googulator>but nothing explicitly "Provides: font(fontawesome)" <Googulator>there's fontawesome4-fonts.spec, but it doesn't declare that provided artifact <Googulator>RPM is able to find and dynamically add this to the provides list, so the final binary RPM will have "Provides: font(fontawesome)" in it, even though the spec neglected to say it <vasi>huh that must require that the repo definitions be _used_, not just present, right? <Googulator>and then that's extracted into the repo definition files (specifically, primary.xml), which gets loaded by "makecache" and subsequently used for dependency resolutions <vasi>like if we put back the azurelinux-repo-* packages, but we don't have host resolution working inside the chroot, this will still break? <Googulator>Luckily no binaries get pulled (all package install operations receive a "disable-repos" parameter for them), but the package list of the binary repo is currently used for resolving dependencies <Googulator>No, because later another call to tdnf makecache happens after everything is populated, and that one succeeds <Googulator>Also, a further speedup is possible if we build sqlite before rpm, and not pass -DENABLE_SQLITE=off to rpm's cmake <vasi>I really don't know how to feel about this, from the "what's the definition of 'bootstrapping'?" perspective <Googulator>For now, I rolled back 3.0-bootstrap to before we started removing the upstream repo dependency, with a new branch "3.0-bootstrap-dependency-resolution" created for solving this <vasi>Ideally a bootstrap-from-source should be self-contained, right? It's a bit weird if it requires someone else serving us metadata from a previous full-build <Googulator>yeah, and it's a chicken-and-egg issue, because, how was the first ever build achieved? By taking the dependency graph of another distro? <Googulator>At least it's not a Trusting-Trust vector, or at least I can't see how it could become one <Googulator>My plan now is to write a script to parse primary.xml from the upstream dependency graph and inject any dependencies found into the relevant spec files <vasi>If I bootstrapped without the external repos, and then bootstrapped _again_ while pointing azurelinux-repos at my original bootstrap, that would work right? <vasi>(would take approximately forever of course) <Googulator>The first one would fail, because of unresolvable dependencies <vasi>Oh and speaking of DNS, I have a failure in the coredns package with `connect: network is unreachable` <vasi>It looks like it's trying to fetch dependencies from the network during the build, which sounds kinda gross <vasi>Doesn't look like a test failure <vasi>I think the source is supposed to include vendored dependencies, so I'm not sure why `go get` would have to reach out to the network <Googulator>go does in fact pull dependencies from the network, but only in source form <Googulator>that's pretty much standard fare in the go world <Googulator>did you try to build with network disconnected? Or was this a random network hickup? <vasi>i didn't turn off network access, i was assuming the chroot runs with network disabled! <vasi>the deps should be included in the source, i mean <stikonas>janneke: hi, did you have a chance to look at that mes libc patch? <stikonas>gtker and I think it would be better to fix it on mes side rather than workaround in M2-Planet <janneke>stikonas: i don't have a problem including this to mes... <stikonas>I tested it already on x86_64 and in progress on riscv64 <stikonas>so on x86_64 I could bootstrap all the way to tinycc's tcc-mes (that is only partially functional and a bit crashy) <janneke>...but it puzzles me a bit how this was not necessary before, or how this isn't necessary for gcc or mescc? <stikonas>and kernel initializes only the lower 32-bits in that syscall <stikonas>so in the latest M2-Planet (which in advance allocates stack space for locals) we have some old data in high bits of uninitilized variables <stikonas>older M2-Planet was doing register pushes (if I recall push rax) <stikonas>I guess we were a bit lucky that it worked <stikonas>anyway, x86_64 works as before with this patch <janneke>i can imagine having 64bit ints simplifies things without (too many) consequences <stikonas>on riscv64 I confirmed that (system* "true) works <stikonas>but rest of the build is still running (it is very slow on my visionfive2) <stikonas>actually we had some of these 32-bit vs 64-bit problems with ekaitz last year too <stikonas>when we worked on 64-bit riscv64 bootstrap <janneke>ACTION may add an #if __M2__ and a comment <ekaitz>oh yeah the padding and all that? <ekaitz>it's like I forgot almost everything we did <stikonas>janneke: I guess for now I'll have to patch mes until 0.27.2 comes out... <ekaitz>also, we didn't fix other arches in that commit <ekaitz>is that related with the issue stikonas ? <stikonas>hmm, don't remember, let me try to refresh my memory by looking at your write-ups <ekaitz>we might have some other problems <stikonas>qemu is till not working well for riscv64 bootstrapping. I still get various random crashes. Which is why I'm running my current test on visionfive2... <stikonas>luckily this time it was easier to debug <stikonas>it was a similar method (side by side debugging) but I had a good guess where to look at (waitpid function) since it was returning wrong value for (system* "true") call