building ubuntu v3.4 xbb-bootstrap fails in openssl tests due to cert expiration

[shabble]

Hi again!

I thought I'd have a go at building the builder image to see if I could slim it down a bit from the 5.5ish GB to make github CI builds a tiny bit faster, and ran into some problems with the image building.

I'm assuming the develop branch is the appropriate place to use, since master doesn't have the v3.4 scripts, and appears to be in a little disrepair.

Develop gets a lot further, but I think it's running into this issue from openssl where their test certs have expired in 2022 😢

version 1.1.1p was the first release that worked for me, was still failing with 1.1.1o. Haven't gotten much further, so can't be certain it won't break further down the line, but I'd hope they're not making massive changes.

(I also noted that the plan is to potentially retire the current approach and do something with installing xpacks directly instead, so maybe this isn't even worth fixing, and I'll just use hte current docker hub image as-is)

Cheers!

[ilg-ul]

building the builder image to see if I could slim it down a bit from the 5.5ish GB

Hmmm... I'm glad you did this, since it allowed you to get a better hands on experience with the build environment, and so understand why we must consider the next step, which is to modularize it.

openssl

Yes, these expiring certificates are a real source of trouble for reproducible builds. In the latest run of the RISC-V GCC I used 1.1.1q.

retire the current approach and do something with installing xpacks directly instead, so maybe this isn't even worth fixing

That's exactly what I was mentioning in a previous message that I'm thinking about. XBB Second Edition should use binary xPacks, not a huge Docker image.

We can get there in several steps. I'll write a proposal for you to think of, but it'll take me a few more days, I had a small setback with the RISC-V GCC build, and I had to redo it, plus that at the same time I installed the future machine for the Linux & Windows builds. Your clang binaries might be the first done by the new machine. ;-)

[shabble]

I'm assuming there isn't really much point setting up the github actions workflows to do parallel/matrix builds of the different targets/platforms if it's ultimately going to be constrained by your build server generally. And it wouldn't be great if it failed the other platforms just because an RPi got hung up or something...

Then again, a certain perverse part of me wonders if you can run distcc workers on github-hosted nodes...

[ilg-ul]

there isn't really much point setting up the github actions workflows to do parallel/matrix builds

initially I used a single action to run all 5 platforms, but, for various reasons, it proven not practical, and now I have 5 separate actions, which I trigger in sequence.

distcc workers

No idea, but I don't think that existing build scripts support it.