That all sounds right. One thing is that it seems like Eric was aiming towards having these images turn into "official" images by basing them off build pack. That's what I gleaned from poking around and trying to figure out what build pack is. That said, I have no idea exactly what would make a docker image "official" or who would confer that status on the cl images.

I made some pull requests. Probably these are primarily of interest as something you would read (by looking at the diffs) rather than actually merge.

One note, I made at least some of the update.sh scripts capable of using gsed on the Mac, instead of sed. On the Mac Apple installs a version of sed that isn't compatible with the GNU version. They look for gsed and use it instead if it's on the user's path.

Best,
R

On 24 Nov 2025, at 11:57, David Cooper wrote


Hi Robert, 

I did not yet notice your PRs somehow, and with the help of AI, I've been stripping down each cl-docker-images/ project one by one, excising Timmons's legacy matrix-based build pipelines, and replacing with straightforward builds on trixie/amd64 only for now. So far I have done this for sbcl/ and ccl/. It still uses the ./update.sh to generate a directory per CL impl version, which contains Dockerfile and support files. And I'm still keeping some (now simplified) shared ci yml code in the cl-docker-images/ci-helpers/  project and included in each project's .gitlab-ci.yml, to avoid tedious code repetition in each. 

The AI agents have assured me that we can layer back in multi-architecture targets in due course, but that Timmons's setup is somewhat over-engineered for our immediate purposes (assuming "immediate purposes" = debian on x64/amd64) and is ripe for replacement with more "modern" (and hopefully simpler) alternatives for achieving multi-architectural docker image targets, with some target platform combos being doable using the local docker on common-lisp.net without need to depend on a far-flung network of runners set up on physical machines on a rack in a closet at MIT or whereever. 

I've already completed a pass of this "stripping down" on sbcl/ and ccl/, so your PR's might not smoothly merge in anymore to those, and I may have to merge them manually unless you'd like to push new commits to your PRs so they will apply to the current HEAD for sbcl/ and ccl/ (please advise on that, after reviewing the current sbcl/ and ccl/ HEADs if you will). 

I was about to start on ecl or clisp next, but i'll look for your PRs before starting to rip anything apart on those, perhaps merging before I start ripping those apart and hereby saving myself some work ...🙏

Dave

P.S. Since it seems you & I may be looking at some of this stuff concurrently, feel free to pop into #common-lisp.net on IRC, I'm usually in there as dcooper. 






---- On Mon, 24 Nov 2025 11:47:50 -0500 Robert Goldman <rpgoldman@sift.net> wrote ---

On 21 Nov 2025, at 18:25, David Cooper wrote:


Hi Dave --

I have bypassed some of these for ASDF. Originally, I sent pull requests for my updates, but with Eric gone, the PRs were going nowhere, so I dropped that. Instead I started building the docker images by hand, pushing them to my personal DockerHub account, and using those in my GitLab pipelines.

I will check today and make sure there are PRs on GitLab for all of my updated docker images. That should help you get started. The configuration that Eric had is now woefully old -- basing the images on Debian versions that are no longer under LTS. So you will want those updates.

That said, I was not able to get the windows images to build at all locally. So they may be broken and I haven't updated their base images (at least not consistently).

I didn't figure out how to get Eric's toolchain to build the images, either. I just used his update.sh script to generate the Dockerfiles and then built them myself. I have no idea how the Gitlab actions are supposed to work with this.

Hope that helps! More soon when I check the PRs.

R

Hi Robert,

 I'm trying to resurrect some of the cl-docker-images pipeline.  Just thought I would check with you because I think you have bypassed these for asdf? In case I get them working again I'd like to compare notes and avoid too much duplication of work, and I'd like to make whatever images I come up with be compatible for retro-fitting into asdf at some point in case you'd like to relieve yourself of the need to keep your own ones maintained (or we could adopt your ones as the clnet-hosted ones).

Did you understand all of Timmons's bashbrew runners? I'm replacing those with a single shell runner on our future host but I'd like to get it to docker-in-docker after that... and maybe support multiarch using emulation (I think Timmons had actual hardware running each of his platform-specific runners). 

Dave Cooper