Arm64 Support In Dockerfile #21

odidev · 2020-05-13T10:11:43Z

Added the support for arm64 in Dockerfile.
As GHC official binaries are not yet released for arm64, I am building the GHC binaries from its source.

odidev · 2020-05-21T03:54:13Z

Ping @psftw could you please share your thoughts on this.

odidev · 2020-06-16T05:15:38Z

@psftw Kindly have a look on this PR

psftw · 2020-06-23T14:44:12Z

Thanks for your work on this @odidev. Unfortunately right now I don't have the time to see this through, and merging/publishing prematurely would be a mistake. This PR only addresses 8.8, which in the past I had experimented with and ran in to usability problems (many of which may be resolved now). I'm not sure of the current 8.8/8.10 status for GHC (+ tooling/ecosystem) on ARM, but I'd like to do significant testing and research to make sure we are not releasing anything we shouldn't be. I'm pretty sure a number of caveats would need to be documented for users in any case. I'd also like to have a sustainable smoke-testing process that can integrate with (or replace) the existing github actions. It is possible to temporarily spin up an ARM server and use it as a github action runner, but this is not ideal.

GrahamCampbell · 2020-08-19T18:52:13Z

I think this needs doing for 8.10 too?

GrahamCampbell · 2020-08-21T09:36:02Z

8.8/buster/Dockerfile

-        xz-utils \
-        zlib1g-dev && \
+RUN apt-get update && \
+    apt-get install -y --no-install-recommends gnupg ca-certificates dirmngr curl git wget  \


don't need wget

GrahamCampbell · 2020-08-21T09:36:16Z

8.8/buster/Dockerfile

+                g++ netbase xz-utils libnuma-dev make openssh-client && \
+    export GNUPGHOME="$(mktemp -d)" && \
+    if [ `uname -m` = "aarch64" ] ; then \
+        wget https://downloads.haskell.org/~ghc/8.8.3/ghc-8.8.3-aarch64-deb9-linux.tar.xz && \


You need to verify the download just like for stack.

odidev · 2020-08-24T11:33:32Z

Hi,

Added the support for arm64 in Dockerfile for 8.8 and 8.10
8.8.4 source for arm64 is not available so i am using 8.8.3 for arm64.
GHC official support for arm64 is only available for 8.8 stretch. I have cross compiled the 8.8 stretch source in buster and it is working.
GHC official support for arm64 is not available for 8.10 stretch. Hence I have only added the support for ghc 8.10 buster.

The stack consist of binary whereas binary of ghc is unavailable so i cannot verify the tar as these tar consists of the source for arm64.

odidev · 2021-01-28T11:17:09Z

@GrahamCampbell
can you please review and let me know if any changes required?

GrahamCampbell · 2021-01-28T12:34:30Z

I think the best approach now would be to only add ARM support for GHC 8.10.3, since there is official support now. There are a lot of issues with ARM on 8.8, even if it does "build". The 8.8 series should be left alone.

GrahamCampbell · 2021-01-28T12:36:23Z

As far as I'm aware, GHC 8.10.3 is the first version of GHC where ARM64 support could actually be described as "mostly working" on Linux: https://downloads.haskell.org/~ghc/8.10.3/ghc-8.10.3-aarch64-deb10-linux.tar.xz.

GrahamCampbell · 2021-01-29T09:15:33Z

8.10/buster/Dockerfile

+RUN arch=`uname -m` && \
+    export GNUPGHOME="$(mktemp -d)" && \
+    if [ $arch  = "aarch64" ] ; then \
+        curl -fSL https://github.com/commercialhaskell/stack/releases/download/v2.1.3/stack-2.1.3-linux-$arch.tar.gz -o  stack.tar.gz && \


version should not be hard coded

Signed-off-by: odidev <[email protected]>

odidev · 2021-01-29T11:22:47Z

I have amended the changes as per the given suggestions.

Now this PR only consists of the changes for 8.10 buster, here 8.10.3 ghc version is used for arm64 development and the latest version of stack available for arm64 is 2.1.3. So I have updated the stack version for arm64.

Can you please review the latest commits and let me know if any further changes is required

GrahamCampbell · 2021-01-29T22:42:51Z

