profile
viewpoint

raw-bin/homebrew 1

The missing package manager for OS X.

raw-bin/mutt-sidebar-patches-jplenz 1

Julius plenz's excellent cleanup and rework of the sidebar patches (kudos Julius!).

raw-bin/redox 1

Redox: A Rust Operating System

raw-bin/cookbook 0

A collection of package recipes for Redox.

raw-bin/fish-nuggets 0

Completions, code snippets helping you to get even more out of the amazing Fish shell

raw-bin/freebsd 0

FreeBSD source tree for FreeBSD Foundation-sponsored projects

raw-bin/fzf-marks 0

Plugin to manage bookmarks in bash and zsh

raw-bin/juniper-vpn-py 0

Python Juniper VPN Authenticator

raw-bin/kernel 0

The Redox microkernel

raw-bin/lisa 0

Linux Integrated System Analysis

startedSpaceVim/SpaceVim

started time in 17 hours

issue commentonivim/oni2

Installing extensions from the CLI fails on macOS

Oh and agree that a helpful prompt in the failure case would be the way to go! Thanks.

raw-bin

comment created time in 5 days

issue commentonivim/oni2

Installing extensions from the CLI fails on macOS

Hi @bryphe !

Thanks for the response.

So I was basically trying to follow the guidance here.

Turns out I wasn't following the advice very well! :)

All the same, I think the page needs to be modded a bit.

I mean: At present the page suggests using:

oni2 --install-extension vscode-clangd

.. but that doesn't work either for clangd. What works is your suggestion above:

oni2 --install-extension llvm-vs-code-extensions.vscode-clangd

Oddly, your suggestion for exuberant-ctags doesn't work though!

raw-bin

comment created time in 5 days

pull request commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

Hi @skade, @tmandry, @cuviper, @jonas-schievink, @pietroalbini, @nikomatsakis, others on the approvals list: I wanted to share that this commentary helped prioritise things. :)

I can now confirm that work to add probe-stack support to LLVM for AArch64 will officially begin from October 1st (so next week) with a dedicated expert assigned to implement this feature. The implementation will be funded by Arm and done up through Linaro (a not for profit alliance of Arm ecosystem partners).

This link which I've shared previously has some details (not all of them openly available sadly).

The relevant change is that the 'Fix/version(s)' attribute, which was previously empty has now been changed to 'LLVM 12'.

This means that the feature is now intended to be a part of the LLVM 12 release. Extrapolating from LLVM's release history, that is likely to be around Q2/Q3 next year. The Rust linkage can be developed in tandem, I suppose. I expect that the actual implementations will be available sooner in RCs etc but we should assume the release as the end-point for feature availability.

raw-bin

comment created time in 5 days

issue openedonivim/oni2

onivim2 build failure on macOS Catalina with macports

On a current macOS Catalina installation using macports, I am unable to build oni2. The build bombs out with:

https://gist.github.com/raw-bin/4290e6b75bf65df09d467dcf8f23e542

Something (perhaps a CMake include directive or some esy equivalent) appears to reference /usr/local/include as an include path which I believe is incorrect for a macports installation (which uses /opt/local/include).

For some reason, this results in a warning due to the compiler being built with '-Wpoison-system-directories'. That then bombs out because of '-Werror'.

As a data point: I managed to build one of the objects above in isolation by cutting and pasting the compiler invocation on the command line while taking care to remove '-Werror'. Not ideal of course. I couldn't figure out where to override the CFLAGS that are used for building objects in esy_libjpeg_turbo to remove '-Werror' globally. That would have given me a stop-gap build.

Any pointers appreciated. I'd rather not switch to Homebrew!

Thanks

created time in 5 days

issue openedonivim/oni2

Installing extensions from the CLI fails on macOS

> oni2 -f --debug --trace --install-extension clangd
[DEBUG]   +72ms Oni2.Exception : Recording backtraces
[DEBUG]    +0ms Oni2.Exception : Recording backtraces
[DEBUG]    +0ms Oni2.Core.Setup : Looking for setup configuration at: /Applications/Onivim2.app/Contents/Resources/../MacOS/setup.json
[ERROR]    +0ms Service.Extensions.Management : Unable to install extension: clangd
[DEBUG]    +0ms Oni2.Core.ThreadHelper : Starting thread: 1 (Utility.waitForCondition)
[DEBUG]    +0ms Oni2.Core.ThreadHelper : Closing thread: 1 (Utility.waitForCondition)
Failed to install extension: clangd

> oni2 -f --debug --trace --install-extension exuberant-ctags
[DEBUG]   +45ms Oni2.Exception : Recording backtraces
[DEBUG]    +0ms Oni2.Exception : Recording backtraces
[DEBUG]    +0ms Oni2.Core.Setup : Looking for setup configuration at: /Applications/Onivim2.app/Contents/Resources/../MacOS/setup.json
[ERROR]    +0ms Service.Extensions.Management : Unable to install extension: exuberant-ctags
[DEBUG]    +0ms Oni2.Core.ThreadHelper : Starting thread: 1 (Utility.waitForCondition)
[DEBUG]    +0ms Oni2.Core.ThreadHelper : Closing thread: 1 (Utility.waitForCondition)
Failed to install extension: exuberant-ctags

Note that installing these extensions using the in-editor extensions UI works just fine.

created time in 5 days

pull request commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

Hi @cuviper , @tmandry , @nagisa , @jonas-schievink and others on the approvals list: RFC author here. Thanks for the comments. All insightful and on point.

There's a couple of things I wanted to say by-the-by, in the spirit of this discussion and the broader RFC:

  1. The guideline we used for structuring all the work done ahead of making this RFC submission was the existing target tier policy document and unfortunately in all the discussions we had, the stack probing aspect did not bubble up either directly or indirectly. It's clearly a gap that needs to be filled without doubt.

  2. As mentioned earlier here: At present, work to add support for stack probing for AArch64 in LLVM is slated to begin in Q4 this year as a part of the Linaro Toolchain Working Group activities (link provided earlier). This unfortunately isn't a guarantee though (it involves a vote etc) so given the narrative here, we will now try to find alternative ways to fill this gap. I'm personally pretty confident that we will resolve this in a reasonable time frame. However it is not possible at present to state exactly when. From past experience, compiler mods of this sort do tend to drag on for a fair bit before landing in mainline repos given the potential implications for multiple triplets associated with the processor target in question.

  3. As also mentioned earlier here: Stack clashing - the primary scenario for which stack probing is the mitigation - is an arguably pathological scenario to exploit. Not meaning to trivialise that scenario of course but I wanted to put that on the table as a fact that I feel should be considered when such decisions are made. I do realise that some of the argumentation that is being used around the lack of stack probing here is oriented somewhat differently - as in - it raises concerns about UB implications from a Rust PoV and not the stack clashing reality more directly. Still thought it best to bring it up. Completely agree that a clear problem has been presented irrespective and we would like to see the right solution happen - even if that means the RFC's merge is delayed.

  4. About delay: This is a slightly unusual one to articulate in such a forum but I feel it is important to do so. Note that this is my personal opinion. It has taken a fair amount of engineering: actual, social and strategic, to get the right folks in an organisation such as Arm to recognise the value proposition that Rust presents for the Arm ecosystem. As is inevitably the case for any such organisation, perception and optics play a strong role in shaping the trajectory of long term strategic plays - especially around relatively new technology. Today, we know that Rust on AArch64 Linux is already being productised despite this target triplet not having the Tier-1 'badge' (for want of a better phrase). That bodes well already, which is neat. However, not having the badge does limit the rate of pervasive uptake of the language, especially on AArch64 based Linux systems - which are hugely popular across an astonishing spectrum of market domains - most of which are a perfect fit for Rust.

Would getting the badge in a hurry change that in a meaningful way ? Hard to say. That said, my experience in speaking with relevant parties in the Arm ecosystem leads me to maintain that the sooner we get the badge, the sooner we can usher in a lot of interest in Rust more generally and Rust on AArch64 Linux, more specifically.

We will of course respect the outcome of your decision, either which way. If you decide that the RFC merge needs to gate on stack probing availability in LLVM and it's coupling to Rust for AArch64 Linux, that's the direction we will move in. I felt it important to share the above points, all the same.

Thanks!

raw-bin

comment created time in 7 days

issue commentonivim/oni2

Using Tab inserts an odd character

To add to @Luke-Argosino's report: I can confirm that I see the same issue on my Mac running the latest macOS Catalina. Unlike @Luke-Argosino's situation, I saw the problem ever since I first installed onivim2.

I assume that pressing tab while in the command line dialogue provides autocompletion. If so, we're missing that convenience. Happy to provide any diagnostic information. Thanks!

Luke-Argosino

comment created time in 9 days

issue commentSpaceVim/SpaceVim

<Leader>y doesn't yank to the system clipboard

Great! Thanks @wsdjeg !

raw-bin

comment created time in 20 days

issue commentSpaceVim/SpaceVim

<Leader>y doesn't yank to the system clipboard

Hi @Rom1deTroyes.

I remap the leader key to '~' in a custom ~/SpaceVim.d/autoload/myspacevim.vim. I assume that that shouldn't cause problems here ?

Having said that, it appears that if I switch to visual mode by pressing 'v', then select a region and then use \ followed by y that works!

So it appears that the statement: Leader-y will yank to the clipboard is wrong. The correct statement appears to be: \-y will yank to the clipboard.

Could you confirm that please ?

Thanks

raw-bin

comment created time in 21 days

issue commentSpaceVim/SpaceVim

<Leader>y doesn't yank to the system clipboard

Hopefully this is better ? https://asciinema.org/a/7zgCTo7FAPgyIRYnUhgJ9q1Na

raw-bin

comment created time in 21 days

issue commentSpaceVim/SpaceVim

<Leader>y doesn't yank to the system clipboard

@wsdjeg : https://asciinema.org/a/3Z92Yyp488wp549C7s6Dff0AP

raw-bin

comment created time in 21 days

issue commentSpaceVim/SpaceVim

<Leader>y doesn't yank to the system clipboard

That's odd! I don't see any [y] option in the guide buffer when I press <Leader> in normal mode! I'll try and do a screencast.

raw-bin

comment created time in 21 days

delete branch raw-bin/SpaceVim

delete branch : improve-issue-template

delete time in 21 days

issue commentSpaceVim/SpaceVim

<Leader>y doesn't yank to the system clipboard

Hmm. That doesn't appear to work on my setup. I also still get the 'Key bindings is not defined...' message in the command line.

raw-bin

comment created time in 21 days

PR opened SpaceVim/SpaceVim

Improve the github ISSUE_TEMPLATE

PR Prelude

Thank you for working on SpaceVim! :)

Please complete these steps and check these boxes before filing your PR:

  • [x] I have read and understood SpaceVim's CONTRIBUTING document.
  • [x] I have read and understood SpaceVim's CODE_OF_CONDUCT document.
  • [x] I understand my PR may be closed if it becomes obvious I didn't actually perform all of these steps.

Why this change is necessary and useful?

This change improves the grammar and readability of the Issue Template.

It also adds text that encourages the submitter to correlate expected behaviour with the existing SpaceVim documentation to try and ensure that the Issue is valid.

+24 -8

0 comment

1 changed file

pr created time in 21 days

create barnchraw-bin/SpaceVim

branch : improve-issue-template

created branch time in 21 days

PR closed SpaceVim/SpaceVim

Improve issue template

PR Prelude

Thank you for working on SpaceVim! :)

Please complete these steps and check these boxes before filing your PR:

  • [x] I have read and understood SpaceVim's CONTRIBUTING document.
  • [x] I have read and understood SpaceVim's CODE_OF_CONDUCT document.
  • [x] I understand my PR may be closed if it becomes obvious I didn't actually perform all of these steps.

Why this change is necessary and useful?

This change improves the grammar and readability of the Issue Template.

It also adds text that encourages the submitter to correlate expected behaviour with the existing SpaceVim documentation to try and ensure that the Issue is valid.

+24 -8

0 comment

1 changed file

raw-bin

pr closed time in 21 days

delete branch raw-bin/SpaceVim

delete branch : improve-issue-template

delete time in 21 days

PR opened SpaceVim/SpaceVim

Improve issue template

PR Prelude

Thank you for working on SpaceVim! :)

Please complete these steps and check these boxes before filing your PR:

  • [x] I have read and understood SpaceVim's CONTRIBUTING document.
  • [x] I have read and understood SpaceVim's CODE_OF_CONDUCT document.
  • [x] I understand my PR may be closed if it becomes obvious I didn't actually perform all of these steps.

Why this change is necessary and useful?

This change improves the grammar and readability of the Issue Template.

It also adds text that encourages the submitter to correlate expected behaviour with the existing SpaceVim documentation to try and ensure that the Issue is valid.

+24 -8

0 comment

1 changed file

pr created time in 22 days

create barnchraw-bin/SpaceVim

branch : improve-issue-template

created branch time in 22 days

PR closed SpaceVim/SpaceVim

Improve issue template

PR Prelude

Thank you for working on SpaceVim! :)

Please complete these steps and check these boxes before filing your PR:

  • [x] I have read and understood SpaceVim's CONTRIBUTING document.
  • [x] I have read and understood SpaceVim's CODE_OF_CONDUCT document.
  • [x] I understand my PR may be closed if it becomes obvious I didn't actually perform all of these steps.

Why this change is necessary and useful?

  • This change improves the grammar in the text within the ISSUE_TEMPLATE.
  • In addition it encourages the submitter to provide references to relevant SpaceVim documentation in order to ensure that it has been read and the intent understood before filing a new issue.
+24 -8

0 comment

1 changed file

raw-bin

pr closed time in 22 days

delete branch raw-bin/SpaceVim

delete branch : improve-issue-template

delete time in 22 days

Pull request review commentSpaceVim/SpaceVim

Improve issue template

-<!-- bug reporting without issue template will be closed automatically -->+<!-- Following this template is mandatory to open an issue. Please use English --> -## Expected behavior, english is required+## Describe the behavior that you expect from SpaceVim -## The reproduce ways from Vim starting (Required!)+**[This is a mandatory section]** -## Debug info+If possible, in addition to the description, please also provide a link to the relevant SpaceVim documentation that describes the expected behaviour/feature. -Please press <kbd>SPC h I</kbd>, debug info will be put into clipboard, then paste all content below.+## Describe the problem -## Screenshots+**[This is a mandatory section]** -If you have any screenshots for this issue, please upload here. BTW you can use https://asciinema.org/ for recording video in terminal.+Please describe the observed problem in simple and clear terms. -<!-- please remove the issue template when request for a feature -->+## Describe steps to reproduce the problem++**[This is a mandatory section]**++Please list all the steps from the point the Vim session was started until the problem was observed, in simple and clear terms.++## Provide debug information from SpaceVim++**[This is a mandatory section]**++From within SpaceVim, please press `SPC h I` (ie: press and release`space`, followed by pressing and releasing the `h` key, followed by pressing and releasing the `I` key (capital I)). This will make SpaceVim print out debug information and also copy it to the clipboard. Please paste this debug information below in entirety.

Thanks @wsdjeg : I'll submit a new PR.

raw-bin

comment created time in 22 days

PullRequestReviewEvent

Pull request review commentSpaceVim/SpaceVim

Improve issue template

-<!-- bug reporting without issue template will be closed automatically -->+<!-- Following this template is mandatory to open an issue. Please use English --> -## Expected behavior, english is required+## Describe the behavior that you expect from SpaceVim -## The reproduce ways from Vim starting (Required!)+**[This is a mandatory section]** -## Debug info+If possible, in addition to the description, please also provide a link to the relevant SpaceVim documentation that describes the expected behaviour/feature. -Please press <kbd>SPC h I</kbd>, debug info will be put into clipboard, then paste all content below.+## Describe the problem -## Screenshots+**[This is a mandatory section]** -If you have any screenshots for this issue, please upload here. BTW you can use https://asciinema.org/ for recording video in terminal.+Please describe the observed problem in simple and clear terms. -<!-- please remove the issue template when request for a feature -->+## Describe steps to reproduce the problem++**[This is a mandatory section]**++Please list all the steps from the point the Vim session was started until the problem was observed, in simple and clear terms.++## Provide debug information from SpaceVim++**[This is a mandatory section]**++From within SpaceVim, please press `SPC h I` (ie: press and release`space`, followed by pressing and releasing the `h` key, followed by pressing and releasing the `I` key (capital I)). This will make SpaceVim print out debug information and also copy it to the clipboard. Please paste this debug information below in entirety.

@Rom1deTroyes: Thanks fore the response. I see that too!

FWIW: I tried spacemacs recently and even it uses the 'tap' dynamic. So whenever they say SPC a b they mean taps.

I agree with you - the question here is how best to disambiguate 'press'. Maybe I should just change the text to:

From within SpaceVim, please tap the following in order: `SPC h I` (ie: tap `space`, then tap `h` and then tap `I` (uppercase `i`). This....

Do you think that's clearer ?

raw-bin

comment created time in 22 days

PullRequestReviewEvent

Pull request review commentSpaceVim/SpaceVim

Improve issue template

-<!-- bug reporting without issue template will be closed automatically -->+<!-- Following this template is mandatory to open an issue. Please use English --> -## Expected behavior, english is required+## Describe the behavior that you expect from SpaceVim -## The reproduce ways from Vim starting (Required!)+**[This is a mandatory section]** -## Debug info+If possible, in addition to the description, please also provide a link to the relevant SpaceVim documentation that describes the expected behaviour/feature. -Please press <kbd>SPC h I</kbd>, debug info will be put into clipboard, then paste all content below.+## Describe the problem -## Screenshots+**[This is a mandatory section]** -If you have any screenshots for this issue, please upload here. BTW you can use https://asciinema.org/ for recording video in terminal.+Please describe the observed problem in simple and clear terms. -<!-- please remove the issue template when request for a feature -->+## Describe steps to reproduce the problem++**[This is a mandatory section]**++Please list all the steps from the point the Vim session was started until the problem was observed, in simple and clear terms.++## Provide debug information from SpaceVim++**[This is a mandatory section]**++From within SpaceVim, please press `SPC h I` (ie: press and release`space`, followed by pressing and releasing the `h` key, followed by pressing and releasing the `I` key (capital I)). This will make SpaceVim print out debug information and also copy it to the clipboard. Please paste this debug information below in entirety.

On my system, I have to 'tap' space (so press and release, rather than press and hold), then tap h and finally tap I. I assume that is the expected way to use these keys ?

Basically, I wanted to prevent SPC h I being interpreted as:

  • Press space and keep it pressed, then
  • press h and keep it pressed, then
  • press I

Does that make sense or have I misunderstood something ?

raw-bin

comment created time in 22 days

PullRequestReviewEvent

PR opened SpaceVim/SpaceVim

Improve issue template

PR Prelude

Thank you for working on SpaceVim! :)

Please complete these steps and check these boxes before filing your PR:

  • [x] I have read and understood SpaceVim's CONTRIBUTING document.
  • [x] I have read and understood SpaceVim's CODE_OF_CONDUCT document.
  • [x] I understand my PR may be closed if it becomes obvious I didn't actually perform all of these steps.

Why this change is necessary and useful?

  • This change improves the grammar in the text within the ISSUE_TEMPLATE.
  • In addition it encourages the submitter to provide references to relevant SpaceVim documentation in order to ensure that it has been read and the intent understood before filing a new issue.
+24 -8

0 comment

1 changed file

pr created time in 23 days

create barnchraw-bin/SpaceVim

branch : improve-issue-template

created branch time in 23 days

fork raw-bin/SpaceVim

A community-driven modular vim distribution - The ultimate vim configuration

https://spacevim.org

fork in 23 days

issue openedSpaceVim/SpaceVim

<Leader>y doesn't yank to the system clipboard

Expected behavior, english is required

