Docker image fails with "ERROR [builder 7/9] COPY containers/os-release /etc/os-release"
(1) By Marcelo Huerta (richieadler) on 2023-02-02 01:19:20 [link] [source]
From checkin ec8ef573 forward, I get the indicated error when I try to create the Docker image.
Using the Dockerfile from checkin cdd89e2d works properly.
(2) By Warren Young (wyoung) on 2023-02-02 10:57:14 in reply to 1 [source]
Lemme guess: you’re on Windows.
That file is now generated at configure time to get around the prior method's limitation of requiring BuildKit, which precludes Podman entirely at the moment, and on Docker requires the longer “docker buildx build” syntax.
Either:
- copy that file over from a Linux box after configuring Fossil there
- use WSL/Cygwin to configure on Windows
- copy the
os-release.infile to the expected name and edit the version variable within by hand - build the image on Linux, push it to a repo, and pull it down on Windows to build your container from that properly versioned image
- use my
tangentsoft/fossilimages on Docker Hub - come up with another way to satisfy all parties
(3) By Marcelo Huerta (richieadler) on 2023-02-02 11:58:28 in reply to 2 [link] [source]
Lemme guess: you’re on Windows.
Correct guess (and apologies for making you guess, that should have been part of my message).
copy the os-release.in file to the expected name and edit the version variable within by hand
Hum. That seems to be the easiest way -- I'll attempt this and see how it works.
use my tangentsoft/fossil images on Docker Hub
That's a tempting idea also.
The other ones are more problematic, as my intent is merely building the image to create a fossil executable that I can upload to my repo farm in Sourceforge. A new version just triggers my itch to compile and upload the latest Linux binary after I compile successfully on Windows.
OTOH I can still use the Dockerfile from cdd89e2d, build the image, extract fossil and revert.
(4) By Warren Young (wyoung) on 2023-02-02 12:22:12 in reply to 3 [link] [source]
The tangentsoft/fossil images are built for production and meant to be reused.
The biggest problem with them is that if you don't like how I build them, you're back to building from source.
As for the os-release file, there's another option in cases like yours: rip the reference to it out of the Dockerfile, since it exists only to make nspawn happy.
Now, given that nspawn is fairly far down the popularity ladder for OCI container runners, you might ask, "Well, Warren, why don't you do that for everyone and make things easier?" And my answer is, "It is so good of you to ask, Marcelo. The reason is, I think having an option to run the containers with a 1.4 MB runtime is awesome. The requirement for dozens, even hundreds of megs of tooling merely to run a six-ish meg Fossil image is the computing world's equivalent of 'conspicuous consumption.'"
And since I've set up a situation where I get to argue both sides, I win. :)
(5) By Marcelo Huerta (richieadler) on 2023-02-02 12:42:23 in reply to 4 [link] [source]
Don't get me wrong, I'm very happy that there is an option to run win minimal resource consumption. It's just that I wasn't very knowledgeable about the process for the creation of containers/os-release. Now it seems that generating this manually is the simplest option for me and I'll go for that. It satisfies my own sense of correctness :)
In any case, your comment is very welcome because it gives me some more insight about the process of container creation for Fossil. So thanks.