Not up to me at this point. Up to one of the maintainers with write permissions.

GrahamCampbell · 2021-01-29T22:43:33Z

Likely they will say wait till the debian builds are ready, then change the code back: #31 (comment).

psftw · 2021-02-06T19:08:38Z

I saw there was a GHC 8.10.4 released yesterday, so I made a few tweaks to this PR and built it on an AWS Graviton system. While I was able to get it "working", there are still critical issues with releasing an aarch64 image. Without cabal-install (and ideally Stack as well) I don't think we should ship. I would rather the issues with packaging get resolved upstream instead of hacking something here. The line in your PR to install the cabal-install package brings in another set of packages including an older GHC from upstream Debian repositories which is not what we want. Similarly, including an old version of Stack because they no longer provide binaries for aarch64 is also not going to fly.

hasufell · 2021-09-22T21:23:09Z

ghcup supports arm now and I also have an unofficial stack binary: https://downloads.haskell.org/ghcup/unofficial-bindists/stack/2.7.3/stack-2.7.3-linux-armv7 (not distributed... these were built in an attempt to migrate stack CI to GHC gitlab, which has first-class support for ARM)

See:

Bodigrim · 2021-11-24T00:07:37Z

@psftw any chance to move this forward? Arm docker images for GHC would be a great help for package maintainers.

AlistairB · 2021-11-24T07:42:23Z

Thanks for the ping on this @Bodigrim . FYI @psftw has stepped down from maintaining this project after many years of service.

I believe the major blockers at this point are:

stack official ARM releases. It seems that this existed for 2.7.1, but not for 2.7.3. I would be inclined to only include an official stack release.
CI that can build the images on ARM based CPUs. Actually it seems that travis might support this https://docs.travis-ci.com/user/multi-cpu-architectures/#multi-cpu-availability.

I'll see if I can get something fully working in travis CI with stack 2.7.1 for now. If that works then perhaps we can bug the stack maintainers (or offer a hand) :)

AlistairB · 2021-11-24T08:28:46Z

Hmm dang, seems that the haskell github org is out of travis ci credits.

Bodigrim · 2021-11-24T19:42:25Z

Yeah, Travis is no longer an option for OSS maintainers. I have successful experience with ARM machines provided by drone.io, see https://github.com/haskell/bytestring/blob/master/.drone.yml and https://github.com/haskell/text/blob/master/.drone.yml

Even a cabal-only docker image would be very helpful.

AlistairB · 2021-11-25T05:52:37Z

Ah drone looks nice thanks I'll try that.

Yeah, ideally we get stack too, but if it is not likely to be possible anytime soon I think it can be omitted (or just provide stack 2.7.1 for now).

AlistairB · 2021-11-25T06:02:37Z

Although, I think someone who is a haskell org admin would need to follow https://docs.drone.io/server/provider/github/ or apply the setup bytestring has to docker-haskell? Do drone host all the 'server' and 'runner' agents for us?

hasufell · 2021-11-25T13:15:19Z

Arm docker images for GHC would be a great help for package maintainers.

I've been working on ghcup docker images, which are more flexible and lightweight than haskell/docker and would use the GHC CI infrastructure to build. But I haven't gotten around it yet.

At any rate, it's not hard to install ghcup in a stock arm64 image.

Bodigrim · 2021-11-25T19:39:21Z

@AlistairB I set up drone.io for bytestring and text myself, so you should be able to do the same for docker-haskell as soon as you have enough rights for the repo. CC @chessai
Alternatively you can try emulated GitHub actions environment, e. g., https://github.com/haskell/bytestring/blob/e682cf7ad44c8299aed23e649472d8ab559109d4/.github/workflows/ci.yml#L69-L90

@hasufell true, but installing everything from the scratch takes too long for a low-latency CI, which is my use case.

chessai · 2021-11-25T20:55:04Z

@AlistairB I set up drone.io for bytestring and text myself, so you should be able to do the same for docker-haskell as soon as you have enough rights for the repo. CC @chessai Alternatively you can try emulated GitHub actions environment, e. g., https://github.com/haskell/bytestring/blob/e682cf7ad44c8299aed23e649472d8ab559109d4/.github/workflows/ci.yml#L69-L90

