Closed stormdragon2976 closed 3 years ago
stormdragon2976 notifications@github.com writes:
Aarch64 and Armv7h machines are becoming more and more common place now days. There are Windows, Mac, and Linux binaries, but the Linux binaries do not cover these architectures. Please add binary releases for them.
The latest ghc bindist I've found for arm architecture is ghc 7.10; debian has 7.8.x; and recent versions of pandoc require ghc >= 8.
I'm sure there's some way to do this. Hopefully someone who needs this can put in the time to figuring out how, and report back here. We could then consider making it part of the release process.
AFAIK, both @vmchale and @2i3r managed to cross-compile pandoc. Maybe they have any insights on how we could support these platforms?
See also hslua/hslua#73.
I have my armv7h
cross-compiler setup running. unfortunately currently I don't have access to an aarch64
platform to test, but as far as I can say, armv7h
binaries will run on most chips providing aarch64
such as armv8
. (link and link). so it might be enough to provide only armv7h
binary.
I would love to share or help on this issue.
On my tries direct compilation of pandoc
and ghc
, was so much slow. so I cross-compiled pandoc using cabal cross-compiler
, which by itself needed binutils
, libffi
, ghc
and pandoc
dependecies cross-compiled, and then Simple
build type in pandoc.cabal
and disabling Template Haskell
flag during compilation was needed.
Someone may manage to run Template Haskell
in cross-compile mode, so Simple
build type may not be mandatory and data files would be embedded in the output binary.
@2i3r do you think it would be hard to set this up on CircleCI (or similar), which we currently use for the pandoc Linux builds?
I don't have any experience with CircleCI
or similar tools.
In the method I described above, what makes armv7h
release is an special binary of cabal
and ghc
which configured to cross-compile binaries, and there are backend tools such as libraries, headers, utils and c compiler (multiple GBs) it uses. It can be configured inside a docker or a PC, then I think build tools such as CirckeCI
might be set up to use those configured compilers and then if errors handled correctly then it might work as expected.
@2i3r, how much time such build would normally take? One concern to use CI to build is the time limit. In the past people has tried using QEMU in CI but it becomes too slow to be manageable.
Otherwise, especially when a docker can be set up, it should be easy to do it in CircleCI.
I'm also interested in this activity. Drone.io have builders for AArch64 and ArmV7. If that is of interest, I could begin to work on this with a colleague.
@rhenwood-arm - since pandoc is open source, nothing stops you from building it and making the binaries available. I think that would be appreciated!
Whether we want to provide officially endorsed ARM binaries here (on the GitHub releases page) is another question. For now, I'd be happy to have a third-party source for them.
My experience on directly compiling on ARM:
For armv7l, I'm trying to provide it as an unofficial effort here: https://github.com/ickc/pandoc-arm/releases. Probably will fall in pandoc-extras later. (By the way, it took Raspberry Pi 4 about 2.8 GiB of RAM and 3 hours to compile.)
For aarch64, I have trouble getting stack/cabal compiled. If I'm not mistaken it is not supported.
If someone can give me the exact command of cross compiling pandoc targeting the 2 platforms, I can try to build them and test it on those arch.
In the long run, if it doesn't take too much time to compile with CI, and if there's a way to run tests on the target arch (current tests are run using cabal/stack in the compiling stage), then may be it can be provided as an official release.
By the way, am I right that for the current released binaries, the Windows' come from CI, but he macOS/Linux builds come from @jgm directly? I think this might be true in the past but not sure any more.
By the way, am I right that for the current released binaries, the Windows' come from CI, but he macOS/Linux builds come from @jgm directly? I think this might be true in the past but not sure any more.
Correct, but this may soon change. I've been working on getting releases built for all three architectures with GitHub Actions CI. See the rc/test branch.
@stormdragon2976 if you want binaries, I have some here: https://github.com/vmchale/ghc-cross/releases/tag/Binaries
I also have linux -> linux cross-compilers for anyone who wants to try on their own: https://github.com/vmchale/ghc-cross/releases/tag/8.6.5 (both armv7 and aarch64)
Howdy Peter,
Thanks for this, it is very awesome. Could you also provide armv7h binaries? I don't currently have an X86 to try the cross compiler.
One small problem that happened when I tried to convert a file:
Could not find data file /home/vanessa/.cabal/share/aarch64-linux-ghc-8.6.5/pandoc-2.7.3/data/abbreviations
Thanks, Storm
On Sat, Nov 30, 2019 at 08:48:57AM -0800, Peter hyman wrote:
@stormdragon2976 if you want binaries, I have some here: https://github.com/vmchale/ghc-cross/releases/tag/Binaries
I also have linux -> linux cross-compilers for anyone who wants to try on their own: https://github.com/vmchale/ghc-cross/releases/tag/8.6.5 (both armv7 and aarch64)
-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/jgm/pandoc/issues/5450#issuecomment-559994325
-- ⛈🐲 Accessible low cost computers for everyone! Get your slice of the Pi: https://asliceofthepi.com My youtube channel: https://www.youtube.com/channel/UCdaTl5vl404OaRxAJPvb8Ew get my public PGP key: gpg --keyserver wwwkeys.pgp.net --recv-key 43DDC193 Follow me on GNU Social: https://social.wolfe.casa/storm "Have you ever been alone at night, thought you heard footsteps behind, and turned around and no one's there? And as you quicken up your pace you'll find it hard to look again because you're sure that someone's there." Iron Maiden - Fear of the Dark
One small problem that happened when I tried to convert a file:
Could not find data file /home/vanessa/.cabal/share/aarch64-linux-ghc-8.6.5/pandoc-2.7.3/data/abbreviations
Set the embed_data_files
flag when you compile; this will ensure that the data files are included in the binary.
Howdy Peter,
I just downloaded the aarch64 binary and tried it on the N2. That's when I got the error.
Thanks, Storm
On Sat, Nov 30, 2019 at 10:27:57AM -0800, Peter hyman wrote:
One small problem that happened when I tried to convert a file:
Could not find data file /home/vanessa/.cabal/share/aarch64-linux-ghc-8.6.5/pandoc-2.7.3/data/abbreviations
Set the
embed_data_files
flag when you compile; this will ensure that the data files are included in the binary.-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/jgm/pandoc/issues/5450#issuecomment-560009068
-- ⛈🐲 Accessible low cost computers for everyone! Get your slice of the Pi: https://asliceofthepi.com My youtube channel: https://www.youtube.com/channel/UCdaTl5vl404OaRxAJPvb8Ew get my public PGP key: gpg --keyserver wwwkeys.pgp.net --recv-key 43DDC193 Follow me on GNU Social: https://social.wolfe.casa/storm "I don't wanna face my fears! I'm afraid of 'em!" SpongeBob SquarePants
I work on Chromebrew and we'd like to have ARMv7 binaries as well since Google chose to ship all ARMv8 Chromebooks with 32-bit user ABIs due to only having 4GB of memory.
Any progress for this issue?
I try to build pandoc-2.9.2 for raspberry pi 4b, and got error
[133 of 161] Compiling Text.Pandoc.Readers.LaTeX
ghc: internal error: getMBlock: mmap: Invalid argument
(GHC version 8.4.4 for arm_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
cabal: Leaving directory '/tmp/cabal-tmp-8306/pandoc-2.9.2'
I have exactly the same issue on both aarch64 and armv7l on Raspberry Pi 4 4GB model with pandoc 2.9+. 4GB was just enough to compile pandoc briefly after Raspberry Pi 4 launched but then pandoc's need soon exceeds that.
If you can't wait there's a build in https://github.com/ickc/pandoc-arm/releases, with the last version compiled successfully on RPi4, I think 2.8.
I should emphasize that you can always add more swap. Long time ago I think I successfully compiled pandoc with 1GB RAM (forgot if it was a RPi original or another low mem. laptop.) Just add a ton of swap and it will work, albeit very slowly and your swap device's life shortened if it is flash (e.g. microSD.)
I was about to experiment with zram if I have time and see if it helps.
(As other has noted, the proper way to do it is to cross-compile and do it in CI, and distribute it officially. But until that happens...)
@ickc the version is 2.7.3. It has problem on epub toc. So I am looking for 2.9+
Then build your own, add a ton of swap and wait for a few days.
I successfully compiled 2.9.2 . see https://github.com/arm4rpi/pandoc-arm/releases
How? Just ton of swap?
Are you going to provide that continuously in the future? If so there's no need for 2 of us doing the same thing. Also, if you decided to continually provided that, you may want to think about security implication. e.g. as outlined in my repo I found that it is reproducible build so providing checksum should be suffices (may be this is the reason we still need to have 2 independent builds just for others to double check.)
As said above if people working on cross compiling has a solution then that would be preferred as doing it in the cloud in the open means less trust on us is needed. But before that it may be something you and I can do in the interim.
@ickc I am trying to build using github actions. But got some errors, see https://github.com/arm4rpi/pandoc-arm/runs/483167534
failed to install.
base-compat-0.11.1-HgwyiOzKEQ9KmBXaEHlBfi failed during the configure step.
The exception was:
ExitFailure 1
base-orphans-0.8.2-3ZQM2pxPHbTALAIaG3rSz1 failed during the configure step.
The exception was:
ExitFailure 1
doctemplates-0.8.1-Iuw4He9PrsFAzb6E5YhZXp depends on doctemplates-0.8.1 which
failed to install.
ipynb-0.1-5azHA6CVSg970U03zfl88V depends on ipynb-0.1 which failed to install.
pandoc-2.9.2-5EHBhYTFz4u65WvZc3TiB5 depends on pandoc-2.9.2 which failed to
install.
pandoc-types-1.20-8EQHit822IcL8VC8fC6OZi depends on pandoc-types-1.20 which
failed to install.
skylighting-0.8.3.2-C2Li4Bm4LPW5TVFmKvF7GB depends on skylighting-0.8.3.2
which failed to install.
skylighting-core-0.8.3.2-BDFsVUriuS2BVnrNvKwqBs depends on
skylighting-core-0.8.3.2 which failed to install.
texmath-0.12.0.1-2htPgXHYu9jEzl2nKKanYP depends on texmath-0.12.0.1 which
failed to install.
time-compat-1.9.2.2-B4M2FpSJt3R4h2zQkxlzCq depends on time-compat-1.9.2.2
which failed to install.
##[error]Process completed with exit code 1.
do you know how to solve it?
Sorry no experience on GitHub Action.
What was the earlier errors? Do you see something fail to compile?
Could you bring me up to speed about the GitHub Action? e.g. do they provide armv7l and aarch64 or are you cross-compiling?
In the past experience when dealing with CI, is the "debug loop" can be troublesome. One way people often try to solve situation like this is to use the docker image of the CI instance itself (e.g. Travis CI) and debug it interactively.
Seem no armv7l and aarch64 provided, I am using qemu-user-static
for debug. run
docker run -it --privileged --rm ann17/pandoc-ghc-arm:latest /bin/bash
cd rootfs
cp /etc/resolv.conf etc
mount -t devtmpfs devtmpfs dev
mount -t devpts devpts dev/pts
mount -t sysfs sysfs sys
mount -t tmpfs tmpfs tmp
mount -t proc proc proc
# chroot to arm
chroot . /bin/bash
uname -m
cabal update
cabal install -v time-compat-1.9.2.2
docker image ann17/pandoc-ghc-arm:latest
was build from https://github.com/arm4rpi/ghc-arm
Now I am trying to build for aarch64
and armv7l
using Github Actions with qemu-user-static
. Encountered two problems, can anyone help?
Limited by execution time(6 hours), it is not possible to build successfull. So I want to pre build dependencies( see https://github.com/arm4rpi/pandoc-deps), but the problem is pandoc
and pandoc-citeproc
resolving deferent dependencies, libraries below need rebuild when build pandoc-citeproc
, can not use prebuilt library for pandoc
, the long suffix of library is different, for example: pandoc-2.9.2-cd37f71aada58e7c054fb0d9850c9c6facc99a5599ef764195fc2ac2b25bb988
and pandoc-2.9.2-028d873232afbbca4423e4e65d416bc237bf7809e93e4d4cd251f51fd681e9b8
. So, now only pandoc
will build successful.
In order, the following will be built:
- time-compat-1.9.3 (lib) (requires download & build)
- aeson-1.4.6.0 (lib) (requires download & build)
- yaml-0.11.3.0 (lib) (requires download & build)
- skylighting-core-0.8.3.2 (lib) (requires download & build)
- pandoc-types-1.20 (lib) (requires download & build)
- ipynb-0.1 (lib) (requires download & build)
- doctemplates-0.8.1 (lib) (requires download & build)
- aeson-pretty-0.8.8 (lib) (requires download & build)
- HsYAML-aeson-0.2.0.0 (lib) (requires download & build)
- skylighting-0.8.3.2 (lib) (requires download & build)
- texmath-0.12.0.1 (lib) (requires download & build)
- pandoc-2.9.2 (lib) (requires download & build)
I had add huge swap.
swapon: /mnt/swapfile: insecure permissions 0644, 0600 suggested.
swapon: /home/swapfile: insecure permissions 0666, 0600 suggested.
total used free shared buff/cache available
Mem: 6945 712 124 25 6108 5904
Swap: 30719 31 30688
alway out of memory when Compiling Text.Pandoc.Readers.LaTeX
[133 of 162] Compiling Text.Pandoc.Readers.LaTeX.Parsing
[134 of 162] Compiling Text.Pandoc.Readers.LaTeX
ghc: out of memory (requested 1048576 bytes)
CallStack (from HasCallStack):
die', called at ./Distribution/Client/ProjectOrchestration.hs:977:55 in main:Distribution.Client.ProjectOrchestration
cabal: Failed to build pandoc-2.9.2 because it depends on pandoc-2.9.2 which
itself failed to build.
Failed to build
pandoc-2.9.2-a37414eb634713f674eb2c181278989d68c5c7af029fece038bbeefb7e04ca90.
The build process terminated with exit code 251
I think the only solution for the out-of-memory error is to further break up Text.Pandoc.Readers.LaTeX
into smaller modules.
Not sure about the dependency problems. The differences in hashes are probably due to different flags being used. Maybe try using more specific constraint --constraint='pandoc:embed_data_files
instead of global --flag embed_data_files
. You could also experiment with cabal.project.freeze
files to ensure reproducible builds.
@tarleb thanks. I will try.
only armv7l
will out-of-memory. aarch64
does not have this problem
I'm working on this via Docker on the NVIDIA Jetson Xavier AGX (arm64 plus CUDA and tensor cores). OS is Linux for Tegra (l4t), which is Ubuntu Bionic plus all the NVIDIA software. See http://github.com/znmeb/dockerfiles.
If anyone wants to try building on an ARM machine with a more recent ghc, ghcup now has experimental arm support: https://www.reddit.com/r/haskell/comments/lsz7ml/ann_ghcup0113_release_experimental_arm_support/
This doesn't help with memory issues, but note that we have broken up some of the bigger modules into smaller ones, which might help a bit, so those who had trouble before might find it worth while to try again.
I can test this on a 4 GB Jetson Nano; the "traditional" method via cabal-install
crashes when the Linux out-of-memory killer nukes some 'ghc' or 'llvm' processes.
But IMHO this isn't a technology problem, it's a resource problem - there aren't pre-built Pandoc ARM binaries because there's no readily-available low-cost CI/CD infrastructure for open source projects like Pandoc. I don't know if it would make economic sense for AWS or Microsoft / GitHub to start supplying such infrastructure, but I think we need to ask them for it.
If I recall, AWS offers ARM EC2 instances. Is that right? If so, that could be an option for building.
Yeah - Gravitons. I did a couple of tests with Travis CI on Gravitions before they shut down their open source support. It didn't work; there was a 50-minute per step time limit and I couldn't break the build into small enough pieces.
Could we use it directly -- not through travis, but just spinning up an instance, doing the build, and uploading an artifact?
Sure - you just need an account. But the 8 GB instances aren't cheap and it may never work in 4 GB if my Nano experience holds. Also, a lot of projects are suddenly biting this bullet because of the Apple Silicon Macs - they end up emulating x86_64 at drastically reduced speed. Engineering economics again :-(
My Docker context is at https://github.com/edgyR/edgyR-containers/tree/main/build-scripts/internal-pandoc. I'm still trying to get it to run on the Nano by updating GHC to something more recent than what ships on Ubuntu 18.04 but that's in a branch at the moment and it takes many hours to get to that point. I'll probably update to the full 8.6 Haskell platform and document the image as part of the project, since I have another use case for Haskell now.
I tried 8GB before and isn’t enough. I can try again soon.
I tried 8GB before and isn’t enough. I can try again soon.
I'm using a 16 GB Jetson AGX Xavier with 8 cores and it does work there with 8 make jobs. I haven't tried with just 8 GB of RAM though. My script first rebuilds cabal-install
, which will run in 4 GB.
The rewrite in progress first builds GHC 8.2, then cabal-install 3.0, then GHC 8.6, then cabal-install 3.4 and then Pandoc. As far as I know the only piece of this chain that won't run in 4 GB is the Pandoc step.
As of 7f1b933aaacf4a01fb23fa4989f190098e96e702 I've split apart the LaTeX reader, which should reduce its compilation footprint. It would be worth trying an armh build again with 8 GB and 4 GB. The LaTeX and Markdown writers are the other ones that take a lot of RAM to compile. See notes on #6546.
We have some money through donations which could pay for build time; the main issue is getting a process set up that makes it easy and painless for the developers to do the build.
We have some money through donations which could pay for build time; the main issue is getting a process set up that makes it easy and painless for the developers to do the build.
Microsoft / GitHub / Azure is the logical place for that to happen. I'm sure open source ARM developers who are already on GitHub and who were kicked to the curb by Travis would be happy to beta-test it, and it would cement Microsoft's position in the open source world. :-)
Oh, I just thought of a simple solution. I can add a CPP macro lowmem
(or something); when it is set, we can trigger OPTIONS_GHC pragmas in the three problematic source files that set -O0 just for those files. So you'd get a mostly optimized build, except for the three difficult modules. Testing that approach now on a 2 GB (non-arm) build machine.
[EDIT: it worked.]
[Further edit: I did some benchmarks with the unoptimized LaTeX reader. The news is not good:]
latex: OK (1.46s)
204 ms ± 17 ms, 417 MB allocated, 18 MB copied, 1230% slower than baseline
The markdown and latex writers are around 20% slower, not bad.
I have successfully built pandoc for aarch64
:
# uname -a; echo; pandoc -v; file /usr/bin/pandoc; ldd /usr/bin/pandoc; echo; pandoc-citeproc -V; file /usr/bin/pandoc-citeproc; ldd /usr/bin/pandoc-citeproc
Linux 4d1028ef6857 4.19.0-14-arm64 #1 SMP Debian 4.19.171-2 (2021-01-30) aarch64 GNU/Linux
pandoc 2.10
Compiled with pandoc-types 1.21, texmath 0.12.1.1, skylighting 0.8.5
Default user data directory: /root/.local/share/pandoc or /root/.pandoc
Copyright (C) 2006-2020 John MacFarlane
Web: https://pandoc.org
This is free software; see the source for copying conditions.
There is no warranty, not even for merchantability or fitness
for a particular purpose.
/usr/bin/pandoc: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, stripped
not a dynamic executable
pandoc-citeproc 0.17.0.2
/usr/bin/pandoc-citeproc: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, stripped
not a dynamic executable
Someone please confirm, that everything works as expected. The Debian package is available at https://dl.b-data.ch/pandoc/releases/2.10/pandoc-2.10-1-arm64.deb.
@jgm I am happy to provide a multi-arch Docker Image (linux/amd64,linux/arm64
) to replace utdemir/ghc-musl:v12-libgmp-ghc8101, which you are using to build the current version of pandoc.
P.S.: Sorry for not providing a more recent version of pandoc for testing. Bootstrapping GHC 8.10.1 is currently ongoing...
A multi-arch docker image would be great!
I've built 2.11 with GHC 8.0 on aarch64
- I'm currently using 8.6 though.
@jgm Here you go:
$ docker manifest inspect registry.gitlab.b-data.ch/ghc/ghc4pandoc:8.10.1
{
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
"manifests": [
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 1379,
"digest": "sha256:83cfc60cb1df984b14d6277946002de6bc7bec25c827f5f9de3b0c5d3aeaa571",
"platform": {
"architecture": "amd64",
"os": "linux"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 1379,
"digest": "sha256:e54a66cf8ef7f8a60b93f6a51cae7a0bd853a763098ffb3dbda2bf91b7ab49ad",
"platform": {
"architecture": "arm64",
"os": "linux"
}
}
]
}
👉 Based on alpine:3.13 (musl libc), providing GHC 8.10.1 (integer-gmp) and cabal-install tool 3.2.0.0.
I have successfully built {pandoc-2.11.4-1-amd64.deb, pandoc-2.11.4-1-arm64.deb} with the above Docker image after applying the following patch:
diff --git a/Makefile b/Makefile
index f27272b08..bf866c65a 100644
--- a/Makefile
+++ b/Makefile
@@ -75,7 +75,7 @@ debpkg: man/pandoc.1
-v `pwd`/linux/artifacts:/artifacts \
-e REVISION=$(REVISION) \
-w /mnt \
- utdemir/ghc-musl:v12-libgmp-ghc8101 bash \
+ registry.gitlab.b-data.ch/ghc/ghc4pandoc:8.10.1 bash \
/mnt/linux/make_artifacts.sh
man/pandoc.1: MANUAL.txt man/pandoc.1.before man/pandoc.1.after
diff --git a/linux/make_artifacts.sh b/linux/make_artifacts.sh
index 34c0bd082..f3aa4742d 100644
--- a/linux/make_artifacts.sh
+++ b/linux/make_artifacts.sh
@@ -2,6 +2,7 @@ set -e
MACHINE=$(uname -m)
case "$MACHINE" in
+ aarch64) ARCHITECTURE=arm64;;
x86_64) ARCHITECTURE=amd64;;
i686) ARCHITECTURE=i386;;
i386) ARCHITECTURE=i386;;
@@ -68,5 +69,5 @@ mv pandoc $TARGET/bin
strip $TARGET/bin/pandoc
gzip -9 $TARGET/share/man/man1/pandoc.1
-tar cvzf $TARGET-linux-amd64.tar.gz $TARGET
+tar cvzf $TARGET-linux-$ARCHITECTURE.tar.gz $TARGET
rm -r $TARGET
All credits go to @odidev who cross-compiled GHC 8.8.3 to aarch64-linux-musl
* and @neosimsim for his docker-builder-images.
ℹ️ I merely put these two things together.
*unfortunately, it never made it into alpine > aports.
Thanks for this! I don't know much about Docker, sorry. Is there a way to audit this image, e.g., see the code by which it is produced?
You find the code base for these images at https://gitlab.b-data.ch/ghc/ghc4pandoc, including CI/CD configuration at https://gitlab.b-data.ch/ghc/ghc4pandoc/-/blob/master/.gitlab-ci.yml.
Images for amd64
are built automatically by GitLab CI/CD (see https://gitlab.b-data.ch/ghc/ghc4pandoc/-/pipelines). The builds for arm64v8
images currently fail; getting stuck at step make binary-dist
.
👉 I'm currently building and pushing arm64v8
images manually using the same Dockerfiles as for amd64
images. There seems to be an issue with the arm64
GitLab Runner image.
In the meantime, the following manifests have been added to the repositories' Container Registry:
registry.gitlab.b-data.ch/ghc/ghc4pandoc:8.10.4
registry.gitlab.b-data.ch/ghc/ghc4pandoc:9.0.1
Super! This worked well when I tried it locally. I'm going to try an arm build next on aws.
docker run -v `pwd`:/mnt \
-v `pwd`/linux/artifacts:/artifacts \
-e REVISION=1 \
-w /mnt \
--memory=0 \
--rm \
registry.gitlab.b-data.ch/ghc/ghc4pandoc:8.10.4@sha256:e54a66cf8ef7f$
a60b93f6a51cae7a0bd853a763098ffb3dbda2bf91b7ab49ad \
bash \
/mnt/linux/make_artifacts.sh
cabal-install version 3.2.0.0
compiled using version 3.2.1.0 of the Cabal library
The Glorious Glasgow Haskell Compilation System, version 8.10.1
So is it really ghc 8.10.1, not 8.10.4 as the name suggests? Is this expected?
@jgm A digest points to a specific Docker image - ignoring the provided tag. sha256:e54a66cf8ef7f$ a60b93f6a51cae7a0bd853a763098ffb3dbda2bf91b7ab49ad
is the image tagged with 8.10.1-linux-arm64v8
(GHC 8.10.1 for os/arch linux/arm64/v8
).
If the script is supposed to use GHC 8.10.4 and work on both architectures, please use tag 8.10.4
only:
$ docker manifest inspect registry.gitlab.b-data.ch/ghc/ghc4pandoc:8.10.4
{
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
"manifests": [
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 1379,
"digest": "sha256:d42634183525b30082fc5b2edc5c236533e6cb1522e55417ea137a7749778ef3",
"platform": {
"architecture": "amd64",
"os": "linux"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 1379,
"digest": "sha256:de85020ea67f7ec8ec531204bbd5b4619c1a5108220a6adccfca6afbd697961d",
"platform": {
"architecture": "arm64",
"os": "linux"
}
}
]
}
If it is supposed to work on aarch64
only, you may use registry.gitlab.b-data.ch/ghc/ghc4pandoc@sha256:de85020ea67f7ec8ec531204bbd5b4619c1a5108220a6adccfca6afbd697961d
Aarch64 and Armv7h machines are becoming more and more common place now days. There are Windows, Mac, and Linux binaries, but the Linux binaries do not cover these architectures. Please add binary releases for them.