As per the SpaceVim documentation, (see: https://spacevim.org/layers/default/), the 'core' layer is enabled by default. With this layer enabled, <Leader>y should yank the relevant text object to the system clipboard.

This doesn't work as expected. No text is copied to the system clipboard. The following message appears in the vim command/status window:

key bindings is not defined: -y

Tested with SpaceVim at commit 18b105c2db7abd8177ee3e1d397452f6aaeba860 on:

  • Ubuntu 20.04 on x86_64 host.
  • Ubuntu 20.04 under WSL2.

The reproduce ways from Vim starting (Required!)

  1. Start SpaceVim
  2. With the cursor on some text, press <Leader>p.

Debug info

Please press <kbd>SPC h I</kbd>, debug info will be put into clipboard, then paste all content below.

SpaceVim layers:

  • VersionControl: not loaded https://spacevim.org/layers/VersionControl/
  • autocomplete: loaded https://spacevim.org/layers/autocomplete/
  • chat: not loaded https://spacevim.org/layers/chat/
  • checkers: loaded https://spacevim.org/layers/checkers/
  • chinese: not loaded https://spacevim.org/layers/chinese/
  • colorscheme: not loaded https://spacevim.org/layers/colorscheme/
  • core#banner: loaded https://spacevim.org/layers/core/banner/
  • core#statusline: loaded https://spacevim.org/layers/core/statusline/
  • core#tabline: loaded https://spacevim.org/layers/core/tabline/
  • core: loaded https://spacevim.org/layers/core/
  • cscope: not loaded https://spacevim.org/layers/cscope/
  • ctrlp: not loaded https://spacevim.org/layers/ctrlp/
  • ctrlspace: not loaded https://spacevim.org/layers/ctrlspace/
  • debug: not loaded https://spacevim.org/layers/debug/
  • denite: not loaded https://spacevim.org/layers/denite/
  • edit: loaded https://spacevim.org/layers/edit/
  • exprfold: not loaded no exists
  • floobits: not loaded https://spacevim.org/layers/floobits/
  • foldsearch: not loaded https://spacevim.org/layers/foldsearch/
  • format: loaded https://spacevim.org/layers/format/
  • fuzzy: not loaded no exists
  • fzf: loaded https://spacevim.org/layers/fzf/
  • games: not loaded no exists
  • git: not loaded https://spacevim.org/layers/git/
  • github: not loaded https://spacevim.org/layers/github/
  • gtags: not loaded https://spacevim.org/layers/gtags/
  • incsearch: not loaded no exists
  • indentmove: not loaded no exists
  • japanese: not loaded https://spacevim.org/layers/japanese/
  • lang#WebAssembly: not loaded https://spacevim.org/layers/lang/WebAssembly/
  • lang#actionscript: not loaded https://spacevim.org/layers/lang/actionscript/
  • lang#agda: not loaded https://spacevim.org/layers/lang/agda/
  • lang#asciidoc: not loaded https://spacevim.org/layers/lang/asciidoc/
  • lang#aspectj: not loaded https://spacevim.org/layers/lang/aspectj/
  • lang#assembly: not loaded https://spacevim.org/layers/lang/assembly/
  • lang#autohotkey: not loaded https://spacevim.org/layers/lang/autohotkey/
  • lang#batch: not loaded https://spacevim.org/layers/lang/batch/
  • lang#c: not loaded https://spacevim.org/layers/lang/c/
  • lang#chapel: not loaded https://spacevim.org/layers/lang/chapel/
  • lang#clojure: not loaded https://spacevim.org/layers/lang/clojure/
  • lang#coffeescript: not loaded https://spacevim.org/layers/lang/coffeescript/
  • lang#crystal: not loaded https://spacevim.org/layers/lang/crystal/
  • lang#csharp: not loaded https://spacevim.org/layers/lang/csharp/
  • lang#d: not loaded https://spacevim.org/layers/lang/d/
  • lang#dart: not loaded https://spacevim.org/layers/lang/dart/
  • lang#dockerfile: not loaded https://spacevim.org/layers/lang/dockerfile/
  • lang#eiffel: not loaded https://spacevim.org/layers/lang/eiffel/
  • lang#elixir: not loaded https://spacevim.org/layers/lang/elixir/
  • lang#elm: not loaded https://spacevim.org/layers/lang/elm/
  • lang#erlang: not loaded https://spacevim.org/layers/lang/erlang/
  • lang#extra: not loaded https://spacevim.org/layers/lang/extra/
  • lang#factor: not loaded no exists
  • lang#forth: not loaded no exists
  • lang#fortran: not loaded https://spacevim.org/layers/lang/fortran/
  • lang#foxpro: not loaded https://spacevim.org/layers/lang/foxpro/
  • lang#fsharp: not loaded https://spacevim.org/layers/lang/fsharp/
  • lang#go: not loaded https://spacevim.org/layers/lang/go/
  • lang#goby: not loaded https://spacevim.org/layers/lang/goby/
  • lang#gosu: not loaded https://spacevim.org/layers/lang/gosu/
  • lang#graphql: not loaded https://spacevim.org/layers/lang/graphql/
  • lang#groovy: not loaded https://spacevim.org/layers/lang/groovy/
  • lang#hack: not loaded https://spacevim.org/layers/lang/hack/
  • lang#haskell: not loaded https://spacevim.org/layers/lang/haskell/
  • lang#html: not loaded https://spacevim.org/layers/lang/html/
  • lang#hy: not loaded https://spacevim.org/layers/lang/hy/
  • lang#idris: not loaded https://spacevim.org/layers/lang/idris/
  • lang#io: not loaded https://spacevim.org/layers/lang/io/
  • lang#ipynb: not loaded https://spacevim.org/layers/lang/ipynb/
  • lang#j: not loaded https://spacevim.org/layers/lang/j/
  • lang#janet: not loaded https://spacevim.org/layers/lang/janet/
  • lang#java: not loaded https://spacevim.org/layers/lang/java/
  • lang#javascript: not loaded https://spacevim.org/layers/lang/javascript/
  • lang#json: not loaded no exists
  • lang#julia: not loaded https://spacevim.org/layers/lang/julia/
  • lang#kotlin: not loaded https://spacevim.org/layers/lang/kotlin/
  • lang#lasso: not loaded https://spacevim.org/layers/lang/lasso/
  • lang#latex: not loaded https://spacevim.org/layers/lang/latex/
  • lang#lisp: not loaded https://spacevim.org/layers/lang/lisp/
  • lang#livescript: not loaded https://spacevim.org/layers/lang/livescript/
  • lang#lua: not loaded https://spacevim.org/layers/lang/lua/
  • lang#markdown: not loaded https://spacevim.org/layers/lang/markdown/
  • lang#matlab: not loaded https://spacevim.org/layers/lang/matlab/
  • lang#moonscript: not loaded https://spacevim.org/layers/lang/moonscript/
  • lang#nim: not loaded https://spacevim.org/layers/lang/nim/
  • lang#nix: not loaded https://spacevim.org/layers/lang/nix/
  • lang#ocaml: not loaded https://spacevim.org/layers/lang/ocaml/
  • lang#pact: not loaded https://spacevim.org/layers/lang/pact/
  • lang#pascal: not loaded https://spacevim.org/layers/lang/pascal/
  • lang#perl: not loaded https://spacevim.org/layers/lang/perl/
  • lang#php: not loaded https://spacevim.org/layers/lang/php/
  • lang#plantuml: not loaded https://spacevim.org/layers/lang/plantuml/
  • lang#pony: not loaded https://spacevim.org/layers/lang/pony/
  • lang#powershell: not loaded https://spacevim.org/layers/lang/powershell/
  • lang#processing: not loaded https://spacevim.org/layers/lang/processing/
  • lang#prolog: not loaded https://spacevim.org/layers/lang/prolog/
  • lang#puppet: not loaded https://spacevim.org/layers/lang/puppet/
  • lang#purescript: not loaded https://spacevim.org/layers/lang/purescript/
  • lang#python: not loaded https://spacevim.org/layers/lang/python/
  • lang#r: not loaded https://spacevim.org/layers/lang/r/
  • lang#racket: not loaded https://spacevim.org/layers/lang/racket/
  • lang#red: not loaded https://spacevim.org/layers/lang/red/
  • lang#ring: not loaded https://spacevim.org/layers/lang/ring/
  • lang#ruby: not loaded https://spacevim.org/layers/lang/ruby/
  • lang#rust: loaded https://spacevim.org/layers/lang/rust/
  • lang#scala: not loaded https://spacevim.org/layers/lang/scala/
  • lang#scheme: not loaded https://spacevim.org/layers/lang/scheme/
  • lang#sh: not loaded https://spacevim.org/layers/lang/sh/
  • lang#slim: not loaded https://spacevim.org/layers/lang/slim/
  • lang#solidity: not loaded no exists
  • lang#sql: not loaded no exists
  • lang#supercollider: not loaded no exists
  • lang#swift: not loaded https://spacevim.org/layers/lang/swift/
  • lang#swig: not loaded no exists
  • lang#tcl: not loaded https://spacevim.org/layers/lang/tcl/
  • lang#toml: not loaded https://spacevim.org/layers/lang/toml/
  • lang#typescript: not loaded https://spacevim.org/layers/lang/typescript/
  • lang#v: not loaded https://spacevim.org/layers/lang/v/
  • lang#vbnet: not loaded https://spacevim.org/layers/lang/vbnet/
  • lang#vim: not loaded https://spacevim.org/layers/lang/vim/
  • lang#vue: not loaded https://spacevim.org/layers/lang/vue/
  • lang#wdl: not loaded no exists
  • lang#wolfram: not loaded https://spacevim.org/layers/lang/wolfram/
  • lang#xml: not loaded https://spacevim.org/layers/lang/xml/
  • lang#xquery: not loaded no exists
  • lang#zig: not loaded https://spacevim.org/layers/lang/zig/
  • leaderf: not loaded https://spacevim.org/layers/leaderf/
  • lsp: not loaded https://spacevim.org/layers/language-server-protocol/
  • mail: not loaded no exists
  • operator: not loaded no exists
  • org: not loaded no exists
  • shell: loaded https://spacevim.org/layers/shell/
  • sudo: not loaded https://spacevim.org/layers/sudo/
  • test: not loaded https://spacevim.org/layers/test/
  • tmux: loaded https://spacevim.org/layers/tmux/
  • tools#dash: not loaded https://spacevim.org/layers/tools/dash/
  • tools#mpv: not loaded https://spacevim.org/layers/tools/mpv/
  • tools#screensaver: not loaded no exists
  • tools#zeal: not loaded https://spacevim.org/layers/tools/zeal/
  • tools: not loaded https://spacevim.org/layers/tools/
  • ui: loaded https://spacevim.org/layers/ui/
  • unite: not loaded https://spacevim.org/layers/unite/
  • vim: not loaded no exists

Screenshots

No screenshot required.

created time in 23 days

issue commentrust-lang/gha-self-hosted

Can't build emulated AArch64 images on x86_64

So my setup is slightly unusual in that it's Ubuntu running on Windows 10 via WSL2:

[09:30:18] robin@sentinel /home/robin
> uname -a
Linux sentinel 4.19.104-microsoft-standard #1 SMP Wed Feb 19 06:37:35 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
[11:54:42] robin@sentinel /home/robin
> cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS"
> qemu-system-aarch64 --version
QEMU emulator version 4.2.0 (Debian 1:4.2-3ubuntu6.4)
Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers

I don't think that Ubuntu/WSL2 should matter though but I can try using a 'normal' Ubuntu Linux x86_64 host too.

pietroalbini

comment created time in a month

issue commentrust-lang/rust

Incorrect code behavior on aarch64

Hi @berkus.

A data point: I just had a play with your reproducer on a native AArch64 machine:

jagran01@scm-arm1 ~/work/projects/rustc-tickets/68812/mre-write_to $ uname -a
Linux scm-arm1 5.0.0-38-generic #41-Ubuntu SMP Tue Dec 3 00:29:46 UTC 2019 aarch64 GNU/Linux

jagran01@scm-arm1 ~/work/projects/rustc-tickets/68812 $ git clone https://github.com/berkus/mre-write_to.git
Cloning into 'mre-write_to'...
remote: Enumerating objects: 9, done.
remote: Counting objects: 100% (9/9), done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 9 (delta 0), reused 9 (delta 0), pack-reused 0
Unpacking objects: 100% (9/9), done.

jagran01@scm-arm1 ~/work/projects/rustc-tickets/68812 $ cd mre-write_to/

jagran01@scm-arm1 ~/work/projects/rustc-tickets/68812/mre-write_to $ cargo build
   Compiling test-write-to v0.1.0 (/home/jagran01/work/projects/rustc-tickets/68812/mre-write_to)
error[E0554]: `#![feature]` may not be used on the stable release channel
 --> src/main.rs:2:1
  |
2 | #![feature(format_args_nl)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0554`.
error: could not compile `test-write-to`.

To learn more, run the command again with --verbose.

jagran01@scm-arm1 ~/work/projects/rustc-tickets/68812/mre-write_to $ echo nightly > rust-toolchain

jagran01@scm-arm1 ~/work/projects/rustc-tickets/68812/mre-write_to $ ~/.rustup/toolchains/nightly-aarch64-unknown-linux-gnu/bin/rustc --version
rustc 1.47.0-nightly (81e754c35 2020-08-02)

jagran01@scm-arm1 ~/work/projects/rustc-tickets/68812/mre-write_to $ cargo build
   Compiling test-write-to v0.1.0 (/home/jagran01/work/projects/rustc-tickets/68812/mre-write_to)
    Finished dev [unoptimized + debuginfo] target(s) in 1.05s

jagran01@scm-arm1 ~/work/projects/rustc-tickets/68812/mre-write_to $ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/test-write-to`
Converting to str
Converted to str
Hello, world!

jagran01@scm-arm1 ~/work/projects/rustc-tickets/68812/mre-write_to $ cargo test
    Finished test [unoptimized + debuginfo] target(s) in 0.02s
     Running target/debug/deps/test_write_to-d86fea7b5f3da2c4

running 1 test
Converting to str
test tests::write_to_works ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

jagran01@scm-arm1 ~/work/projects/rustc-tickets/68812/mre-write_to $ cargo clean

jagran01@scm-arm1 ~/work/projects/rustc-tickets/68812/mre-write_to $ cargo build --verbose
   Compiling test-write-to v0.1.0 (/home/jagran01/work/projects/rustc-tickets/68812/mre-write_to)
     Running `rustc --crate-name test_write_to --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C panic=abort -Cembed-bitcode=no -C debuginfo=2 -C metadata=50ae77b73baa9539 -C extra-filename=-50ae77b73baa9539 --out-dir /home/jagran01/work/projects/rustc-tickets/68812/mre-write_to/target/debug/deps -C incremental=/home/jagran01/work/projects/rustc-tickets/68812/mre-write_to/target/debug/incremental -L dependency=/home/jagran01/work/projects/rustc-tickets/68812/mre-write_to/target/debug/deps`
    Finished dev [unoptimized + debuginfo] target(s) in 1.00s

On the face of it, it appears that the test succeeds with nightly. There are some assumptions in the test that couple it to nightly so I couldn't test other versions.

Can you confirm that this is expected ? Is there anything else you would like us to try ?

Thanks

berkus

comment created time in a month

issue commentrust-lang/gha-self-hosted

Can't build emulated AArch64 images on x86_64

Hi Pietro.

As of now, on my setup, which is:

[23:09:09] robin@sentinel /home/robin/Work/projects/pietro-packet-qemu-failure
> uname -a
Linux sentinel 4.19.104-microsoft-standard #1 SMP Wed Feb 19 06:37:35 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

... I see the following error:

[23:07:47] robin@sentinel /home/robin/Work/projects/pietro-packet-qemu-failure
> git clone git@github.com:rust-lang/gha-self-hosted.git
Cloning into 'gha-self-hosted'...
remote: Enumerating objects: 269, done.
remote: Counting objects: 100% (269/269), done.
remote: Compressing objects: 100% (148/148), done.
remote: Total 269 (delta 133), reused 230 (delta 94), pack-reused 0
Receiving objects: 100% (269/269), 69.29 KiB | 724.00 KiB/s, done.
Resolving deltas: 100% (133/133), done.
[23:07:55] robin@sentinel /home/robin/Work/projects/pietro-packet-qemu-failure
> cd gha-self-hosted
[23:08:04] robin@sentinel /home/robin/Work/projects/pietro-packet-qemu-failure/gha-self-hosted
> cd images/ubuntu/
[23:08:07] robin@sentinel /home/robin/Work/projects/pietro-packet-qemu-failure/gha-self-hosted/images/ubuntu
> make aarch64-emul PACKER_LOG=1
curl -Lo build/QEMU_EFI.fd https://releases.linaro.org/components/kernel/uefi-linaro/latest/release/qemu64/QEMU_EFI.fd
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 2048k  100 2048k    0     0  1235k      0  0:00:01  0:00:01 --:--:-- 3013k
rm -rf build/aarch64
PACKER_CACHE_DIR=build/cache GIT_SHA=f5dc1708ec64ec55012690dddc63cf729b62a1a8 QEMU_ACCELERATOR=tcg SSH_TIMEOUT=1h SSH_HANDSHAKE_ATTEMPTS=100 AARCH64_MACHINE=virt AARCH64_CPU=cortex-a57 packer build -only ubuntu-aarch64 ubuntu.json
2020/09/01 23:08:11 [INFO] Packer version: 1.3.4
2020/09/01 23:08:11 Packer Target OS/Arch: linux amd64
2020/09/01 23:08:11 Built with Go Version: go1.10.4
2020/09/01 23:08:11 Detected home directory from env var: /home/robin
2020/09/01 23:08:11 Using internal plugin for parallels-iso
2020/09/01 23:08:11 Using internal plugin for qemu
2020/09/01 23:08:11 Using internal plugin for amazon-ebs
2020/09/01 23:08:11 Using internal plugin for amazon-ebssurrogate
2020/09/01 23:08:11 Using internal plugin for amazon-ebsvolume
2020/09/01 23:08:11 Using internal plugin for cloudstack
2020/09/01 23:08:11 Using internal plugin for hyperv-iso
2020/09/01 23:08:11 Using internal plugin for lxd
2020/09/01 23:08:11 Using internal plugin for virtualbox-ovf
2020/09/01 23:08:11 Using internal plugin for amazon-chroot
2020/09/01 23:08:11 Using internal plugin for amazon-instance
2020/09/01 23:08:11 Using internal plugin for digitalocean
2020/09/01 23:08:11 Using internal plugin for hyperv-vmcx
2020/09/01 23:08:11 Using internal plugin for lxc
2020/09/01 23:08:11 Using internal plugin for parallels-pvm
2020/09/01 23:08:11 Using internal plugin for alicloud-ecs
2020/09/01 23:08:11 Using internal plugin for file
2020/09/01 23:08:11 Using internal plugin for vmware-vmx
2020/09/01 23:08:11 Using internal plugin for docker
2020/09/01 23:08:11 Using internal plugin for googlecompute
2020/09/01 23:08:11 Using internal plugin for null
2020/09/01 23:08:11 Using internal plugin for openstack
2020/09/01 23:08:11 Using internal plugin for virtualbox-iso
2020/09/01 23:08:11 Using internal plugin for vmware-iso
2020/09/01 23:08:11 Using internal plugin for chef-solo
2020/09/01 23:08:11 Using internal plugin for converge
2020/09/01 23:08:11 Using internal plugin for file
2020/09/01 23:08:11 Using internal plugin for puppet-server
2020/09/01 23:08:11 Using internal plugin for salt-masterless
2020/09/01 23:08:11 Using internal plugin for shell
2020/09/01 23:08:11 Using internal plugin for ansible
2020/09/01 23:08:11 Using internal plugin for puppet-masterless
2020/09/01 23:08:11 Using internal plugin for breakpoint
2020/09/01 23:08:11 Using internal plugin for chef-client
2020/09/01 23:08:11 Using internal plugin for shell-local
2020/09/01 23:08:11 Using internal plugin for ansible-local
2020/09/01 23:08:11 Using internal plugin for powershell
2020/09/01 23:08:11 Using internal plugin for windows-restart
2020/09/01 23:08:11 Using internal plugin for windows-shell
2020/09/01 23:08:11 Using internal plugin for googlecompute-export
2020/09/01 23:08:11 Using internal plugin for googlecompute-import
2020/09/01 23:08:11 Using internal plugin for amazon-import
2020/09/01 23:08:11 Using internal plugin for docker-push
2020/09/01 23:08:11 Using internal plugin for docker-tag
2020/09/01 23:08:11 Using internal plugin for manifest
2020/09/01 23:08:11 Using internal plugin for vagrant-cloud
2020/09/01 23:08:11 Using internal plugin for compress
2020/09/01 23:08:11 Using internal plugin for docker-save
2020/09/01 23:08:11 Using internal plugin for shell-local
2020/09/01 23:08:11 Using internal plugin for vagrant
2020/09/01 23:08:11 Using internal plugin for vsphere
2020/09/01 23:08:11 Using internal plugin for alicloud-import
2020/09/01 23:08:11 Using internal plugin for artifice
2020/09/01 23:08:11 Using internal plugin for checksum
2020/09/01 23:08:11 Using internal plugin for vsphere-template
2020/09/01 23:08:11 Using internal plugin for docker-import
2020/09/01 23:08:11 Detected home directory from env var: /home/robin
2020/09/01 23:08:11 Attempting to open config file: /home/robin/.packerconfig
2020/09/01 23:08:11 [WARN] Config file doesn't exist: /home/robin/.packerconfig
2020/09/01 23:08:11 Packer config: &{DisableCheckpoint:false DisableCheckpointSignature:false PluginMinPort:10000 PluginMaxPort:25000 Builders:map[amazon-ebsvolume:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-amazon-ebsvolume amazon-instance:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-amazon-instance hyperv-vmcx:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-hyperv-vmcx file:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-file vmware-vmx:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-vmware-vmx openstack:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-openstack qemu:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-qemu amazon-ebs:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-amazon-ebs virtualbox-iso:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-virtualbox-iso vmware-iso:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-vmware-iso amazon-ebssurrogate:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-amazon-ebssurrogate alicloud-ecs:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-alicloud-ecs lxd:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-lxd virtualbox-ovf:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-virtualbox-ovf amazon-chroot:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-amazon-chroot digitalocean:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-digitalocean docker:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-docker googlecompute:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-googlecompute parallels-iso:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-parallels-iso cloudstack:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-cloudstack null:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-null parallels-pvm:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-parallels-pvm hyperv-iso:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-hyperv-iso lxc:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-lxc] PostProcessors:map[artifice:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-artifice vsphere-template:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-vsphere-template vagrant-cloud:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-vagrant-cloud vsphere:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-vsphere checksum:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-checksum docker-import:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-docker-import googlecompute-export:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-googlecompute-export googlecompute-import:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-googlecompute-import docker-push:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-docker-push shell-local:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-shell-local alicloud-import:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-alicloud-import vagrant:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-vagrant amazon-import:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-amazon-import docker-tag:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-docker-tag manifest:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-manifest compress:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-compress docker-save:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-docker-save] Provisioners:map[shell:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-shell breakpoint:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-breakpoint windows-restart:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-windows-restart file:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-file salt-masterless:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-salt-masterless ansible-local:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-ansible-local windows-shell:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-windows-shell converge:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-converge ansible:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-ansible chef-client:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-chef-client shell-local:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-shell-local powershell:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-powershell chef-solo:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-chef-solo puppet-server:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-puppet-server puppet-masterless:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-puppet-masterless]}
2020/09/01 23:08:11 Setting cache directory: /home/robin/Work/projects/pietro-packet-qemu-failure/gha-self-hosted/images/ubuntu/build/cache
2020/09/01 23:08:11 Detected home directory from env var: /home/robin
2020/09/01 23:08:11 Loading builder: qemu
2020/09/01 23:08:11 Plugin could not be found. Checking same directory as executable.
2020/09/01 23:08:11 Current exe path: /usr/bin/packer
2020/09/01 23:08:11 Creating plugin client for path: /usr/bin/packer
2020/09/01 23:08:11 Starting plugin: /usr/bin/packer []string{"/usr/bin/packer", "plugin", "packer-builder-qemu"}
2020/09/01 23:08:11 Waiting for RPC address for: /usr/bin/packer
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 [INFO] Packer version: 1.3.4
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Packer Target OS/Arch: linux amd64
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Built with Go Version: go1.10.4
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Detected home directory from env var: /home/robin
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Attempting to open config file: /home/robin/.packerconfig
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 [WARN] Config file doesn't exist: /home/robin/.packerconfig
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Packer config: &{DisableCheckpoint:false DisableCheckpointSignature:false PluginMinPort:10000 PluginMaxPort:25000 Builders:map[] PostProcessors:map[] Provisioners:map[]}
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Setting cache directory: /home/robin/Work/projects/pietro-packet-qemu-failure/gha-self-hosted/images/ubuntu/build/cache
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 args: []string{"packer-builder-qemu"}
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Plugin minimum port: 10000
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Plugin maximum port: 25000
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Detected home directory from env var: /home/robin
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Plugin address: unix /tmp/packer-plugin120779301
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Waiting for connection...
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Serving a plugin connection...
2020/09/01 23:08:11 Loading provisioner: shell
2020/09/01 23:08:11 Plugin could not be found. Checking same directory as executable.
2020/09/01 23:08:11 Current exe path: /usr/bin/packer
2020/09/01 23:08:11 Creating plugin client for path: /usr/bin/packer
2020/09/01 23:08:11 Starting plugin: /usr/bin/packer []string{"/usr/bin/packer", "plugin", "packer-provisioner-shell"}
2020/09/01 23:08:11 Waiting for RPC address for: /usr/bin/packer
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 [INFO] Packer version: 1.3.4
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Packer Target OS/Arch: linux amd64
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Built with Go Version: go1.10.4
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Detected home directory from env var: /home/robin
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Attempting to open config file: /home/robin/.packerconfig
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 [WARN] Config file doesn't exist: /home/robin/.packerconfig
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Packer config: &{DisableCheckpoint:false DisableCheckpointSignature:false PluginMinPort:10000 PluginMaxPort:25000 Builders:map[] PostProcessors:map[] Provisioners:map[]}
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Setting cache directory: /home/robin/Work/projects/pietro-packet-qemu-failure/gha-self-hosted/images/ubuntu/build/cache
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 args: []string{"packer-provisioner-shell"}
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Plugin minimum port: 10000
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Plugin maximum port: 25000
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Detected home directory from env var: /home/robin
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Plugin address: unix /tmp/packer-plugin309355150
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Waiting for connection...
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Serving a plugin connection...
2020/09/01 23:08:11 Loading provisioner: file
2020/09/01 23:08:11 Plugin could not be found. Checking same directory as executable.
2020/09/01 23:08:11 Current exe path: /usr/bin/packer
2020/09/01 23:08:11 Creating plugin client for path: /usr/bin/packer
2020/09/01 23:08:11 Starting plugin: /usr/bin/packer []string{"/usr/bin/packer", "plugin", "packer-provisioner-file"}
2020/09/01 23:08:11 Waiting for RPC address for: /usr/bin/packer
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 [INFO] Packer version: 1.3.4
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Packer Target OS/Arch: linux amd64
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Built with Go Version: go1.10.4
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Detected home directory from env var: /home/robin
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Attempting to open config file: /home/robin/.packerconfig
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 [WARN] Config file doesn't exist: /home/robin/.packerconfig
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Packer config: &{DisableCheckpoint:false DisableCheckpointSignature:false PluginMinPort:10000 PluginMaxPort:25000 Builders:map[] PostProcessors:map[] Provisioners:map[]}
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Setting cache directory: /home/robin/Work/projects/pietro-packet-qemu-failure/gha-self-hosted/images/ubuntu/build/cache
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 args: []string{"packer-provisioner-file"}
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Plugin minimum port: 10000
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Plugin maximum port: 25000
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Detected home directory from env var: /home/robin
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Plugin address: unix /tmp/packer-plugin131213759
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Waiting for connection...
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Serving a plugin connection...
2020/09/01 23:08:11 Loading provisioner: shell
2020/09/01 23:08:11 Plugin could not be found. Checking same directory as executable.
2020/09/01 23:08:11 Current exe path: /usr/bin/packer
2020/09/01 23:08:11 Creating plugin client for path: /usr/bin/packer
2020/09/01 23:08:11 Starting plugin: /usr/bin/packer []string{"/usr/bin/packer", "plugin", "packer-provisioner-shell"}
2020/09/01 23:08:11 Waiting for RPC address for: /usr/bin/packer
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 [INFO] Packer version: 1.3.4
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Packer Target OS/Arch: linux amd64
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Built with Go Version: go1.10.4
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Detected home directory from env var: /home/robin
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Attempting to open config file: /home/robin/.packerconfig
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 [WARN] Config file doesn't exist: /home/robin/.packerconfig
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Packer config: &{DisableCheckpoint:false DisableCheckpointSignature:false PluginMinPort:10000 PluginMaxPort:25000 Builders:map[] PostProcessors:map[] Provisioners:map[]}
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Setting cache directory: /home/robin/Work/projects/pietro-packet-qemu-failure/gha-self-hosted/images/ubuntu/build/cache
ubuntu-aarch64 output will be in this color.
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 args: []string{"packer-provisioner-shell"}

2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Plugin minimum port: 10000
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Plugin maximum port: 25000
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Detected home directory from env var: /home/robin
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Plugin address: unix /tmp/packer-plugin350617188
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Waiting for connection...
2020/09/01 23:08:11 packer: 2020/09/01 23:08:11 Serving a plugin connection...
2020/09/01 23:08:11 Build debug mode: false
2020/09/01 23:08:11 Force build: false
2020/09/01 23:08:11 On error:
2020/09/01 23:08:11 Preparing build: ubuntu-aarch64
2020/09/01 23:08:11 Build 'ubuntu-aarch64' prepare failure: 1 error(s) decoding:

* cannot parse 'disk_size' as uint: strconv.ParseUint: parsing "5G": invalid syntax
2020/09/01 23:08:11 ui error: 1 error(s) decoding:

* cannot parse 'disk_size' as uint: strconv.ParseUint: parsing "5G": invalid syntax
2020/09/01 23:08:11 waiting for all plugin processes to complete...
1 error(s) decoding:

* cannot parse 'disk_size' as uint: strconv.ParseUint: parsing "5G": invalid syntax
2020/09/01 23:08:11 /usr/bin/packer: plugin process exited
2020/09/01 23:08:11 /usr/bin/packer: plugin process exited
2020/09/01 23:08:11 /usr/bin/packer: plugin process exited
2020/09/01 23:08:11 /usr/bin/packer: plugin process exited
make: *** [Makefile:27: aarch64-emul] Error 1

... which I fix using this trivial mod:

diff --git a/images/ubuntu/ubuntu.json b/images/ubuntu/ubuntu.json
index 4224bcc..3a880c2 100644
--- a/images/ubuntu/ubuntu.json
+++ b/images/ubuntu/ubuntu.json
@@ -3,7 +3,7 @@
         "ubuntu_codename": "focal",
         "ubuntu_version": "20.04",

-        "build_disk_size": "5G",
+        "build_disk_size": "5120",
         "build_hostname": "gha-self-hosted-vm",
         "build_cpus": "8",

... which gives me:

> make aarch64-emul PACKER_LOG=1
rm -rf build/aarch64
PACKER_CACHE_DIR=build/cache GIT_SHA=f5dc1708ec64ec55012690dddc63cf729b62a1a8 QEMU_ACCELERATOR=tcg SSH_TIMEOUT=1h SSH_HANDSHAKE_ATTEMPTS=100 AARCH64_MACHINE=virt AARCH64_CPU=cortex-a57 packer build -only ubuntu-aarch64 ubuntu.json
2020/09/01 22:11:04 [INFO] Packer version: 1.3.4
2020/09/01 22:11:04 Packer Target OS/Arch: linux amd64
2020/09/01 22:11:04 Built with Go Version: go1.10.4
2020/09/01 22:11:04 Detected home directory from env var: /home/robin
2020/09/01 22:11:04 Using internal plugin for cloudstack
2020/09/01 22:11:04 Using internal plugin for openstack
2020/09/01 22:11:04 Using internal plugin for parallels-iso
2020/09/01 22:11:04 Using internal plugin for vmware-vmx
2020/09/01 22:11:04 Using internal plugin for amazon-instance
2020/09/01 22:11:04 Using internal plugin for digitalocean
2020/09/01 22:11:04 Using internal plugin for docker
2020/09/01 22:11:04 Using internal plugin for file
2020/09/01 22:11:04 Using internal plugin for googlecompute
2020/09/01 22:11:04 Using internal plugin for parallels-pvm
2020/09/01 22:11:04 Using internal plugin for virtualbox-ovf
2020/09/01 22:11:04 Using internal plugin for vmware-iso
2020/09/01 22:11:04 Using internal plugin for amazon-ebsvolume
2020/09/01 22:11:04 Using internal plugin for amazon-ebs
2020/09/01 22:11:04 Using internal plugin for hyperv-iso
2020/09/01 22:11:04 Using internal plugin for hyperv-vmcx
2020/09/01 22:11:04 Using internal plugin for null
2020/09/01 22:11:04 Using internal plugin for amazon-chroot
2020/09/01 22:11:04 Using internal plugin for amazon-ebssurrogate
2020/09/01 22:11:04 Using internal plugin for lxc
2020/09/01 22:11:04 Using internal plugin for lxd
2020/09/01 22:11:04 Using internal plugin for qemu
2020/09/01 22:11:04 Using internal plugin for virtualbox-iso
2020/09/01 22:11:04 Using internal plugin for alicloud-ecs
2020/09/01 22:11:04 Using internal plugin for ansible-local
2020/09/01 22:11:04 Using internal plugin for shell
2020/09/01 22:11:04 Using internal plugin for windows-restart
2020/09/01 22:11:04 Using internal plugin for breakpoint
2020/09/01 22:11:04 Using internal plugin for windows-shell
2020/09/01 22:11:04 Using internal plugin for ansible
2020/09/01 22:11:04 Using internal plugin for chef-client
2020/09/01 22:11:04 Using internal plugin for converge
2020/09/01 22:11:04 Using internal plugin for chef-solo
2020/09/01 22:11:04 Using internal plugin for file
2020/09/01 22:11:04 Using internal plugin for powershell
2020/09/01 22:11:04 Using internal plugin for puppet-masterless
2020/09/01 22:11:04 Using internal plugin for puppet-server
2020/09/01 22:11:04 Using internal plugin for salt-masterless
2020/09/01 22:11:04 Using internal plugin for shell-local
2020/09/01 22:11:04 Using internal plugin for compress
2020/09/01 22:11:04 Using internal plugin for docker-save
2020/09/01 22:11:04 Using internal plugin for shell-local
2020/09/01 22:11:04 Using internal plugin for docker-import
2020/09/01 22:11:04 Using internal plugin for docker-push
2020/09/01 22:11:04 Using internal plugin for docker-tag
2020/09/01 22:11:04 Using internal plugin for vagrant-cloud
2020/09/01 22:11:04 Using internal plugin for amazon-import
2020/09/01 22:11:04 Using internal plugin for checksum
2020/09/01 22:11:04 Using internal plugin for googlecompute-import
2020/09/01 22:11:04 Using internal plugin for manifest
2020/09/01 22:11:04 Using internal plugin for vsphere-template
2020/09/01 22:11:04 Using internal plugin for alicloud-import
2020/09/01 22:11:04 Using internal plugin for artifice
2020/09/01 22:11:04 Using internal plugin for googlecompute-export
2020/09/01 22:11:04 Using internal plugin for vagrant
2020/09/01 22:11:04 Using internal plugin for vsphere
2020/09/01 22:11:04 Detected home directory from env var: /home/robin
2020/09/01 22:11:04 Attempting to open config file: /home/robin/.packerconfig
2020/09/01 22:11:04 [WARN] Config file doesn't exist: /home/robin/.packerconfig
2020/09/01 22:11:04 Packer config: &{DisableCheckpoint:false DisableCheckpointSignature:false PluginMinPort:10000 PluginMaxPort:25000 Builders:map[vmware-vmx:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-vmware-vmx digitalocean:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-digitalocean file:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-file amazon-ebsvolume:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-amazon-ebsvolume amazon-ebs:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-amazon-ebs amazon-ebssurrogate:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-amazon-ebssurrogate lxc:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-lxc alicloud-ecs:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-alicloud-ecs parallels-iso:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-parallels-iso hyperv-vmcx:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-hyperv-vmcx amazon-chroot:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-amazon-chroot cloudstack:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-cloudstack amazon-instance:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-amazon-instance docker:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-docker googlecompute:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-googlecompute parallels-pvm:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-parallels-pvm null:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-null openstack:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-openstack virtualbox-ovf:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-virtualbox-ovf vmware-iso:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-vmware-iso hyperv-iso:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-hyperv-iso lxd:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-lxd qemu:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-qemu virtualbox-iso:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-builder-virtualbox-iso] PostProcessors:map[docker-import:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-docker-import vagrant-cloud:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-vagrant-cloud googlecompute-export:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-googlecompute-export compress:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-compress docker-save:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-docker-save shell-local:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-shell-local artifice:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-artifice vagrant:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-vagrant docker-tag:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-docker-tag amazon-import:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-amazon-import googlecompute-import:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-googlecompute-import docker-push:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-docker-push checksum:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-checksum vsphere-template:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-vsphere-template manifest:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-manifest alicloud-import:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-alicloud-import vsphere:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-post-processor-vsphere] Provisioners:map[shell:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-shell windows-shell:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-windows-shell salt-masterless:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-salt-masterless shell-local:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-shell-local ansible-local:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-ansible-local breakpoint:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-breakpoint file:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-file powershell:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-powershell converge:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-converge chef-solo:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-chef-solo puppet-server:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-puppet-server windows-restart:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-windows-restart ansible:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-ansible chef-client:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-chef-client puppet-masterless:/usr/bin/packer-PACKERSPACE-plugin-PACKERSPACE-packer-provisioner-puppet-masterless]}
2020/09/01 22:11:04 Setting cache directory: /home/robin/Work/projects/pietro-packet-qemu-failure/gha-self-hosted/images/ubuntu/build/cache
2020/09/01 22:11:04 Detected home directory from env var: /home/robin
2020/09/01 22:11:04 Loading builder: qemu
2020/09/01 22:11:04 Plugin could not be found. Checking same directory as executable.
2020/09/01 22:11:04 Current exe path: /usr/bin/packer
2020/09/01 22:11:04 Creating plugin client for path: /usr/bin/packer
2020/09/01 22:11:04 Starting plugin: /usr/bin/packer []string{"/usr/bin/packer", "plugin", "packer-builder-qemu"}
2020/09/01 22:11:04 Waiting for RPC address for: /usr/bin/packer
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 [INFO] Packer version: 1.3.4
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Packer Target OS/Arch: linux amd64
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Built with Go Version: go1.10.4
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Detected home directory from env var: /home/robin
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Attempting to open config file: /home/robin/.packerconfig
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 [WARN] Config file doesn't exist: /home/robin/.packerconfig
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Packer config: &{DisableCheckpoint:false DisableCheckpointSignature:false PluginMinPort:10000 PluginMaxPort:25000 Builders:map[] PostProcessors:map[] Provisioners:map[]}
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Setting cache directory: /home/robin/Work/projects/pietro-packet-qemu-failure/gha-self-hosted/images/ubuntu/build/cache
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 args: []string{"packer-builder-qemu"}
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Plugin minimum port: 10000
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Plugin maximum port: 25000
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Plugin address: unix /tmp/packer-plugin214983131
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Waiting for connection...
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Detected home directory from env var: /home/robin
2020/09/01 22:11:04 Loading provisioner: shell
2020/09/01 22:11:04 Plugin could not be found. Checking same directory as executable.
2020/09/01 22:11:04 Current exe path: /usr/bin/packer
2020/09/01 22:11:04 Creating plugin client for path: /usr/bin/packer
2020/09/01 22:11:04 Starting plugin: /usr/bin/packer []string{"/usr/bin/packer", "plugin", "packer-provisioner-shell"}
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Serving a plugin connection...
2020/09/01 22:11:04 Waiting for RPC address for: /usr/bin/packer
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 [INFO] Packer version: 1.3.4
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Packer Target OS/Arch: linux amd64
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Built with Go Version: go1.10.4
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Detected home directory from env var: /home/robin
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Attempting to open config file: /home/robin/.packerconfig
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 [WARN] Config file doesn't exist: /home/robin/.packerconfig
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Packer config: &{DisableCheckpoint:false DisableCheckpointSignature:false PluginMinPort:10000 PluginMaxPort:25000 Builders:map[] PostProcessors:map[] Provisioners:map[]}
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Setting cache directory: /home/robin/Work/projects/pietro-packet-qemu-failure/gha-self-hosted/images/ubuntu/build/cache
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Detected home directory from env var: /home/robin
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 args: []string{"packer-provisioner-shell"}
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Plugin minimum port: 10000
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Plugin maximum port: 25000
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Plugin address: unix /tmp/packer-plugin273715280
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Waiting for connection...
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Serving a plugin connection...
2020/09/01 22:11:04 Loading provisioner: file
2020/09/01 22:11:04 Plugin could not be found. Checking same directory as executable.
2020/09/01 22:11:04 Current exe path: /usr/bin/packer
2020/09/01 22:11:04 Creating plugin client for path: /usr/bin/packer
2020/09/01 22:11:04 Starting plugin: /usr/bin/packer []string{"/usr/bin/packer", "plugin", "packer-provisioner-file"}
2020/09/01 22:11:04 Waiting for RPC address for: /usr/bin/packer
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 [INFO] Packer version: 1.3.4
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Packer Target OS/Arch: linux amd64
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Built with Go Version: go1.10.4
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Detected home directory from env var: /home/robin
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Attempting to open config file: /home/robin/.packerconfig
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 [WARN] Config file doesn't exist: /home/robin/.packerconfig
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Packer config: &{DisableCheckpoint:false DisableCheckpointSignature:false PluginMinPort:10000 PluginMaxPort:25000 Builders:map[] PostProcessors:map[] Provisioners:map[]}
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Setting cache directory: /home/robin/Work/projects/pietro-packet-qemu-failure/gha-self-hosted/images/ubuntu/build/cache
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 args: []string{"packer-provisioner-file"}
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Plugin minimum port: 10000
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Plugin maximum port: 25000
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Plugin address: unix /tmp/packer-plugin240616909
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Waiting for connection...
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Detected home directory from env var: /home/robin
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Serving a plugin connection...
2020/09/01 22:11:04 Loading provisioner: shell
2020/09/01 22:11:04 Plugin could not be found. Checking same directory as executable.
2020/09/01 22:11:04 Current exe path: /usr/bin/packer
2020/09/01 22:11:04 Creating plugin client for path: /usr/bin/packer
2020/09/01 22:11:04 Starting plugin: /usr/bin/packer []string{"/usr/bin/packer", "plugin", "packer-provisioner-shell"}
2020/09/01 22:11:04 Waiting for RPC address for: /usr/bin/packer
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 [INFO] Packer version: 1.3.4
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Packer Target OS/Arch: linux amd64
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Built with Go Version: go1.10.4
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Detected home directory from env var: /home/robin
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Attempting to open config file: /home/robin/.packerconfig
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 [WARN] Config file doesn't exist: /home/robin/.packerconfig
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Packer config: &{DisableCheckpoint:false DisableCheckpointSignature:false PluginMinPort:10000 PluginMaxPort:25000 Builders:map[] PostProcessors:map[] Provisioners:map[]}
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Setting cache directory: /home/robin/Work/projects/pietro-packet-qemu-failure/gha-self-hosted/images/ubuntu/build/cache
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 args: []string{"packer-provisioner-shell"}
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Plugin minimum port: 10000
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Plugin maximum port: 25000
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Plugin address: unix /tmp/packer-plugin073466415
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Waiting for connection...
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Detected home directory from env var: /home/robin
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Serving a plugin connection...
2020/09/01 22:11:04 Build debug mode: false
ubuntu-aarch64 output will be in this color.
2020/09/01 22:11:04 Force build: false

2020/09/01 22:11:04 On error:
2020/09/01 22:11:04 Preparing build: ubuntu-aarch64
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 use specified accelerator: tcg
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 MemorySize 0 is too small, using default: 512
2020/09/01 22:11:04 Waiting on builds to complete...
2020/09/01 22:11:04 Starting build run: ubuntu-aarch64
2020/09/01 22:11:04 Running builder: qemu
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Qemu path: /usr/bin/qemu-system-aarch64, Qemu Image page: /usr/bin/qemu-img
==> ubuntu-aarch64: Retrieving ISO
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Acquiring lock to download: http://cloud-images.ubuntu.com/releases/focal/release/ubuntu-20.04-server-cloudimg-arm64.img
2020/09/01 22:11:04 packer: 2020/09/01 22:11:04 Verifying checksum of /home/robin/Work/projects/pietro-packet-qemu-failure/gha-self-hosted/images/ubuntu/build/cache/bd2792f5b7476dcedc4e4f8d6506f92b739e017e6b6781596b9752b09ac5b041.iso
    ubuntu-aarch64: Found already downloaded, initial checksum matched, no download needed: http://cloud-images.ubuntu.com/releases/focal/release/ubuntu-20.04-server-cloudimg-arm64.img
==> ubuntu-aarch64: Copying hard drive...
2020/09/01 22:11:06 packer: 2020/09/01 22:11:06 No floppy files specified. Floppy disk will not be made.
2020/09/01 22:11:06 packer: 2020/09/01 22:11:06 Executing qemu-img: []string{"convert", "-O", "qcow2", "/home/robin/Work/projects/pietro-packet-qemu-failure/gha-self-hosted/images/ubuntu/build/cache/bd2792f5b7476dcedc4e4f8d6506f92b739e017e6b6781596b9752b09ac5b041.iso", "build/aarch64/rootfs.qcow2"}
2020/09/01 22:11:09 packer: 2020/09/01 22:11:09 stdout:
2020/09/01 22:11:09 packer: 2020/09/01 22:11:09 stderr:
==> ubuntu-aarch64: Resizing hard drive...
2020/09/01 22:11:09 packer: 2020/09/01 22:11:09 Executing qemu-img: []string{"resize", "-f", "qcow2", "build/aarch64/rootfs.qcow2", "5120M"}
==> ubuntu-aarch64: Starting HTTP server on port 8779
2020/09/01 22:11:10 packer: 2020/09/01 22:11:10 stdout: Image resized.
2020/09/01 22:11:10 packer: 2020/09/01 22:11:10 stderr:
2020/09/01 22:11:10 packer: 2020/09/01 22:11:10 Trying port: 8779
==> ubuntu-aarch64: Found port for communicator (SSH, WinRM, etc): 3809.
2020/09/01 22:11:10 packer: 2020/09/01 22:11:10 Looking for available communicator (SSH, WinRM, etc) port between 2222 and 4444
2020/09/01 22:11:10 packer: 2020/09/01 22:11:10 Trying port: 3809
==> ubuntu-aarch64: Looking for available port between 5900 and 6000 on 127.0.0.1
==> ubuntu-aarch64: Starting VM, booting disk image
2020/09/01 22:11:10 packer: 2020/09/01 22:11:10 Looking for available port between 5900 and 6000 on 127.0.0.1
2020/09/01 22:11:10 packer: 2020/09/01 22:11:10 Trying port: 5908
2020/09/01 22:11:10 packer: 2020/09/01 22:11:10 Found available VNC port: 5908 on IP: 127.0.0.1
2020/09/01 22:11:10 packer: 2020/09/01 22:11:10 Qemu --version output: QEMU emulator version 4.2.0 (Debian 1:4.2-3ubuntu6.4)
2020/09/01 22:11:10 packer: Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
2020/09/01 22:11:10 packer: 2020/09/01 22:11:10 Qemu version: 4.2.0
2020/09/01 22:11:10 packer: 2020/09/01 22:11:10 Qemu Builder has no floppy files, not attaching a floppy.
==> ubuntu-aarch64: Overriding defaults Qemu arguments with QemuArgs...
2020/09/01 22:11:10 packer: 2020/09/01 22:11:10 Executing /usr/bin/qemu-system-aarch64: []string{"-nographic", "-device", "virtio-scsi-pci,id=scsi0", "-device", "scsi-hd,bus=scsi0.0,drive=drive0", "-device", "virtio-net,netdev=user.0", "-vnc", "127.0.0.1:8", "-smp", "cpus=8,sockets=8", "-boot", "c", "-cpu", "cortex-a57", "-bios", "build/QEMU_EFI.fd", "-name", "rootfs.qcow2", "-machine", "type=virt,accel=tcg", "-netdev", "user,id=user.0,hostfwd=tcp::3809-:22", "-drive", "if=none,file=build/aarch64/rootfs.qcow2,id=drive0,cache=writeback,discard=unmap,format=qcow2", "-serial", "pty", "-smbios", "type=1,serial=ds=nocloud-net;instance-id=gha-self-hosted-vm;seedfrom=http://10.0.2.2:8779/", "-m", "512M"}
2020/09/01 22:11:10 packer: 2020/09/01 22:11:10 Started Qemu. Pid: 4721
2020/09/01 22:11:10 packer: 2020/09/01 22:11:10 Qemu stdout: QEMU 4.2.0 monitor - type 'help' for more information
2020/09/01 22:11:10 packer: 2020/09/01 22:11:10 Qemu stdout: (qemu) char device redirected to /dev/pts/7 (label serial0)
==> ubuntu-aarch64: Waiting 10s for boot...
==> ubuntu-aarch64: Connecting to VM via VNC (127.0.0.1:5908)
==> ubuntu-aarch64: Typing the boot command over VNC...
2020/09/01 22:11:22 packer: 2020/09/01 22:11:22 Connected to VNC desktop: QEMU (rootfs.qcow2)
==> ubuntu-aarch64: Using ssh communicator to connect: 127.0.0.1
==> ubuntu-aarch64: Waiting for SSH to become available...
2020/09/01 22:11:22 packer: 2020/09/01 22:11:22 [INFO] Waiting for SSH, up to timeout: 1h0m0s
2020/09/01 22:11:22 packer: 2020/09/01 22:11:22 [INFO] Attempting SSH connection...
2020/09/01 22:11:22 packer: 2020/09/01 22:11:22 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:11:22 packer: 2020/09/01 22:11:22 [DEBUG] handshaking with SSH
2020/09/01 22:12:22 packer: 2020/09/01 22:12:22 [DEBUG] SSH handshake err: Timeout during SSH handshake
2020/09/01 22:12:29 packer: 2020/09/01 22:12:29 [INFO] Attempting SSH connection...
2020/09/01 22:12:29 packer: 2020/09/01 22:12:29 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:12:29 packer: 2020/09/01 22:12:29 [DEBUG] handshaking with SSH
2020/09/01 22:13:29 packer: 2020/09/01 22:13:29 [DEBUG] SSH handshake err: Timeout during SSH handshake
2020/09/01 22:13:36 packer: 2020/09/01 22:13:36 [INFO] Attempting SSH connection...
2020/09/01 22:13:36 packer: 2020/09/01 22:13:36 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:13:36 packer: 2020/09/01 22:13:36 [DEBUG] handshaking with SSH
2020/09/01 22:13:36 packer: 2020/09/01 22:13:36 [DEBUG] SSH handshake err: ssh: handshake failed: read tcp 127.0.0.1:52738->127.0.0.1:3809: read: connection reset by peer
2020/09/01 22:13:43 packer: 2020/09/01 22:13:43 [INFO] Attempting SSH connection...
2020/09/01 22:13:43 packer: 2020/09/01 22:13:43 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:13:43 packer: 2020/09/01 22:13:43 [DEBUG] handshaking with SSH
2020/09/01 22:13:43 packer: 2020/09/01 22:13:43 [DEBUG] SSH handshake err: ssh: handshake failed: read tcp 127.0.0.1:52746->127.0.0.1:3809: read: connection reset by peer
2020/09/01 22:13:50 packer: 2020/09/01 22:13:50 [INFO] Attempting SSH connection...
2020/09/01 22:13:50 packer: 2020/09/01 22:13:50 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:13:50 packer: 2020/09/01 22:13:50 [DEBUG] handshaking with SSH
2020/09/01 22:13:50 packer: 2020/09/01 22:13:50 [DEBUG] SSH handshake err: ssh: handshake failed: read tcp 127.0.0.1:52750->127.0.0.1:3809: read: connection reset by peer
2020/09/01 22:13:57 packer: 2020/09/01 22:13:57 [INFO] Attempting SSH connection...
2020/09/01 22:13:57 packer: 2020/09/01 22:13:57 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:13:57 packer: 2020/09/01 22:13:57 [DEBUG] handshaking with SSH
2020/09/01 22:13:57 packer: 2020/09/01 22:13:57 [DEBUG] SSH handshake err: ssh: handshake failed: read tcp 127.0.0.1:52754->127.0.0.1:3809: read: connection reset by peer
2020/09/01 22:14:04 packer: 2020/09/01 22:14:04 [INFO] Attempting SSH connection...
2020/09/01 22:14:04 packer: 2020/09/01 22:14:04 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:14:04 packer: 2020/09/01 22:14:04 [DEBUG] handshaking with SSH
2020/09/01 22:14:04 packer: 2020/09/01 22:14:04 [DEBUG] SSH handshake err: ssh: handshake failed: read tcp 127.0.0.1:52760->127.0.0.1:3809: read: connection reset by peer
2020/09/01 22:14:11 packer: 2020/09/01 22:14:11 [INFO] Attempting SSH connection...
2020/09/01 22:14:11 packer: 2020/09/01 22:14:11 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:14:11 packer: 2020/09/01 22:14:11 [DEBUG] handshaking with SSH
2020/09/01 22:14:12 packer: 2020/09/01 22:14:12 [DEBUG] SSH handshake err: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain
2020/09/01 22:14:12 packer: 2020/09/01 22:14:12 [DEBUG] Detected authentication error. Increasing handshake attempts.
2020/09/01 22:14:19 packer: 2020/09/01 22:14:19 [INFO] Attempting SSH connection...
2020/09/01 22:14:19 packer: 2020/09/01 22:14:19 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:14:19 packer: 2020/09/01 22:14:19 [DEBUG] handshaking with SSH
2020/09/01 22:14:19 packer: 2020/09/01 22:14:19 [DEBUG] SSH handshake err: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain
2020/09/01 22:14:19 packer: 2020/09/01 22:14:19 [DEBUG] Detected authentication error. Increasing handshake attempts.
2020/09/01 22:14:26 packer: 2020/09/01 22:14:26 [INFO] Attempting SSH connection...
2020/09/01 22:14:26 packer: 2020/09/01 22:14:26 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:14:26 packer: 2020/09/01 22:14:26 [DEBUG] handshaking with SSH
2020/09/01 22:14:26 packer: 2020/09/01 22:14:26 [DEBUG] SSH handshake err: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain
2020/09/01 22:14:26 packer: 2020/09/01 22:14:26 [DEBUG] Detected authentication error. Increasing handshake attempts.
2020/09/01 22:14:33 packer: 2020/09/01 22:14:33 [INFO] Attempting SSH connection...
2020/09/01 22:14:33 packer: 2020/09/01 22:14:33 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:14:33 packer: 2020/09/01 22:14:33 [DEBUG] handshaking with SSH
2020/09/01 22:14:34 packer: 2020/09/01 22:14:34 [DEBUG] SSH handshake err: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain
2020/09/01 22:14:34 packer: 2020/09/01 22:14:34 [DEBUG] Detected authentication error. Increasing handshake attempts.
2020/09/01 22:14:41 packer: 2020/09/01 22:14:41 [INFO] Attempting SSH connection...
2020/09/01 22:14:41 packer: 2020/09/01 22:14:41 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:14:41 packer: 2020/09/01 22:14:41 [DEBUG] handshaking with SSH
2020/09/01 22:14:41 packer: 2020/09/01 22:14:41 [DEBUG] SSH handshake err: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain
2020/09/01 22:14:41 packer: 2020/09/01 22:14:41 [DEBUG] Detected authentication error. Increasing handshake attempts.
2020/09/01 22:14:48 packer: 2020/09/01 22:14:48 [INFO] Attempting SSH connection...
2020/09/01 22:14:48 packer: 2020/09/01 22:14:48 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:14:48 packer: 2020/09/01 22:14:48 [DEBUG] handshaking with SSH
2020/09/01 22:14:49 packer: 2020/09/01 22:14:49 [DEBUG] SSH handshake err: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain
2020/09/01 22:14:49 packer: 2020/09/01 22:14:49 [DEBUG] Detected authentication error. Increasing handshake attempts.
2020/09/01 22:14:56 packer: 2020/09/01 22:14:56 [INFO] Attempting SSH connection...
2020/09/01 22:14:56 packer: 2020/09/01 22:14:56 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:14:56 packer: 2020/09/01 22:14:56 [DEBUG] handshaking with SSH
2020/09/01 22:14:56 packer: 2020/09/01 22:14:56 [DEBUG] SSH handshake err: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain
2020/09/01 22:14:56 packer: 2020/09/01 22:14:56 [DEBUG] Detected authentication error. Increasing handshake attempts.
2020/09/01 22:15:03 packer: 2020/09/01 22:15:03 [INFO] Attempting SSH connection...
2020/09/01 22:15:03 packer: 2020/09/01 22:15:03 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:15:03 packer: 2020/09/01 22:15:03 [DEBUG] handshaking with SSH
2020/09/01 22:15:04 packer: 2020/09/01 22:15:04 [DEBUG] SSH handshake err: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain
2020/09/01 22:15:04 packer: 2020/09/01 22:15:04 [DEBUG] Detected authentication error. Increasing handshake attempts.
2020/09/01 22:15:11 packer: 2020/09/01 22:15:11 [INFO] Attempting SSH connection...
2020/09/01 22:15:11 packer: 2020/09/01 22:15:11 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:15:11 packer: 2020/09/01 22:15:11 [DEBUG] handshaking with SSH
2020/09/01 22:15:11 packer: 2020/09/01 22:15:11 [DEBUG] SSH handshake err: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain
2020/09/01 22:15:11 packer: 2020/09/01 22:15:11 [DEBUG] Detected authentication error. Increasing handshake attempts.
2020/09/01 22:15:18 packer: 2020/09/01 22:15:18 [INFO] Attempting SSH connection...
2020/09/01 22:15:18 packer: 2020/09/01 22:15:18 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:15:18 packer: 2020/09/01 22:15:18 [DEBUG] handshaking with SSH
2020/09/01 22:15:18 packer: 2020/09/01 22:15:18 [DEBUG] SSH handshake err: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain
2020/09/01 22:15:18 packer: 2020/09/01 22:15:18 [DEBUG] Detected authentication error. Increasing handshake attempts.
2020/09/01 22:15:25 packer: 2020/09/01 22:15:25 [INFO] Attempting SSH connection...
2020/09/01 22:15:25 packer: 2020/09/01 22:15:25 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:15:25 packer: 2020/09/01 22:15:25 [DEBUG] handshaking with SSH
2020/09/01 22:15:26 packer: 2020/09/01 22:15:26 [DEBUG] SSH handshake err: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain
2020/09/01 22:15:26 packer: 2020/09/01 22:15:26 [DEBUG] Detected authentication error. Increasing handshake attempts.
2020/09/01 22:15:33 packer: 2020/09/01 22:15:33 [INFO] Attempting SSH connection...
2020/09/01 22:15:33 packer: 2020/09/01 22:15:33 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:15:33 packer: 2020/09/01 22:15:33 [DEBUG] handshaking with SSH
2020/09/01 22:15:33 packer: 2020/09/01 22:15:33 [DEBUG] SSH handshake err: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain
2020/09/01 22:15:33 packer: 2020/09/01 22:15:33 [DEBUG] Detected authentication error. Increasing handshake attempts.
2020/09/01 22:15:40 packer: 2020/09/01 22:15:40 [INFO] Attempting SSH connection...
2020/09/01 22:15:40 packer: 2020/09/01 22:15:40 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:15:40 packer: 2020/09/01 22:15:40 [DEBUG] handshaking with SSH
2020/09/01 22:15:41 packer: 2020/09/01 22:15:41 [DEBUG] SSH handshake err: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain
2020/09/01 22:15:41 packer: 2020/09/01 22:15:41 [DEBUG] Detected authentication error. Increasing handshake attempts.
2020/09/01 22:15:48 packer: 2020/09/01 22:15:48 [INFO] Attempting SSH connection...
2020/09/01 22:15:48 packer: 2020/09/01 22:15:48 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:15:48 packer: 2020/09/01 22:15:48 [DEBUG] handshaking with SSH
2020/09/01 22:15:48 packer: 2020/09/01 22:15:48 [DEBUG] SSH handshake err: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain
2020/09/01 22:15:48 packer: 2020/09/01 22:15:48 [DEBUG] Detected authentication error. Increasing handshake attempts.
2020/09/01 22:15:55 packer: 2020/09/01 22:15:55 [INFO] Attempting SSH connection...
2020/09/01 22:15:55 packer: 2020/09/01 22:15:55 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:15:55 packer: 2020/09/01 22:15:55 [DEBUG] handshaking with SSH
2020/09/01 22:15:56 packer: 2020/09/01 22:15:56 [DEBUG] SSH handshake err: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain
2020/09/01 22:15:56 packer: 2020/09/01 22:15:56 [DEBUG] Detected authentication error. Increasing handshake attempts.
2020/09/01 22:16:03 packer: 2020/09/01 22:16:03 [INFO] Attempting SSH connection...
2020/09/01 22:16:03 packer: 2020/09/01 22:16:03 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:16:03 packer: 2020/09/01 22:16:03 [DEBUG] handshaking with SSH
2020/09/01 22:16:03 packer: 2020/09/01 22:16:03 [DEBUG] SSH handshake err: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain
2020/09/01 22:16:03 packer: 2020/09/01 22:16:03 [DEBUG] Detected authentication error. Increasing handshake attempts.
2020/09/01 22:16:10 packer: 2020/09/01 22:16:10 [INFO] Attempting SSH connection...
2020/09/01 22:16:10 packer: 2020/09/01 22:16:10 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:16:10 packer: 2020/09/01 22:16:10 [DEBUG] handshaking with SSH
2020/09/01 22:16:10 packer: 2020/09/01 22:16:10 [DEBUG] SSH handshake err: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain
2020/09/01 22:16:10 packer: 2020/09/01 22:16:10 [DEBUG] Detected authentication error. Increasing handshake attempts.
2020/09/01 22:16:17 packer: 2020/09/01 22:16:17 [INFO] Attempting SSH connection...
2020/09/01 22:16:17 packer: 2020/09/01 22:16:17 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:16:17 packer: 2020/09/01 22:16:17 [DEBUG] handshaking with SSH
2020/09/01 22:16:17 packer: 2020/09/01 22:16:17 [DEBUG] SSH handshake err: ssh: handshake failed: read tcp 127.0.0.1:52840->127.0.0.1:3809: read: connection reset by peer
2020/09/01 22:16:24 packer: 2020/09/01 22:16:24 [INFO] Attempting SSH connection...
2020/09/01 22:16:24 packer: 2020/09/01 22:16:24 [DEBUG] reconnecting to TCP connection for SSH
2020/09/01 22:16:24 packer: 2020/09/01 22:16:24 [DEBUG] handshaking with SSH
2020/09/01 22:16:25 packer: 2020/09/01 22:16:25 [DEBUG] handshake complete!
2020/09/01 22:16:25 packer: 2020/09/01 22:16:25 [INFO] no local agent socket, will not connect agent
==> ubuntu-aarch64: Connected to SSH!
2020/09/01 22:16:25 packer: 2020/09/01 22:16:25 Running the provision hook
==> ubuntu-aarch64: Provisioning with shell script: /tmp/packer-shell104553839
2020/09/01 22:16:25 packer: 2020/09/01 22:16:25 Opening /tmp/packer-shell104553839 for reading
2020/09/01 22:16:25 packer: 2020/09/01 22:16:25 [INFO] 37 bytes written for 'uploadData'
2020/09/01 22:16:25 [INFO] 37 bytes written for 'uploadData'
2020/09/01 22:16:25 packer: 2020/09/01 22:16:25 [DEBUG] Opening new ssh session
2020/09/01 22:16:45 packer: 2020/09/01 22:16:45 [DEBUG] Starting remote scp process:  scp -vt /tmp
2020/09/01 22:16:45 packer: 2020/09/01 22:16:45 [DEBUG] Started SCP session, beginning transfers...
2020/09/01 22:16:45 packer: 2020/09/01 22:16:45 [DEBUG] Copying input data into temporary file so we can read the length
2020/09/01 22:16:45 packer: 2020/09/01 22:16:45 [DEBUG] scp: Uploading script_523.sh: perms=C0644 size=37
2020/09/01 22:16:45 packer: 2020/09/01 22:16:45 [DEBUG] SCP session complete, closing stdin pipe.
2020/09/01 22:16:45 packer: 2020/09/01 22:16:45 [DEBUG] Waiting for SSH session to complete.
2020/09/01 22:16:45 packer: 2020/09/01 22:16:45 [DEBUG] scp stderr (length 29): Sink: C0644 37 script_523.sh
2020/09/01 22:16:45 packer: 2020/09/01 22:16:45 [DEBUG] Opening new ssh session
2020/09/01 22:16:45 packer: 2020/09/01 22:16:45 [DEBUG] starting remote command: chmod 0755 /tmp/script_523.sh
2020/09/01 22:16:45 packer: 2020/09/01 22:16:45 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:16:45 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:16:45 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:16:45 packer: 2020/09/01 22:16:45 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:16:45 packer: 2020/09/01 22:16:45 [DEBUG] Opening new ssh session
2020/09/01 22:16:45 packer: 2020/09/01 22:16:45 [DEBUG] starting remote command: chmod +x /tmp/script_523.sh; PACKER_BUILDER_TYPE='qemu' PACKER_BUILD_NAME='ubuntu-aarch64' PACKER_HTTP_ADDR='10.0.2.2:8779' PACKER_HTTP_IP='10.0.2.2' PACKER_HTTP_PORT='8779'  /tmp/script_523.sh
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:16:46 [INFO] 0 bytes written for 'stdout'
2020/09/01 22:16:46 [INFO] 0 bytes written for 'stderr'
2020/09/01 22:16:46 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:16:46 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [INFO] 0 bytes written for 'stdout'
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [INFO] 0 bytes written for 'stderr'
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] Opening new ssh session
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] starting remote command: rm -f /tmp/script_523.sh
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:16:46 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:16:46 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] Opening new ssh session
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] starting remote command: rm -f
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:16:46 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:16:46 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [INFO] RPC client: Communicator ended with: 0
==> ubuntu-aarch64: Uploading ./files/ => /tmp/packer-files/
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] Upload dir './files/' to '/tmp/packer-files/'
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] Opening new ssh session
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] Starting remote scp process:  scp -rvt /tmp/packer-files/
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] Started SCP session, beginning transfers...
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] scp: Uploading resize-disk.service: perms=C0644 size=143
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] scp: Uploading gha-runner.service: perms=C0644 size=194
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] scp: Uploading resize-disk.sh: perms=C0644 size=532
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] scp: Uploading regenerate-ssh-host-keys.sh: perms=C0644 size=186
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] scp: Uploading start-gha-runner.py: perms=C0644 size=1201
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] scp: Uploading regenerate-ssh-host-keys.service: perms=C0644 size=175
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] SCP session complete, closing stdin pipe.
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] Waiting for SSH session to complete.
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] scp stderr (length 232): Sink: C0644 143 resize-disk.service
2020/09/01 22:16:46 packer: Sink: C0644 194 gha-runner.service
2020/09/01 22:16:46 packer: Sink: C0644 532 resize-disk.sh
2020/09/01 22:16:46 packer: Sink: C0644 186 regenerate-ssh-host-keys.sh
2020/09/01 22:16:46 packer: Sink: C0644 1201 start-gha-runner.py
2020/09/01 22:16:46 packer: Sink: C0644 175 regenerate-ssh-host-keys.service
==> ubuntu-aarch64: Provisioning with shell script: ./scripts/install-packages.sh
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 Opening ./scripts/install-packages.sh for reading
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] Opening new ssh session
2020/09/01 22:16:46 [INFO] 401 bytes written for 'uploadData'
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [INFO] 401 bytes written for 'uploadData'
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] Starting remote scp process:  scp -vt /tmp
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] Started SCP session, beginning transfers...
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] Copying input data into temporary file so we can read the length
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] scp: Uploading script_2758.sh: perms=C0644 size=401
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] SCP session complete, closing stdin pipe.
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] Waiting for SSH session to complete.
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] scp stderr (length 31): Sink: C0644 401 script_2758.sh
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] Opening new ssh session
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] starting remote command: chmod 0755 /tmp/script_2758.sh
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:16:46 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:16:46 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] Opening new ssh session
2020/09/01 22:16:46 packer: 2020/09/01 22:16:46 [DEBUG] starting remote command: chmod +x /tmp/script_2758.sh; GIT_SHA='f5dc1708ec64ec55012690dddc63cf729b62a1a8' PACKER_BUILDER_TYPE='qemu' PACKER_BUILD_NAME='ubuntu-aarch64' PACKER_HTTP_ADDR='10.0.2.2:8779' PACKER_HTTP_IP='10.0.2.2' PACKER_HTTP_PORT='8779'  /tmp/script_2758.sh
    ubuntu-aarch64: Hit:1 http://ports.ubuntu.com/ubuntu-ports focal InRelease
    ubuntu-aarch64: Get:2 http://ports.ubuntu.com/ubuntu-ports focal-updates InRelease [111 kB]
    ubuntu-aarch64: Get:3 http://ports.ubuntu.com/ubuntu-ports focal-backports InRelease [98.3 kB]
    ubuntu-aarch64: Get:4 http://ports.ubuntu.com/ubuntu-ports focal-security InRelease [107 kB]
    ubuntu-aarch64: Get:5 http://ports.ubuntu.com/ubuntu-ports focal/universe arm64 Packages [8458 kB]
    ubuntu-aarch64: Get:6 http://ports.ubuntu.com/ubuntu-ports focal/universe Translation-en [5124 kB]
    ubuntu-aarch64: Get:7 http://ports.ubuntu.com/ubuntu-ports focal/universe arm64 c-n-f Metadata [255 kB]
    ubuntu-aarch64: Get:8 http://ports.ubuntu.com/ubuntu-ports focal/multiverse arm64 Packages [114 kB]
    ubuntu-aarch64: Get:9 http://ports.ubuntu.com/ubuntu-ports focal/multiverse Translation-en [104 kB]
    ubuntu-aarch64: Get:10 http://ports.ubuntu.com/ubuntu-ports focal/multiverse arm64 c-n-f Metadata [8024 B]
    ubuntu-aarch64: Get:11 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 Packages [302 kB]
    ubuntu-aarch64: Get:12 http://ports.ubuntu.com/ubuntu-ports focal-updates/main Translation-en [129 kB]
    ubuntu-aarch64: Get:13 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 c-n-f Metadata [8780 B]
    ubuntu-aarch64: Get:14 http://ports.ubuntu.com/ubuntu-ports focal-updates/restricted Translation-en [8340 B]
    ubuntu-aarch64: Get:15 http://ports.ubuntu.com/ubuntu-ports focal-updates/universe arm64 Packages [159 kB]
    ubuntu-aarch64: Get:16 http://ports.ubuntu.com/ubuntu-ports focal-updates/universe Translation-en [82.0 kB]
    ubuntu-aarch64: Get:17 http://ports.ubuntu.com/ubuntu-ports focal-updates/universe arm64 c-n-f Metadata [5216 B]
    ubuntu-aarch64: Get:18 http://ports.ubuntu.com/ubuntu-ports focal-updates/multiverse arm64 Packages [2260 B]
    ubuntu-aarch64: Get:19 http://ports.ubuntu.com/ubuntu-ports focal-updates/multiverse Translation-en [3892 B]
    ubuntu-aarch64: Get:20 http://ports.ubuntu.com/ubuntu-ports focal-updates/multiverse arm64 c-n-f Metadata [116 B]
    ubuntu-aarch64: Get:21 http://ports.ubuntu.com/ubuntu-ports focal-backports/main arm64 c-n-f Metadata [112 B]
    ubuntu-aarch64: Get:22 http://ports.ubuntu.com/ubuntu-ports focal-backports/restricted arm64 c-n-f Metadata [116 B]
    ubuntu-aarch64: Get:23 http://ports.ubuntu.com/ubuntu-ports focal-backports/universe arm64 Packages [3088 B]
    ubuntu-aarch64: Get:24 http://ports.ubuntu.com/ubuntu-ports focal-backports/universe Translation-en [1448 B]
    ubuntu-aarch64: Get:25 http://ports.ubuntu.com/ubuntu-ports focal-backports/universe arm64 c-n-f Metadata [224 B]
    ubuntu-aarch64: Get:26 http://ports.ubuntu.com/ubuntu-ports focal-backports/multiverse arm64 c-n-f Metadata [116 B]
    ubuntu-aarch64: Get:27 http://ports.ubuntu.com/ubuntu-ports focal-security/main arm64 Packages [135 kB]
    ubuntu-aarch64: Get:28 http://ports.ubuntu.com/ubuntu-ports focal-security/main Translation-en [61.7 kB]
    ubuntu-aarch64: Get:29 http://ports.ubuntu.com/ubuntu-ports focal-security/main arm64 c-n-f Metadata [4388 B]
    ubuntu-aarch64: Get:30 http://ports.ubuntu.com/ubuntu-ports focal-security/restricted Translation-en [8312 B]
    ubuntu-aarch64: Get:31 http://ports.ubuntu.com/ubuntu-ports focal-security/universe arm64 Packages [52.0 kB]
    ubuntu-aarch64: Get:32 http://ports.ubuntu.com/ubuntu-ports focal-security/universe Translation-en [28.4 kB]
    ubuntu-aarch64: Get:33 http://ports.ubuntu.com/ubuntu-ports focal-security/universe arm64 c-n-f Metadata [2152 B]
    ubuntu-aarch64: Get:34 http://ports.ubuntu.com/ubuntu-ports focal-security/multiverse Translation-en [540 B]
    ubuntu-aarch64: Get:35 http://ports.ubuntu.com/ubuntu-ports focal-security/multiverse arm64 c-n-f Metadata [116 B]
    ubuntu-aarch64: Fetched 15.4 MB in 25s (619 kB/s)
    ubuntu-aarch64: Reading package lists...
    ubuntu-aarch64: Reading package lists...
    ubuntu-aarch64: Building dependency tree...
    ubuntu-aarch64: Reading state information...
    ubuntu-aarch64: Calculating upgrade...
    ubuntu-aarch64: The following packages have been kept back:
    ubuntu-aarch64:   linux-headers-generic linux-headers-virtual linux-image-virtual
    ubuntu-aarch64:   linux-virtual
    ubuntu-aarch64: The following packages will be upgraded:
    ubuntu-aarch64:   alsa-ucm-conf apport bcache-tools bind9-dnsutils bind9-host bind9-libs curl
    ubuntu-aarch64:   grub-common grub-efi-arm64 grub-efi-arm64-bin grub2-common libasound2
    ubuntu-aarch64:   libasound2-data libcurl3-gnutls libcurl4 libdns-export1109 libisc-export1105
    ubuntu-aarch64:   liblzma5 libpam-modules libpam-modules-bin libpam-runtime libpam0g
    ubuntu-aarch64:   python3-apport python3-distupgrade python3-problem-report
    ubuntu-aarch64:   python3-software-properties rsyslog software-properties-common sudo tmux
    ubuntu-aarch64:   ubuntu-release-upgrader-core unattended-upgrades xz-utils
    ubuntu-aarch64: 33 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
    ubuntu-aarch64: Need to get 8150 kB of archives.
    ubuntu-aarch64: After this operation, 89.1 kB of additional disk space will be used.
    ubuntu-aarch64: Get:1 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 libpam0g arm64 1.3.1-5ubuntu4.1 [53.9 kB]
    ubuntu-aarch64: Get:2 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 libpam-modules-bin arm64 1.3.1-5ubuntu4.1 [35.9 kB]
    ubuntu-aarch64: Get:3 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 libpam-modules arm64 1.3.1-5ubuntu4.1 [242 kB]
    ubuntu-aarch64: Get:4 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 rsyslog arm64 8.2001.0-1ubuntu1.1 [403 kB]
    ubuntu-aarch64: Get:5 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 liblzma5 arm64 5.2.4-1ubuntu1 [87.9 kB]
    ubuntu-aarch64: Get:6 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 libpam-runtime all 1.3.1-5ubuntu4.1 [37.3 kB]
    ubuntu-aarch64: Get:7 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 libisc-export1105 arm64 1:9.11.16+dfsg-3~ubuntu1 [159 kB]
    ubuntu-aarch64: Get:8 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 libdns-export1109 arm64 1:9.11.16+dfsg-3~ubuntu1 [683 kB]
    ubuntu-aarch64: Get:9 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 sudo arm64 1.8.31-1ubuntu1.1 [473 kB]
    ubuntu-aarch64: Get:10 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 xz-utils arm64 5.2.4-1ubuntu1 [81.2 kB]
    ubuntu-aarch64: Get:11 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 bind9-dnsutils arm64 1:9.16.1-0ubuntu2.3 [129 kB]
    ubuntu-aarch64: Get:12 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 bind9-libs arm64 1:9.16.1-0ubuntu2.3 [1001 kB]
    ubuntu-aarch64: Get:13 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 bind9-host arm64 1:9.16.1-0ubuntu2.3 [41.3 kB]
    ubuntu-aarch64: Get:14 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 ubuntu-release-upgrader-core all 1:20.04.24 [23.7 kB]
    ubuntu-aarch64: Get:15 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 python3-distupgrade all 1:20.04.24 [103 kB]
    ubuntu-aarch64: Get:16 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 alsa-ucm-conf all 1.2.2-1ubuntu0.2 [24.8 kB]
    ubuntu-aarch64: Get:17 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 grub-efi-arm64 arm64 2.04-1ubuntu26.3 [46.6 kB]
    ubuntu-aarch64: Get:18 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 grub2-common arm64 2.04-1ubuntu26.3 [568 kB]
    ubuntu-aarch64: Get:19 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 grub-efi-arm64-bin arm64 2.04-1ubuntu26.3 [601 kB]
    ubuntu-aarch64: Get:20 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 grub-common arm64 2.04-1ubuntu26.3 [1855 kB]
    ubuntu-aarch64: Get:21 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 python3-problem-report all 2.20.11-0ubuntu27.8 [9744 B]
    ubuntu-aarch64: Get:22 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 python3-apport all 2.20.11-0ubuntu27.8 [84.3 kB]
    ubuntu-aarch64: Get:23 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 apport all 2.20.11-0ubuntu27.8 [128 kB]
    ubuntu-aarch64: Get:24 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 bcache-tools arm64 1.0.8-3ubuntu0.1 [19.2 kB]
    ubuntu-aarch64: Get:25 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 curl arm64 7.68.0-1ubuntu2.2 [156 kB]
    ubuntu-aarch64: Get:26 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 libcurl4 arm64 7.68.0-1ubuntu2.2 [213 kB]
    ubuntu-aarch64: Get:27 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 libasound2 arm64 1.2.2-2.1ubuntu2 [304 kB]
    ubuntu-aarch64: Get:28 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 libasound2-data all 1.2.2-2.1ubuntu2 [20.1 kB]
    ubuntu-aarch64: Get:29 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 libcurl3-gnutls arm64 7.68.0-1ubuntu2.2 [211 kB]
    ubuntu-aarch64: Get:30 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 software-properties-common all 0.98.9.2 [10.6 kB]
    ubuntu-aarch64: Get:31 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 python3-software-properties all 0.98.9.2 [25.2 kB]
    ubuntu-aarch64: Get:32 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 tmux arm64 3.0a-2ubuntu0.1 [269 kB]
    ubuntu-aarch64: Get:33 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 unattended-upgrades all 2.3ubuntu0.1 [48.7 kB]
    ubuntu-aarch64: debconf: unable to initialize frontend: Dialog
    ubuntu-aarch64: debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
    ubuntu-aarch64: debconf: falling back to frontend: Readline
    ubuntu-aarch64: debconf: unable to initialize frontend: Readline
    ubuntu-aarch64: debconf: (This frontend requires a controlling tty.)
    ubuntu-aarch64: debconf: falling back to frontend: Teletype
    ubuntu-aarch64: dpkg-preconfigure: unable to re-open stdin:
    ubuntu-aarch64: Fetched 8150 kB in 4s (2093 kB/s)
    ubuntu-aarch64: (Reading database ... 64234 files and directories currently installed.)
    ubuntu-aarch64: Preparing to unpack .../libpam0g_1.3.1-5ubuntu4.1_arm64.deb ...
    ubuntu-aarch64: Unpacking libpam0g:arm64 (1.3.1-5ubuntu4.1) over (1.3.1-5ubuntu4) ...
    ubuntu-aarch64: Setting up libpam0g:arm64 (1.3.1-5ubuntu4.1) ...
    ubuntu-aarch64: debconf: unable to initialize frontend: Dialog
    ubuntu-aarch64: debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
    ubuntu-aarch64: debconf: falling back to frontend: Readline
    ubuntu-aarch64: (Reading database ... 64234 files and directories currently installed.)
    ubuntu-aarch64: Preparing to unpack .../libpam-modules-bin_1.3.1-5ubuntu4.1_arm64.deb ...
    ubuntu-aarch64: Unpacking libpam-modules-bin (1.3.1-5ubuntu4.1) over (1.3.1-5ubuntu4) ...
    ubuntu-aarch64: Setting up libpam-modules-bin (1.3.1-5ubuntu4.1) ...
    ubuntu-aarch64: (Reading database ... 64234 files and directories currently installed.)
    ubuntu-aarch64: Preparing to unpack .../libpam-modules_1.3.1-5ubuntu4.1_arm64.deb ...
    ubuntu-aarch64: debconf: unable to initialize frontend: Dialog
    ubuntu-aarch64: debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
    ubuntu-aarch64: debconf: falling back to frontend: Readline
    ubuntu-aarch64: Unpacking libpam-modules:arm64 (1.3.1-5ubuntu4.1) over (1.3.1-5ubuntu4) ...
    ubuntu-aarch64: Setting up libpam-modules:arm64 (1.3.1-5ubuntu4.1) ...
    ubuntu-aarch64: (Reading database ... 64234 files and directories currently installed.)
    ubuntu-aarch64: Preparing to unpack .../rsyslog_8.2001.0-1ubuntu1.1_arm64.deb ...
    ubuntu-aarch64: Unpacking rsyslog (8.2001.0-1ubuntu1.1) over (8.2001.0-1ubuntu1) ...
    ubuntu-aarch64: Preparing to unpack .../liblzma5_5.2.4-1ubuntu1_arm64.deb ...
    ubuntu-aarch64: Unpacking liblzma5:arm64 (5.2.4-1ubuntu1) over (5.2.4-1) ...
    ubuntu-aarch64: Setting up liblzma5:arm64 (5.2.4-1ubuntu1) ...
    ubuntu-aarch64: (Reading database ... 64234 files and directories currently installed.)
    ubuntu-aarch64: Preparing to unpack .../libpam-runtime_1.3.1-5ubuntu4.1_all.deb ...
    ubuntu-aarch64: Unpacking libpam-runtime (1.3.1-5ubuntu4.1) over (1.3.1-5ubuntu4) ...
    ubuntu-aarch64: Setting up libpam-runtime (1.3.1-5ubuntu4.1) ...
    ubuntu-aarch64: debconf: unable to initialize frontend: Dialog
    ubuntu-aarch64: debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
    ubuntu-aarch64: debconf: falling back to frontend: Readline
    ubuntu-aarch64: (Reading database ... 64234 files and directories currently installed.)
    ubuntu-aarch64: Preparing to unpack .../00-libisc-export1105_1%3a9.11.16+dfsg-3~ubuntu1_arm64.deb ...
    ubuntu-aarch64: Unpacking libisc-export1105:arm64 (1:9.11.16+dfsg-3~ubuntu1) over (1:9.11.16+dfsg-3~build1) ...
    ubuntu-aarch64: Preparing to unpack .../01-libdns-export1109_1%3a9.11.16+dfsg-3~ubuntu1_arm64.deb ...
    ubuntu-aarch64: Unpacking libdns-export1109 (1:9.11.16+dfsg-3~ubuntu1) over (1:9.11.16+dfsg-3~build1) ...
    ubuntu-aarch64: Preparing to unpack .../02-sudo_1.8.31-1ubuntu1.1_arm64.deb ...
    ubuntu-aarch64: Unpacking sudo (1.8.31-1ubuntu1.1) over (1.8.31-1ubuntu1) ...
    ubuntu-aarch64: Preparing to unpack .../03-xz-utils_5.2.4-1ubuntu1_arm64.deb ...
    ubuntu-aarch64: Unpacking xz-utils (5.2.4-1ubuntu1) over (5.2.4-1) ...
    ubuntu-aarch64: Preparing to unpack .../04-bind9-dnsutils_1%3a9.16.1-0ubuntu2.3_arm64.deb ...
    ubuntu-aarch64: Unpacking bind9-dnsutils (1:9.16.1-0ubuntu2.3) over (1:9.16.1-0ubuntu2.2) ...
    ubuntu-aarch64: Preparing to unpack .../05-bind9-libs_1%3a9.16.1-0ubuntu2.3_arm64.deb ...
    ubuntu-aarch64: Unpacking bind9-libs:arm64 (1:9.16.1-0ubuntu2.3) over (1:9.16.1-0ubuntu2.2) ...
    ubuntu-aarch64: Preparing to unpack .../06-bind9-host_1%3a9.16.1-0ubuntu2.3_arm64.deb ...
    ubuntu-aarch64: Unpacking bind9-host (1:9.16.1-0ubuntu2.3) over (1:9.16.1-0ubuntu2.2) ...
    ubuntu-aarch64: Preparing to unpack .../07-ubuntu-release-upgrader-core_1%3a20.04.24_all.deb ...
    ubuntu-aarch64: Unpacking ubuntu-release-upgrader-core (1:20.04.24) over (1:20.04.23) ...
    ubuntu-aarch64: Preparing to unpack .../08-python3-distupgrade_1%3a20.04.24_all.deb ...
    ubuntu-aarch64: Unpacking python3-distupgrade (1:20.04.24) over (1:20.04.23) ...
    ubuntu-aarch64: Preparing to unpack .../09-alsa-ucm-conf_1.2.2-1ubuntu0.2_all.deb ...
    ubuntu-aarch64: Unpacking alsa-ucm-conf (1.2.2-1ubuntu0.2) over (1.2.2-1ubuntu0.1) ...
    ubuntu-aarch64: Preparing to unpack .../10-grub-efi-arm64_2.04-1ubuntu26.3_arm64.deb ...
    ubuntu-aarch64: Unpacking grub-efi-arm64 (2.04-1ubuntu26.3) over (2.04-1ubuntu26.2) ...
    ubuntu-aarch64: Preparing to unpack .../11-grub2-common_2.04-1ubuntu26.3_arm64.deb ...
    ubuntu-aarch64: Unpacking grub2-common (2.04-1ubuntu26.3) over (2.04-1ubuntu26.2) ...
    ubuntu-aarch64: Preparing to unpack .../12-grub-efi-arm64-bin_2.04-1ubuntu26.3_arm64.deb ...
    ubuntu-aarch64: Unpacking grub-efi-arm64-bin (2.04-1ubuntu26.3) over (2.04-1ubuntu26.2) ...
    ubuntu-aarch64: Preparing to unpack .../13-grub-common_2.04-1ubuntu26.3_arm64.deb ...
    ubuntu-aarch64: Unpacking grub-common (2.04-1ubuntu26.3) over (2.04-1ubuntu26.2) ...
    ubuntu-aarch64: Preparing to unpack .../14-python3-problem-report_2.20.11-0ubuntu27.8_all.deb ...
    ubuntu-aarch64: Unpacking python3-problem-report (2.20.11-0ubuntu27.8) over (2.20.11-0ubuntu27.6) ...
    ubuntu-aarch64: Preparing to unpack .../15-python3-apport_2.20.11-0ubuntu27.8_all.deb ...
    ubuntu-aarch64: Unpacking python3-apport (2.20.11-0ubuntu27.8) over (2.20.11-0ubuntu27.6) ...
    ubuntu-aarch64: Preparing to unpack .../16-apport_2.20.11-0ubuntu27.8_all.deb ...
    ubuntu-aarch64: Unpacking apport (2.20.11-0ubuntu27.8) over (2.20.11-0ubuntu27.6) ...
    ubuntu-aarch64: Preparing to unpack .../17-bcache-tools_1.0.8-3ubuntu0.1_arm64.deb ...
    ubuntu-aarch64: Unpacking bcache-tools (1.0.8-3ubuntu0.1) over (1.0.8-3) ...
    ubuntu-aarch64: Preparing to unpack .../18-curl_7.68.0-1ubuntu2.2_arm64.deb ...
    ubuntu-aarch64: Unpacking curl (7.68.0-1ubuntu2.2) over (7.68.0-1ubuntu2.1) ...
    ubuntu-aarch64: Preparing to unpack .../19-libcurl4_7.68.0-1ubuntu2.2_arm64.deb ...
    ubuntu-aarch64: Unpacking libcurl4:arm64 (7.68.0-1ubuntu2.2) over (7.68.0-1ubuntu2.1) ...
    ubuntu-aarch64: Preparing to unpack .../20-libasound2_1.2.2-2.1ubuntu2_arm64.deb ...
    ubuntu-aarch64: Unpacking libasound2:arm64 (1.2.2-2.1ubuntu2) over (1.2.2-2.1ubuntu1) ...
    ubuntu-aarch64: Preparing to unpack .../21-libasound2-data_1.2.2-2.1ubuntu2_all.deb ...
    ubuntu-aarch64: Unpacking libasound2-data (1.2.2-2.1ubuntu2) over (1.2.2-2.1ubuntu1) ...
    ubuntu-aarch64: Preparing to unpack .../22-libcurl3-gnutls_7.68.0-1ubuntu2.2_arm64.deb ...
    ubuntu-aarch64: Unpacking libcurl3-gnutls:arm64 (7.68.0-1ubuntu2.2) over (7.68.0-1ubuntu2.1) ...
    ubuntu-aarch64: Preparing to unpack .../23-software-properties-common_0.98.9.2_all.deb ...
    ubuntu-aarch64: Unpacking software-properties-common (0.98.9.2) over (0.98.9.1) ...
    ubuntu-aarch64: Preparing to unpack .../24-python3-software-properties_0.98.9.2_all.deb ...
    ubuntu-aarch64: Unpacking python3-software-properties (0.98.9.2) over (0.98.9.1) ...
    ubuntu-aarch64: Preparing to unpack .../25-tmux_3.0a-2ubuntu0.1_arm64.deb ...
    ubuntu-aarch64: Unpacking tmux (3.0a-2ubuntu0.1) over (3.0a-2) ...
    ubuntu-aarch64: Preparing to unpack .../26-unattended-upgrades_2.3ubuntu0.1_all.deb ...
    ubuntu-aarch64: Unpacking unattended-upgrades (2.3ubuntu0.1) over (2.3) ...
    ubuntu-aarch64: Setting up bcache-tools (1.0.8-3ubuntu0.1) ...
    ubuntu-aarch64: Setting up bind9-libs:arm64 (1:9.16.1-0ubuntu2.3) ...
    ubuntu-aarch64: Setting up alsa-ucm-conf (1.2.2-1ubuntu0.2) ...
    ubuntu-aarch64: Setting up python3-problem-report (2.20.11-0ubuntu27.8) ...
    ubuntu-aarch64: Setting up rsyslog (8.2001.0-1ubuntu1.1) ...
    ubuntu-aarch64: The user `syslog' is already a member of `adm'.
    ubuntu-aarch64: Adding user `syslog' to group `tty' ...
    ubuntu-aarch64: Adding user syslog to group tty
    ubuntu-aarch64: Done.
    ubuntu-aarch64: debconf: unable to initialize frontend: Dialog
    ubuntu-aarch64: debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
    ubuntu-aarch64: debconf: falling back to frontend: Readline
    ubuntu-aarch64: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
    ubuntu-aarch64: Setting up libcurl3-gnutls:arm64 (7.68.0-1ubuntu2.2) ...
    ubuntu-aarch64: Setting up python3-distupgrade (1:20.04.24) ...
    ubuntu-aarch64: Setting up python3-apport (2.20.11-0ubuntu27.8) ...
    ubuntu-aarch64: Setting up grub-common (2.04-1ubuntu26.3) ...
    ubuntu-aarch64: Installing new version of config file /etc/grub.d/10_linux ...
    ubuntu-aarch64: Installing new version of config file /etc/grub.d/10_linux_zfs ...
    ubuntu-aarch64: update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
    ubuntu-aarch64: Setting up libasound2-data (1.2.2-2.1ubuntu2) ...
    ubuntu-aarch64: Setting up libisc-export1105:arm64 (1:9.11.16+dfsg-3~ubuntu1) ...
    ubuntu-aarch64: Setting up python3-software-properties (0.98.9.2) ...
    ubuntu-aarch64: Setting up xz-utils (5.2.4-1ubuntu1) ...
    ubuntu-aarch64: Setting up ubuntu-release-upgrader-core (1:20.04.24) ...
    ubuntu-aarch64: Setting up sudo (1.8.31-1ubuntu1.1) ...
    ubuntu-aarch64: Setting up grub-efi-arm64-bin (2.04-1ubuntu26.3) ...
    ubuntu-aarch64: Setting up libasound2:arm64 (1.2.2-2.1ubuntu2) ...
    ubuntu-aarch64: Setting up libcurl4:arm64 (7.68.0-1ubuntu2.2) ...
    ubuntu-aarch64: Setting up curl (7.68.0-1ubuntu2.2) ...
    ubuntu-aarch64: Setting up bind9-host (1:9.16.1-0ubuntu2.3) ...
    ubuntu-aarch64: Setting up tmux (3.0a-2ubuntu0.1) ...
    ubuntu-aarch64: Setting up grub2-common (2.04-1ubuntu26.3) ...
    ubuntu-aarch64: Setting up libdns-export1109 (1:9.11.16+dfsg-3~ubuntu1) ...
    ubuntu-aarch64: Setting up software-properties-common (0.98.9.2) ...
    ubuntu-aarch64: Setting up apport (2.20.11-0ubuntu27.8) ...
    ubuntu-aarch64: apport-autoreport.service is a disabled or a static unit, not starting it.
    ubuntu-aarch64: Setting up unattended-upgrades (2.3ubuntu0.1) ...
    ubuntu-aarch64: debconf: unable to initialize frontend: Dialog
    ubuntu-aarch64: debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
    ubuntu-aarch64: debconf: falling back to frontend: Readline
    ubuntu-aarch64: Setting up bind9-dnsutils (1:9.16.1-0ubuntu2.3) ...
    ubuntu-aarch64: Setting up grub-efi-arm64 (2.04-1ubuntu26.3) ...
    ubuntu-aarch64: debconf: unable to initialize frontend: Dialog
    ubuntu-aarch64: debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
    ubuntu-aarch64: debconf: falling back to frontend: Readline
    ubuntu-aarch64: Trying to migrate /boot/efi into esp config
    ubuntu-aarch64: Installing grub to /boot/efi.
    ubuntu-aarch64: Installing for arm64-efi platform.
    ubuntu-aarch64: Installation finished. No error reported.
    ubuntu-aarch64: Sourcing file `/etc/default/grub'
    ubuntu-aarch64: Sourcing file `/etc/default/grub.d/40-force-partuuid.cfg'
    ubuntu-aarch64: Sourcing file `/etc/default/grub.d/init-select.cfg'
    ubuntu-aarch64: Generating grub configuration file ...
    ubuntu-aarch64: Found linux image: /boot/vmlinuz-5.4.0-42-generic
    ubuntu-aarch64: Found initrd image: /boot/initrd.img-5.4.0-42-generic
    ubuntu-aarch64: Adding boot menu entry for UEFI Firmware Settings
    ubuntu-aarch64: done
    ubuntu-aarch64: Processing triggers for libc-bin (2.31-0ubuntu9) ...
    ubuntu-aarch64: Processing triggers for systemd (245.4-4ubuntu3.2) ...
    ubuntu-aarch64: Processing triggers for man-db (2.9.1-1) ...
    ubuntu-aarch64: Processing triggers for dbus (1.12.16-2ubuntu2.1) ...
    ubuntu-aarch64: Processing triggers for install-info (6.7.0.dfsg.2-5) ...
    ubuntu-aarch64: Processing triggers for initramfs-tools (0.136ubuntu6.2) ...
    ubuntu-aarch64: update-initramfs: Generating /boot/initrd.img-5.4.0-42-generic
    ubuntu-aarch64: Unsupported platform on EFI system, doing nothing.
    ubuntu-aarch64: Reading package lists...
    ubuntu-aarch64: Building dependency tree...
    ubuntu-aarch64: Reading state information...
    ubuntu-aarch64: The following additional packages will be installed:
    ubuntu-aarch64:   bridge-utils build-essential cgroupfs-mount containerd cpp cpp-9
    ubuntu-aarch64:   dns-root-data dnsmasq-base dpkg-dev fakeroot g++ g++-9 gcc gcc-9 gcc-9-base
    ubuntu-aarch64:   libalgorithm-diff-perl libalgorithm-diff-xs-perl libalgorithm-merge-perl
    ubuntu-aarch64:   libasan5 libatomic1 libc-dev-bin libc6-dev libcc1-0 libcrypt-dev
    ubuntu-aarch64:   libdpkg-perl libexpat1-dev libfakeroot libfile-fcntllock-perl libgcc-9-dev
    ubuntu-aarch64:   libgomp1 libidn11 libisl22 libitm1 libjq1 liblsan0 libmpc3 libonig5
    ubuntu-aarch64:   libpython2-stdlib libpython2.7-minimal libpython2.7-stdlib libpython3-dev
    ubuntu-aarch64:   libpython3.8-dev libstdc++-9-dev libtsan0 libubsan1 linux-libc-dev make
    ubuntu-aarch64:   manpages-dev pigz python-pip-whl python2 python2-minimal python2.7
    ubuntu-aarch64:   python2.7-minimal python3-dev python3-wheel python3.8-dev runc ubuntu-fan
    ubuntu-aarch64:   zlib1g-dev
    ubuntu-aarch64: Suggested packages:
    ubuntu-aarch64:   ifupdown cpp-doc gcc-9-locales aufs-tools debootstrap docker-doc rinse
    ubuntu-aarch64:   zfs-fuse | zfsutils debian-keyring gcc-9-doc gcc-multilib autoconf automake
    ubuntu-aarch64:   libtool flex bison gdb gcc-doc glibc-doc bzr libstdc++-9-doc make-doc
    ubuntu-aarch64:   python2-doc python-tk python2.7-doc binfmt-support
    ubuntu-aarch64: The following NEW packages will be installed:
    ubuntu-aarch64:   acpid bridge-utils build-essential cgroupfs-mount containerd cpp cpp-9
    ubuntu-aarch64:   dns-root-data dnsmasq-base docker.io dpkg-dev fakeroot g++ g++-9 gcc gcc-9
    ubuntu-aarch64:   gcc-9-base jq libalgorithm-diff-perl libalgorithm-diff-xs-perl
    ubuntu-aarch64:   libalgorithm-merge-perl libasan5 libatomic1 libc-dev-bin libc6-dev libcc1-0
    ubuntu-aarch64:   libcrypt-dev libdpkg-perl libexpat1-dev libfakeroot libfile-fcntllock-perl
    ubuntu-aarch64:   libgcc-9-dev libgomp1 libidn11 libisl22 libitm1 libjq1 liblsan0 libmpc3
    ubuntu-aarch64:   libonig5 libpython2-stdlib libpython2.7-minimal libpython2.7-stdlib
    ubuntu-aarch64:   libpython3-dev libpython3.8-dev libstdc++-9-dev libtsan0 libubsan1
    ubuntu-aarch64:   linux-libc-dev make manpages-dev pigz python-is-python2 python-pip-whl
    ubuntu-aarch64:   python2 python2-minimal python2.7 python2.7-minimal python3-dev python3-pip
    ubuntu-aarch64:   python3-wheel python3.8-dev runc ubuntu-fan zlib1g-dev
    ubuntu-aarch64: 0 upgraded, 65 newly installed, 0 to remove and 4 not upgraded.
    ubuntu-aarch64: Need to get 89.6 MB of archives.
    ubuntu-aarch64: After this operation, 443 MB of additional disk space will be used.
    ubuntu-aarch64: Get:1 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 acpid arm64 1:2.0.32-1ubuntu1 [37.1 kB]
    ubuntu-aarch64: Get:2 http://ports.ubuntu.com/ubuntu-ports focal/universe arm64 libpython2.7-minimal arm64 2.7.18~rc1-2 [335 kB]
    ubuntu-aarch64: Get:3 http://ports.ubuntu.com/ubuntu-ports focal/universe arm64 python2.7-minimal arm64 2.7.18~rc1-2 [1226 kB]
    ubuntu-aarch64: Get:4 http://ports.ubuntu.com/ubuntu-ports focal/universe arm64 python2-minimal arm64 2.7.17-2ubuntu4 [27.5 kB]
    ubuntu-aarch64: Get:5 http://ports.ubuntu.com/ubuntu-ports focal/universe arm64 libpython2.7-stdlib arm64 2.7.18~rc1-2 [1866 kB]
    ubuntu-aarch64: Get:6 http://ports.ubuntu.com/ubuntu-ports focal/universe arm64 python2.7 arm64 2.7.18~rc1-2 [248 kB]
    ubuntu-aarch64: Get:7 http://ports.ubuntu.com/ubuntu-ports focal/universe arm64 libpython2-stdlib arm64 2.7.17-2ubuntu4 [7072 B]
    ubuntu-aarch64: Get:8 http://ports.ubuntu.com/ubuntu-ports focal/universe arm64 python2 arm64 2.7.17-2ubuntu4 [26.5 kB]
    ubuntu-aarch64: Get:9 http://ports.ubuntu.com/ubuntu-ports focal/universe arm64 pigz arm64 2.4-1 [47.8 kB]
    ubuntu-aarch64: Get:10 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 bridge-utils arm64 1.6-2ubuntu1 [30.6 kB]
    ubuntu-aarch64: Get:11 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libc-dev-bin arm64 2.31-0ubuntu9 [64.1 kB]
    ubuntu-aarch64: Get:12 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 linux-libc-dev arm64 5.4.0-45.49 [1117 kB]
    ubuntu-aarch64: Get:13 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libcrypt-dev arm64 1:4.4.10-10ubuntu4 [111 kB]
    ubuntu-aarch64: Get:14 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libc6-dev arm64 2.31-0ubuntu9 [2058 kB]
    ubuntu-aarch64: Get:15 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 gcc-9-base arm64 9.3.0-10ubuntu2 [19.3 kB]
    ubuntu-aarch64: Get:16 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libisl22 arm64 0.22.1-1 [537 kB]
    ubuntu-aarch64: Get:17 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libmpc3 arm64 1.1.0-1 [37.2 kB]
    ubuntu-aarch64: Get:18 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 cpp-9 arm64 9.3.0-10ubuntu2 [5966 kB]
    ubuntu-aarch64: Get:19 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 cpp arm64 4:9.3.0-1ubuntu2 [27.6 kB]
    ubuntu-aarch64: Get:20 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libcc1-0 arm64 10-20200411-0ubuntu1 [37.0 kB]
    ubuntu-aarch64: Get:21 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libgomp1 arm64 10-20200411-0ubuntu1 [92.0 kB]
    ubuntu-aarch64: Get:22 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libitm1 arm64 10-20200411-0ubuntu1 [23.8 kB]
    ubuntu-aarch64: Get:23 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libatomic1 arm64 10-20200411-0ubuntu1 [9188 B]
    ubuntu-aarch64: Get:24 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libasan5 arm64 9.3.0-10ubuntu2 [365 kB]
    ubuntu-aarch64: Get:25 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 liblsan0 arm64 10-20200411-0ubuntu1 [130 kB]
    ubuntu-aarch64: Get:26 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libtsan0 arm64 10-20200411-0ubuntu1 [302 kB]
    ubuntu-aarch64: Get:27 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libubsan1 arm64 10-20200411-0ubuntu1 [126 kB]
    ubuntu-aarch64: Get:28 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libgcc-9-dev arm64 9.3.0-10ubuntu2 [908 kB]
    ubuntu-aarch64: Get:29 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 gcc-9 arm64 9.3.0-10ubuntu2 [6690 kB]
    ubuntu-aarch64: Get:30 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 gcc arm64 4:9.3.0-1ubuntu2 [5228 B]
    ubuntu-aarch64: Get:31 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libstdc++-9-dev arm64 9.3.0-10ubuntu2 [1676 kB]
    ubuntu-aarch64: Get:32 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 g++-9 arm64 9.3.0-10ubuntu2 [6818 kB]
    ubuntu-aarch64: Get:33 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 g++ arm64 4:9.3.0-1ubuntu2 [1592 B]
    ubuntu-aarch64: Get:34 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 make arm64 4.2.1-1.2 [154 kB]
    ubuntu-aarch64: Get:35 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libdpkg-perl all 1.19.7ubuntu3 [230 kB]
    ubuntu-aarch64: Get:36 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 dpkg-dev all 1.19.7ubuntu3 [679 kB]
    ubuntu-aarch64: Get:37 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 build-essential arm64 12.8ubuntu1 [4620 B]
    ubuntu-aarch64: Get:38 http://ports.ubuntu.com/ubuntu-ports focal/universe arm64 cgroupfs-mount all 1.4 [6320 B]
    ubuntu-aarch64: Get:39 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 runc arm64 1.0.0~rc10-0ubuntu1 [2249 kB]
    ubuntu-aarch64: Get:40 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 containerd arm64 1.3.3-0ubuntu2 [19.7 MB]
    ubuntu-aarch64: Get:41 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 dns-root-data all 2019052802 [5300 B]
    ubuntu-aarch64: Get:42 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libidn11 arm64 1.33-2.2ubuntu2 [45.3 kB]
    ubuntu-aarch64: Get:43 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 dnsmasq-base arm64 2.80-1.1ubuntu1 [294 kB]
    ubuntu-aarch64: Get:44 http://ports.ubuntu.com/ubuntu-ports focal-updates/universe arm64 docker.io arm64 19.03.8-0ubuntu1.20.04 [25.9 MB]
    ubuntu-aarch64: Get:45 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libfakeroot arm64 1.24-1 [26.0 kB]
    ubuntu-aarch64: Get:46 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 fakeroot arm64 1.24-1 [61.9 kB]
    ubuntu-aarch64: Get:47 http://ports.ubuntu.com/ubuntu-ports focal/universe arm64 libonig5 arm64 6.9.4-1 [134 kB]
    ubuntu-aarch64: Get:48 http://ports.ubuntu.com/ubuntu-ports focal/universe arm64 libjq1 arm64 1.6-1 [107 kB]
    ubuntu-aarch64: Get:49 http://ports.ubuntu.com/ubuntu-ports focal/universe arm64 jq arm64 1.6-1 [49.6 kB]
    ubuntu-aarch64: Get:50 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libalgorithm-diff-perl all 1.19.03-2 [46.6 kB]
    ubuntu-aarch64: Get:51 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libalgorithm-diff-xs-perl arm64 0.04-6 [11.1 kB]
    ubuntu-aarch64: Get:52 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libalgorithm-merge-perl all 0.08-3 [12.0 kB]
    ubuntu-aarch64: Get:53 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libexpat1-dev arm64 2.2.9-1build1 [103 kB]
    ubuntu-aarch64: Get:54 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libfile-fcntllock-perl arm64 0.22-3build4 [33.0 kB]
    ubuntu-aarch64: Get:55 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 libpython3.8-dev arm64 3.8.2-1ubuntu1.2 [3751 kB]
    ubuntu-aarch64: Get:56 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 libpython3-dev arm64 3.8.2-0ubuntu2 [7236 B]
    ubuntu-aarch64: Get:57 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 manpages-dev all 5.05-1 [2266 kB]
    ubuntu-aarch64: Get:58 http://ports.ubuntu.com/ubuntu-ports focal/universe arm64 python-is-python2 all 2.7.17-4 [2496 B]
    ubuntu-aarch64: Get:59 http://ports.ubuntu.com/ubuntu-ports focal/universe arm64 python-pip-whl all 20.0.2-5ubuntu1 [1799 kB]
    ubuntu-aarch64: Get:60 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 zlib1g-dev arm64 1:1.2.11.dfsg-2ubuntu1 [154 kB]
    ubuntu-aarch64: Get:61 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 python3.8-dev arm64 3.8.2-1ubuntu1.2 [515 kB]
    ubuntu-aarch64: Get:62 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 python3-dev arm64 3.8.2-0ubuntu2 [1212 B]
    ubuntu-aarch64: Get:63 http://ports.ubuntu.com/ubuntu-ports focal/universe arm64 python3-wheel all 0.34.2-1 [23.8 kB]
    ubuntu-aarch64: Get:64 http://ports.ubuntu.com/ubuntu-ports focal/universe arm64 python3-pip all 20.0.2-5ubuntu1 [230 kB]
    ubuntu-aarch64: Get:65 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 ubuntu-fan all 0.12.13 [34.5 kB]
    ubuntu-aarch64: debconf: unable to initialize frontend: Dialog
    ubuntu-aarch64: debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
    ubuntu-aarch64: debconf: falling back to frontend: Readline
    ubuntu-aarch64: debconf: unable to initialize frontend: Readline
    ubuntu-aarch64: debconf: (This frontend requires a controlling tty.)
    ubuntu-aarch64: debconf: falling back to frontend: Teletype
    ubuntu-aarch64: dpkg-preconfigure: unable to re-open stdin:
    ubuntu-aarch64: Fetched 89.6 MB in 40s (2241 kB/s)
    ubuntu-aarch64: Selecting previously unselected package acpid.
    ubuntu-aarch64: (Reading database ... 64271 files and directories currently installed.)
    ubuntu-aarch64: Preparing to unpack .../0-acpid_1%3a2.0.32-1ubuntu1_arm64.deb ...
    ubuntu-aarch64: Unpacking acpid (1:2.0.32-1ubuntu1) ...
    ubuntu-aarch64: Selecting previously unselected package libpython2.7-minimal:arm64.
    ubuntu-aarch64: Preparing to unpack .../1-libpython2.7-minimal_2.7.18~rc1-2_arm64.deb ...
    ubuntu-aarch64: Unpacking libpython2.7-minimal:arm64 (2.7.18~rc1-2) ...
    ubuntu-aarch64: Selecting previously unselected package python2.7-minimal.
    ubuntu-aarch64: Preparing to unpack .../2-python2.7-minimal_2.7.18~rc1-2_arm64.deb ...
    ubuntu-aarch64: Unpacking python2.7-minimal (2.7.18~rc1-2) ...
    ubuntu-aarch64: Selecting previously unselected package python2-minimal.
    ubuntu-aarch64: Preparing to unpack .../3-python2-minimal_2.7.17-2ubuntu4_arm64.deb ...
    ubuntu-aarch64: Unpacking python2-minimal (2.7.17-2ubuntu4) ...
    ubuntu-aarch64: Selecting previously unselected package libpython2.7-stdlib:arm64.
    ubuntu-aarch64: Preparing to unpack .../4-libpython2.7-stdlib_2.7.18~rc1-2_arm64.deb ...
    ubuntu-aarch64: Unpacking libpython2.7-stdlib:arm64 (2.7.18~rc1-2) ...
    ubuntu-aarch64: Selecting previously unselected package python2.7.
    ubuntu-aarch64: Preparing to unpack .../5-python2.7_2.7.18~rc1-2_arm64.deb ...
    ubuntu-aarch64: Unpacking python2.7 (2.7.18~rc1-2) ...
    ubuntu-aarch64: Selecting previously unselected package libpython2-stdlib:arm64.
    ubuntu-aarch64: Preparing to unpack .../6-libpython2-stdlib_2.7.17-2ubuntu4_arm64.deb ...
    ubuntu-aarch64: Unpacking libpython2-stdlib:arm64 (2.7.17-2ubuntu4) ...
    ubuntu-aarch64: Setting up libpython2.7-minimal:arm64 (2.7.18~rc1-2) ...
    ubuntu-aarch64: Setting up python2.7-minimal (2.7.18~rc1-2) ...
    ubuntu-aarch64: Linking and byte-compiling packages for runtime python2.7...
    ubuntu-aarch64: Setting up python2-minimal (2.7.17-2ubuntu4) ...
    ubuntu-aarch64: Selecting previously unselected package python2.
    ubuntu-aarch64: (Reading database ... 65041 files and directories currently installed.)
    ubuntu-aarch64: Preparing to unpack .../00-python2_2.7.17-2ubuntu4_arm64.deb ...
    ubuntu-aarch64: Unpacking python2 (2.7.17-2ubuntu4) ...
    ubuntu-aarch64: Selecting previously unselected package pigz.
    ubuntu-aarch64: Preparing to unpack .../01-pigz_2.4-1_arm64.deb ...
    ubuntu-aarch64: Unpacking pigz (2.4-1) ...
    ubuntu-aarch64: Selecting previously unselected package bridge-utils.
    ubuntu-aarch64: Preparing to unpack .../02-bridge-utils_1.6-2ubuntu1_arm64.deb ...
    ubuntu-aarch64: Unpacking bridge-utils (1.6-2ubuntu1) ...
    ubuntu-aarch64: Selecting previously unselected package libc-dev-bin.
    ubuntu-aarch64: Preparing to unpack .../03-libc-dev-bin_2.31-0ubuntu9_arm64.deb ...
    ubuntu-aarch64: Unpacking libc-dev-bin (2.31-0ubuntu9) ...
    ubuntu-aarch64: Selecting previously unselected package linux-libc-dev:arm64.
    ubuntu-aarch64: Preparing to unpack .../04-linux-libc-dev_5.4.0-45.49_arm64.deb ...
    ubuntu-aarch64: Unpacking linux-libc-dev:arm64 (5.4.0-45.49) ...
    ubuntu-aarch64: Selecting previously unselected package libcrypt-dev:arm64.
    ubuntu-aarch64: Preparing to unpack .../05-libcrypt-dev_1%3a4.4.10-10ubuntu4_arm64.deb ...
    ubuntu-aarch64: Unpacking libcrypt-dev:arm64 (1:4.4.10-10ubuntu4) ...
    ubuntu-aarch64: Selecting previously unselected package libc6-dev:arm64.
    ubuntu-aarch64: Preparing to unpack .../06-libc6-dev_2.31-0ubuntu9_arm64.deb ...
    ubuntu-aarch64: Unpacking libc6-dev:arm64 (2.31-0ubuntu9) ...
    ubuntu-aarch64: Selecting previously unselected package gcc-9-base:arm64.
    ubuntu-aarch64: Preparing to unpack .../07-gcc-9-base_9.3.0-10ubuntu2_arm64.deb ...
    ubuntu-aarch64: Unpacking gcc-9-base:arm64 (9.3.0-10ubuntu2) ...
    ubuntu-aarch64: Selecting previously unselected package libisl22:arm64.
    ubuntu-aarch64: Preparing to unpack .../08-libisl22_0.22.1-1_arm64.deb ...
    ubuntu-aarch64: Unpacking libisl22:arm64 (0.22.1-1) ...
    ubuntu-aarch64: Selecting previously unselected package libmpc3:arm64.
    ubuntu-aarch64: Preparing to unpack .../09-libmpc3_1.1.0-1_arm64.deb ...
    ubuntu-aarch64: Unpacking libmpc3:arm64 (1.1.0-1) ...
    ubuntu-aarch64: Selecting previously unselected package cpp-9.
    ubuntu-aarch64: Preparing to unpack .../10-cpp-9_9.3.0-10ubuntu2_arm64.deb ...
    ubuntu-aarch64: Unpacking cpp-9 (9.3.0-10ubuntu2) ...
    ubuntu-aarch64: Selecting previously unselected package cpp.
    ubuntu-aarch64: Preparing to unpack .../11-cpp_4%3a9.3.0-1ubuntu2_arm64.deb ...
    ubuntu-aarch64: Unpacking cpp (4:9.3.0-1ubuntu2) ...
    ubuntu-aarch64: Selecting previously unselected package libcc1-0:arm64.
    ubuntu-aarch64: Preparing to unpack .../12-libcc1-0_10-20200411-0ubuntu1_arm64.deb ...
    ubuntu-aarch64: Unpacking libcc1-0:arm64 (10-20200411-0ubuntu1) ...
    ubuntu-aarch64: Selecting previously unselected package libgomp1:arm64.
    ubuntu-aarch64: Preparing to unpack .../13-libgomp1_10-20200411-0ubuntu1_arm64.deb ...
    ubuntu-aarch64: Unpacking libgomp1:arm64 (10-20200411-0ubuntu1) ...
    ubuntu-aarch64: Selecting previously unselected package libitm1:arm64.
    ubuntu-aarch64: Preparing to unpack .../14-libitm1_10-20200411-0ubuntu1_arm64.deb ...
    ubuntu-aarch64: Unpacking libitm1:arm64 (10-20200411-0ubuntu1) ...
    ubuntu-aarch64: Selecting previously unselected package libatomic1:arm64.
    ubuntu-aarch64: Preparing to unpack .../15-libatomic1_10-20200411-0ubuntu1_arm64.deb ...
    ubuntu-aarch64: Unpacking libatomic1:arm64 (10-20200411-0ubuntu1) ...
    ubuntu-aarch64: Selecting previously unselected package libasan5:arm64.
    ubuntu-aarch64: Preparing to unpack .../16-libasan5_9.3.0-10ubuntu2_arm64.deb ...
    ubuntu-aarch64: Unpacking libasan5:arm64 (9.3.0-10ubuntu2) ...
    ubuntu-aarch64: Selecting previously unselected package liblsan0:arm64.
    ubuntu-aarch64: Preparing to unpack .../17-liblsan0_10-20200411-0ubuntu1_arm64.deb ...
    ubuntu-aarch64: Unpacking liblsan0:arm64 (10-20200411-0ubuntu1) ...
    ubuntu-aarch64: Selecting previously unselected package libtsan0:arm64.
    ubuntu-aarch64: Preparing to unpack .../18-libtsan0_10-20200411-0ubuntu1_arm64.deb ...
    ubuntu-aarch64: Unpacking libtsan0:arm64 (10-20200411-0ubuntu1) ...
    ubuntu-aarch64: Selecting previously unselected package libubsan1:arm64.
    ubuntu-aarch64: Preparing to unpack .../19-libubsan1_10-20200411-0ubuntu1_arm64.deb ...
    ubuntu-aarch64: Unpacking libubsan1:arm64 (10-20200411-0ubuntu1) ...
    ubuntu-aarch64: Selecting previously unselected package libgcc-9-dev:arm64.
    ubuntu-aarch64: Preparing to unpack .../20-libgcc-9-dev_9.3.0-10ubuntu2_arm64.deb ...
    ubuntu-aarch64: Unpacking libgcc-9-dev:arm64 (9.3.0-10ubuntu2) ...
    ubuntu-aarch64: Selecting previously unselected package gcc-9.
    ubuntu-aarch64: Preparing to unpack .../21-gcc-9_9.3.0-10ubuntu2_arm64.deb ...
    ubuntu-aarch64: Unpacking gcc-9 (9.3.0-10ubuntu2) ...
    ubuntu-aarch64: Selecting previously unselected package gcc.
    ubuntu-aarch64: Preparing to unpack .../22-gcc_4%3a9.3.0-1ubuntu2_arm64.deb ...
    ubuntu-aarch64: Unpacking gcc (4:9.3.0-1ubuntu2) ...
    ubuntu-aarch64: Selecting previously unselected package libstdc++-9-dev:arm64.
    ubuntu-aarch64: Preparing to unpack .../23-libstdc++-9-dev_9.3.0-10ubuntu2_arm64.deb ...
    ubuntu-aarch64: Unpacking libstdc++-9-dev:arm64 (9.3.0-10ubuntu2) ...
    ubuntu-aarch64: Selecting previously unselected package g++-9.
    ubuntu-aarch64: Preparing to unpack .../24-g++-9_9.3.0-10ubuntu2_arm64.deb ...
    ubuntu-aarch64: Unpacking g++-9 (9.3.0-10ubuntu2) ...
    ubuntu-aarch64: Selecting previously unselected package g++.
    ubuntu-aarch64: Preparing to unpack .../25-g++_4%3a9.3.0-1ubuntu2_arm64.deb ...
    ubuntu-aarch64: Unpacking g++ (4:9.3.0-1ubuntu2) ...
    ubuntu-aarch64: Selecting previously unselected package make.
    ubuntu-aarch64: Preparing to unpack .../26-make_4.2.1-1.2_arm64.deb ...
    ubuntu-aarch64: Unpacking make (4.2.1-1.2) ...
    ubuntu-aarch64: Selecting previously unselected package libdpkg-perl.
    ubuntu-aarch64: Preparing to unpack .../27-libdpkg-perl_1.19.7ubuntu3_all.deb ...
    ubuntu-aarch64: Unpacking libdpkg-perl (1.19.7ubuntu3) ...
    ubuntu-aarch64: Selecting previously unselected package dpkg-dev.
    ubuntu-aarch64: Preparing to unpack .../28-dpkg-dev_1.19.7ubuntu3_all.deb ...
    ubuntu-aarch64: Unpacking dpkg-dev (1.19.7ubuntu3) ...
    ubuntu-aarch64: Selecting previously unselected package build-essential.
    ubuntu-aarch64: Preparing to unpack .../29-build-essential_12.8ubuntu1_arm64.deb ...
    ubuntu-aarch64: Unpacking build-essential (12.8ubuntu1) ...
    ubuntu-aarch64: Selecting previously unselected package cgroupfs-mount.
    ubuntu-aarch64: Preparing to unpack .../30-cgroupfs-mount_1.4_all.deb ...
    ubuntu-aarch64: Unpacking cgroupfs-mount (1.4) ...
    ubuntu-aarch64: Selecting previously unselected package runc.
    ubuntu-aarch64: Preparing to unpack .../31-runc_1.0.0~rc10-0ubuntu1_arm64.deb ...
    ubuntu-aarch64: Unpacking runc (1.0.0~rc10-0ubuntu1) ...
    ubuntu-aarch64: Selecting previously unselected package containerd.
    ubuntu-aarch64: Preparing to unpack .../32-containerd_1.3.3-0ubuntu2_arm64.deb ...
    ubuntu-aarch64: Unpacking containerd (1.3.3-0ubuntu2) ...
    ubuntu-aarch64: Selecting previously unselected package dns-root-data.
    ubuntu-aarch64: Preparing to unpack .../33-dns-root-data_2019052802_all.deb ...
    ubuntu-aarch64: Unpacking dns-root-data (2019052802) ...
    ubuntu-aarch64: Selecting previously unselected package libidn11:arm64.
    ubuntu-aarch64: Preparing to unpack .../34-libidn11_1.33-2.2ubuntu2_arm64.deb ...
    ubuntu-aarch64: Unpacking libidn11:arm64 (1.33-2.2ubuntu2) ...
    ubuntu-aarch64: Selecting previously unselected package dnsmasq-base.
    ubuntu-aarch64: Preparing to unpack .../35-dnsmasq-base_2.80-1.1ubuntu1_arm64.deb ...
    ubuntu-aarch64: Unpacking dnsmasq-base (2.80-1.1ubuntu1) ...
    ubuntu-aarch64: Selecting previously unselected package docker.io.
    ubuntu-aarch64: Preparing to unpack .../36-docker.io_19.03.8-0ubuntu1.20.04_arm64.deb ...
    ubuntu-aarch64: Unpacking docker.io (19.03.8-0ubuntu1.20.04) ...
    ubuntu-aarch64: Selecting previously unselected package libfakeroot:arm64.
    ubuntu-aarch64: Preparing to unpack .../37-libfakeroot_1.24-1_arm64.deb ...
    ubuntu-aarch64: Unpacking libfakeroot:arm64 (1.24-1) ...
    ubuntu-aarch64: Selecting previously unselected package fakeroot.
    ubuntu-aarch64: Preparing to unpack .../38-fakeroot_1.24-1_arm64.deb ...
    ubuntu-aarch64: Unpacking fakeroot (1.24-1) ...
    ubuntu-aarch64: Selecting previously unselected package libonig5:arm64.
    ubuntu-aarch64: Preparing to unpack .../39-libonig5_6.9.4-1_arm64.deb ...
    ubuntu-aarch64: Unpacking libonig5:arm64 (6.9.4-1) ...
    ubuntu-aarch64: Selecting previously unselected package libjq1:arm64.
    ubuntu-aarch64: Preparing to unpack .../40-libjq1_1.6-1_arm64.deb ...
    ubuntu-aarch64: Unpacking libjq1:arm64 (1.6-1) ...
    ubuntu-aarch64: Selecting previously unselected package jq.
    ubuntu-aarch64: Preparing to unpack .../41-jq_1.6-1_arm64.deb ...
    ubuntu-aarch64: Unpacking jq (1.6-1) ...
    ubuntu-aarch64: Selecting previously unselected package libalgorithm-diff-perl.
    ubuntu-aarch64: Preparing to unpack .../42-libalgorithm-diff-perl_1.19.03-2_all.deb ...
    ubuntu-aarch64: Unpacking libalgorithm-diff-perl (1.19.03-2) ...
    ubuntu-aarch64: Selecting previously unselected package libalgorithm-diff-xs-perl.
    ubuntu-aarch64: Preparing to unpack .../43-libalgorithm-diff-xs-perl_0.04-6_arm64.deb ...
    ubuntu-aarch64: Unpacking libalgorithm-diff-xs-perl (0.04-6) ...
    ubuntu-aarch64: Selecting previously unselected package libalgorithm-merge-perl.
    ubuntu-aarch64: Preparing to unpack .../44-libalgorithm-merge-perl_0.08-3_all.deb ...
    ubuntu-aarch64: Unpacking libalgorithm-merge-perl (0.08-3) ...
    ubuntu-aarch64: Selecting previously unselected package libexpat1-dev:arm64.
    ubuntu-aarch64: Preparing to unpack .../45-libexpat1-dev_2.2.9-1build1_arm64.deb ...
    ubuntu-aarch64: Unpacking libexpat1-dev:arm64 (2.2.9-1build1) ...
    ubuntu-aarch64: Selecting previously unselected package libfile-fcntllock-perl.
    ubuntu-aarch64: Preparing to unpack .../46-libfile-fcntllock-perl_0.22-3build4_arm64.deb ...
    ubuntu-aarch64: Unpacking libfile-fcntllock-perl (0.22-3build4) ...
    ubuntu-aarch64: Selecting previously unselected package libpython3.8-dev:arm64.
    ubuntu-aarch64: Preparing to unpack .../47-libpython3.8-dev_3.8.2-1ubuntu1.2_arm64.deb ...
    ubuntu-aarch64: Unpacking libpython3.8-dev:arm64 (3.8.2-1ubuntu1.2) ...
    ubuntu-aarch64: Selecting previously unselected package libpython3-dev:arm64.
    ubuntu-aarch64: Preparing to unpack .../48-libpython3-dev_3.8.2-0ubuntu2_arm64.deb ...
    ubuntu-aarch64: Unpacking libpython3-dev:arm64 (3.8.2-0ubuntu2) ...
    ubuntu-aarch64: Selecting previously unselected package manpages-dev.
    ubuntu-aarch64: Preparing to unpack .../49-manpages-dev_5.05-1_all.deb ...
    ubuntu-aarch64: Unpacking manpages-dev (5.05-1) ...
    ubuntu-aarch64: Selecting previously unselected package python-is-python2.
    ubuntu-aarch64: Preparing to unpack .../50-python-is-python2_2.7.17-4_all.deb ...
    ubuntu-aarch64: Unpacking python-is-python2 (2.7.17-4) ...
    ubuntu-aarch64: Selecting previously unselected package python-pip-whl.
    ubuntu-aarch64: Preparing to unpack .../51-python-pip-whl_20.0.2-5ubuntu1_all.deb ...
    ubuntu-aarch64: Unpacking python-pip-whl (20.0.2-5ubuntu1) ...
    ubuntu-aarch64: Selecting previously unselected package zlib1g-dev:arm64.
    ubuntu-aarch64: Preparing to unpack .../52-zlib1g-dev_1%3a1.2.11.dfsg-2ubuntu1_arm64.deb ...
    ubuntu-aarch64: Unpacking zlib1g-dev:arm64 (1:1.2.11.dfsg-2ubuntu1) ...
    ubuntu-aarch64: Selecting previously unselected package python3.8-dev.
    ubuntu-aarch64: Preparing to unpack .../53-python3.8-dev_3.8.2-1ubuntu1.2_arm64.deb ...
    ubuntu-aarch64: Unpacking python3.8-dev (3.8.2-1ubuntu1.2) ...
    ubuntu-aarch64: Selecting previously unselected package python3-dev.
    ubuntu-aarch64: Preparing to unpack .../54-python3-dev_3.8.2-0ubuntu2_arm64.deb ...
    ubuntu-aarch64: Unpacking python3-dev (3.8.2-0ubuntu2) ...
    ubuntu-aarch64: Selecting previously unselected package python3-wheel.
    ubuntu-aarch64: Preparing to unpack .../55-python3-wheel_0.34.2-1_all.deb ...
    ubuntu-aarch64: Unpacking python3-wheel (0.34.2-1) ...
    ubuntu-aarch64: Selecting previously unselected package python3-pip.
    ubuntu-aarch64: Preparing to unpack .../56-python3-pip_20.0.2-5ubuntu1_all.deb ...
    ubuntu-aarch64: Unpacking python3-pip (20.0.2-5ubuntu1) ...
    ubuntu-aarch64: Selecting previously unselected package ubuntu-fan.
    ubuntu-aarch64: Preparing to unpack .../57-ubuntu-fan_0.12.13_all.deb ...
    ubuntu-aarch64: Unpacking ubuntu-fan (0.12.13) ...
    ubuntu-aarch64: Setting up manpages-dev (5.05-1) ...
    ubuntu-aarch64: Setting up libfile-fcntllock-perl (0.22-3build4) ...
    ubuntu-aarch64: Setting up libalgorithm-diff-perl (1.19.03-2) ...
    ubuntu-aarch64: Setting up linux-libc-dev:arm64 (5.4.0-45.49) ...
    ubuntu-aarch64: Setting up acpid (1:2.0.32-1ubuntu1) ...
    ubuntu-aarch64: Created symlink /etc/systemd/system/sockets.target.wants/acpid.socket → /lib/systemd/system/acpid.socket.
    ubuntu-aarch64: Created symlink /etc/systemd/system/paths.target.wants/acpid.path → /lib/systemd/system/acpid.path.
    ubuntu-aarch64: Setting up libgomp1:arm64 (10-20200411-0ubuntu1) ...
    ubuntu-aarch64: Setting up python3-wheel (0.34.2-1) ...
    ubuntu-aarch64: Setting up libfakeroot:arm64 (1.24-1) ...
    ubuntu-aarch64: Setting up runc (1.0.0~rc10-0ubuntu1) ...
    ubuntu-aarch64: Setting up dns-root-data (2019052802) ...
    ubuntu-aarch64: Setting up libpython2.7-stdlib:arm64 (2.7.18~rc1-2) ...
    ubuntu-aarch64: Setting up fakeroot (1.24-1) ...
    ubuntu-aarch64: update-alternatives: using /usr/bin/fakeroot-sysv to provide /usr/bin/fakeroot (fakeroot) in auto mode
    ubuntu-aarch64: Setting up make (4.2.1-1.2) ...
    ubuntu-aarch64: Setting up libidn11:arm64 (1.33-2.2ubuntu2) ...
    ubuntu-aarch64: Setting up libmpc3:arm64 (1.1.0-1) ...
    ubuntu-aarch64: Setting up libatomic1:arm64 (10-20200411-0ubuntu1) ...
    ubuntu-aarch64: Setting up bridge-utils (1.6-2ubuntu1) ...
    ubuntu-aarch64: debconf: unable to initialize frontend: Dialog
    ubuntu-aarch64: debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
    ubuntu-aarch64: debconf: falling back to frontend: Readline
    ubuntu-aarch64: Setting up libdpkg-perl (1.19.7ubuntu3) ...
    ubuntu-aarch64: Setting up libubsan1:arm64 (10-20200411-0ubuntu1) ...
    ubuntu-aarch64: Setting up pigz (2.4-1) ...
    ubuntu-aarch64: Setting up libcrypt-dev:arm64 (1:4.4.10-10ubuntu4) ...
    ubuntu-aarch64: Setting up libisl22:arm64 (0.22.1-1) ...
    ubuntu-aarch64: Setting up python-pip-whl (20.0.2-5ubuntu1) ...
    ubuntu-aarch64: Setting up cgroupfs-mount (1.4) ...
    ubuntu-aarch64: Setting up libc-dev-bin (2.31-0ubuntu9) ...
    ubuntu-aarch64: Setting up containerd (1.3.3-0ubuntu2) ...
    ubuntu-aarch64: Created symlink /etc/systemd/system/multi-user.target.wants/containerd.service → /lib/systemd/system/containerd.service.
    ubuntu-aarch64: Setting up libalgorithm-diff-xs-perl (0.04-6) ...
    ubuntu-aarch64: Setting up libcc1-0:arm64 (10-20200411-0ubuntu1) ...
    ubuntu-aarch64: Setting up libonig5:arm64 (6.9.4-1) ...
    ubuntu-aarch64: Setting up liblsan0:arm64 (10-20200411-0ubuntu1) ...
    ubuntu-aarch64: Setting up libitm1:arm64 (10-20200411-0ubuntu1) ...
    ubuntu-aarch64: Setting up gcc-9-base:arm64 (9.3.0-10ubuntu2) ...
    ubuntu-aarch64: Setting up libalgorithm-merge-perl (0.08-3) ...
    ubuntu-aarch64: Setting up libtsan0:arm64 (10-20200411-0ubuntu1) ...
    ubuntu-aarch64: Setting up python2.7 (2.7.18~rc1-2) ...
    ubuntu-aarch64: Setting up libpython2-stdlib:arm64 (2.7.17-2ubuntu4) ...
    ubuntu-aarch64: Setting up libjq1:arm64 (1.6-1) ...
    ubuntu-aarch64: Setting up docker.io (19.03.8-0ubuntu1.20.04) ...
    ubuntu-aarch64: debconf: unable to initialize frontend: Dialog
    ubuntu-aarch64: debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
    ubuntu-aarch64: debconf: falling back to frontend: Readline
    ubuntu-aarch64: Adding group `docker' (GID 119) ...
    ubuntu-aarch64: Done.
    ubuntu-aarch64: Created symlink /etc/systemd/system/sockets.target.wants/docker.socket → /lib/systemd/system/docker.socket.
    ubuntu-aarch64: docker.service is a disabled or a static unit, not starting it.
    ubuntu-aarch64: Setting up dnsmasq-base (2.80-1.1ubuntu1) ...
    ubuntu-aarch64: Setting up python2 (2.7.17-2ubuntu4) ...
    ubuntu-aarch64: Setting up dpkg-dev (1.19.7ubuntu3) ...
    ubuntu-aarch64: Setting up libasan5:arm64 (9.3.0-10ubuntu2) ...
    ubuntu-aarch64: Setting up python3-pip (20.0.2-5ubuntu1) ...
    ubuntu-aarch64: Setting up jq (1.6-1) ...
    ubuntu-aarch64: Setting up cpp-9 (9.3.0-10ubuntu2) ...
    ubuntu-aarch64: Setting up libc6-dev:arm64 (2.31-0ubuntu9) ...
    ubuntu-aarch64: Setting up python-is-python2 (2.7.17-4) ...
    ubuntu-aarch64: Setting up ubuntu-fan (0.12.13) ...
    ubuntu-aarch64: Created symlink /etc/systemd/system/multi-user.target.wants/ubuntu-fan.service → /lib/systemd/system/ubuntu-fan.service.
    ubuntu-aarch64: Setting up libgcc-9-dev:arm64 (9.3.0-10ubuntu2) ...
    ubuntu-aarch64: Setting up libexpat1-dev:arm64 (2.2.9-1build1) ...
    ubuntu-aarch64: Setting up libpython3.8-dev:arm64 (3.8.2-1ubuntu1.2) ...
    ubuntu-aarch64: Setting up zlib1g-dev:arm64 (1:1.2.11.dfsg-2ubuntu1) ...
    ubuntu-aarch64: Setting up cpp (4:9.3.0-1ubuntu2) ...
    ubuntu-aarch64: Setting up gcc-9 (9.3.0-10ubuntu2) ...
    ubuntu-aarch64: Setting up libpython3-dev:arm64 (3.8.2-0ubuntu2) ...
    ubuntu-aarch64: Setting up libstdc++-9-dev:arm64 (9.3.0-10ubuntu2) ...
    ubuntu-aarch64: Setting up gcc (4:9.3.0-1ubuntu2) ...
    ubuntu-aarch64: Setting up g++-9 (9.3.0-10ubuntu2) ...
    ubuntu-aarch64: Setting up python3.8-dev (3.8.2-1ubuntu1.2) ...
    ubuntu-aarch64: Setting up g++ (4:9.3.0-1ubuntu2) ...
    ubuntu-aarch64: update-alternatives: using /usr/bin/g++ to provide /usr/bin/c++ (c++) in auto mode
    ubuntu-aarch64: Setting up build-essential (12.8ubuntu1) ...
    ubuntu-aarch64: Setting up python3-dev (3.8.2-0ubuntu2) ...
    ubuntu-aarch64: Processing triggers for libc-bin (2.31-0ubuntu9) ...
    ubuntu-aarch64: Processing triggers for systemd (245.4-4ubuntu3.2) ...
    ubuntu-aarch64: Processing triggers for man-db (2.9.1-1) ...
    ubuntu-aarch64: Processing triggers for dbus (1.12.16-2ubuntu2.1) ...
    ubuntu-aarch64: Processing triggers for mime-support (3.64ubuntu1) ...
    ubuntu-aarch64: Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /lib/systemd/system/docker.service.
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:41:53 [INFO] 46697 bytes written for 'stdout'
2020/09/01 22:41:53 [INFO] 917 bytes written for 'stderr'
2020/09/01 22:41:53 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:41:53 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [INFO] 46697 bytes written for 'stdout'
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [INFO] 917 bytes written for 'stderr'
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [DEBUG] Opening new ssh session
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [DEBUG] starting remote command: rm -f /tmp/script_2758.sh
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:41:53 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:41:53 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [DEBUG] Opening new ssh session
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [DEBUG] starting remote command: rm -f
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:41:53 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:41:53 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [INFO] RPC client: Communicator ended with: 0
==> ubuntu-aarch64: Provisioning with shell script: ./scripts/install-gha-runner.sh
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 Opening ./scripts/install-gha-runner.sh for reading
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [INFO] 1520 bytes written for 'uploadData'
2020/09/01 22:41:53 [INFO] 1520 bytes written for 'uploadData'
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [DEBUG] Opening new ssh session
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [DEBUG] Starting remote scp process:  scp -vt /tmp
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [DEBUG] Started SCP session, beginning transfers...
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [DEBUG] Copying input data into temporary file so we can read the length
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [DEBUG] scp: Uploading script_2758.sh: perms=C0644 size=1520
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [DEBUG] SCP session complete, closing stdin pipe.
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [DEBUG] Waiting for SSH session to complete.
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [DEBUG] scp stderr (length 32): Sink: C0644 1520 script_2758.sh
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [DEBUG] Opening new ssh session
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [DEBUG] starting remote command: chmod 0755 /tmp/script_2758.sh
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:41:53 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:41:53 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [DEBUG] Opening new ssh session
2020/09/01 22:41:53 packer: 2020/09/01 22:41:53 [DEBUG] starting remote command: chmod +x /tmp/script_2758.sh; GIT_SHA='f5dc1708ec64ec55012690dddc63cf729b62a1a8' PACKER_BUILDER_TYPE='qemu' PACKER_BUILD_NAME='ubuntu-aarch64' PACKER_HTTP_ADDR='10.0.2.2:8779' PACKER_HTTP_IP='10.0.2.2' PACKER_HTTP_PORT='8779'  /tmp/script_2758.sh
    ubuntu-aarch64: adding the gha user...
    ubuntu-aarch64: Adding user `gha' ...
    ubuntu-aarch64: Adding new group `gha' (1001) ...
    ubuntu-aarch64: Adding new user `gha' (1001) with group `gha' ...
    ubuntu-aarch64: Creating home directory `/gha' ...
    ubuntu-aarch64: Copying files from `/etc/skel' ...
    ubuntu-aarch64: Changing the user information for gha
    ubuntu-aarch64: Enter the new value, or press ENTER for the default
    ubuntu-aarch64: Use of uninitialized value $answer in chop at /usr/sbin/adduser line 621.
    ubuntu-aarch64: Use of uninitialized value $answer in pattern match (m//) at /usr/sbin/adduser line 622.
    ubuntu-aarch64:     Full Name []:   Room Number []:         Work Phone []:  Home Phone []:  Other []: Is the information correct? [Y/n] Adding user `gha' to group `docker' ...
    ubuntu-aarch64: Adding user gha to group docker
    ubuntu-aarch64: Done.
    ubuntu-aarch64: gha ALL=(ALL) NOPASSWD: ALL
    ubuntu-aarch64: downloading and installing the runner...
    ubuntu-aarch64:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
    ubuntu-aarch64:                                  Dload  Upload   Total   Spent    Left  Speed
    ubuntu-aarch64: 100   673  100   673    0     0   1225      0 --:--:-- --:--:-- --:--:--  1243
    ubuntu-aarch64: 100 53.5M  100 53.5M    0     0  1983k      0  0:00:27  0:00:27 --:--:-- 2123k
    ubuntu-aarch64: configuring startup of the runner...
    ubuntu-aarch64: Created symlink /etc/systemd/system/multi-user.target.wants/gha-runner.service → /etc/systemd/system/gha-runner.service.
    ubuntu-aarch64: adding runner information...
2020/09/01 22:42:59 packer: 2020/09/01 22:42:59 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:42:59 [INFO] 611 bytes written for 'stdout'
2020/09/01 22:42:59 [INFO] 2816 bytes written for 'stderr'
2020/09/01 22:42:59 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:42:59 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:42:59 packer: 2020/09/01 22:42:59 [INFO] 611 bytes written for 'stdout'
2020/09/01 22:42:59 packer: 2020/09/01 22:42:59 [INFO] 2816 bytes written for 'stderr'
2020/09/01 22:42:59 packer: 2020/09/01 22:42:59 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:42:59 packer: 2020/09/01 22:42:59 [DEBUG] Opening new ssh session
2020/09/01 22:42:59 packer: 2020/09/01 22:42:59 [DEBUG] starting remote command: rm -f /tmp/script_2758.sh
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:00 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:43:00 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 [DEBUG] Opening new ssh session
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 [DEBUG] starting remote command: rm -f
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:00 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:43:00 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 [INFO] RPC client: Communicator ended with: 0
==> ubuntu-aarch64: Provisioning with shell script: ./scripts/setup-ssh.sh
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 Opening ./scripts/setup-ssh.sh for reading
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 [INFO] 545 bytes written for 'uploadData'
2020/09/01 22:43:00 [INFO] 545 bytes written for 'uploadData'
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 [DEBUG] Opening new ssh session
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 [DEBUG] Starting remote scp process:  scp -vt /tmp
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 [DEBUG] Started SCP session, beginning transfers...
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 [DEBUG] Copying input data into temporary file so we can read the length
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 [DEBUG] scp: Uploading script_2758.sh: perms=C0644 size=545
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 [DEBUG] SCP session complete, closing stdin pipe.
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 [DEBUG] Waiting for SSH session to complete.
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 [DEBUG] scp stderr (length 31): Sink: C0644 545 script_2758.sh
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 [DEBUG] Opening new ssh session
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 [DEBUG] starting remote command: chmod 0755 /tmp/script_2758.sh
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:00 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:43:00 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 [DEBUG] Opening new ssh session
2020/09/01 22:43:00 packer: 2020/09/01 22:43:00 [DEBUG] starting remote command: chmod +x /tmp/script_2758.sh; GIT_SHA='f5dc1708ec64ec55012690dddc63cf729b62a1a8' PACKER_BUILDER_TYPE='qemu' PACKER_BUILD_NAME='ubuntu-aarch64' PACKER_HTTP_ADDR='10.0.2.2:8779' PACKER_HTTP_IP='10.0.2.2' PACKER_HTTP_PORT='8779'  /tmp/script_2758.sh
    ubuntu-aarch64: Created symlink /etc/systemd/system/multi-user.target.wants/regenerate-ssh-host-keys.service → /etc/systemd/system/regenerate-ssh-host-keys.service.
2020/09/01 22:43:16 packer: 2020/09/01 22:43:16 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:16 [INFO] 0 bytes written for 'stdout'
2020/09/01 22:43:16 [INFO] 151 bytes written for 'stderr'
2020/09/01 22:43:16 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:43:16 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:16 packer: 2020/09/01 22:43:16 [INFO] 0 bytes written for 'stdout'
2020/09/01 22:43:16 packer: 2020/09/01 22:43:16 [INFO] 151 bytes written for 'stderr'
2020/09/01 22:43:16 packer: 2020/09/01 22:43:16 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:43:16 packer: 2020/09/01 22:43:16 [DEBUG] Opening new ssh session
2020/09/01 22:43:16 packer: 2020/09/01 22:43:16 [DEBUG] starting remote command: rm -f /tmp/script_2758.sh
2020/09/01 22:43:16 packer: 2020/09/01 22:43:16 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:16 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:43:16 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:16 packer: 2020/09/01 22:43:16 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:43:16 packer: 2020/09/01 22:43:16 [DEBUG] Opening new ssh session
2020/09/01 22:43:16 packer: 2020/09/01 22:43:16 [DEBUG] starting remote command: rm -f
2020/09/01 22:43:16 packer: 2020/09/01 22:43:16 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:16 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:43:16 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:16 packer: 2020/09/01 22:43:16 [INFO] RPC client: Communicator ended with: 0
==> ubuntu-aarch64: Provisioning with shell script: ./scripts/setup-disk-resize.sh
2020/09/01 22:43:16 packer: 2020/09/01 22:43:16 Opening ./scripts/setup-disk-resize.sh for reading
2020/09/01 22:43:16 packer: 2020/09/01 22:43:16 [INFO] 397 bytes written for 'uploadData'
2020/09/01 22:43:16 [INFO] 397 bytes written for 'uploadData'
2020/09/01 22:43:16 packer: 2020/09/01 22:43:16 [DEBUG] Opening new ssh session
2020/09/01 22:43:16 packer: 2020/09/01 22:43:16 [DEBUG] Starting remote scp process:  scp -vt /tmp
2020/09/01 22:43:16 packer: 2020/09/01 22:43:16 [DEBUG] Started SCP session, beginning transfers...
2020/09/01 22:43:16 packer: 2020/09/01 22:43:16 [DEBUG] Copying input data into temporary file so we can read the length
2020/09/01 22:43:16 packer: 2020/09/01 22:43:16 [DEBUG] scp: Uploading script_2758.sh: perms=C0644 size=397
2020/09/01 22:43:17 packer: 2020/09/01 22:43:17 [DEBUG] SCP session complete, closing stdin pipe.
2020/09/01 22:43:17 packer: 2020/09/01 22:43:17 [DEBUG] Waiting for SSH session to complete.
2020/09/01 22:43:17 packer: 2020/09/01 22:43:17 [DEBUG] scp stderr (length 31): Sink: C0644 397 script_2758.sh
2020/09/01 22:43:17 packer: 2020/09/01 22:43:17 [DEBUG] Opening new ssh session
2020/09/01 22:43:17 packer: 2020/09/01 22:43:17 [DEBUG] starting remote command: chmod 0755 /tmp/script_2758.sh
2020/09/01 22:43:17 packer: 2020/09/01 22:43:17 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:17 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:43:17 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:17 packer: 2020/09/01 22:43:17 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:43:17 packer: 2020/09/01 22:43:17 [DEBUG] Opening new ssh session
2020/09/01 22:43:17 packer: 2020/09/01 22:43:17 [DEBUG] starting remote command: chmod +x /tmp/script_2758.sh; GIT_SHA='f5dc1708ec64ec55012690dddc63cf729b62a1a8' PACKER_BUILDER_TYPE='qemu' PACKER_BUILD_NAME='ubuntu-aarch64' PACKER_HTTP_ADDR='10.0.2.2:8779' PACKER_HTTP_IP='10.0.2.2' PACKER_HTTP_PORT='8779'  /tmp/script_2758.sh
    ubuntu-aarch64: Created symlink /etc/systemd/system/multi-user.target.wants/resize-disk.service → /etc/systemd/system/resize-disk.service.
2020/09/01 22:43:32 packer: 2020/09/01 22:43:32 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:32 [INFO] 0 bytes written for 'stdout'
2020/09/01 22:43:32 [INFO] 125 bytes written for 'stderr'
2020/09/01 22:43:32 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:43:32 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:32 packer: 2020/09/01 22:43:32 [INFO] 0 bytes written for 'stdout'
2020/09/01 22:43:32 packer: 2020/09/01 22:43:32 [INFO] 125 bytes written for 'stderr'
2020/09/01 22:43:32 packer: 2020/09/01 22:43:32 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:43:32 packer: 2020/09/01 22:43:32 [DEBUG] Opening new ssh session
2020/09/01 22:43:32 packer: 2020/09/01 22:43:32 [DEBUG] starting remote command: rm -f /tmp/script_2758.sh
2020/09/01 22:43:32 packer: 2020/09/01 22:43:32 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:32 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:43:32 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:32 packer: 2020/09/01 22:43:32 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:43:32 packer: 2020/09/01 22:43:32 [DEBUG] Opening new ssh session
2020/09/01 22:43:32 packer: 2020/09/01 22:43:32 [DEBUG] starting remote command: rm -f
2020/09/01 22:43:33 packer: 2020/09/01 22:43:33 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:33 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:43:33 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:33 packer: 2020/09/01 22:43:33 [INFO] RPC client: Communicator ended with: 0
==> ubuntu-aarch64: Provisioning with shell script: ./scripts/setup-grub.sh
2020/09/01 22:43:33 packer: 2020/09/01 22:43:33 Opening ./scripts/setup-grub.sh for reading
2020/09/01 22:43:33 packer: 2020/09/01 22:43:33 [INFO] 306 bytes written for 'uploadData'
2020/09/01 22:43:33 [INFO] 306 bytes written for 'uploadData'
2020/09/01 22:43:33 packer: 2020/09/01 22:43:33 [DEBUG] Opening new ssh session
2020/09/01 22:43:33 packer: 2020/09/01 22:43:33 [DEBUG] Starting remote scp process:  scp -vt /tmp
2020/09/01 22:43:33 packer: 2020/09/01 22:43:33 [DEBUG] Started SCP session, beginning transfers...
2020/09/01 22:43:33 packer: 2020/09/01 22:43:33 [DEBUG] Copying input data into temporary file so we can read the length
2020/09/01 22:43:33 packer: 2020/09/01 22:43:33 [DEBUG] scp: Uploading script_2758.sh: perms=C0644 size=306
2020/09/01 22:43:33 packer: 2020/09/01 22:43:33 [DEBUG] SCP session complete, closing stdin pipe.
2020/09/01 22:43:33 packer: 2020/09/01 22:43:33 [DEBUG] Waiting for SSH session to complete.
2020/09/01 22:43:33 packer: 2020/09/01 22:43:33 [DEBUG] scp stderr (length 31): Sink: C0644 306 script_2758.sh
2020/09/01 22:43:33 packer: 2020/09/01 22:43:33 [DEBUG] Opening new ssh session
2020/09/01 22:43:33 packer: 2020/09/01 22:43:33 [DEBUG] starting remote command: chmod 0755 /tmp/script_2758.sh
2020/09/01 22:43:33 packer: 2020/09/01 22:43:33 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:33 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:43:33 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:43:33 packer: 2020/09/01 22:43:33 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:43:33 packer: 2020/09/01 22:43:33 [DEBUG] Opening new ssh session
2020/09/01 22:43:33 packer: 2020/09/01 22:43:33 [DEBUG] starting remote command: chmod +x /tmp/script_2758.sh; GIT_SHA='f5dc1708ec64ec55012690dddc63cf729b62a1a8' PACKER_BUILDER_TYPE='qemu' PACKER_BUILD_NAME='ubuntu-aarch64' PACKER_HTTP_ADDR='10.0.2.2:8779' PACKER_HTTP_IP='10.0.2.2' PACKER_HTTP_PORT='8779'  /tmp/script_2758.sh
    ubuntu-aarch64: Sourcing file `/etc/default/grub'
    ubuntu-aarch64: Sourcing file `/etc/default/grub.d/40-force-partuuid.cfg'
    ubuntu-aarch64: Sourcing file `/etc/default/grub.d/init-select.cfg'
    ubuntu-aarch64: Generating grub configuration file ...
    ubuntu-aarch64: Found linux image: /boot/vmlinuz-5.4.0-42-generic
    ubuntu-aarch64: Found initrd image: /boot/initrd.img-5.4.0-42-generic
    ubuntu-aarch64: Adding boot menu entry for UEFI Firmware Settings
    ubuntu-aarch64: done
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:44:05 [INFO] 0 bytes written for 'stdout'
2020/09/01 22:44:05 [INFO] 342 bytes written for 'stderr'
2020/09/01 22:44:05 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:44:05 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [INFO] 0 bytes written for 'stdout'
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [INFO] 342 bytes written for 'stderr'
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [DEBUG] Opening new ssh session
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [DEBUG] starting remote command: rm -f /tmp/script_2758.sh
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:44:05 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:44:05 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [DEBUG] Opening new ssh session
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [DEBUG] starting remote command: rm -f
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [INFO] RPC endpoint: Communicator ended with: 0
==> ubuntu-aarch64: Provisioning with shell script: ./scripts/finalize.sh
2020/09/01 22:44:05 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:44:05 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 Opening ./scripts/finalize.sh for reading
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [INFO] 253 bytes written for 'uploadData'
2020/09/01 22:44:05 [INFO] 253 bytes written for 'uploadData'
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [DEBUG] Opening new ssh session
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [DEBUG] Starting remote scp process:  scp -vt /tmp
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [DEBUG] Started SCP session, beginning transfers...
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [DEBUG] Copying input data into temporary file so we can read the length
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [DEBUG] scp: Uploading script_2758.sh: perms=C0644 size=253
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [DEBUG] SCP session complete, closing stdin pipe.
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [DEBUG] Waiting for SSH session to complete.
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [DEBUG] scp stderr (length 31): Sink: C0644 253 script_2758.sh
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [DEBUG] Opening new ssh session
2020/09/01 22:44:05 packer: 2020/09/01 22:44:05 [DEBUG] starting remote command: chmod 0755 /tmp/script_2758.sh
2020/09/01 22:44:06 packer: 2020/09/01 22:44:06 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:44:06 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:44:06 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:44:06 packer: 2020/09/01 22:44:06 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:44:06 packer: 2020/09/01 22:44:06 [DEBUG] Opening new ssh session
2020/09/01 22:44:06 packer: 2020/09/01 22:44:06 [DEBUG] starting remote command: chmod +x /tmp/script_2758.sh; GIT_SHA='f5dc1708ec64ec55012690dddc63cf729b62a1a8' PACKER_BUILDER_TYPE='qemu' PACKER_BUILD_NAME='ubuntu-aarch64' PACKER_HTTP_ADDR='10.0.2.2:8779' PACKER_HTTP_IP='10.0.2.2' PACKER_HTTP_PORT='8779'  /tmp/script_2758.sh
    ubuntu-aarch64: synchronizing changes to disk...
2020/09/01 22:44:06 packer: 2020/09/01 22:44:06 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:44:06 [INFO] 33 bytes written for 'stdout'
2020/09/01 22:44:06 [INFO] 0 bytes written for 'stderr'
2020/09/01 22:44:06 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:44:06 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:44:06 packer: 2020/09/01 22:44:06 [INFO] 33 bytes written for 'stdout'
2020/09/01 22:44:06 packer: 2020/09/01 22:44:06 [INFO] 0 bytes written for 'stderr'
2020/09/01 22:44:06 packer: 2020/09/01 22:44:06 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:44:06 packer: 2020/09/01 22:44:06 [DEBUG] Opening new ssh session
2020/09/01 22:44:06 packer: 2020/09/01 22:44:06 [DEBUG] starting remote command: rm -f /tmp/script_2758.sh
2020/09/01 22:44:06 packer: 2020/09/01 22:44:06 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:44:06 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:44:06 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:44:06 packer: 2020/09/01 22:44:06 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:44:06 packer: 2020/09/01 22:44:06 [DEBUG] Opening new ssh session
2020/09/01 22:44:06 packer: 2020/09/01 22:44:06 [DEBUG] starting remote command: rm -f
2020/09/01 22:44:07 packer: 2020/09/01 22:44:07 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:44:07 [INFO] RPC client: Communicator ended with: 0
2020/09/01 22:44:07 [INFO] RPC endpoint: Communicator ended with: 0
2020/09/01 22:44:07 packer: 2020/09/01 22:44:07 [INFO] RPC client: Communicator ended with: 0
==> ubuntu-aarch64: Halting the virtual machine...
2020/09/01 22:44:07 packer: 2020/09/01 22:44:07 VM shut down.
==> ubuntu-aarch64: Converting hard drive...
2020/09/01 22:44:07 packer: 2020/09/01 22:44:07 Executing qemu-img: []string{"convert", "-O", "qcow2", "build/aarch64/rootfs.qcow2", "build/aarch64/rootfs.qcow2.convert"}
2020/09/01 22:44:07 packer: 2020/09/01 22:44:07 stdout:
2020/09/01 22:44:07 packer: 2020/09/01 22:44:07 stderr: qemu-img: Could not open 'build/aarch64/rootfs.qcow2': Failed to get shared "write" lock
2020/09/01 22:44:07 packer: Is another process using the image [build/aarch64/rootfs.qcow2]?
==> ubuntu-aarch64: Error getting file lock for conversion; retrying...
2020/09/01 22:44:08 packer: 2020/09/01 22:44:08 Executing qemu-img: []string{"convert", "-O", "qcow2", "build/aarch64/rootfs.qcow2", "build/aarch64/rootfs.qcow2.convert"}
2020/09/01 22:44:09 packer: 2020/09/01 22:44:09 stdout:
2020/09/01 22:44:09 packer: 2020/09/01 22:44:09 stderr:
2020/09/01 22:44:11 Builds completed. Waiting on interrupt barrier...
Build 'ubuntu-aarch64' finished.
==> Builds finished. The artifacts of successful builds are:

2020/09/01 22:44:11 machine readable: ubuntu-aarch64,artifact-count []string{"1"}
==> Builds finished. The artifacts of successful builds are:
2020/09/01 22:44:11 machine readable: ubuntu-aarch64,artifact []string{"0", "builder-id", "transcend.qemu"}
2020/09/01 22:44:11 machine readable: ubuntu-aarch64,artifact []string{"0", "id", "VM"}
2020/09/01 22:44:11 machine readable: ubuntu-aarch64,artifact []string{"0", "string", "VM files in directory: build/aarch64"}
2020/09/01 22:44:11 machine readable: ubuntu-aarch64,artifact []string{"0", "files-count", "1"}
--> ubuntu-aarch64: VM files in directory: build/aarch64
2020/09/01 22:44:11 machine readable: ubuntu-aarch64,artifact []string{"0", "file", "0", "build/aarch64/rootfs.qcow2"}
2020/09/01 22:44:11 machine readable: ubuntu-aarch64,artifact []string{"0", "end"}
2020/09/01 22:44:11 waiting for all plugin processes to complete...
2020/09/01 22:44:11 /usr/bin/packer: plugin process exited
2020/09/01 22:44:11 /usr/bin/packer: plugin process exited
2020/09/01 22:44:11 /usr/bin/packer: plugin process exited
2020/09/01 22:44:11 /usr/bin/packer: plugin process exited

... which looks like a successful run but I'm not 100% sure.

I note that there is about a 6 minute delay from qemu invocation to the SSH connect to the emulated machine succeeding but things eventually do apparently run through to successful completion.

Can you please confirm either ways and let me know ? I'll then dig more if needed.

Thanks.

pietroalbini

comment created time in a month

pull request commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

Hi @pnkfelix

I'm throwing a link to rust-lang/rust#74820 on here because I suspect we'll want to better understand that bug before we can stabilize a Tier 1 ARM target.

Sure I'll have a look. You probably already know this but just in case: That bug appears to be an armv7 related one and this RFC is for AArch64.

raw-bin

comment created time in a month

pull request commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

@Lokathor - please could you contact me (somehow! Sorry wasn't exactly sure how else!) ? I'd like to follow-up on the NEON SIMD intrinsics work! Thanks!

raw-bin

comment created time in a month

pull request commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

Should stack probes be required for all tier-1 platforms? See rust-lang/rust#43241 and rust-lang/rust#49355.

@mbrubeck, @alexcrichton : For the record, here's a link to the official ticket tracking this work: https://projects.linaro.org/browse/LLVM-618

There is now a high certainty of this being progressed in Q4 this year. I'll update as and when events occur.

raw-bin

comment created time in a month

issue commentctz/rustls

Delegating crypto to a RustCrypto traits implementation

Hey @Darkspirit! Those are good questions and not naive ones at all! :)

I think it should be possible to find good and reasonable ways in which both Ring's AArch64 support improves as well as Rustls gains the ability to work with secure hardware elements.

More choice for folks wanting to use Rust on AArch64 can never be a bad thing! :)

Completely take your point that there is a balance to be maintained though.

More than happy to discuss options!

hug-dev

comment created time in 2 months

issue commentctz/rustls

Delegating crypto to a RustCrypto traits implementation

A few additional points:

  • There is growing interest in using Rust on AArch64 systems, for safety and security sensitive software layers, such as firmware.
  • This is especially so for bare-metal deployments on AArch64 systems.
  • Rustls has evidently gained a lot of momentum as a good TLS library.
  • At present, the perception is that Rustls doesn't have a clear and standardised path to using secure hardware elements for crypto ops.
  • One good way ahead would be adopting the RustCrypto traits within Rustls. Given that Rustls already works with Ring and given that Ring has already broken ground to start using the RustCrypto traits, it bodes well for Rustls to do so too.
  • That would then enable Rustls to benefit from software crypto implementations as is the case today but have a wider set of options (Ring today, PSA Crypto services tomorrow).
  • Ultimately, what would be a neat outcome is for Rustls to be able to work seamlessly with options such as Parsec.

It would be great if we can brain-storm on these options and then work out a feasible path to implementation ahead.

hug-dev

comment created time in 2 months

pull request commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

All tests now pass reliably for aarch64-unknown-linux-gnu! :)

Updated the PR to reflect this.

raw-bin

comment created time in 2 months

push eventraw-bin/rfcs

Robin Randhawa

commit sha a6e879351bd547dab6c73c67b9284d6aa81d44b0

RFC: aarch4-unknown-linux-gnu: Tier-1: All tests now pass reliably!

view details

push time in 2 months

Pull request review commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

+- Feature Name: `promote-aarch64-unknown-linux-gnu-to-tier-1`+- Start Date: 2020-07-17+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Promote the Arm aarch64-unknown-linux-gnu Rust target to Tier-1.++# Motivation+[motivation]: #motivation++Arch64-unknown-linux-gnu is [currently a Tier-2 Rust target](https://forge.rust-lang.org/release/platform-support.html#tier-2), in accordance with the target tier policy articulated [here](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-09-20-target-tier-policy/).++In the last 2 quarters, very good progress has been made in understanding and filling the gaps that remain in the path to attaining Tier-1 status for this target.++As a direct result, those gaps have either already been filled or are very close to being filled.++As such, this RFC aims to:++- Evidence what has been done.++- On the basis of that evidence propose that the proceeedings to promote the aarch64-unknown-linux-gnu target to the Tier-1 category may please be kickstarted.++- Culminate in the actual promotion of the aarch64-unknown-linux-gnu target to Tier-1, including any and all of the relevant processes and actions as appropriate.++Please note that the narrative here doesn't always match the RFC template so some liberties may have been taken in the expression.++Please also note, by way of wilful disclosure, that this RFC's author is an employee of Arm.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++1. **In essence, the target tier policy for a Tier-1 target aims to obtain the following technical and tangible assurances:**++   a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.++   b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.++   c. There must exist a robust and convenient CI integration for the target in question.++2. **In addition, the target tier policy for a Tier-1 target aims to obtain the following stategic assurances:**++   a. The long term viability of the existence of a target specific ecosystem should be clear.++   b. The long term viability of supporting the target should be clear.++   c. The target must have substantial and widespread interest within the Rust developer community.++   d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.++3. **Finally, the target tier policy for a Tier-1 target aims to obtain the following approvals:**++   a. An approval from the Compiler Team that Tier-1 target requirements have been met.++   b. An approval from the Infrastructure Team that the target in question may be integrated into CI.++   c. An approval from the Release Team that supporting the target in question is viable in the long term.++The following section details how points 1 and 2 of the above assurances have either already been met or are close to being met. ++Items in point 3 are addressed in the section titled [Unresolved Questions](#Unresolved-questions). That is not to say that they are unresolved per se but more that they are proposed next steps.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++**1.a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.**++ - As of today, all tests pass reliably barring one test. + + - A fix addressing the failing test [has been posted for review.](https://github.com/rust-lang/rust/pull/73655)++    The failure will likely be addressed very shortly.++ - In addition, as a result of inputs from the core team, engineers from Arm performed an audit of all tests that are currently marked **'only-x86_64'** and **'only-aarch64'** has been done. This was to ascertain whether past viewpoints and/or decisions that led to those markings are still valid. +     - The audit report is available [here.](https://docs.google.com/spreadsheets/d/1B-Jg1Ml6nAF6Tf9wJGTgqkFUNeJEejC3aMikGl6vXlc/edit?usp=sharing)++     - Work is being planned under the guidance of core team members to upstream patches that came out of the audit as well as to address any open questions that came about.++**1.b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.**++ - Two quarters ago, Arm donated a [Packet c2.large.arm system](https://www.packet.com/cloud/servers/c2-large-arm/) to the core team.++ - It is noteworthy that the core team have done a brilliant job in integrating this system into Rust's CI infrastructure while also circumventing myriad Github Actions security problems that popped up.++ - Over time, Arm intends to further donate newer and more capable hardware to this initiative.++**1.c. There must exist a robust and convenient CI integration for the target in question.**++ - The happy outcome of the core team's work with the donated system is that the system integrates largely seamlessly with existing Rust CI infrastructure. ++ - The integration has been verified to produce green runs once patches from the two outstanding PRs are in place.++**2.a. The long term viability of the existence of a target specific ecosystem should be clear.**++ - It is hard to concretely quantify this aspect.++ - That said, Arm AArch64 silicon is either already prevalent or is en-route to prevalance in a wide spectrum of application domains ranging from 'traditional' embedded systems at one end of the spectrum, on to mobile phones, clam-shell devices, desktops, vehicle autonomy controllers, datacenter servers etc all the way to high performance super-computers.++ - The evidence to that effect is too numerous to quote but generally easy to verify openly. ++ - It is fair to state that this is an ongoing reality which is unlikely to stop trending upwards and sidewards for the forseeable future.++ - Software stacks built for those domains predominantly use an AArch64 Linux kernel build.++ - Rust presents an attractive value proposition across all such domains, irrespective of the underlying processor architecture.++ - **As such, the Rust aarch64-unknown-linux-gnu target's ecosystem presents very strong viability for the long term.**++**2.b. The long term viability of supporting the target should be clear.**++ - It is hard to concretely quantify this aspect.++ - It is worth calling out, in the same vein as the previous point, that given the increasing prevalance of AArch64 silicon deployments and given Rust's general value proposition, **supporting the Rust aarch64-unknown-linux-gnu target presents very strong viability for the long term.**++**2.c. The target must have substantial and widespread interest within the Rust developer community.**++ - It is hard to concretely quantify this aspect.++ - It is generally fair to state that **there is already substantial and widespread interest for the aarch64-unknown-linux-gnu target in the Rust developer commmunity**.++ - It is also generally fair to state that there is a clear upward trend in the use of AArch64 systems as self hosted development environments. ++ - Most major operating system environments support hosted development on AArch64 based systems and this trend is increasing.++ - As a somewhat related note: Slow but steady progress is being made to support Windows AArch64 targets, initially for cross-platform development. This shall inevitably trend towards hosted development.++ - As such, **it is very likely that developer interest in Rust on aarch64-unknown-linux-gnu will continue to increase in the medium to long term.**++**2.d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.**++ - It is hard to concretely quantify this aspect.++ - Most major Arm software ecosystem partners are either already using Rust extensively, or are building up to extensive use. A few publically known examples are Microsoft and Google. There are many more.++ - Arm itself recognises Rust as an important component to consider in a broader horizontal safety and security foundation across multiple processor portfolios. ++ - Arm has dedicated a small team to help improve Rust for the aarch64-unknown-linux-gnu target.++ - **It is very likely that support for aarch64-unknown-linux-gnu in these organisations will trend upwards commensurate with the increasing prevalence of AArch64 silicon based systems.**++Points 3.a through 3.c from the [Guide-level explanation](#Guide-level-explanation) section above are addressed in the [Unresolved questions](#unresolved-questions) section below.++# Drawbacks+[drawbacks]: #drawbacks++**There is no drawback envisioned in promoting the Rust aarch64-unknown-linux-gnu to Tier-1.**++# Rationale and alternatives+[rationale-and-alternatives]: #rationale-and-alternatives++Given the narrative above, it is the opinion of the author that it would now be tactically sound to promote aarch64-unknown-linux-gnu to Tier-1.++- Inclusion in the Tier-1 category is very likely to be a self sustaining action in that it will promote increased scrutiny with increasing quality as a return. With that return, interest in Rust will grow further both in the AArch64 context and even more generally.++- Anecdotally, not having the Tier-1 'badge' has been seen to become an obstacle to increasing mindshare in Rust for this target. Organisations tend to associate a Tier-1 categorisation with better quality, suitability for key projects, longevity etc. With a reasonably justified Tier-1 badge in place, the likelihood is that such organisations will tend to promote the use of Rust in production.++As such **there is no substantially robust reason to not proceed with promoting aarch64-unknown-linux-gnu to Tier-1.**++# Prior art+[prior-art]: #prior-art++- Existing Tier-1 targets represent prior-art.++- It is appropriate to call out that no non i686 or x86_64 based target has ever been promoted to Tier-1. The fact that those targets have intrinsically supported self hosted development has arguably been a primary reason for their maturity.++- The aarch64-unknown-linux-gnu target is therefore somewhat uncharted territory.++However, as emphasised in the narrative thus far, **the aarch64-unknown-linux-gnu target now exhibits the properties required by a Tier-1 target as per the target tier policy.**++# Unresolved questions+[unresolved-questions]: #unresolved-questions++The following points are 'unresolved' at present. From the author's PoV, these are next steps, subject to agreement with the RFC reviewers.++**3.a. An approval from the Compiler Team that Tier-1 target requirements have been met.**++**3.b. An approval from the Infrastructure Team that the target in question may be integrated into CI.**++**3.c. An approval from the Release Team that supporting the target in question is viable in the long term.**++The expectation is that these will get resolved as a result of the discussion that ensues with this RFC posting.

I've added a commit that refactors the RFC to address @joshtriplett 's comments.

raw-bin

comment created time in 2 months

Pull request review commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

+- Feature Name: `promote-aarch64-unknown-linux-gnu-to-tier-1`+- Start Date: 2020-07-17+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Promote the Arm aarch64-unknown-linux-gnu Rust target to Tier-1.++# Motivation+[motivation]: #motivation++Arch64-unknown-linux-gnu is [currently a Tier-2 Rust target](https://forge.rust-lang.org/release/platform-support.html#tier-2), in accordance with the target tier policy articulated [here](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-09-20-target-tier-policy/).++In the last 2 quarters, very good progress has been made in understanding and filling the gaps that remain in the path to attaining Tier-1 status for this target.++As a direct result, those gaps have either already been filled or are very close to being filled.++As such, this RFC aims to:++- Evidence what has been done.++- On the basis of that evidence propose that the proceeedings to promote the aarch64-unknown-linux-gnu target to the Tier-1 category may please be kickstarted.++- Culminate in the actual promotion of the aarch64-unknown-linux-gnu target to Tier-1, including any and all of the relevant processes and actions as appropriate.++Please note that the narrative here doesn't always match the RFC template so some liberties may have been taken in the expression.++Please also note, by way of wilful disclosure, that this RFC's author is an employee of Arm.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++1. **In essence, the target tier policy for a Tier-1 target aims to obtain the following technical and tangible assurances:**++   a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.++   b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.++   c. There must exist a robust and convenient CI integration for the target in question.++2. **In addition, the target tier policy for a Tier-1 target aims to obtain the following stategic assurances:**++   a. The long term viability of the existence of a target specific ecosystem should be clear.++   b. The long term viability of supporting the target should be clear.++   c. The target must have substantial and widespread interest within the Rust developer community.++   d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.++3. **Finally, the target tier policy for a Tier-1 target aims to obtain the following approvals:**++   a. An approval from the Compiler Team that Tier-1 target requirements have been met.++   b. An approval from the Infrastructure Team that the target in question may be integrated into CI.++   c. An approval from the Release Team that supporting the target in question is viable in the long term.++The following section details how points 1 and 2 of the above assurances have either already been met or are close to being met. ++Items in point 3 are addressed in the section titled [Unresolved Questions](#Unresolved-questions). That is not to say that they are unresolved per se but more that they are proposed next steps.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++**1.a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.**++ - As of today, all tests pass reliably barring one test. + + - A fix addressing the failing test [has been posted for review.](https://github.com/rust-lang/rust/pull/73655)++    The failure will likely be addressed very shortly.++ - In addition, as a result of inputs from the core team, engineers from Arm performed an audit of all tests that are currently marked **'only-x86_64'** and **'only-aarch64'** has been done. This was to ascertain whether past viewpoints and/or decisions that led to those markings are still valid. +     - The audit report is available [here.](https://docs.google.com/spreadsheets/d/1B-Jg1Ml6nAF6Tf9wJGTgqkFUNeJEejC3aMikGl6vXlc/edit?usp=sharing)++     - Work is being planned under the guidance of core team members to upstream patches that came out of the audit as well as to address any open questions that came about.++**1.b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.**++ - Two quarters ago, Arm donated a [Packet c2.large.arm system](https://www.packet.com/cloud/servers/c2-large-arm/) to the core team.++ - It is noteworthy that the core team have done a brilliant job in integrating this system into Rust's CI infrastructure while also circumventing myriad Github Actions security problems that popped up.++ - Over time, Arm intends to further donate newer and more capable hardware to this initiative.++**1.c. There must exist a robust and convenient CI integration for the target in question.**++ - The happy outcome of the core team's work with the donated system is that the system integrates largely seamlessly with existing Rust CI infrastructure. ++ - The integration has been verified to produce green runs once patches from the two outstanding PRs are in place.++**2.a. The long term viability of the existence of a target specific ecosystem should be clear.**++ - It is hard to concretely quantify this aspect.++ - That said, Arm AArch64 silicon is either already prevalent or is en-route to prevalance in a wide spectrum of application domains ranging from 'traditional' embedded systems at one end of the spectrum, on to mobile phones, clam-shell devices, desktops, vehicle autonomy controllers, datacenter servers etc all the way to high performance super-computers.++ - The evidence to that effect is too numerous to quote but generally easy to verify openly. ++ - It is fair to state that this is an ongoing reality which is unlikely to stop trending upwards and sidewards for the forseeable future.++ - Software stacks built for those domains predominantly use an AArch64 Linux kernel build.++ - Rust presents an attractive value proposition across all such domains, irrespective of the underlying processor architecture.++ - **As such, the Rust aarch64-unknown-linux-gnu target's ecosystem presents very strong viability for the long term.**++**2.b. The long term viability of supporting the target should be clear.**++ - It is hard to concretely quantify this aspect.++ - It is worth calling out, in the same vein as the previous point, that given the increasing prevalance of AArch64 silicon deployments and given Rust's general value proposition, **supporting the Rust aarch64-unknown-linux-gnu target presents very strong viability for the long term.**++**2.c. The target must have substantial and widespread interest within the Rust developer community.**++ - It is hard to concretely quantify this aspect.++ - It is generally fair to state that **there is already substantial and widespread interest for the aarch64-unknown-linux-gnu target in the Rust developer commmunity**.

I've added a commit to address @JohnTitor's comment.

raw-bin

comment created time in 2 months

Pull request review commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

+- Feature Name: `promote-aarch64-unknown-linux-gnu-to-tier-1`+- Start Date: 2020-07-17+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Promote the Arm aarch64-unknown-linux-gnu Rust target to Tier-1.++# Motivation+[motivation]: #motivation++Arch64-unknown-linux-gnu is [currently a Tier-2 Rust target](https://forge.rust-lang.org/release/platform-support.html#tier-2), in accordance with the target tier policy articulated [here](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-09-20-target-tier-policy/).++In the last 2 quarters, very good progress has been made in understanding and filling the gaps that remain in the path to attaining Tier-1 status for this target.++As a direct result, those gaps have either already been filled or are very close to being filled.++As such, this RFC aims to:++- Evidence what has been done.++- On the basis of that evidence propose that the proceeedings to promote the aarch64-unknown-linux-gnu target to the Tier-1 category may please be kickstarted.

I've added a commit to address @JohnTitor's comments.

raw-bin

comment created time in 2 months

Pull request review commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

+- Feature Name: `promote-aarch64-unknown-linux-gnu-to-tier-1`+- Start Date: 2020-07-17+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Promote the Arm aarch64-unknown-linux-gnu Rust target to Tier-1.++# Motivation+[motivation]: #motivation++Arch64-unknown-linux-gnu is [currently a Tier-2 Rust target](https://forge.rust-lang.org/release/platform-support.html#tier-2), in accordance with the target tier policy articulated [here](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-09-20-target-tier-policy/).++In the last 2 quarters, very good progress has been made in understanding and filling the gaps that remain in the path to attaining Tier-1 status for this target.++As a direct result, those gaps have either already been filled or are very close to being filled.++As such, this RFC aims to:++- Evidence what has been done.++- On the basis of that evidence propose that the proceeedings to promote the aarch64-unknown-linux-gnu target to the Tier-1 category may please be kickstarted.++- Culminate in the actual promotion of the aarch64-unknown-linux-gnu target to Tier-1, including any and all of the relevant processes and actions as appropriate.++Please note that the narrative here doesn't always match the RFC template so some liberties may have been taken in the expression.++Please also note, by way of wilful disclosure, that this RFC's author is an employee of Arm.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++1. **In essence, the target tier policy for a Tier-1 target aims to obtain the following technical and tangible assurances:**++   a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.++   b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.++   c. There must exist a robust and convenient CI integration for the target in question.++2. **In addition, the target tier policy for a Tier-1 target aims to obtain the following stategic assurances:**++   a. The long term viability of the existence of a target specific ecosystem should be clear.++   b. The long term viability of supporting the target should be clear.++   c. The target must have substantial and widespread interest within the Rust developer community.++   d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.++3. **Finally, the target tier policy for a Tier-1 target aims to obtain the following approvals:**++   a. An approval from the Compiler Team that Tier-1 target requirements have been met.++   b. An approval from the Infrastructure Team that the target in question may be integrated into CI.++   c. An approval from the Release Team that supporting the target in question is viable in the long term.++The following section details how points 1 and 2 of the above assurances have either already been met or are close to being met. ++Items in point 3 are addressed in the section titled [Unresolved Questions](#Unresolved-questions). That is not to say that they are unresolved per se but more that they are proposed next steps.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++**1.a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.**++ - As of today, all tests pass reliably barring one test. + + - A fix addressing the failing test [has been posted for review.](https://github.com/rust-lang/rust/pull/73655)++    The failure will likely be addressed very shortly.++ - In addition, as a result of inputs from the core team, engineers from Arm performed an audit of all tests that are currently marked **'only-x86_64'** and **'only-aarch64'** has been done. This was to ascertain whether past viewpoints and/or decisions that led to those markings are still valid. +     - The audit report is available [here.](https://docs.google.com/spreadsheets/d/1B-Jg1Ml6nAF6Tf9wJGTgqkFUNeJEejC3aMikGl6vXlc/edit?usp=sharing)++     - Work is being planned under the guidance of core team members to upstream patches that came out of the audit as well as to address any open questions that came about.++**1.b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.**++ - Two quarters ago, Arm donated a [Packet c2.large.arm system](https://www.packet.com/cloud/servers/c2-large-arm/) to the core team.++ - It is noteworthy that the core team have done a brilliant job in integrating this system into Rust's CI infrastructure while also circumventing myriad Github Actions security problems that popped up.++ - Over time, Arm intends to further donate newer and more capable hardware to this initiative.++**1.c. There must exist a robust and convenient CI integration for the target in question.**++ - The happy outcome of the core team's work with the donated system is that the system integrates largely seamlessly with existing Rust CI infrastructure. ++ - The integration has been verified to produce green runs once patches from the two outstanding PRs are in place.++**2.a. The long term viability of the existence of a target specific ecosystem should be clear.**++ - It is hard to concretely quantify this aspect.++ - That said, Arm AArch64 silicon is either already prevalent or is en-route to prevalance in a wide spectrum of application domains ranging from 'traditional' embedded systems at one end of the spectrum, on to mobile phones, clam-shell devices, desktops, vehicle autonomy controllers, datacenter servers etc all the way to high performance super-computers.++ - The evidence to that effect is too numerous to quote but generally easy to verify openly. ++ - It is fair to state that this is an ongoing reality which is unlikely to stop trending upwards and sidewards for the forseeable future.++ - Software stacks built for those domains predominantly use an AArch64 Linux kernel build.++ - Rust presents an attractive value proposition across all such domains, irrespective of the underlying processor architecture.++ - **As such, the Rust aarch64-unknown-linux-gnu target's ecosystem presents very strong viability for the long term.**++**2.b. The long term viability of supporting the target should be clear.**++ - It is hard to concretely quantify this aspect.++ - It is worth calling out, in the same vein as the previous point, that given the increasing prevalance of AArch64 silicon deployments and given Rust's general value proposition, **supporting the Rust aarch64-unknown-linux-gnu target presents very strong viability for the long term.**++**2.c. The target must have substantial and widespread interest within the Rust developer community.**++ - It is hard to concretely quantify this aspect.++ - It is generally fair to state that **there is already substantial and widespread interest for the aarch64-unknown-linux-gnu target in the Rust developer commmunity**.++ - It is also generally fair to state that there is a clear upward trend in the use of AArch64 systems as self hosted development environments. ++ - Most major operating system environments support hosted development on AArch64 based systems and this trend is increasing.++ - As a somewhat related note: Slow but steady progress is being made to support Windows AArch64 targets, initially for cross-platform development. This shall inevitably trend towards hosted development.++ - As such, **it is very likely that developer interest in Rust on aarch64-unknown-linux-gnu will continue to increase in the medium to long term.**++**2.d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.**++ - It is hard to concretely quantify this aspect.++ - Most major Arm software ecosystem partners are either already using Rust extensively, or are building up to extensive use. A few publically known examples are Microsoft and Google. There are many more.++ - Arm itself recognises Rust as an important component to consider in a broader horizontal safety and security foundation across multiple processor portfolios. ++ - Arm has dedicated a small team to help improve Rust for the aarch64-unknown-linux-gnu target.

I've added commits to address comments from @JohnTitor and @lambda.

I'm setting up a sync with @Lokathor.

I've responded hopefully suitably to the other good comments.

I'm now going to resolve this conversation. Happy to engage further if needed.

raw-bin

comment created time in 2 months

Pull request review commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

+- Feature Name: `promote-aarch64-unknown-linux-gnu-to-tier-1`+- Start Date: 2020-07-17+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Promote the Arm aarch64-unknown-linux-gnu Rust target to Tier-1.++# Motivation+[motivation]: #motivation++Arch64-unknown-linux-gnu is [currently a Tier-2 Rust target](https://forge.rust-lang.org/release/platform-support.html#tier-2), in accordance with the target tier policy articulated [here](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-09-20-target-tier-policy/).++In the last 2 quarters, very good progress has been made in understanding and filling the gaps that remain in the path to attaining Tier-1 status for this target.++As a direct result, those gaps have either already been filled or are very close to being filled.++As such, this RFC aims to:++- Evidence what has been done.++- On the basis of that evidence propose that the proceeedings to promote the aarch64-unknown-linux-gnu target to the Tier-1 category may please be kickstarted.++- Culminate in the actual promotion of the aarch64-unknown-linux-gnu target to Tier-1, including any and all of the relevant processes and actions as appropriate.++Please note that the narrative here doesn't always match the RFC template so some liberties may have been taken in the expression.++Please also note, by way of wilful disclosure, that this RFC's author is an employee of Arm.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++1. **In essence, the target tier policy for a Tier-1 target aims to obtain the following technical and tangible assurances:**++   a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.++   b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.++   c. There must exist a robust and convenient CI integration for the target in question.++2. **In addition, the target tier policy for a Tier-1 target aims to obtain the following stategic assurances:**++   a. The long term viability of the existence of a target specific ecosystem should be clear.++   b. The long term viability of supporting the target should be clear.++   c. The target must have substantial and widespread interest within the Rust developer community.++   d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.++3. **Finally, the target tier policy for a Tier-1 target aims to obtain the following approvals:**++   a. An approval from the Compiler Team that Tier-1 target requirements have been met.++   b. An approval from the Infrastructure Team that the target in question may be integrated into CI.++   c. An approval from the Release Team that supporting the target in question is viable in the long term.++The following section details how points 1 and 2 of the above assurances have either already been met or are close to being met. ++Items in point 3 are addressed in the section titled [Unresolved Questions](#Unresolved-questions). That is not to say that they are unresolved per se but more that they are proposed next steps.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++**1.a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.**++ - As of today, all tests pass reliably barring one test. + + - A fix addressing the failing test [has been posted for review.](https://github.com/rust-lang/rust/pull/73655)++    The failure will likely be addressed very shortly.++ - In addition, as a result of inputs from the core team, engineers from Arm performed an audit of all tests that are currently marked **'only-x86_64'** and **'only-aarch64'** has been done. This was to ascertain whether past viewpoints and/or decisions that led to those markings are still valid. +     - The audit report is available [here.](https://docs.google.com/spreadsheets/d/1B-Jg1Ml6nAF6Tf9wJGTgqkFUNeJEejC3aMikGl6vXlc/edit?usp=sharing)++     - Work is being planned under the guidance of core team members to upstream patches that came out of the audit as well as to address any open questions that came about.++**1.b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.**++ - Two quarters ago, Arm donated a [Packet c2.large.arm system](https://www.packet.com/cloud/servers/c2-large-arm/) to the core team.++ - It is noteworthy that the core team have done a brilliant job in integrating this system into Rust's CI infrastructure while also circumventing myriad Github Actions security problems that popped up.++ - Over time, Arm intends to further donate newer and more capable hardware to this initiative.++**1.c. There must exist a robust and convenient CI integration for the target in question.**++ - The happy outcome of the core team's work with the donated system is that the system integrates largely seamlessly with existing Rust CI infrastructure. ++ - The integration has been verified to produce green runs once patches from the two outstanding PRs are in place.++**2.a. The long term viability of the existence of a target specific ecosystem should be clear.**++ - It is hard to concretely quantify this aspect.++ - That said, Arm AArch64 silicon is either already prevalent or is en-route to prevalance in a wide spectrum of application domains ranging from 'traditional' embedded systems at one end of the spectrum, on to mobile phones, clam-shell devices, desktops, vehicle autonomy controllers, datacenter servers etc all the way to high performance super-computers.++ - The evidence to that effect is too numerous to quote but generally easy to verify openly. ++ - It is fair to state that this is an ongoing reality which is unlikely to stop trending upwards and sidewards for the forseeable future.++ - Software stacks built for those domains predominantly use an AArch64 Linux kernel build.++ - Rust presents an attractive value proposition across all such domains, irrespective of the underlying processor architecture.++ - **As such, the Rust aarch64-unknown-linux-gnu target's ecosystem presents very strong viability for the long term.**++**2.b. The long term viability of supporting the target should be clear.**++ - It is hard to concretely quantify this aspect.++ - It is worth calling out, in the same vein as the previous point, that given the increasing prevalance of AArch64 silicon deployments and given Rust's general value proposition, **supporting the Rust aarch64-unknown-linux-gnu target presents very strong viability for the long term.**++**2.c. The target must have substantial and widespread interest within the Rust developer community.**++ - It is hard to concretely quantify this aspect.++ - It is generally fair to state that **there is already substantial and widespread interest for the aarch64-unknown-linux-gnu target in the Rust developer commmunity**.++ - It is also generally fair to state that there is a clear upward trend in the use of AArch64 systems as self hosted development environments. ++ - Most major operating system environments support hosted development on AArch64 based systems and this trend is increasing.++ - As a somewhat related note: Slow but steady progress is being made to support Windows AArch64 targets, initially for cross-platform development. This shall inevitably trend towards hosted development.++ - As such, **it is very likely that developer interest in Rust on aarch64-unknown-linux-gnu will continue to increase in the medium to long term.**++**2.d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.**++ - It is hard to concretely quantify this aspect.++ - Most major Arm software ecosystem partners are either already using Rust extensively, or are building up to extensive use. A few publically known examples are Microsoft and Google. There are many more.

I've added a commit to address @lambda 's comments.

Also responded hopefully suitably to the other comments here.

I'm going to resolve this conversation. Happy to engage further as needed.

raw-bin

comment created time in 2 months

Pull request review commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

+- Feature Name: `promote-aarch64-unknown-linux-gnu-to-tier-1`+- Start Date: 2020-07-17+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Promote the Arm aarch64-unknown-linux-gnu Rust target to Tier-1.++# Motivation+[motivation]: #motivation++Arch64-unknown-linux-gnu is [currently a Tier-2 Rust target](https://forge.rust-lang.org/release/platform-support.html#tier-2), in accordance with the target tier policy articulated [here](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-09-20-target-tier-policy/).++In the last 2 quarters, very good progress has been made in understanding and filling the gaps that remain in the path to attaining Tier-1 status for this target.++As a direct result, those gaps have either already been filled or are very close to being filled.++As such, this RFC aims to:++- Evidence what has been done.++- On the basis of that evidence propose that the proceeedings to promote the aarch64-unknown-linux-gnu target to the Tier-1 category may please be kickstarted.++- Culminate in the actual promotion of the aarch64-unknown-linux-gnu target to Tier-1, including any and all of the relevant processes and actions as appropriate.++Please note that the narrative here doesn't always match the RFC template so some liberties may have been taken in the expression.++Please also note, by way of wilful disclosure, that this RFC's author is an employee of Arm.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++1. **In essence, the target tier policy for a Tier-1 target aims to obtain the following technical and tangible assurances:**++   a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.++   b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.++   c. There must exist a robust and convenient CI integration for the target in question.++2. **In addition, the target tier policy for a Tier-1 target aims to obtain the following stategic assurances:**++   a. The long term viability of the existence of a target specific ecosystem should be clear.++   b. The long term viability of supporting the target should be clear.++   c. The target must have substantial and widespread interest within the Rust developer community.++   d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.++3. **Finally, the target tier policy for a Tier-1 target aims to obtain the following approvals:**++   a. An approval from the Compiler Team that Tier-1 target requirements have been met.++   b. An approval from the Infrastructure Team that the target in question may be integrated into CI.++   c. An approval from the Release Team that supporting the target in question is viable in the long term.++The following section details how points 1 and 2 of the above assurances have either already been met or are close to being met. ++Items in point 3 are addressed in the section titled [Unresolved Questions](#Unresolved-questions). That is not to say that they are unresolved per se but more that they are proposed next steps.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++**1.a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.**++ - As of today, all tests pass reliably barring one test. + + - A fix addressing the failing test [has been posted for review.](https://github.com/rust-lang/rust/pull/73655)++    The failure will likely be addressed very shortly.++ - In addition, as a result of inputs from the core team, engineers from Arm performed an audit of all tests that are currently marked **'only-x86_64'** and **'only-aarch64'** has been done. This was to ascertain whether past viewpoints and/or decisions that led to those markings are still valid. +     - The audit report is available [here.](https://docs.google.com/spreadsheets/d/1B-Jg1Ml6nAF6Tf9wJGTgqkFUNeJEejC3aMikGl6vXlc/edit?usp=sharing)++     - Work is being planned under the guidance of core team members to upstream patches that came out of the audit as well as to address any open questions that came about.++**1.b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.**++ - Two quarters ago, Arm donated a [Packet c2.large.arm system](https://www.packet.com/cloud/servers/c2-large-arm/) to the core team.++ - It is noteworthy that the core team have done a brilliant job in integrating this system into Rust's CI infrastructure while also circumventing myriad Github Actions security problems that popped up.++ - Over time, Arm intends to further donate newer and more capable hardware to this initiative.++**1.c. There must exist a robust and convenient CI integration for the target in question.**++ - The happy outcome of the core team's work with the donated system is that the system integrates largely seamlessly with existing Rust CI infrastructure. ++ - The integration has been verified to produce green runs once patches from the two outstanding PRs are in place.++**2.a. The long term viability of the existence of a target specific ecosystem should be clear.**++ - It is hard to concretely quantify this aspect.++ - That said, Arm AArch64 silicon is either already prevalent or is en-route to prevalance in a wide spectrum of application domains ranging from 'traditional' embedded systems at one end of the spectrum, on to mobile phones, clam-shell devices, desktops, vehicle autonomy controllers, datacenter servers etc all the way to high performance super-computers.++ - The evidence to that effect is too numerous to quote but generally easy to verify openly. ++ - It is fair to state that this is an ongoing reality which is unlikely to stop trending upwards and sidewards for the forseeable future.++ - Software stacks built for those domains predominantly use an AArch64 Linux kernel build.++ - Rust presents an attractive value proposition across all such domains, irrespective of the underlying processor architecture.++ - **As such, the Rust aarch64-unknown-linux-gnu target's ecosystem presents very strong viability for the long term.**++**2.b. The long term viability of supporting the target should be clear.**++ - It is hard to concretely quantify this aspect.++ - It is worth calling out, in the same vein as the previous point, that given the increasing prevalance of AArch64 silicon deployments and given Rust's general value proposition, **supporting the Rust aarch64-unknown-linux-gnu target presents very strong viability for the long term.**++**2.c. The target must have substantial and widespread interest within the Rust developer community.**++ - It is hard to concretely quantify this aspect.++ - It is generally fair to state that **there is already substantial and widespread interest for the aarch64-unknown-linux-gnu target in the Rust developer commmunity**.++ - It is also generally fair to state that there is a clear upward trend in the use of AArch64 systems as self hosted development environments. ++ - Most major operating system environments support hosted development on AArch64 based systems and this trend is increasing.++ - As a somewhat related note: Slow but steady progress is being made to support Windows AArch64 targets, initially for cross-platform development. This shall inevitably trend towards hosted development.++ - As such, **it is very likely that developer interest in Rust on aarch64-unknown-linux-gnu will continue to increase in the medium to long term.**++**2.d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.**++ - It is hard to concretely quantify this aspect.++ - Most major Arm software ecosystem partners are either already using Rust extensively, or are building up to extensive use. A few publically known examples are Microsoft and Google. There are many more.++ - Arm itself recognises Rust as an important component to consider in a broader horizontal safety and security foundation across multiple processor portfolios. ++ - Arm has dedicated a small team to help improve Rust for the aarch64-unknown-linux-gnu target.++ - **It is very likely that support for aarch64-unknown-linux-gnu in these organisations will trend upwards commensurate with the increasing prevalence of AArch64 silicon based systems.**++Points 3.a through 3.c from the [Guide-level explanation](#Guide-level-explanation) section above are addressed in the [Unresolved questions](#unresolved-questions) section below.++# Drawbacks+[drawbacks]: #drawbacks++**There is no drawback envisioned in promoting the Rust aarch64-unknown-linux-gnu to Tier-1.**

I've added a commit to the PR that addresses comments made by @lambda.

I think I've responded suitably to the other good comments.

I'll now resolve this conversation. Happy to engage further if needed.

raw-bin

comment created time in 2 months

push eventraw-bin/rfcs

Robin Randhawa

commit sha 08b0ff1d85c4638de26469e3ef8252a44a4ba12f

RFC: aarch64-unknown-linux-gnu Tier1: Addres l4l's comments Spellfix.

view details

Robin Randhawa

commit sha f5e4812ab2ca751dba4b9b36a045c732c06b2b5d

RFC: aarch64-unknown-linux-gnu: Tier-1: Address JohnTitor's comments Spellfixes.

view details

Robin Randhawa

commit sha 93234dd1395933f4e3f5937514b2720b684bb364

RFC: aarch64-unknown-linux-gnu: Tier-1: Address joshtriplett's comments Refactor the required next steps into the summary.

view details

Robin Randhawa

commit sha 4d591143275126b2f7ab2128c53578c6e1197769

RFC: aarch64-unknown-linux-gnu: Tier-1: Address lambda's comments Add Amazon as an example of an organisation doing prominent work with Rust.

view details

Robin Randhawa

commit sha d42cf187a38c7fbd50d6f38e54439f497802ab6b

RFC: aarch64-unknown-linux-gnu Tier-1: Address lambda and JohnTitor's comments Add references to the Arm marker team and the Zulip t-compiler/arm stream.

view details

Robin Randhawa

commit sha 0b8b3ccba5c9c8655a6a965cf2148de3e062e7d8

RFC: aarch64-unknown-linux-gnu: Tier-1: Spellfix

view details

push time in 2 months

Pull request review commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

+- Feature Name: `promote-aarch64-unknown-linux-gnu-to-tier-1`+- Start Date: 2020-07-17+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Promote the Arm aarch64-unknown-linux-gnu Rust target to Tier-1.++# Motivation+[motivation]: #motivation++Arch64-unknown-linux-gnu is [currently a Tier-2 Rust target](https://forge.rust-lang.org/release/platform-support.html#tier-2), in accordance with the target tier policy articulated [here](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-09-20-target-tier-policy/).++In the last 2 quarters, very good progress has been made in understanding and filling the gaps that remain in the path to attaining Tier-1 status for this target.++As a direct result, those gaps have either already been filled or are very close to being filled.++As such, this RFC aims to:++- Evidence what has been done.++- On the basis of that evidence propose that the proceeedings to promote the aarch64-unknown-linux-gnu target to the Tier-1 category may please be kickstarted.++- Culminate in the actual promotion of the aarch64-unknown-linux-gnu target to Tier-1, including any and all of the relevant processes and actions as appropriate.++Please note that the narrative here doesn't always match the RFC template so some liberties may have been taken in the expression.++Please also note, by way of wilful disclosure, that this RFC's author is an employee of Arm.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++1. **In essence, the target tier policy for a Tier-1 target aims to obtain the following technical and tangible assurances:**++   a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.++   b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.++   c. There must exist a robust and convenient CI integration for the target in question.++2. **In addition, the target tier policy for a Tier-1 target aims to obtain the following stategic assurances:**++   a. The long term viability of the existence of a target specific ecosystem should be clear.++   b. The long term viability of supporting the target should be clear.++   c. The target must have substantial and widespread interest within the Rust developer community.++   d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.++3. **Finally, the target tier policy for a Tier-1 target aims to obtain the following approvals:**++   a. An approval from the Compiler Team that Tier-1 target requirements have been met.++   b. An approval from the Infrastructure Team that the target in question may be integrated into CI.++   c. An approval from the Release Team that supporting the target in question is viable in the long term.++The following section details how points 1 and 2 of the above assurances have either already been met or are close to being met. ++Items in point 3 are addressed in the section titled [Unresolved Questions](#Unresolved-questions). That is not to say that they are unresolved per se but more that they are proposed next steps.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++**1.a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.**++ - As of today, all tests pass reliably barring one test. + + - A fix addressing the failing test [has been posted for review.](https://github.com/rust-lang/rust/pull/73655)++    The failure will likely be addressed very shortly.++ - In addition, as a result of inputs from the core team, engineers from Arm performed an audit of all tests that are currently marked **'only-x86_64'** and **'only-aarch64'** has been done. This was to ascertain whether past viewpoints and/or decisions that led to those markings are still valid. +     - The audit report is available [here.](https://docs.google.com/spreadsheets/d/1B-Jg1Ml6nAF6Tf9wJGTgqkFUNeJEejC3aMikGl6vXlc/edit?usp=sharing)++     - Work is being planned under the guidance of core team members to upstream patches that came out of the audit as well as to address any open questions that came about.++**1.b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.**++ - Two quarters ago, Arm donated a [Packet c2.large.arm system](https://www.packet.com/cloud/servers/c2-large-arm/) to the core team.++ - It is noteworthy that the core team have done a brilliant job in integrating this system into Rust's CI infrastructure while also circumventing myriad Github Actions security problems that popped up.++ - Over time, Arm intends to further donate newer and more capable hardware to this initiative.++**1.c. There must exist a robust and convenient CI integration for the target in question.**++ - The happy outcome of the core team's work with the donated system is that the system integrates largely seamlessly with existing Rust CI infrastructure. ++ - The integration has been verified to produce green runs once patches from the two outstanding PRs are in place.++**2.a. The long term viability of the existence of a target specific ecosystem should be clear.**++ - It is hard to concretely quantify this aspect.++ - That said, Arm AArch64 silicon is either already prevalent or is en-route to prevalance in a wide spectrum of application domains ranging from 'traditional' embedded systems at one end of the spectrum, on to mobile phones, clam-shell devices, desktops, vehicle autonomy controllers, datacenter servers etc all the way to high performance super-computers.++ - The evidence to that effect is too numerous to quote but generally easy to verify openly. ++ - It is fair to state that this is an ongoing reality which is unlikely to stop trending upwards and sidewards for the forseeable future.++ - Software stacks built for those domains predominantly use an AArch64 Linux kernel build.++ - Rust presents an attractive value proposition across all such domains, irrespective of the underlying processor architecture.++ - **As such, the Rust aarch64-unknown-linux-gnu target's ecosystem presents very strong viability for the long term.**++**2.b. The long term viability of supporting the target should be clear.**++ - It is hard to concretely quantify this aspect.++ - It is worth calling out, in the same vein as the previous point, that given the increasing prevalance of AArch64 silicon deployments and given Rust's general value proposition, **supporting the Rust aarch64-unknown-linux-gnu target presents very strong viability for the long term.**++**2.c. The target must have substantial and widespread interest within the Rust developer community.**++ - It is hard to concretely quantify this aspect.++ - It is generally fair to state that **there is already substantial and widespread interest for the aarch64-unknown-linux-gnu target in the Rust developer commmunity**.++ - It is also generally fair to state that there is a clear upward trend in the use of AArch64 systems as self hosted development environments. ++ - Most major operating system environments support hosted development on AArch64 based systems and this trend is increasing.++ - As a somewhat related note: Slow but steady progress is being made to support Windows AArch64 targets, initially for cross-platform development. This shall inevitably trend towards hosted development.++ - As such, **it is very likely that developer interest in Rust on aarch64-unknown-linux-gnu will continue to increase in the medium to long term.**++**2.d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.**++ - It is hard to concretely quantify this aspect.++ - Most major Arm software ecosystem partners are either already using Rust extensively, or are building up to extensive use. A few publically known examples are Microsoft and Google. There are many more.++ - Arm itself recognises Rust as an important component to consider in a broader horizontal safety and security foundation across multiple processor portfolios. ++ - Arm has dedicated a small team to help improve Rust for the aarch64-unknown-linux-gnu target.

Hey @Lokathor: Thanks for sharing! Yes we should sync up! I'll fix something up with you and the team ASAP!

raw-bin

comment created time in 2 months

Pull request review commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

+- Feature Name: `promote-aarch64-unknown-linux-gnu-to-tier-1`+- Start Date: 2020-07-17+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Promote the Arm aarch64-unknown-linux-gnu Rust target to Tier-1.++# Motivation+[motivation]: #motivation++Arch64-unknown-linux-gnu is [currently a Tier-2 Rust target](https://forge.rust-lang.org/release/platform-support.html#tier-2), in accordance with the target tier policy articulated [here](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-09-20-target-tier-policy/).++In the last 2 quarters, very good progress has been made in understanding and filling the gaps that remain in the path to attaining Tier-1 status for this target.++As a direct result, those gaps have either already been filled or are very close to being filled.++As such, this RFC aims to:++- Evidence what has been done.++- On the basis of that evidence propose that the proceeedings to promote the aarch64-unknown-linux-gnu target to the Tier-1 category may please be kickstarted.++- Culminate in the actual promotion of the aarch64-unknown-linux-gnu target to Tier-1, including any and all of the relevant processes and actions as appropriate.++Please note that the narrative here doesn't always match the RFC template so some liberties may have been taken in the expression.++Please also note, by way of wilful disclosure, that this RFC's author is an employee of Arm.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++1. **In essence, the target tier policy for a Tier-1 target aims to obtain the following technical and tangible assurances:**++   a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.++   b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.++   c. There must exist a robust and convenient CI integration for the target in question.++2. **In addition, the target tier policy for a Tier-1 target aims to obtain the following stategic assurances:**++   a. The long term viability of the existence of a target specific ecosystem should be clear.++   b. The long term viability of supporting the target should be clear.++   c. The target must have substantial and widespread interest within the Rust developer community.++   d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.++3. **Finally, the target tier policy for a Tier-1 target aims to obtain the following approvals:**++   a. An approval from the Compiler Team that Tier-1 target requirements have been met.++   b. An approval from the Infrastructure Team that the target in question may be integrated into CI.++   c. An approval from the Release Team that supporting the target in question is viable in the long term.++The following section details how points 1 and 2 of the above assurances have either already been met or are close to being met. ++Items in point 3 are addressed in the section titled [Unresolved Questions](#Unresolved-questions). That is not to say that they are unresolved per se but more that they are proposed next steps.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++**1.a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.**++ - As of today, all tests pass reliably barring one test. + + - A fix addressing the failing test [has been posted for review.](https://github.com/rust-lang/rust/pull/73655)++    The failure will likely be addressed very shortly.++ - In addition, as a result of inputs from the core team, engineers from Arm performed an audit of all tests that are currently marked **'only-x86_64'** and **'only-aarch64'** has been done. This was to ascertain whether past viewpoints and/or decisions that led to those markings are still valid. +     - The audit report is available [here.](https://docs.google.com/spreadsheets/d/1B-Jg1Ml6nAF6Tf9wJGTgqkFUNeJEejC3aMikGl6vXlc/edit?usp=sharing)++     - Work is being planned under the guidance of core team members to upstream patches that came out of the audit as well as to address any open questions that came about.++**1.b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.**++ - Two quarters ago, Arm donated a [Packet c2.large.arm system](https://www.packet.com/cloud/servers/c2-large-arm/) to the core team.++ - It is noteworthy that the core team have done a brilliant job in integrating this system into Rust's CI infrastructure while also circumventing myriad Github Actions security problems that popped up.++ - Over time, Arm intends to further donate newer and more capable hardware to this initiative.++**1.c. There must exist a robust and convenient CI integration for the target in question.**++ - The happy outcome of the core team's work with the donated system is that the system integrates largely seamlessly with existing Rust CI infrastructure. ++ - The integration has been verified to produce green runs once patches from the two outstanding PRs are in place.++**2.a. The long term viability of the existence of a target specific ecosystem should be clear.**++ - It is hard to concretely quantify this aspect.++ - That said, Arm AArch64 silicon is either already prevalent or is en-route to prevalance in a wide spectrum of application domains ranging from 'traditional' embedded systems at one end of the spectrum, on to mobile phones, clam-shell devices, desktops, vehicle autonomy controllers, datacenter servers etc all the way to high performance super-computers.++ - The evidence to that effect is too numerous to quote but generally easy to verify openly. ++ - It is fair to state that this is an ongoing reality which is unlikely to stop trending upwards and sidewards for the forseeable future.++ - Software stacks built for those domains predominantly use an AArch64 Linux kernel build.++ - Rust presents an attractive value proposition across all such domains, irrespective of the underlying processor architecture.++ - **As such, the Rust aarch64-unknown-linux-gnu target's ecosystem presents very strong viability for the long term.**++**2.b. The long term viability of supporting the target should be clear.**++ - It is hard to concretely quantify this aspect.++ - It is worth calling out, in the same vein as the previous point, that given the increasing prevalance of AArch64 silicon deployments and given Rust's general value proposition, **supporting the Rust aarch64-unknown-linux-gnu target presents very strong viability for the long term.**++**2.c. The target must have substantial and widespread interest within the Rust developer community.**++ - It is hard to concretely quantify this aspect.++ - It is generally fair to state that **there is already substantial and widespread interest for the aarch64-unknown-linux-gnu target in the Rust developer commmunity**.++ - It is also generally fair to state that there is a clear upward trend in the use of AArch64 systems as self hosted development environments. ++ - Most major operating system environments support hosted development on AArch64 based systems and this trend is increasing.++ - As a somewhat related note: Slow but steady progress is being made to support Windows AArch64 targets, initially for cross-platform development. This shall inevitably trend towards hosted development.++ - As such, **it is very likely that developer interest in Rust on aarch64-unknown-linux-gnu will continue to increase in the medium to long term.**++**2.d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.**++ - It is hard to concretely quantify this aspect.++ - Most major Arm software ecosystem partners are either already using Rust extensively, or are building up to extensive use. A few publically known examples are Microsoft and Google. There are many more.++ - Arm itself recognises Rust as an important component to consider in a broader horizontal safety and security foundation across multiple processor portfolios. ++ - Arm has dedicated a small team to help improve Rust for the aarch64-unknown-linux-gnu target.

Fair point.

Me and the team have been put on the #t-compiler/arm Zulip channel by the core team. I’ll add a reference.

Contributions have begun but it’s early days to be fair. All of us are embedded systems folks and Rust aficionados.

Given the official mandate - which is to work with the community towards improving Rust on AArch64 - contributions will tick upwards. We’ve a number of streams in flight to do with SIMD intrinsics - all in consultation with the core team.

As a related aside: A key value add here is to act as a bi-directional channel to more specialised groups inside Arm working on processor architecture, toolchains etc.

The intent is to get Rust to pick up on the continuous innovations in the Arm architecture. Stuff like memory tagging extensions, capability architecture etc but I digress.

raw-bin

comment created time in 2 months

Pull request review commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

+- Feature Name: `promote-aarch64-unknown-linux-gnu-to-tier-1`+- Start Date: 2020-07-17+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Promote the Arm aarch64-unknown-linux-gnu Rust target to Tier-1.++# Motivation+[motivation]: #motivation++Arch64-unknown-linux-gnu is [currently a Tier-2 Rust target](https://forge.rust-lang.org/release/platform-support.html#tier-2), in accordance with the target tier policy articulated [here](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-09-20-target-tier-policy/).++In the last 2 quarters, very good progress has been made in understanding and filling the gaps that remain in the path to attaining Tier-1 status for this target.++As a direct result, those gaps have either already been filled or are very close to being filled.++As such, this RFC aims to:++- Evidence what has been done.++- On the basis of that evidence propose that the proceeedings to promote the aarch64-unknown-linux-gnu target to the Tier-1 category may please be kickstarted.++- Culminate in the actual promotion of the aarch64-unknown-linux-gnu target to Tier-1, including any and all of the relevant processes and actions as appropriate.++Please note that the narrative here doesn't always match the RFC template so some liberties may have been taken in the expression.++Please also note, by way of wilful disclosure, that this RFC's author is an employee of Arm.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++1. **In essence, the target tier policy for a Tier-1 target aims to obtain the following technical and tangible assurances:**++   a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.++   b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.++   c. There must exist a robust and convenient CI integration for the target in question.++2. **In addition, the target tier policy for a Tier-1 target aims to obtain the following stategic assurances:**++   a. The long term viability of the existence of a target specific ecosystem should be clear.++   b. The long term viability of supporting the target should be clear.++   c. The target must have substantial and widespread interest within the Rust developer community.++   d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.++3. **Finally, the target tier policy for a Tier-1 target aims to obtain the following approvals:**++   a. An approval from the Compiler Team that Tier-1 target requirements have been met.++   b. An approval from the Infrastructure Team that the target in question may be integrated into CI.++   c. An approval from the Release Team that supporting the target in question is viable in the long term.++The following section details how points 1 and 2 of the above assurances have either already been met or are close to being met. ++Items in point 3 are addressed in the section titled [Unresolved Questions](#Unresolved-questions). That is not to say that they are unresolved per se but more that they are proposed next steps.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++**1.a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.**++ - As of today, all tests pass reliably barring one test. + + - A fix addressing the failing test [has been posted for review.](https://github.com/rust-lang/rust/pull/73655)++    The failure will likely be addressed very shortly.++ - In addition, as a result of inputs from the core team, engineers from Arm performed an audit of all tests that are currently marked **'only-x86_64'** and **'only-aarch64'** has been done. This was to ascertain whether past viewpoints and/or decisions that led to those markings are still valid. +     - The audit report is available [here.](https://docs.google.com/spreadsheets/d/1B-Jg1Ml6nAF6Tf9wJGTgqkFUNeJEejC3aMikGl6vXlc/edit?usp=sharing)++     - Work is being planned under the guidance of core team members to upstream patches that came out of the audit as well as to address any open questions that came about.++**1.b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.**++ - Two quarters ago, Arm donated a [Packet c2.large.arm system](https://www.packet.com/cloud/servers/c2-large-arm/) to the core team.++ - It is noteworthy that the core team have done a brilliant job in integrating this system into Rust's CI infrastructure while also circumventing myriad Github Actions security problems that popped up.++ - Over time, Arm intends to further donate newer and more capable hardware to this initiative.++**1.c. There must exist a robust and convenient CI integration for the target in question.**++ - The happy outcome of the core team's work with the donated system is that the system integrates largely seamlessly with existing Rust CI infrastructure. ++ - The integration has been verified to produce green runs once patches from the two outstanding PRs are in place.++**2.a. The long term viability of the existence of a target specific ecosystem should be clear.**++ - It is hard to concretely quantify this aspect.++ - That said, Arm AArch64 silicon is either already prevalent or is en-route to prevalance in a wide spectrum of application domains ranging from 'traditional' embedded systems at one end of the spectrum, on to mobile phones, clam-shell devices, desktops, vehicle autonomy controllers, datacenter servers etc all the way to high performance super-computers.++ - The evidence to that effect is too numerous to quote but generally easy to verify openly. ++ - It is fair to state that this is an ongoing reality which is unlikely to stop trending upwards and sidewards for the forseeable future.++ - Software stacks built for those domains predominantly use an AArch64 Linux kernel build.++ - Rust presents an attractive value proposition across all such domains, irrespective of the underlying processor architecture.++ - **As such, the Rust aarch64-unknown-linux-gnu target's ecosystem presents very strong viability for the long term.**++**2.b. The long term viability of supporting the target should be clear.**++ - It is hard to concretely quantify this aspect.++ - It is worth calling out, in the same vein as the previous point, that given the increasing prevalance of AArch64 silicon deployments and given Rust's general value proposition, **supporting the Rust aarch64-unknown-linux-gnu target presents very strong viability for the long term.**++**2.c. The target must have substantial and widespread interest within the Rust developer community.**++ - It is hard to concretely quantify this aspect.++ - It is generally fair to state that **there is already substantial and widespread interest for the aarch64-unknown-linux-gnu target in the Rust developer commmunity**.++ - It is also generally fair to state that there is a clear upward trend in the use of AArch64 systems as self hosted development environments. ++ - Most major operating system environments support hosted development on AArch64 based systems and this trend is increasing.++ - As a somewhat related note: Slow but steady progress is being made to support Windows AArch64 targets, initially for cross-platform development. This shall inevitably trend towards hosted development.++ - As such, **it is very likely that developer interest in Rust on aarch64-unknown-linux-gnu will continue to increase in the medium to long term.**++**2.d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.**++ - It is hard to concretely quantify this aspect.++ - Most major Arm software ecosystem partners are either already using Rust extensively, or are building up to extensive use. A few publically known examples are Microsoft and Google. There are many more.

Hi again.

Fair point about Amazon. Will fix.

I simply mentioned orgs I was directly involved with on impulse.

Thanks

raw-bin

comment created time in 2 months

Pull request review commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

+- Feature Name: `promote-aarch64-unknown-linux-gnu-to-tier-1`+- Start Date: 2020-07-17+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Promote the Arm aarch64-unknown-linux-gnu Rust target to Tier-1.++# Motivation+[motivation]: #motivation++Arch64-unknown-linux-gnu is [currently a Tier-2 Rust target](https://forge.rust-lang.org/release/platform-support.html#tier-2), in accordance with the target tier policy articulated [here](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-09-20-target-tier-policy/).++In the last 2 quarters, very good progress has been made in understanding and filling the gaps that remain in the path to attaining Tier-1 status for this target.++As a direct result, those gaps have either already been filled or are very close to being filled.++As such, this RFC aims to:++- Evidence what has been done.++- On the basis of that evidence propose that the proceeedings to promote the aarch64-unknown-linux-gnu target to the Tier-1 category may please be kickstarted.++- Culminate in the actual promotion of the aarch64-unknown-linux-gnu target to Tier-1, including any and all of the relevant processes and actions as appropriate.++Please note that the narrative here doesn't always match the RFC template so some liberties may have been taken in the expression.++Please also note, by way of wilful disclosure, that this RFC's author is an employee of Arm.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++1. **In essence, the target tier policy for a Tier-1 target aims to obtain the following technical and tangible assurances:**++   a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.++   b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.++   c. There must exist a robust and convenient CI integration for the target in question.++2. **In addition, the target tier policy for a Tier-1 target aims to obtain the following stategic assurances:**++   a. The long term viability of the existence of a target specific ecosystem should be clear.++   b. The long term viability of supporting the target should be clear.++   c. The target must have substantial and widespread interest within the Rust developer community.++   d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.++3. **Finally, the target tier policy for a Tier-1 target aims to obtain the following approvals:**++   a. An approval from the Compiler Team that Tier-1 target requirements have been met.++   b. An approval from the Infrastructure Team that the target in question may be integrated into CI.++   c. An approval from the Release Team that supporting the target in question is viable in the long term.++The following section details how points 1 and 2 of the above assurances have either already been met or are close to being met. ++Items in point 3 are addressed in the section titled [Unresolved Questions](#Unresolved-questions). That is not to say that they are unresolved per se but more that they are proposed next steps.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++**1.a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.**++ - As of today, all tests pass reliably barring one test. + + - A fix addressing the failing test [has been posted for review.](https://github.com/rust-lang/rust/pull/73655)++    The failure will likely be addressed very shortly.++ - In addition, as a result of inputs from the core team, engineers from Arm performed an audit of all tests that are currently marked **'only-x86_64'** and **'only-aarch64'** has been done. This was to ascertain whether past viewpoints and/or decisions that led to those markings are still valid. +     - The audit report is available [here.](https://docs.google.com/spreadsheets/d/1B-Jg1Ml6nAF6Tf9wJGTgqkFUNeJEejC3aMikGl6vXlc/edit?usp=sharing)++     - Work is being planned under the guidance of core team members to upstream patches that came out of the audit as well as to address any open questions that came about.++**1.b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.**++ - Two quarters ago, Arm donated a [Packet c2.large.arm system](https://www.packet.com/cloud/servers/c2-large-arm/) to the core team.++ - It is noteworthy that the core team have done a brilliant job in integrating this system into Rust's CI infrastructure while also circumventing myriad Github Actions security problems that popped up.++ - Over time, Arm intends to further donate newer and more capable hardware to this initiative.++**1.c. There must exist a robust and convenient CI integration for the target in question.**++ - The happy outcome of the core team's work with the donated system is that the system integrates largely seamlessly with existing Rust CI infrastructure. ++ - The integration has been verified to produce green runs once patches from the two outstanding PRs are in place.++**2.a. The long term viability of the existence of a target specific ecosystem should be clear.**++ - It is hard to concretely quantify this aspect.++ - That said, Arm AArch64 silicon is either already prevalent or is en-route to prevalance in a wide spectrum of application domains ranging from 'traditional' embedded systems at one end of the spectrum, on to mobile phones, clam-shell devices, desktops, vehicle autonomy controllers, datacenter servers etc all the way to high performance super-computers.++ - The evidence to that effect is too numerous to quote but generally easy to verify openly. ++ - It is fair to state that this is an ongoing reality which is unlikely to stop trending upwards and sidewards for the forseeable future.++ - Software stacks built for those domains predominantly use an AArch64 Linux kernel build.++ - Rust presents an attractive value proposition across all such domains, irrespective of the underlying processor architecture.++ - **As such, the Rust aarch64-unknown-linux-gnu target's ecosystem presents very strong viability for the long term.**++**2.b. The long term viability of supporting the target should be clear.**++ - It is hard to concretely quantify this aspect.++ - It is worth calling out, in the same vein as the previous point, that given the increasing prevalance of AArch64 silicon deployments and given Rust's general value proposition, **supporting the Rust aarch64-unknown-linux-gnu target presents very strong viability for the long term.**++**2.c. The target must have substantial and widespread interest within the Rust developer community.**++ - It is hard to concretely quantify this aspect.++ - It is generally fair to state that **there is already substantial and widespread interest for the aarch64-unknown-linux-gnu target in the Rust developer commmunity**.++ - It is also generally fair to state that there is a clear upward trend in the use of AArch64 systems as self hosted development environments. ++ - Most major operating system environments support hosted development on AArch64 based systems and this trend is increasing.++ - As a somewhat related note: Slow but steady progress is being made to support Windows AArch64 targets, initially for cross-platform development. This shall inevitably trend towards hosted development.++ - As such, **it is very likely that developer interest in Rust on aarch64-unknown-linux-gnu will continue to increase in the medium to long term.**++**2.d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.**++ - It is hard to concretely quantify this aspect.++ - Most major Arm software ecosystem partners are either already using Rust extensively, or are building up to extensive use. A few publically known examples are Microsoft and Google. There are many more.++ - Arm itself recognises Rust as an important component to consider in a broader horizontal safety and security foundation across multiple processor portfolios. ++ - Arm has dedicated a small team to help improve Rust for the aarch64-unknown-linux-gnu target.++ - **It is very likely that support for aarch64-unknown-linux-gnu in these organisations will trend upwards commensurate with the increasing prevalence of AArch64 silicon based systems.**++Points 3.a through 3.c from the [Guide-level explanation](#Guide-level-explanation) section above are addressed in the [Unresolved questions](#unresolved-questions) section below.++# Drawbacks+[drawbacks]: #drawbacks++**There is no drawback envisioned in promoting the Rust aarch64-unknown-linux-gnu to Tier-1.**

Hi @lambda.

Good points, thanks.

Agree that facilitating access to relevant teams will help.

The way I anticipate that this will work out (on the basis of the discussions I’ve had thus far and the outcomes from them) is that as and when systems are needed the core team will reach out and I’ll help with provisioning and access etc.

When we started out the immediate need was getting CI sorted so that was the primary focus. The discussions for understanding the ask and working out specifics came out of the core team. I expect that this will then get handed over to the infrastructure team perhaps. So a kind of triaging protocol.

Incidentally we ended up enabling WASM work similarly.

I think this can and will be done similarly in future.

raw-bin

comment created time in 2 months

pull request commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

I'd really love to see more non-x86 targets become Tier 1!

Me too! :)

raw-bin

comment created time in 2 months

Pull request review commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

+- Feature Name: `promote-aarch64-unknown-linux-gnu-to-tier-1`+- Start Date: 2020-07-17+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Promote the Arm aarch64-unknown-linux-gnu Rust target to Tier-1.++# Motivation+[motivation]: #motivation++Arch64-unknown-linux-gnu is [currently a Tier-2 Rust target](https://forge.rust-lang.org/release/platform-support.html#tier-2), in accordance with the target tier policy articulated [here](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-09-20-target-tier-policy/).++In the last 2 quarters, very good progress has been made in understanding and filling the gaps that remain in the path to attaining Tier-1 status for this target.++As a direct result, those gaps have either already been filled or are very close to being filled.++As such, this RFC aims to:++- Evidence what has been done.++- On the basis of that evidence propose that the proceeedings to promote the aarch64-unknown-linux-gnu target to the Tier-1 category may please be kickstarted.++- Culminate in the actual promotion of the aarch64-unknown-linux-gnu target to Tier-1, including any and all of the relevant processes and actions as appropriate.++Please note that the narrative here doesn't always match the RFC template so some liberties may have been taken in the expression.++Please also note, by way of wilful disclosure, that this RFC's author is an employee of Arm.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++1. **In essence, the target tier policy for a Tier-1 target aims to obtain the following technical and tangible assurances:**++   a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.++   b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.++   c. There must exist a robust and convenient CI integration for the target in question.++2. **In addition, the target tier policy for a Tier-1 target aims to obtain the following stategic assurances:**

Agree! :) Will address. I was meaning to provide a justification for the latter part of the coment from l4l (which was 'Does this word bring any meaning....'.

raw-bin

comment created time in 2 months

Pull request review commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

+- Feature Name: `promote-aarch64-unknown-linux-gnu-to-tier-1`+- Start Date: 2020-07-17+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Promote the Arm aarch64-unknown-linux-gnu Rust target to Tier-1.++# Motivation+[motivation]: #motivation++Arch64-unknown-linux-gnu is [currently a Tier-2 Rust target](https://forge.rust-lang.org/release/platform-support.html#tier-2), in accordance with the target tier policy articulated [here](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-09-20-target-tier-policy/).++In the last 2 quarters, very good progress has been made in understanding and filling the gaps that remain in the path to attaining Tier-1 status for this target.++As a direct result, those gaps have either already been filled or are very close to being filled.++As such, this RFC aims to:++- Evidence what has been done.++- On the basis of that evidence propose that the proceeedings to promote the aarch64-unknown-linux-gnu target to the Tier-1 category may please be kickstarted.++- Culminate in the actual promotion of the aarch64-unknown-linux-gnu target to Tier-1, including any and all of the relevant processes and actions as appropriate.++Please note that the narrative here doesn't always match the RFC template so some liberties may have been taken in the expression.++Please also note, by way of wilful disclosure, that this RFC's author is an employee of Arm.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++1. **In essence, the target tier policy for a Tier-1 target aims to obtain the following technical and tangible assurances:**++   a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.++   b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.++   c. There must exist a robust and convenient CI integration for the target in question.++2. **In addition, the target tier policy for a Tier-1 target aims to obtain the following stategic assurances:**++   a. The long term viability of the existence of a target specific ecosystem should be clear.++   b. The long term viability of supporting the target should be clear.++   c. The target must have substantial and widespread interest within the Rust developer community.++   d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.++3. **Finally, the target tier policy for a Tier-1 target aims to obtain the following approvals:**++   a. An approval from the Compiler Team that Tier-1 target requirements have been met.++   b. An approval from the Infrastructure Team that the target in question may be integrated into CI.++   c. An approval from the Release Team that supporting the target in question is viable in the long term.++The following section details how points 1 and 2 of the above assurances have either already been met or are close to being met. ++Items in point 3 are addressed in the section titled [Unresolved Questions](#Unresolved-questions). That is not to say that they are unresolved per se but more that they are proposed next steps.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++**1.a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.**++ - As of today, all tests pass reliably barring one test. + + - A fix addressing the failing test [has been posted for review.](https://github.com/rust-lang/rust/pull/73655)++    The failure will likely be addressed very shortly.++ - In addition, as a result of inputs from the core team, engineers from Arm performed an audit of all tests that are currently marked **'only-x86_64'** and **'only-aarch64'** has been done. This was to ascertain whether past viewpoints and/or decisions that led to those markings are still valid. +     - The audit report is available [here.](https://docs.google.com/spreadsheets/d/1B-Jg1Ml6nAF6Tf9wJGTgqkFUNeJEejC3aMikGl6vXlc/edit?usp=sharing)++     - Work is being planned under the guidance of core team members to upstream patches that came out of the audit as well as to address any open questions that came about.++**1.b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.**++ - Two quarters ago, Arm donated a [Packet c2.large.arm system](https://www.packet.com/cloud/servers/c2-large-arm/) to the core team.++ - It is noteworthy that the core team have done a brilliant job in integrating this system into Rust's CI infrastructure while also circumventing myriad Github Actions security problems that popped up.++ - Over time, Arm intends to further donate newer and more capable hardware to this initiative.++**1.c. There must exist a robust and convenient CI integration for the target in question.**++ - The happy outcome of the core team's work with the donated system is that the system integrates largely seamlessly with existing Rust CI infrastructure. ++ - The integration has been verified to produce green runs once patches from the two outstanding PRs are in place.++**2.a. The long term viability of the existence of a target specific ecosystem should be clear.**++ - It is hard to concretely quantify this aspect.++ - That said, Arm AArch64 silicon is either already prevalent or is en-route to prevalance in a wide spectrum of application domains ranging from 'traditional' embedded systems at one end of the spectrum, on to mobile phones, clam-shell devices, desktops, vehicle autonomy controllers, datacenter servers etc all the way to high performance super-computers.++ - The evidence to that effect is too numerous to quote but generally easy to verify openly. ++ - It is fair to state that this is an ongoing reality which is unlikely to stop trending upwards and sidewards for the forseeable future.++ - Software stacks built for those domains predominantly use an AArch64 Linux kernel build.++ - Rust presents an attractive value proposition across all such domains, irrespective of the underlying processor architecture.++ - **As such, the Rust aarch64-unknown-linux-gnu target's ecosystem presents very strong viability for the long term.**++**2.b. The long term viability of supporting the target should be clear.**++ - It is hard to concretely quantify this aspect.++ - It is worth calling out, in the same vein as the previous point, that given the increasing prevalance of AArch64 silicon deployments and given Rust's general value proposition, **supporting the Rust aarch64-unknown-linux-gnu target presents very strong viability for the long term.**++**2.c. The target must have substantial and widespread interest within the Rust developer community.**++ - It is hard to concretely quantify this aspect.++ - It is generally fair to state that **there is already substantial and widespread interest for the aarch64-unknown-linux-gnu target in the Rust developer commmunity**.++ - It is also generally fair to state that there is a clear upward trend in the use of AArch64 systems as self hosted development environments. ++ - Most major operating system environments support hosted development on AArch64 based systems and this trend is increasing.++ - As a somewhat related note: Slow but steady progress is being made to support Windows AArch64 targets, initially for cross-platform development. This shall inevitably trend towards hosted development.++ - As such, **it is very likely that developer interest in Rust on aarch64-unknown-linux-gnu will continue to increase in the medium to long term.**++**2.d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.**++ - It is hard to concretely quantify this aspect.++ - Most major Arm software ecosystem partners are either already using Rust extensively, or are building up to extensive use. A few publically known examples are Microsoft and Google. There are many more.++ - Arm itself recognises Rust as an important component to consider in a broader horizontal safety and security foundation across multiple processor portfolios. ++ - Arm has dedicated a small team to help improve Rust for the aarch64-unknown-linux-gnu target.++ - **It is very likely that support for aarch64-unknown-linux-gnu in these organisations will trend upwards commensurate with the increasing prevalence of AArch64 silicon based systems.**++Points 3.a through 3.c from the [Guide-level explanation](#Guide-level-explanation) section above are addressed in the [Unresolved questions](#unresolved-questions) section below.++# Drawbacks+[drawbacks]: #drawbacks++**There is no drawback envisioned in promoting the Rust aarch64-unknown-linux-gnu to Tier-1.**++# Rationale and alternatives+[rationale-and-alternatives]: #rationale-and-alternatives++Given the narrative above, it is the opinion of the author that it would now be tactically sound to promote aarch64-unknown-linux-gnu to Tier-1.++- Inclusion in the Tier-1 category is very likely to be a self sustaining action in that it will promote increased scrutiny with increasing quality as a return. With that return, interest in Rust will grow further both in the AArch64 context and even more generally.++- Anecdotally, not having the Tier-1 'badge' has been seen to become an obstacle to increasing mindshare in Rust for this target. Organisations tend to associate a Tier-1 categorisation with better quality, suitability for key projects, longevity etc. With a reasonably justified Tier-1 badge in place, the likelihood is that such organisations will tend to promote the use of Rust in production.++As such **there is no substantially robust reason to not proceed with promoting aarch64-unknown-linux-gnu to Tier-1.**++# Prior art+[prior-art]: #prior-art++- Existing Tier-1 targets represent prior-art.++- It is appropriate to call out that no non i686 or x86_64 based target has ever been promoted to Tier-1. The fact that those targets have intrinsically supported self hosted development has arguably been a primary reason for their maturity.++- The aarch64-unknown-linux-gnu target is therefore somewhat uncharted territory.++However, as emphasised in the narrative thus far, **the aarch64-unknown-linux-gnu target now exhibits the properties required by a Tier-1 target as per the target tier policy.**++# Unresolved questions+[unresolved-questions]: #unresolved-questions++The following points are 'unresolved' at present. From the author's PoV, these are next steps, subject to agreement with the RFC reviewers.++**3.a. An approval from the Compiler Team that Tier-1 target requirements have been met.**++**3.b. An approval from the Infrastructure Team that the target in question may be integrated into CI.**++**3.c. An approval from the Release Team that supporting the target in question is viable in the long term.**++The expectation is that these will get resolved as a result of the discussion that ensues with this RFC posting.

Hi @joshtriplett!

Thanks! I completely agree. I did try and explain that I'm treating these more as next steps. The 'Unresolved Questions' sections just seemed to me as a suitable venue for those at the time.

raw-bin

comment created time in 2 months

pull request commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

Should stack probes be required for all tier-1 platforms? See rust-lang/rust#43241 and rust-lang/rust#49355.

Hi and thanks for your comment.

As it happens, @alexcrichton recently reached out to highlight this gap. There is work pencilled in in Q3 to address this. There is an element of uncertainty involved though (the work is planned to be done as a part of the Linaro Toolchain Working Group and there is a vote involved). However stack probing support in LLVM for AArch64 Linux is understood to be a key requirement so servicing it is an inevitability.

Whether stack probing needs to be a gating feature for Tier-1 attainment is debatable. Given the ultra complex (to the point of being pathologically hard!) synthetic scenarios that need to be arranged in order to get an exploitable stack clash, I would state that the feature should be a high priority ask and not a gate.

Happy to discuss further.

Thanks.

raw-bin

comment created time in 2 months

Pull request review commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

+- Feature Name: `promote-aarch64-unknown-linux-gnu-to-tier-1`+- Start Date: 2020-07-17+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Promote the Arm aarch64-unknown-linux-gnu Rust target to Tier-1.++# Motivation+[motivation]: #motivation++Arch64-unknown-linux-gnu is [currently a Tier-2 Rust target](https://forge.rust-lang.org/release/platform-support.html#tier-2), in accordance with the target tier policy articulated [here](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-09-20-target-tier-policy/).++In the last 2 quarters, very good progress has been made in understanding and filling the gaps that remain in the path to attaining Tier-1 status for this target.++As a direct result, those gaps have either already been filled or are very close to being filled.++As such, this RFC aims to:++- Evidence what has been done.++- On the basis of that evidence propose that the proceeedings to promote the aarch64-unknown-linux-gnu target to the Tier-1 category may please be kickstarted.++- Culminate in the actual promotion of the aarch64-unknown-linux-gnu target to Tier-1, including any and all of the relevant processes and actions as appropriate.++Please note that the narrative here doesn't always match the RFC template so some liberties may have been taken in the expression.++Please also note, by way of wilful disclosure, that this RFC's author is an employee of Arm.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++1. **In essence, the target tier policy for a Tier-1 target aims to obtain the following technical and tangible assurances:**++   a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.++   b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.++   c. There must exist a robust and convenient CI integration for the target in question.++2. **In addition, the target tier policy for a Tier-1 target aims to obtain the following stategic assurances:**++   a. The long term viability of the existence of a target specific ecosystem should be clear.++   b. The long term viability of supporting the target should be clear.++   c. The target must have substantial and widespread interest within the Rust developer community.++   d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.++3. **Finally, the target tier policy for a Tier-1 target aims to obtain the following approvals:**++   a. An approval from the Compiler Team that Tier-1 target requirements have been met.++   b. An approval from the Infrastructure Team that the target in question may be integrated into CI.++   c. An approval from the Release Team that supporting the target in question is viable in the long term.++The following section details how points 1 and 2 of the above assurances have either already been met or are close to being met. ++Items in point 3 are addressed in the section titled [Unresolved Questions](#Unresolved-questions). That is not to say that they are unresolved per se but more that they are proposed next steps.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++**1.a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.**++ - As of today, all tests pass reliably barring one test. + + - A fix addressing the failing test [has been posted for review.](https://github.com/rust-lang/rust/pull/73655)++    The failure will likely be addressed very shortly.++ - In addition, as a result of inputs from the core team, engineers from Arm performed an audit of all tests that are currently marked **'only-x86_64'** and **'only-aarch64'** has been done. This was to ascertain whether past viewpoints and/or decisions that led to those markings are still valid. +     - The audit report is available [here.](https://docs.google.com/spreadsheets/d/1B-Jg1Ml6nAF6Tf9wJGTgqkFUNeJEejC3aMikGl6vXlc/edit?usp=sharing)++     - Work is being planned under the guidance of core team members to upstream patches that came out of the audit as well as to address any open questions that came about.++**1.b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.**++ - Two quarters ago, Arm donated a [Packet c2.large.arm system](https://www.packet.com/cloud/servers/c2-large-arm/) to the core team.++ - It is noteworthy that the core team have done a brilliant job in integrating this system into Rust's CI infrastructure while also circumventing myriad Github Actions security problems that popped up.++ - Over time, Arm intends to further donate newer and more capable hardware to this initiative.++**1.c. There must exist a robust and convenient CI integration for the target in question.**++ - The happy outcome of the core team's work with the donated system is that the system integrates largely seamlessly with existing Rust CI infrastructure. ++ - The integration has been verified to produce green runs once patches from the two outstanding PRs are in place.++**2.a. The long term viability of the existence of a target specific ecosystem should be clear.**++ - It is hard to concretely quantify this aspect.++ - That said, Arm AArch64 silicon is either already prevalent or is en-route to prevalance in a wide spectrum of application domains ranging from 'traditional' embedded systems at one end of the spectrum, on to mobile phones, clam-shell devices, desktops, vehicle autonomy controllers, datacenter servers etc all the way to high performance super-computers.++ - The evidence to that effect is too numerous to quote but generally easy to verify openly. ++ - It is fair to state that this is an ongoing reality which is unlikely to stop trending upwards and sidewards for the forseeable future.++ - Software stacks built for those domains predominantly use an AArch64 Linux kernel build.++ - Rust presents an attractive value proposition across all such domains, irrespective of the underlying processor architecture.++ - **As such, the Rust aarch64-unknown-linux-gnu target's ecosystem presents very strong viability for the long term.**++**2.b. The long term viability of supporting the target should be clear.**++ - It is hard to concretely quantify this aspect.++ - It is worth calling out, in the same vein as the previous point, that given the increasing prevalance of AArch64 silicon deployments and given Rust's general value proposition, **supporting the Rust aarch64-unknown-linux-gnu target presents very strong viability for the long term.**++**2.c. The target must have substantial and widespread interest within the Rust developer community.**++ - It is hard to concretely quantify this aspect.++ - It is generally fair to state that **there is already substantial and widespread interest for the aarch64-unknown-linux-gnu target in the Rust developer commmunity**.

Hi again.

Good catch too! Will address.

raw-bin

comment created time in 2 months

Pull request review commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

+- Feature Name: `promote-aarch64-unknown-linux-gnu-to-tier-1`+- Start Date: 2020-07-17+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Promote the Arm aarch64-unknown-linux-gnu Rust target to Tier-1.++# Motivation+[motivation]: #motivation++Arch64-unknown-linux-gnu is [currently a Tier-2 Rust target](https://forge.rust-lang.org/release/platform-support.html#tier-2), in accordance with the target tier policy articulated [here](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-09-20-target-tier-policy/).++In the last 2 quarters, very good progress has been made in understanding and filling the gaps that remain in the path to attaining Tier-1 status for this target.++As a direct result, those gaps have either already been filled or are very close to being filled.++As such, this RFC aims to:++- Evidence what has been done.++- On the basis of that evidence propose that the proceeedings to promote the aarch64-unknown-linux-gnu target to the Tier-1 category may please be kickstarted.

Hi and thanks for your comment.

Good catch! Will address.

raw-bin

comment created time in 2 months

pull request commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

I’m in support of this RFC.

Hi again @nagisa. Thank you for your support! :)

raw-bin

comment created time in 2 months

Pull request review commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

+- Feature Name: `promote-aarch64-unknown-linux-gnu-to-tier-1`+- Start Date: 2020-07-17+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Promote the Arm aarch64-unknown-linux-gnu Rust target to Tier-1.++# Motivation+[motivation]: #motivation++Arch64-unknown-linux-gnu is [currently a Tier-2 Rust target](https://forge.rust-lang.org/release/platform-support.html#tier-2), in accordance with the target tier policy articulated [here](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-09-20-target-tier-policy/).++In the last 2 quarters, very good progress has been made in understanding and filling the gaps that remain in the path to attaining Tier-1 status for this target.++As a direct result, those gaps have either already been filled or are very close to being filled.++As such, this RFC aims to:++- Evidence what has been done.++- On the basis of that evidence propose that the proceeedings to promote the aarch64-unknown-linux-gnu target to the Tier-1 category may please be kickstarted.++- Culminate in the actual promotion of the aarch64-unknown-linux-gnu target to Tier-1, including any and all of the relevant processes and actions as appropriate.++Please note that the narrative here doesn't always match the RFC template so some liberties may have been taken in the expression.++Please also note, by way of wilful disclosure, that this RFC's author is an employee of Arm.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++1. **In essence, the target tier policy for a Tier-1 target aims to obtain the following technical and tangible assurances:**++   a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.++   b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.++   c. There must exist a robust and convenient CI integration for the target in question.++2. **In addition, the target tier policy for a Tier-1 target aims to obtain the following stategic assurances:**++   a. The long term viability of the existence of a target specific ecosystem should be clear.++   b. The long term viability of supporting the target should be clear.++   c. The target must have substantial and widespread interest within the Rust developer community.++   d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.++3. **Finally, the target tier policy for a Tier-1 target aims to obtain the following approvals:**++   a. An approval from the Compiler Team that Tier-1 target requirements have been met.++   b. An approval from the Infrastructure Team that the target in question may be integrated into CI.++   c. An approval from the Release Team that supporting the target in question is viable in the long term.++The following section details how points 1 and 2 of the above assurances have either already been met or are close to being met. ++Items in point 3 are addressed in the section titled [Unresolved Questions](#Unresolved-questions). That is not to say that they are unresolved per se but more that they are proposed next steps.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++**1.a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.**++ - As of today, all tests pass reliably barring one test. + + - A fix addressing the failing test [has been posted for review.](https://github.com/rust-lang/rust/pull/73655)++    The failure will likely be addressed very shortly.++ - In addition, as a result of inputs from the core team, engineers from Arm performed an audit of all tests that are currently marked **'only-x86_64'** and **'only-aarch64'** has been done. This was to ascertain whether past viewpoints and/or decisions that led to those markings are still valid. +     - The audit report is available [here.](https://docs.google.com/spreadsheets/d/1B-Jg1Ml6nAF6Tf9wJGTgqkFUNeJEejC3aMikGl6vXlc/edit?usp=sharing)++     - Work is being planned under the guidance of core team members to upstream patches that came out of the audit as well as to address any open questions that came about.++**1.b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.**++ - Two quarters ago, Arm donated a [Packet c2.large.arm system](https://www.packet.com/cloud/servers/c2-large-arm/) to the core team.++ - It is noteworthy that the core team have done a brilliant job in integrating this system into Rust's CI infrastructure while also circumventing myriad Github Actions security problems that popped up.++ - Over time, Arm intends to further donate newer and more capable hardware to this initiative.++**1.c. There must exist a robust and convenient CI integration for the target in question.**++ - The happy outcome of the core team's work with the donated system is that the system integrates largely seamlessly with existing Rust CI infrastructure. ++ - The integration has been verified to produce green runs once patches from the two outstanding PRs are in place.++**2.a. The long term viability of the existence of a target specific ecosystem should be clear.**++ - It is hard to concretely quantify this aspect.++ - That said, Arm AArch64 silicon is either already prevalent or is en-route to prevalance in a wide spectrum of application domains ranging from 'traditional' embedded systems at one end of the spectrum, on to mobile phones, clam-shell devices, desktops, vehicle autonomy controllers, datacenter servers etc all the way to high performance super-computers.++ - The evidence to that effect is too numerous to quote but generally easy to verify openly. ++ - It is fair to state that this is an ongoing reality which is unlikely to stop trending upwards and sidewards for the forseeable future.++ - Software stacks built for those domains predominantly use an AArch64 Linux kernel build.++ - Rust presents an attractive value proposition across all such domains, irrespective of the underlying processor architecture.++ - **As such, the Rust aarch64-unknown-linux-gnu target's ecosystem presents very strong viability for the long term.**++**2.b. The long term viability of supporting the target should be clear.**++ - It is hard to concretely quantify this aspect.++ - It is worth calling out, in the same vein as the previous point, that given the increasing prevalance of AArch64 silicon deployments and given Rust's general value proposition, **supporting the Rust aarch64-unknown-linux-gnu target presents very strong viability for the long term.**++**2.c. The target must have substantial and widespread interest within the Rust developer community.**++ - It is hard to concretely quantify this aspect.++ - It is generally fair to state that **there is already substantial and widespread interest for the aarch64-unknown-linux-gnu target in the Rust developer commmunity**.++ - It is also generally fair to state that there is a clear upward trend in the use of AArch64 systems as self hosted development environments. ++ - Most major operating system environments support hosted development on AArch64 based systems and this trend is increasing.++ - As a somewhat related note: Slow but steady progress is being made to support Windows AArch64 targets, initially for cross-platform development. This shall inevitably trend towards hosted development.++ - As such, **it is very likely that developer interest in Rust on aarch64-unknown-linux-gnu will continue to increase in the medium to long term.**++**2.d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.**++ - It is hard to concretely quantify this aspect.++ - Most major Arm software ecosystem partners are either already using Rust extensively, or are building up to extensive use. A few publically known examples are Microsoft and Google. There are many more.++ - Arm itself recognises Rust as an important component to consider in a broader horizontal safety and security foundation across multiple processor portfolios. ++ - Arm has dedicated a small team to help improve Rust for the aarch64-unknown-linux-gnu target.++ - **It is very likely that support for aarch64-unknown-linux-gnu in these organisations will trend upwards commensurate with the increasing prevalence of AArch64 silicon based systems.**++Points 3.a through 3.c from the [Guide-level explanation](#Guide-level-explanation) section above are addressed in the [Unresolved questions](#unresolved-questions) section below.++# Drawbacks+[drawbacks]: #drawbacks++**There is no drawback envisioned in promoting the Rust aarch64-unknown-linux-gnu to Tier-1.**

I don’t think your average contributor will be willing to spend their own dollars just to hack on an architecture that they don’t have much stake in.

That said, this doesn't really affect me much, I've in my possession of a fairly competent aarch64 machine already. If others don't consider it a problem, that’s fine by me.

Hi again @nagisa.

I think the reality shall be that the non-average contributor won't have to spend their own dollars and that should be enough to gain the necessary critical mass in order to get a bulk of the essential support in motion.

That will then end up facilitating the average contributor as a side effect. Rest assured that commoditised access to suitable AArch64 silicon (for the aarch64-unknown-linux-gnu target) is inevitable in the short term.

The short term isn't now, I agree. However, that doesn't change the fact that the essential asks for a Tier-1 target aren't resolved today.

I hope that helps. Happy to discuss further.

Thanks.

raw-bin

comment created time in 2 months

Pull request review commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

+- Feature Name: `promote-aarch64-unknown-linux-gnu-to-tier-1`+- Start Date: 2020-07-17+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Promote the Arm aarch64-unknown-linux-gnu Rust target to Tier-1.++# Motivation+[motivation]: #motivation++Arch64-unknown-linux-gnu is [currently a Tier-2 Rust target](https://forge.rust-lang.org/release/platform-support.html#tier-2), in accordance with the target tier policy articulated [here](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-09-20-target-tier-policy/).++In the last 2 quarters, very good progress has been made in understanding and filling the gaps that remain in the path to attaining Tier-1 status for this target.++As a direct result, those gaps have either already been filled or are very close to being filled.++As such, this RFC aims to:++- Evidence what has been done.++- On the basis of that evidence propose that the proceeedings to promote the aarch64-unknown-linux-gnu target to the Tier-1 category may please be kickstarted.++- Culminate in the actual promotion of the aarch64-unknown-linux-gnu target to Tier-1, including any and all of the relevant processes and actions as appropriate.++Please note that the narrative here doesn't always match the RFC template so some liberties may have been taken in the expression.++Please also note, by way of wilful disclosure, that this RFC's author is an employee of Arm.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++1. **In essence, the target tier policy for a Tier-1 target aims to obtain the following technical and tangible assurances:**++   a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.++   b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.++   c. There must exist a robust and convenient CI integration for the target in question.++2. **In addition, the target tier policy for a Tier-1 target aims to obtain the following stategic assurances:**++   a. The long term viability of the existence of a target specific ecosystem should be clear.++   b. The long term viability of supporting the target should be clear.++   c. The target must have substantial and widespread interest within the Rust developer community.++   d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.++3. **Finally, the target tier policy for a Tier-1 target aims to obtain the following approvals:**++   a. An approval from the Compiler Team that Tier-1 target requirements have been met.++   b. An approval from the Infrastructure Team that the target in question may be integrated into CI.++   c. An approval from the Release Team that supporting the target in question is viable in the long term.++The following section details how points 1 and 2 of the above assurances have either already been met or are close to being met. ++Items in point 3 are addressed in the section titled [Unresolved Questions](#Unresolved-questions). That is not to say that they are unresolved per se but more that they are proposed next steps.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++**1.a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.**++ - As of today, all tests pass reliably barring one test. + + - A fix addressing the failing test [has been posted for review.](https://github.com/rust-lang/rust/pull/73655)++    The failure will likely be addressed very shortly.++ - In addition, as a result of inputs from the core team, engineers from Arm performed an audit of all tests that are currently marked **'only-x86_64'** and **'only-aarch64'** has been done. This was to ascertain whether past viewpoints and/or decisions that led to those markings are still valid. +     - The audit report is available [here.](https://docs.google.com/spreadsheets/d/1B-Jg1Ml6nAF6Tf9wJGTgqkFUNeJEejC3aMikGl6vXlc/edit?usp=sharing)++     - Work is being planned under the guidance of core team members to upstream patches that came out of the audit as well as to address any open questions that came about.++**1.b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.**++ - Two quarters ago, Arm donated a [Packet c2.large.arm system](https://www.packet.com/cloud/servers/c2-large-arm/) to the core team.++ - It is noteworthy that the core team have done a brilliant job in integrating this system into Rust's CI infrastructure while also circumventing myriad Github Actions security problems that popped up.++ - Over time, Arm intends to further donate newer and more capable hardware to this initiative.++**1.c. There must exist a robust and convenient CI integration for the target in question.**++ - The happy outcome of the core team's work with the donated system is that the system integrates largely seamlessly with existing Rust CI infrastructure. ++ - The integration has been verified to produce green runs once patches from the two outstanding PRs are in place.++**2.a. The long term viability of the existence of a target specific ecosystem should be clear.**++ - It is hard to concretely quantify this aspect.++ - That said, Arm AArch64 silicon is either already prevalent or is en-route to prevalance in a wide spectrum of application domains ranging from 'traditional' embedded systems at one end of the spectrum, on to mobile phones, clam-shell devices, desktops, vehicle autonomy controllers, datacenter servers etc all the way to high performance super-computers.++ - The evidence to that effect is too numerous to quote but generally easy to verify openly. ++ - It is fair to state that this is an ongoing reality which is unlikely to stop trending upwards and sidewards for the forseeable future.++ - Software stacks built for those domains predominantly use an AArch64 Linux kernel build.++ - Rust presents an attractive value proposition across all such domains, irrespective of the underlying processor architecture.++ - **As such, the Rust aarch64-unknown-linux-gnu target's ecosystem presents very strong viability for the long term.**++**2.b. The long term viability of supporting the target should be clear.**++ - It is hard to concretely quantify this aspect.++ - It is worth calling out, in the same vein as the previous point, that given the increasing prevalance of AArch64 silicon deployments and given Rust's general value proposition, **supporting the Rust aarch64-unknown-linux-gnu target presents very strong viability for the long term.**++**2.c. The target must have substantial and widespread interest within the Rust developer community.**++ - It is hard to concretely quantify this aspect.++ - It is generally fair to state that **there is already substantial and widespread interest for the aarch64-unknown-linux-gnu target in the Rust developer commmunity**.++ - It is also generally fair to state that there is a clear upward trend in the use of AArch64 systems as self hosted development environments. ++ - Most major operating system environments support hosted development on AArch64 based systems and this trend is increasing.++ - As a somewhat related note: Slow but steady progress is being made to support Windows AArch64 targets, initially for cross-platform development. This shall inevitably trend towards hosted development.++ - As such, **it is very likely that developer interest in Rust on aarch64-unknown-linux-gnu will continue to increase in the medium to long term.**++**2.d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.**++ - It is hard to concretely quantify this aspect.++ - Most major Arm software ecosystem partners are either already using Rust extensively, or are building up to extensive use. A few publically known examples are Microsoft and Google. There are many more.++ - Arm itself recognises Rust as an important component to consider in a broader horizontal safety and security foundation across multiple processor portfolios. ++ - Arm has dedicated a small team to help improve Rust for the aarch64-unknown-linux-gnu target.++ - **It is very likely that support for aarch64-unknown-linux-gnu in these organisations will trend upwards commensurate with the increasing prevalence of AArch64 silicon based systems.**++Points 3.a through 3.c from the [Guide-level explanation](#Guide-level-explanation) section above are addressed in the [Unresolved questions](#unresolved-questions) section below.++# Drawbacks+[drawbacks]: #drawbacks++**There is no drawback envisioned in promoting the Rust aarch64-unknown-linux-gnu to Tier-1.**

Or AWS's Graviton CPUs, which are heavily subsidized and are actually priced below the x86_64 CPUs with equivalent performance

Hi and thanks for your comments.

Agree that AWS Graviton2 systems are good options. FYI: We mean to enable access to AWS Graviton2 instances for the Rust lang core team in the medium term.

Thanks!

raw-bin

comment created time in 2 months

Pull request review commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

+- Feature Name: `promote-aarch64-unknown-linux-gnu-to-tier-1`+- Start Date: 2020-07-17+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Promote the Arm aarch64-unknown-linux-gnu Rust target to Tier-1.++# Motivation+[motivation]: #motivation++Arch64-unknown-linux-gnu is [currently a Tier-2 Rust target](https://forge.rust-lang.org/release/platform-support.html#tier-2), in accordance with the target tier policy articulated [here](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-09-20-target-tier-policy/).++In the last 2 quarters, very good progress has been made in understanding and filling the gaps that remain in the path to attaining Tier-1 status for this target.++As a direct result, those gaps have either already been filled or are very close to being filled.++As such, this RFC aims to:++- Evidence what has been done.++- On the basis of that evidence propose that the proceeedings to promote the aarch64-unknown-linux-gnu target to the Tier-1 category may please be kickstarted.++- Culminate in the actual promotion of the aarch64-unknown-linux-gnu target to Tier-1, including any and all of the relevant processes and actions as appropriate.++Please note that the narrative here doesn't always match the RFC template so some liberties may have been taken in the expression.++Please also note, by way of wilful disclosure, that this RFC's author is an employee of Arm.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++1. **In essence, the target tier policy for a Tier-1 target aims to obtain the following technical and tangible assurances:**++   a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.++   b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.++   c. There must exist a robust and convenient CI integration for the target in question.++2. **In addition, the target tier policy for a Tier-1 target aims to obtain the following stategic assurances:**++   a. The long term viability of the existence of a target specific ecosystem should be clear.++   b. The long term viability of supporting the target should be clear.++   c. The target must have substantial and widespread interest within the Rust developer community.++   d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.++3. **Finally, the target tier policy for a Tier-1 target aims to obtain the following approvals:**++   a. An approval from the Compiler Team that Tier-1 target requirements have been met.++   b. An approval from the Infrastructure Team that the target in question may be integrated into CI.++   c. An approval from the Release Team that supporting the target in question is viable in the long term.++The following section details how points 1 and 2 of the above assurances have either already been met or are close to being met. ++Items in point 3 are addressed in the section titled [Unresolved Questions](#Unresolved-questions). That is not to say that they are unresolved per se but more that they are proposed next steps.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++**1.a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.**++ - As of today, all tests pass reliably barring one test. + + - A fix addressing the failing test [has been posted for review.](https://github.com/rust-lang/rust/pull/73655)++    The failure will likely be addressed very shortly.++ - In addition, as a result of inputs from the core team, engineers from Arm performed an audit of all tests that are currently marked **'only-x86_64'** and **'only-aarch64'** has been done. This was to ascertain whether past viewpoints and/or decisions that led to those markings are still valid. +     - The audit report is available [here.](https://docs.google.com/spreadsheets/d/1B-Jg1Ml6nAF6Tf9wJGTgqkFUNeJEejC3aMikGl6vXlc/edit?usp=sharing)++     - Work is being planned under the guidance of core team members to upstream patches that came out of the audit as well as to address any open questions that came about.++**1.b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.**++ - Two quarters ago, Arm donated a [Packet c2.large.arm system](https://www.packet.com/cloud/servers/c2-large-arm/) to the core team.++ - It is noteworthy that the core team have done a brilliant job in integrating this system into Rust's CI infrastructure while also circumventing myriad Github Actions security problems that popped up.++ - Over time, Arm intends to further donate newer and more capable hardware to this initiative.++**1.c. There must exist a robust and convenient CI integration for the target in question.**++ - The happy outcome of the core team's work with the donated system is that the system integrates largely seamlessly with existing Rust CI infrastructure. ++ - The integration has been verified to produce green runs once patches from the two outstanding PRs are in place.++**2.a. The long term viability of the existence of a target specific ecosystem should be clear.**++ - It is hard to concretely quantify this aspect.++ - That said, Arm AArch64 silicon is either already prevalent or is en-route to prevalance in a wide spectrum of application domains ranging from 'traditional' embedded systems at one end of the spectrum, on to mobile phones, clam-shell devices, desktops, vehicle autonomy controllers, datacenter servers etc all the way to high performance super-computers.++ - The evidence to that effect is too numerous to quote but generally easy to verify openly. ++ - It is fair to state that this is an ongoing reality which is unlikely to stop trending upwards and sidewards for the forseeable future.++ - Software stacks built for those domains predominantly use an AArch64 Linux kernel build.++ - Rust presents an attractive value proposition across all such domains, irrespective of the underlying processor architecture.++ - **As such, the Rust aarch64-unknown-linux-gnu target's ecosystem presents very strong viability for the long term.**++**2.b. The long term viability of supporting the target should be clear.**++ - It is hard to concretely quantify this aspect.++ - It is worth calling out, in the same vein as the previous point, that given the increasing prevalance of AArch64 silicon deployments and given Rust's general value proposition, **supporting the Rust aarch64-unknown-linux-gnu target presents very strong viability for the long term.**++**2.c. The target must have substantial and widespread interest within the Rust developer community.**++ - It is hard to concretely quantify this aspect.++ - It is generally fair to state that **there is already substantial and widespread interest for the aarch64-unknown-linux-gnu target in the Rust developer commmunity**.++ - It is also generally fair to state that there is a clear upward trend in the use of AArch64 systems as self hosted development environments. ++ - Most major operating system environments support hosted development on AArch64 based systems and this trend is increasing.++ - As a somewhat related note: Slow but steady progress is being made to support Windows AArch64 targets, initially for cross-platform development. This shall inevitably trend towards hosted development.++ - As such, **it is very likely that developer interest in Rust on aarch64-unknown-linux-gnu will continue to increase in the medium to long term.**++**2.d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.**++ - It is hard to concretely quantify this aspect.++ - Most major Arm software ecosystem partners are either already using Rust extensively, or are building up to extensive use. A few publically known examples are Microsoft and Google. There are many more.++ - Arm itself recognises Rust as an important component to consider in a broader horizontal safety and security foundation across multiple processor portfolios. ++ - Arm has dedicated a small team to help improve Rust for the aarch64-unknown-linux-gnu target.++ - **It is very likely that support for aarch64-unknown-linux-gnu in these organisations will trend upwards commensurate with the increasing prevalence of AArch64 silicon based systems.**++Points 3.a through 3.c from the [Guide-level explanation](#Guide-level-explanation) section above are addressed in the [Unresolved questions](#unresolved-questions) section below.++# Drawbacks+[drawbacks]: #drawbacks++**There is no drawback envisioned in promoting the Rust aarch64-unknown-linux-gnu to Tier-1.**

Within a year or two it will likely become more reasonable to use the latest raspberry pi 4 (the 8gb model) as a compiler development system. Currently the 64-bit support of rpi4 is a little on the "beta" side, but folks are working on it. Both with the official raspberry pi OS and also using off the shelf linux distros like ubuntu and arch.

Maybe instead of "reasonable" I should say "possible". 1.5Mhz and 8GB of RAM means you can do cargo check and see results in "minutes", but a full build/test of the compiler would very likely take "hours". Might have to let CI occasionally do some of the heavy work.

source: I use a 4gb rpi4 for development of smaller projects and it's "slower than a proper desktop" speed, but you can still get work done.

Hi and thank you for your comments!

You make good points about how currently available off the shelf AArch64 silicon provides some measure of respite for self hosted aarch64-unknown-linux-gnu development. While this is not 'perfect', rest assured that more capable AArch64 silicon targeting Linux is certain and certain in a reasonable time frame.

Thanks.

raw-bin

comment created time in 2 months

Pull request review commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

+- Feature Name: `promote-aarch64-unknown-linux-gnu-to-tier-1`+- Start Date: 2020-07-17+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Promote the Arm aarch64-unknown-linux-gnu Rust target to Tier-1.++# Motivation+[motivation]: #motivation++Arch64-unknown-linux-gnu is [currently a Tier-2 Rust target](https://forge.rust-lang.org/release/platform-support.html#tier-2), in accordance with the target tier policy articulated [here](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-09-20-target-tier-policy/).++In the last 2 quarters, very good progress has been made in understanding and filling the gaps that remain in the path to attaining Tier-1 status for this target.++As a direct result, those gaps have either already been filled or are very close to being filled.++As such, this RFC aims to:++- Evidence what has been done.++- On the basis of that evidence propose that the proceeedings to promote the aarch64-unknown-linux-gnu target to the Tier-1 category may please be kickstarted.++- Culminate in the actual promotion of the aarch64-unknown-linux-gnu target to Tier-1, including any and all of the relevant processes and actions as appropriate.++Please note that the narrative here doesn't always match the RFC template so some liberties may have been taken in the expression.++Please also note, by way of wilful disclosure, that this RFC's author is an employee of Arm.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++1. **In essence, the target tier policy for a Tier-1 target aims to obtain the following technical and tangible assurances:**++   a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.++   b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.++   c. There must exist a robust and convenient CI integration for the target in question.++2. **In addition, the target tier policy for a Tier-1 target aims to obtain the following stategic assurances:**++   a. The long term viability of the existence of a target specific ecosystem should be clear.++   b. The long term viability of supporting the target should be clear.++   c. The target must have substantial and widespread interest within the Rust developer community.++   d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.++3. **Finally, the target tier policy for a Tier-1 target aims to obtain the following approvals:**++   a. An approval from the Compiler Team that Tier-1 target requirements have been met.++   b. An approval from the Infrastructure Team that the target in question may be integrated into CI.++   c. An approval from the Release Team that supporting the target in question is viable in the long term.++The following section details how points 1 and 2 of the above assurances have either already been met or are close to being met. ++Items in point 3 are addressed in the section titled [Unresolved Questions](#Unresolved-questions). That is not to say that they are unresolved per se but more that they are proposed next steps.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++**1.a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.**++ - As of today, all tests pass reliably barring one test. + + - A fix addressing the failing test [has been posted for review.](https://github.com/rust-lang/rust/pull/73655)++    The failure will likely be addressed very shortly.++ - In addition, as a result of inputs from the core team, engineers from Arm performed an audit of all tests that are currently marked **'only-x86_64'** and **'only-aarch64'** has been done. This was to ascertain whether past viewpoints and/or decisions that led to those markings are still valid. +     - The audit report is available [here.](https://docs.google.com/spreadsheets/d/1B-Jg1Ml6nAF6Tf9wJGTgqkFUNeJEejC3aMikGl6vXlc/edit?usp=sharing)++     - Work is being planned under the guidance of core team members to upstream patches that came out of the audit as well as to address any open questions that came about.++**1.b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.**++ - Two quarters ago, Arm donated a [Packet c2.large.arm system](https://www.packet.com/cloud/servers/c2-large-arm/) to the core team.++ - It is noteworthy that the core team have done a brilliant job in integrating this system into Rust's CI infrastructure while also circumventing myriad Github Actions security problems that popped up.++ - Over time, Arm intends to further donate newer and more capable hardware to this initiative.++**1.c. There must exist a robust and convenient CI integration for the target in question.**++ - The happy outcome of the core team's work with the donated system is that the system integrates largely seamlessly with existing Rust CI infrastructure. ++ - The integration has been verified to produce green runs once patches from the two outstanding PRs are in place.++**2.a. The long term viability of the existence of a target specific ecosystem should be clear.**++ - It is hard to concretely quantify this aspect.++ - That said, Arm AArch64 silicon is either already prevalent or is en-route to prevalance in a wide spectrum of application domains ranging from 'traditional' embedded systems at one end of the spectrum, on to mobile phones, clam-shell devices, desktops, vehicle autonomy controllers, datacenter servers etc all the way to high performance super-computers.++ - The evidence to that effect is too numerous to quote but generally easy to verify openly. ++ - It is fair to state that this is an ongoing reality which is unlikely to stop trending upwards and sidewards for the forseeable future.++ - Software stacks built for those domains predominantly use an AArch64 Linux kernel build.++ - Rust presents an attractive value proposition across all such domains, irrespective of the underlying processor architecture.++ - **As such, the Rust aarch64-unknown-linux-gnu target's ecosystem presents very strong viability for the long term.**++**2.b. The long term viability of supporting the target should be clear.**++ - It is hard to concretely quantify this aspect.++ - It is worth calling out, in the same vein as the previous point, that given the increasing prevalance of AArch64 silicon deployments and given Rust's general value proposition, **supporting the Rust aarch64-unknown-linux-gnu target presents very strong viability for the long term.**++**2.c. The target must have substantial and widespread interest within the Rust developer community.**++ - It is hard to concretely quantify this aspect.++ - It is generally fair to state that **there is already substantial and widespread interest for the aarch64-unknown-linux-gnu target in the Rust developer commmunity**.++ - It is also generally fair to state that there is a clear upward trend in the use of AArch64 systems as self hosted development environments. ++ - Most major operating system environments support hosted development on AArch64 based systems and this trend is increasing.++ - As a somewhat related note: Slow but steady progress is being made to support Windows AArch64 targets, initially for cross-platform development. This shall inevitably trend towards hosted development.++ - As such, **it is very likely that developer interest in Rust on aarch64-unknown-linux-gnu will continue to increase in the medium to long term.**++**2.d. The target must serve the interests of multiple production users of Rust across multiple organizations or projects.**++ - It is hard to concretely quantify this aspect.++ - Most major Arm software ecosystem partners are either already using Rust extensively, or are building up to extensive use. A few publically known examples are Microsoft and Google. There are many more.++ - Arm itself recognises Rust as an important component to consider in a broader horizontal safety and security foundation across multiple processor portfolios. ++ - Arm has dedicated a small team to help improve Rust for the aarch64-unknown-linux-gnu target.++ - **It is very likely that support for aarch64-unknown-linux-gnu in these organisations will trend upwards commensurate with the increasing prevalence of AArch64 silicon based systems.**++Points 3.a through 3.c from the [Guide-level explanation](#Guide-level-explanation) section above are addressed in the [Unresolved questions](#unresolved-questions) section below.++# Drawbacks+[drawbacks]: #drawbacks++**There is no drawback envisioned in promoting the Rust aarch64-unknown-linux-gnu to Tier-1.**

There is one important caveat/drawback/? compared to other current T1 targets – most developers won’t yet have access to aarch64 hardware that's capable enough to support compiler development. We do not currently have any infrastructure to provide such access either. As such there's a significant limitation in terms of developer-power that we would be able to mobilize in case something broke on aarch64.

That’s not an explicit requirement for a target to become T1 though (should it be?), so not saying this is a blocker or anything of the sort.

Hi @nagisa.

Thanks for your comment. You raise a good point.

I think that it is reasonable to state that at present access to AArch64 systems capable of typical self hosted development is not as widespread as it perhaps needs to be.

That said, the key points to consider are:

  1. That adequate access has been enabled such that the essential Rust lang compiler tests can be reliably run. Something that is key to track the evolution of the Rust lang master repository on AArch64 systems.

  2. That there is strong evidence of rapid commoditisation of AArch64 silicon based systems that are convenient for self hosted development.

  3. That until that commoditisation is truly widespread, the organisations that are putting skin into the game will likely provide suitable stop gaps.

On the basis of the above points, I am sincerely of the opinion that this problem should not impede the intent here. In fact, moving to Tier-1 is likely to accelerate the commoditisation of AArch64 systems to an extent that suitable systems are genuinely accessible to the Rust developer community.

I hope that the above assuages your concern. Happy to discuss further through to a mutually agreeable conclusion.

Thanks

raw-bin

comment created time in 2 months

Pull request review commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

+- Feature Name: `promote-aarch64-unknown-linux-gnu-to-tier-1`+- Start Date: 2020-07-17+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Promote the Arm aarch64-unknown-linux-gnu Rust target to Tier-1.++# Motivation+[motivation]: #motivation++Arch64-unknown-linux-gnu is [currently a Tier-2 Rust target](https://forge.rust-lang.org/release/platform-support.html#tier-2), in accordance with the target tier policy articulated [here](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-09-20-target-tier-policy/).++In the last 2 quarters, very good progress has been made in understanding and filling the gaps that remain in the path to attaining Tier-1 status for this target.++As a direct result, those gaps have either already been filled or are very close to being filled.++As such, this RFC aims to:++- Evidence what has been done.++- On the basis of that evidence propose that the proceeedings to promote the aarch64-unknown-linux-gnu target to the Tier-1 category may please be kickstarted.++- Culminate in the actual promotion of the aarch64-unknown-linux-gnu target to Tier-1, including any and all of the relevant processes and actions as appropriate.++Please note that the narrative here doesn't always match the RFC template so some liberties may have been taken in the expression.++Please also note, by way of wilful disclosure, that this RFC's author is an employee of Arm.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++1. **In essence, the target tier policy for a Tier-1 target aims to obtain the following technical and tangible assurances:**++   a. The Rust compiler and compiler tests must all build and pass reliably for the target in question.++   b. All necessary supporting infrastructure, including dedicated hardware, to build and run the Rust compiler and compiler tests reliably must be available openly.++   c. There must exist a robust and convenient CI integration for the target in question.++2. **In addition, the target tier policy for a Tier-1 target aims to obtain the following stategic assurances:**

Hi.

Thanks for your comments. I chose the word 'strategic' as it appeared to me to best describe the relevant non-technical asks in the target tier policy. I think it is important to use a discriminator for the asks in question in order to help structure the discussion. I am more than happy to use some replacement for 'strategic'. Thanks!

raw-bin

comment created time in 2 months

Pull request review commentrust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

+- Feature Name: `promote-aarch64-unknown-linux-gnu-to-tier-1`+- Start Date: 2020-07-17+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++Promote the Arm aarch64-unknown-linux-gnu Rust target to Tier-1.++# Motivation+[motivation]: #motivation++Arch64-unknown-linux-gnu is [currently a Tier-2 Rust target](https://forge.rust-lang.org/release/platform-support.html#tier-2), in accordance with the target tier policy articulated [here](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2019-09-20-target-tier-policy/).++In the last 2 quarters, very good progress has been made in understanding and filling the gaps that remain in the path to attaining Tier-1 status for this target.++As a direct result, those gaps have either already been filled or are very close to being filled.++As such, this RFC aims to:++- Evidence what has been done.

The use of evidence as a transitive verb is considered legal! (see: https://www.merriam-webster.com/dictionary/evidence). A purist would argue that that's not the case with the British English definition though! :)

raw-bin

comment created time in 2 months

PR opened rust-lang/rfcs

RFC: Promote aarch64-unknown-linux-gnu to a Tier-1 Rust target

This commit contains an RFC proposal to promote the aarch64-unknown-linux-gnu Rust target to Tier-1.

+188 -0

0 comment

1 changed file

pr created time in 2 months

create barnchraw-bin/rfcs

branch : promote-aarch64-unknown-linux-gnu-to-tier-1

created branch time in 2 months

delete branch raw-bin/rfcs

delete branch : promote-aarch64-unknown-linux-gnu-to-tier-1

delete time in 2 months

create barnchraw-bin/rfcs

branch : promote-aarch64-unknown-linux-gnu-to-tier-1

created branch time in 2 months

delete branch raw-bin/rfcs

delete branch : promote-aarch64-unknown-linux-gnu-to-tier-1

delete time in 2 months

create barnchraw-bin/rfcs

branch : promote-aarch64-unknown-linux-gnu-to-tier-1

created branch time in 2 months

fork raw-bin/rfcs

RFCs for changes to Rust

https://rust-lang.github.io/rfcs/

fork in 2 months

more