@hasufell true, but installing everything from the scratch takes too long for a low-latency CI, which is my use case.

@Bodigrim, @AlistairB already has admin access to this repo (docker-haskell). Did you mean another repo?

Bodigrim · 2021-11-25T20:56:32Z

Ah, good, then he should be able to set up drone.io for docker-haskell himself.

AlistairB · 2021-11-25T21:58:17Z

Ah hmm, ok let me have another go. The instructions seemed to suggest it needs to be done at an org level.

AlistairB · 2021-11-28T07:50:23Z

So I've been playing with the emulated approach. The good news I think I have a good pattern now to make the Dockerfiles processor architecture agnostic in that PR. Unfortunately the emulated approach is not working as uname -m (and dpkg-architecture --query DEB_BUILD_GNU_CPU) apparently returns the processor architecture of the real host on the CI agent, not that of the emulated ARM64 docker container.

@Bodigrim Re drone, am I correct in thinking I would need to run 'servers' and/or 'runners' myself somewhere? The instructions ask me to set up a GitHub OAuth App.

And I would need to host some http://drone.myserver/login or something?

I don't really want to host anything myself (if I am understanding this all correctly) and if I did I would probably set up a self hosted github CI agent.

I think if there are no viable non-self hosted options, it is actually not the worst to just have no CI verifying ARM in this repo. As when new releases are PRed against https://github.com/docker-library/official-images as part of the release process their CI should check everything.

Bodigrim · 2021-11-28T12:56:47Z

@AlistairB Drone provides both servers and runners. I remember that GitHub integration was not documented well, but I managed to setup it for bytestring and text - just do not remember how :)

Dunno, try adding .drone.yml to a fork first and see whether you can integrate it?

AlistairB · 2021-11-28T18:58:47Z

Ok thanks that is good to know. I will figure this out! 😅

AlistairB · 2021-12-05T03:48:05Z

Just an update:

So it turns out there is a manual approval process for cloud.drone.io. I am waiting for this, then I think I am good to test the updated images on ARM.
I have pinged the stack people on the HF slack about 2.7.3 missing aarch64 binaries and whether stack intends to produce aarch64 binaries in the future. I'd like to at least get a response from the stack people before releasing something with stack 2.7.1 (or with no stack). Another option is unofficial stack binaries, but I really think the official images should not include anything unofficial.

AlistairB · 2021-12-27T00:01:50Z

Still waiting for drone.io account.. Another option is try to use haskell gitlab ci, like haskell language server, but that looks really complex to set up so would rather avoid.
I pinged the stack people and someone put their hand up to automate and add 2.7.3 ARM64 binaries. However, I have investigated and it seems the official images people are happy to have old versions of binaries when newer versions have issues. I am happy to release with 2.7.1 (at least while I see no actual movement to on the 2.7.3 issue) and Add ARM64 processor architecture support #53 has this fallback logic.
Add ARM64 processor architecture support #53 is ready to go minus CI testing ARM64 on drone.io . Feedback welcome.

Going to close this PR and continue with the other one. Thanks @odidev this was useful to show how it is done!

GrahamCampbell suggested changes Aug 21, 2020

View reviewed changes

odidev force-pushed the arm_support branch from 08e1097 to 0007ab1 Compare August 24, 2020 10:59

odidev force-pushed the arm_support branch from 0007ab1 to d59e202 Compare January 29, 2021 09:05

GrahamCampbell suggested changes Jan 29, 2021

View reviewed changes

Arm64 Support In Dockerfile

98e4402

Signed-off-by: odidev <[email protected]>

odidev force-pushed the arm_support branch from d59e202 to 98e4402 Compare January 29, 2021 11:01

AlistairB mentioned this pull request Dec 27, 2021

Add ARM64 processor architecture support #53

Merged

7 tasks

AlistairB closed this Dec 27, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Arm64 Support In Dockerfile #21

Arm64 Support In Dockerfile #21

odidev commented May 13, 2020 •

edited by AlistairB

Loading

odidev commented May 21, 2020

odidev commented Jun 16, 2020

psftw commented Jun 23, 2020

