Conversation
Pushed out updates to fix some test errors. |
Thanks for the work on arm64! This has a lot of Godeps changes but Since it is a lot of changes and GitHub is not able to display the diff, maybe you could write a PR for just Godeps first and get the rest of the changes in a second PR? |
@alban For the Godeps, I just replaced the files from upstream. I'll split that into a separate PR and follow the prescribed procedure. Also, How can I find out why Jenkins is failing? I seem to need CoreOS login credentials. |
Rebased to latest, removed patch 'Godeps: Update sys/unix to get arm64 support'. |
Depends on #2764 |
@glevand looks great, can't wait to try it out. Regarding the jenkins failure, this is the relevant failure, but I don't see how it is related to your PR:
|
It's not related, Jenkins is not reliable yet. Working on it in #2762 |
Regarding the Godeps bumps/changes: I went through all commits I think can catch up with this in case it lands first and factor it in my glide PR. |
Rebased to latest, which includes #2764 |
Rebased to latest. |
CCN_IMG_RELEASE := 1032.0.0 | ||
endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
General concern: I'm not sure we want to venture into this path of having different arch-specific versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lucab So you prefer a patch that bumps x86 to 1053.2.0 or later?
Our options are here: https://alpha.release.core-os.net/arm64-usr/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd opt-in for a single version too. But that would need testing if nothing breaks in amd64 too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's update to 1068.0.0 then, which is also the current base for the beta channel. I'm testing a bump to it right now for amd64, if everything is fine I'll ping back here with the PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lucab 1068.0.0 builds OK on arm64. I'll try running it and adjust my stage1 manifest files if needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lucab Tested 1068.0.0 based arm64 stage1-coreos.aci and stage1-fly.aci and they seem to run OK.
@coreos/rkt-maintainers PTAL for 1.9.0 |
@@ -724,7 +735,8 @@ RKT_IF_HAS_FLAVOR([${RKT_STAGE1_FLAVORS}], [coreos,kvm], | |||
coreos/kvm flavor specific build parameters | |||
|
|||
local CoreOS PXE image path: '${RKT_LOCAL_COREOS_PXE_IMAGE_PATH}' | |||
local CoreOS PXE image systemd version: '${RKT_LOCAL_COREOS_PXE_IMAGE_SYSTEMD_VER}'])]) | |||
local CoreOS PXE image systemd version: '${RKT_LOCAL_COREOS_PXE_IMAGE_SYSTEMD_VER}' | |||
stage1 CoreOS board: '${RKT_STAGE1_COREOS_BOARD}'])]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just asking: why it is named "CoreOS board"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@krnowak 'board' is the terminology used by coreos for the build target. Currently we have amd64-usr and arm64-usr.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Specifically inherited from ChromeOS where each image type literally is targeting a specific piece of physical hardware. Our image types are more general purpose so it makes less sense but the term is used so extensively it wouldn't really be worth changing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, thanks for info!
There are some changes in the builddir layout that probably require some change log entry too, as the built rkt and stage1 images are now in a different directory. |
CCing myself, @krnowak |
Rebased to latest, addressed all comments so far. |
The makefile variable MAKETOOLSDIR is unused, so remove it. Signed-off-by: Geoff Levand <geoff@infradead.org>
To aid in debugging go build problems, add go verbosity flags when the make variable V is set. Signed-off-by: Geoff Levand <geoff@infradead.org>
To allow for cross compile builds, output CC and CXX to the makefile. Signed-off-by: Geoff Levand <geoff@infradead.org>
To allow the build system to target multiple architectures, add the new arch related makefile variables GOARCH, RKT_ACI_ARCH, and RKT_STAGE1_COREOS_BOARD. Signed-off-by: Geoff Levand <geoff@infradead.org>
To allow GO_ENV to be the default environment, and for BGB_ADDITIONAL_GO_ENV to override that default when needed, switch the order of the two on the go invocation. Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Geoff Levand <geoff@infradead.org>
The generated actool is a host tool, so move it to the TOOLSDIR. Signed-off-by: Geoff Levand <geoff@infradead.org>
Create new makfile variables TARGET_BINDIR and TARGET_TOOLSDIR to hold files for use within the target image. Files intended to be used on the host at build time will continue to be located in TOOLSDIR. Signed-off-by: Geoff Levand <geoff@infradead.org>
To allow building rkt from multiple CoreOS board images move the manifest files to board specific directories. Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Geoff Levand <geoff@infradead.org>
Set the arch value of the ACI manifest based on the RKT_ACI_ARCH variable. Signed-off-by: Geoff Levand <geoff@infradead.org>
Set the arch value of the ACI manifest based on the RKT_ACI_ARCH variable. Signed-off-by: Geoff Levand <geoff@infradead.org>
The interpreter binary is arch specific, so split the interpBin definition off into the arch specific file init_linux_amd64.go, and add a new one, init_linux_arm64.go. Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Geoff Levand <geoff@infradead.org>
Use the travis apt packages addon to simplify installing packages. Signed-off-by: Geoff Levand <geoff@infradead.org>
Add a local gimme script that knows how to provide a go compiler with arm64 cgo support. This change can be reverted once travis PR #45 is merged. Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Geoff Levand <geoff@infradead.org>
Rebased to latest. |
LFAD. |
@glevand thanks for the awesome work and your patience! |
This series adds arm64 support to rkt. It also includes some minor build enhancements. I can split the series into multiple PRs if it would make review easier.
I tested cross building stage1 flavors 'coreos' and 'fly'. The rkt binary and ACI images generated can run successfully on CoreOS running on qemu-system-aarch64.
On my system (ubuntu 15.10), cross building stage1 flavor 'kvm' failed:
configure: error: ** No development headers for openssl found
. I'll look into getting and environment with the needed cross build dependencies.This PR includes the gimme script submitted upstream at travis-ci/gimme#45. If that is merged we can remove the gimme.local here.
cc: @crawford