docker: update some dockerfiles #588
Conversation
The modified implementations have been tested on Debian bullseye. * prefer latest Ubuntu image, hopefully reducing the image count * for Ubuntu versions, prefer numerical versions to unsorted codenames * prefer packaged build systems to local rebuilds * prefer the current default version of each build system * delegate resolution of indirect dependencies to apt
There was a problem hiding this comment.
Looks good. See one small comment below.
@asarhaddon have you built these new images and tests the mal impls in them? That's a lot of work...
impls/ocaml/Dockerfile
Outdated
| [FROM ubuntu:vivid | ||
| [FROM ubuntu:20.04 |
There was a problem hiding this comment.
hmm, what is this [ (also in the original file)?
There was a problem hiding this comment.
It was apparently inoffensive.
There was a problem hiding this comment.
I am testing manual installations on a physical machine. This does not catch all issues.
There was a problem hiding this comment.
From your comment and the error message with the factor language, I guess that Dockerfiles are not executed before each test run, but only used when manually generating a new image for each language.
If this is correct, the results are probably not meaningful, but the merge request at least documents a way to recreate a local test environment, and may be useful during next update of the image.
Spotted by dubek. The bracket was apparently ignored.
The initial motivation is to provide an explicit path to the python3 interpreter, as the versioned executable is not always in PATH.
|
The xslt failures illustrate such differences. I have hopefully solved the first issue (python3 may not be in PATH), but now runtest.py fails to find impl/xslt/run on actual docker images. |
Debian/Ubuntu do not ship a python->python2 link by default. With the improved logo implementation in another branch, there is no need anymore to tweat the garbage collector settings.
|
Hello. |
|
Sure. |
Explictly select python 3. The `python2` and `python` packages will
be removed from Ubuntu. Until each call site is fixed, install a
/usr/local/bin/python symbolic link as a non-intrusive work-around
(.deb packages do not interfer with /usr/local).
Add an explicit maintainer for bbc-basic.
Undo some cosmetic changes in order to reduce the global diff, this
merge request will probably be sqashed before acceptance.
Move lib{readline,edit}-dev out of the generic part.
Use existing .deb packages for GHDL and vim.
|
@asarhaddon BTW, so that we don't duplicate work, I'm working on getting this refactored on this personal branch: https://github.com/kanaka/mal/tree/update-some-dockerfiles. I think I just need to track down a go build issue and then I'll merge since it will be no worse (i.e. elm, common-lisp, and objpascal that have issues). |
|
I have refactored these and merged them to master now. Here is the CI workflow: https://github.com/kanaka/mal/actions/runs/10256887753 Should just be objpascal, elm, and common-lisp that fail. |
|
In order to fix objpascal, just remove the |
|
@asarhaddon Removing the CMem module did the trick. Out of curiosity, where did you find the info about CMem? |
|
@asarhaddon The common-lisp issue is weird. If I go into the container and run make 5 times, each time it complains about a different dependency and then eventually succeeds. So something isn't quite hooked up right to work with more recent versions of stuff. |
|
I have found https://wiki.freepascal.org/CMem while investigating the differences between step0 (not affected) and step1 (affected). Now, CMem is present in both, and motivated by the C pointers in readline, so trying to remove it was a short in the dark. |
|
@asarhaddon sigh, I got common-lisp working on my local system by using sbcl to build instead of cl-launch: 062fb6f. However, in GHA CI, it crashes right after building the first step: https://github.com/kanaka/mal/actions/runs/10270914448/job/28419731317 I've filed a ticket and pinged the original author: #660 |
The modified implementations have been tested on Debian bullseye.
prefer latest Ubuntu image, hopefully reducing the image count
for Ubuntu versions, prefer numerical versions to unsorted codenames
prefer packaged build systems to local rebuilds
prefer the current default version of each build system
delegate resolution of indirect dependencies to apt