GrahamCampbell commented Aug 19, 2020

GrahamCampbell Aug 21, 2020

GrahamCampbell Aug 21, 2020

odidev commented Aug 24, 2020

odidev commented Jan 28, 2021

GrahamCampbell commented Jan 28, 2021 •

edited

Loading

GrahamCampbell commented Jan 28, 2021 •

edited

Loading

GrahamCampbell Jan 29, 2021

odidev commented Jan 29, 2021

GrahamCampbell commented Jan 29, 2021

GrahamCampbell commented Jan 29, 2021 •

edited

Loading

psftw commented Feb 6, 2021

hasufell commented Sep 22, 2021

Bodigrim commented Nov 24, 2021

AlistairB commented Nov 24, 2021

AlistairB commented Nov 24, 2021 •

edited

Loading

Bodigrim commented Nov 24, 2021

AlistairB commented Nov 25, 2021 •

edited

Loading

AlistairB commented Nov 25, 2021 •

edited

Loading

hasufell commented Nov 25, 2021 •

edited

Loading

Bodigrim commented Nov 25, 2021 •

edited

Loading

chessai commented Nov 25, 2021

Bodigrim commented Nov 25, 2021

AlistairB commented Nov 25, 2021

AlistairB commented Nov 28, 2021 •

edited

Loading

Bodigrim commented Nov 28, 2021

AlistairB commented Nov 28, 2021

AlistairB commented Dec 5, 2021 •

edited

Loading

AlistairB commented Dec 27, 2021 •

edited

Loading

Arm64 Support In Dockerfile #21

Arm64 Support In Dockerfile #21

Conversation

odidev commented May 13, 2020 • edited by AlistairB Loading

odidev commented May 21, 2020

odidev commented Jun 16, 2020

psftw commented Jun 23, 2020

GrahamCampbell commented Aug 19, 2020

GrahamCampbell Aug 21, 2020

Choose a reason for hiding this comment

GrahamCampbell Aug 21, 2020

Choose a reason for hiding this comment

odidev commented Aug 24, 2020

odidev commented Jan 28, 2021

GrahamCampbell commented Jan 28, 2021 • edited Loading

GrahamCampbell commented Jan 28, 2021 • edited Loading

GrahamCampbell Jan 29, 2021

Choose a reason for hiding this comment

odidev commented Jan 29, 2021

GrahamCampbell commented Jan 29, 2021

GrahamCampbell commented Jan 29, 2021 • edited Loading

psftw commented Feb 6, 2021

hasufell commented Sep 22, 2021

Bodigrim commented Nov 24, 2021

AlistairB commented Nov 24, 2021

AlistairB commented Nov 24, 2021 • edited Loading

Bodigrim commented Nov 24, 2021

AlistairB commented Nov 25, 2021 • edited Loading

AlistairB commented Nov 25, 2021 • edited Loading

hasufell commented Nov 25, 2021 • edited Loading

Bodigrim commented Nov 25, 2021 • edited Loading

chessai commented Nov 25, 2021

Bodigrim commented Nov 25, 2021

AlistairB commented Nov 25, 2021

AlistairB commented Nov 28, 2021 • edited Loading

Bodigrim commented Nov 28, 2021

AlistairB commented Nov 28, 2021

AlistairB commented Dec 5, 2021 • edited Loading

AlistairB commented Dec 27, 2021 • edited Loading

odidev commented May 13, 2020 •

edited by AlistairB

Loading

GrahamCampbell commented Jan 28, 2021 •

edited

Loading

GrahamCampbell commented Jan 28, 2021 •

edited

Loading

GrahamCampbell commented Jan 29, 2021 •

edited

Loading

AlistairB commented Nov 24, 2021 •

edited

Loading

AlistairB commented Nov 25, 2021 •

edited

Loading

AlistairB commented Nov 25, 2021 •

edited

Loading

hasufell commented Nov 25, 2021 •

edited

Loading

Bodigrim commented Nov 25, 2021 •

edited

Loading

AlistairB commented Nov 28, 2021 •

edited

Loading

AlistairB commented Dec 5, 2021 •

edited

Loading

AlistairB commented Dec 27, 2021 •

edited

Loading