chore: build armhf on GNU/Linux #1482

jviotti · 2017-05-30T00:58:57Z

This commit makes use of the resin/armv7hf-debian Docker image to
test and generate armhf builds.

We needed to add a slash before build in .gitignore given that git
was refusing to include any changes on scripts/build otherwise.

Signed-off-by: Juan Cruz Viotti jviotti@openmailbox.org

lurch · 2017-05-31T13:32:48Z

Could you add -t docker support to scripts/build/architecture-convert.sh and then update scripts/build/docker/run-command.sh to use it?

I've not tested myself yet, but does changing armv7l to armv7hf in various places now mean that Etcher won't build so easily on a RPi3 as it did before? (which isn't something we officially support yet, but apparently some users have tried it and found it works)

We needed to add a slash before build in .gitignore given that git was refusing to include any changes on scripts/build otherwise.

Lol, good catch!

EDIT: Once this is all working, should we also start publishing armv7hf builds to bintray?

jviotti · 2017-05-31T13:50:48Z

Could you add -t docker support to scripts/build/architecture-convert.sh and then update scripts/build/docker/run-command.sh to use it?

Done!

I've not tested myself yet, but does changing armv7l to armv7hf in various places now mean that Etcher won't build so easily on a RPi3 as it did before? (which isn't something we officially support yet, but apparently some users have tried it and found it works)

This whole ARM architecture mess confuses me, but as far as I understand, both armv7l and armv7hf builds are compatible with each other. In fact, Debian only seems to support armhf (https://wiki.debian.org/SupportedArchitectures), so we'd have to coerce both to that anyway.

jviotti · 2017-05-31T13:51:19Z

EDIT: Once this is all working, should we also start publishing armv7hf builds to bintray?

Yeah, let's try to sort out snapshot Bintray builds first.

lurch · 2017-05-31T14:24:06Z

This whole ARM architecture mess confuses me

...and lots of other people too! ;-)

In fact, Debian only seems to support armhf

https://wiki.debian.org/ArmHardFloatPort says "Currently the Debian armhf port requires at least an ARMv7 CPU with Thumb-2 and VFP3D16." so I guess the armhf in Debian is actually armv7hf.

I'm not sure what armv7l indicates though :-S

jviotti · 2017-05-31T14:26:56Z

Once we get this running, I'll give the compiled package a go in an armv7l Pi and we'll see how that goes.

lurch · 2017-05-31T14:27:27Z

scripts/build/docker/run-command.sh

-IMAGE_ID="etcher-build-$ARGV_ARCHITECTURE"
+DOCKER_ARCHITECTURE=$(./scripts/build/architecture-convert.sh -r "$ARGV_ARCHITECTURE" -t docker)
+DOCKERFILE="$HERE/Dockerfile-$DOCKER_ARCHITECTURE"
+IMAGE_ID="etcher-build-$DOCKER_ARCHITECTURE"


Much nicer 🎉
Although does changing IMAGE_ID from etcher-build-$ARGV_ARCHITECTURE to etcher-build-$DOCKER_ARCHITECTURE mean that any existing Docker images will become invalidated / redundant?

Just on your build environment, so that's fine, they will get re-created the next time.

lurch · 2017-05-31T15:32:01Z

Makefile

@@ -73,7 +73,7 @@ else
 			HOST_ARCH = x86
 		endif
 		ifeq ($(shell uname -m),armv7l)
-			HOST_ARCH = armv7l
+			HOST_ARCH = armhf


IMHO we should keep this 'top-level' ARCH string as armv7hf, as that's much more specific, and then convert it as necessary inside the other scripts.

Yeah, I thought about that, however I think it'd be even more confusing that various armv7 similar architectures (like armv7l and armv7hf) generate the same armhf package. What do you think?

Since they all result in the same generic architecture, maybe its worth to convey that very clearly from the start?

I think "generate the same armhf package" is an OS-specific assumption. E.g. just because armv7hf actually maps to armhf on Debian, there might be separate armv6hf and armv7hf packages on some other OS. So IMHO we should keep the Makefile as specific as possible, and then let architecture-convert.sh map that to whatever arch-strings different systems / platforms / OSes / tools need, as necessary.

EDIT: but yeah, I agree that we should probably treat armv7hf and armv7l as equivalent - I've asked for more info about it in flowdock.

Fair enough. Check my latest changes!

lurch · 2017-06-01T19:59:12Z

scripts/build/architecture-convert.sh

@@ -51,17 +51,25 @@ if [ "$ARGV_TYPE" == "node" ]; then
    RESULT=ia32
  elif [ "$ARGV_ARCHITECTURE" == "x64" ]; then
    RESULT=x64
-  elif [ "$ARGV_ARCHITECTURE" == "armv7l" ]; then
+  elif [ "$ARGV_ARCHITECTURE" == "armhf" ]; then


This should be armv7hf ;-)

It might also be worth this script checking that the supplied $ARGV_ARCHITECTURE is in the list [x86, x64, armv7hf] of 'recognised arches' before then checking the $ARGV_TYPE?

Oops, I missed that one!

It might also be worth this script checking that the supplied $ARGV_ARCHITECTURE is in the list [x86, x64, armv7hf] of 'recognised arches' before then checking the $ARGV_TYPE?

What would be the difference? Unless I'm missing something, if the architecture is not set by the specified type, then the script will complain when it finds out that RESULT is not defined.

I guess it's just a "belt and braces" approach, but you're right in that it's probably not necessary. As long as we're always sure that the type-blocks are always checking for the identical ARCH strings ;)

alexandrosm · 2017-06-01T22:00:35Z

team, please make sure to be in line with the designations the rest of the resin team uses for architectures etc, as we want to prevent divergence that will be a mess to handle in the future.

…

-- *Alexandros Marinos* Founder & CEO, Resin.io +1 206-637-5498 @alexandrosm

On Thu, Jun 1, 2017 at 1:47 PM, Juan Cruz Viotti ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In scripts/build/architecture-convert.sh <#1482 (comment)>: > @@ -51,17 +51,25 @@ if [ "$ARGV_TYPE" == "node" ]; then RESULT=ia32 elif [ "$ARGV_ARCHITECTURE" == "x64" ]; then RESULT=x64 - elif [ "$ARGV_ARCHITECTURE" == "armv7l" ]; then + elif [ "$ARGV_ARCHITECTURE" == "armhf" ]; then Oops, I missed that one! It might also be worth this script checking that the supplied $ARGV_ARCHITECTURE is in the list [x86, x64, armv7hf] of 'recognised arches' before then checking the $ARGV_TYPE? What would be the difference? Unless I'm missing something, if the architecture is not set by the specified type, then the script will complain when it finds out that RESULT is not defined. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1482 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABLUCEmfEpqRJv0GJ9X_X3flIWkIFc6Rks5r_yNzgaJpZM4NpuW8> .

jviotti · 2017-06-01T23:01:17Z

What is the current source of truth? Should I look at the current device types, given we're aware they are already diverging in some cases? — Juan Cruz Viotti

--- original message --- On Thu, Jun 1, 2017 at 06:00 pm, <notifications@github.com> Alexandros Marinos wrote: team, please make sure to be in line with the designations the rest of the resin team uses for architectures etc, as we want to prevent divergence that will be a mess to handle in the future.

-- *Alexandros Marinos* Founder & CEO, Resin.io +1 206-637-5498 @alexandrosm

On Thu, Jun 1, 2017 at 1:47 PM, Juan Cruz Viotti ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In scripts/build/architecture-convert.sh <#1482 (comment)>: > @@ -51,17 +51,25 @@ if [ "$ARGV_TYPE" == "node" ]; then RESULT=ia32 elif [ "$ARGV_ARCHITECTURE" == "x64" ]; then RESULT=x64 - elif [ "$ARGV_ARCHITECTURE" == "armv7l" ]; then + elif [ "$ARGV_ARCHITECTURE" == "armhf" ]; then Oops, I missed that one! It might also be worth this script checking that the supplied $ARGV_ARCHITECTURE is in the list [x86, x64, armv7hf] of 'recognised arches' before then checking the $ARGV_TYPE? What would be the difference? Unless I'm missing something, if the architecture is not set by the specified type, then the script will complain when it finds out that RESULT is not defined. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <<#1482 (comment)>, or mute the thread <<https://github.com/notifications/unsubscribe-auth/ABLUCEmfEpqRJv0GJ9X_X3flIWkIFc6Rks5r_yNzgaJpZM4NpuW8> .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread. --- end of original message ---

alexandrosm · 2017-06-01T23:37:36Z

@shaunmulligan can provide guidance

…

-- *Alexandros Marinos* Founder & CEO, Resin.io +1 206-637-5498 @alexandrosm On Thu, Jun 1, 2017 at 4:01 PM, Juan Cruz Viotti <notifications@github.com> wrote:

What is the current source of truth? Should I look at the current device types, given we're aware they are already diverging in some cases? — Juan Cruz Viotti --- original message --- On Thu, Jun 1, 2017 at 06:00 pm, ***@***.***> Alexandros Marinos wrote: team, please make sure to be in line with the designations the rest of the resin team uses for architectures etc, as we want to prevent divergence that will be a mess to handle in the future. -- *Alexandros Marinos* Founder & CEO, Resin.io +1 206-637-5498 <(206)%20637-5498> @alexandrosm On Thu, Jun 1, 2017 at 1:47 PM, Juan Cruz Viotti ***@***.*** > wrote: > ***@***.**** commented on this pull request. > ------------------------------ > > In scripts/build/architecture-convert.sh > <#1482 (comment)>: > > > @@ -51,17 +51,25 @@ if [ "$ARGV_TYPE" == "node" ]; then > RESULT=ia32 > elif [ "$ARGV_ARCHITECTURE" == "x64" ]; then > RESULT=x64 > - elif [ "$ARGV_ARCHITECTURE" == "armv7l" ]; then > + elif [ "$ARGV_ARCHITECTURE" == "armhf" ]; then > > Oops, I missed that one! > > It might also be worth this script checking that the supplied > $ARGV_ARCHITECTURE is in the list [x86, x64, armv7hf] of 'recognised > arches' before then checking the $ARGV_TYPE? > > What would be the difference? Unless I'm missing something, if the > architecture is not set by the specified type, then the script will > complain when it finds out that RESULT is not defined. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <<#1482 (comment)>, or mute > the thread > <<https://github.com/notifications/unsubscribe-auth/ABLUCEmfEpqRJv0GJ9X_ X3flIWkIFc6Rks5r_yNzgaJpZM4NpuW8> > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread. --- end of original message --- — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1482 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABLUCLm1KCq0xK2ZOuzdjsNj4h841uN4ks5r_0LAgaJpZM4NpuW8> .

jviotti · 2017-06-12T17:47:08Z

@petrosagg @nghiant2710 Sorry to bother again, but can someone help me out with this? The builds don't work, I have no clue why, and my Docker knowledge is far from enough to debug this issue.

The Travis CI builds just silently stop without any errors, and I get some weird Go stacktraces on misc1.dev.resin.io.

lurch · 2017-06-12T18:31:09Z

The Travis CI builds just silently stop without any errors

Nope, it says Timeout (20 minutes) reached. Terminating "./scripts/ci/install.sh -o linux -r armv7hf"
Which is obviously because the resin base-image being used is so minimal, that installing all the dependencies we require is just taking too long (and of course everything is being run through qemu so that'll be slowing things down too).
Perhaps we could get a resin/armv7hf-debian-qemu-with-etcher-deps:latest ;-)

I get some weird Go stacktraces on misc1.dev.resin.io.

Maybe that's because the docker on misc1 has these qemu patches already built-in, and so gets confused when you try doing the 'manual workaround' for non-patched docker? (just a guess!)

jviotti · 2017-06-12T18:40:14Z

Nope, it says Timeout (20 minutes) reached. Terminating "./scripts/ci/install.sh -o linux -r armv7hf"

Oh, good observation. I increased the timeout limit to 40 minutes just to see if another error is thrown, but we should investigate why it takes so long, since that's definitely not expected (it takes very little time on misc1 with the non qemu base image).

lurch · 2017-06-12T18:56:29Z

"(and of course everything is being run through qemu so that'll be slowing things down too)"

And misc1 probably has many more spare CPU cycles (and disk bandwidth) than the overloaded Travis VMs ;)

jviotti · 2017-06-15T16:07:10Z

I now get a scary go stacktrace in the builds. Any ideas @petrosagg ?

panic: standard_init_linux.go:175: exec user process caused "exec format error" [recovered]

	panic: standard_init_linux.go:175: exec user process caused "exec format error"

goroutine 1 [running, locked to thread]:

panic(0x7ddea0, 0xc820145500)

	/usr/local/go/src/runtime/panic.go:481 +0x3e6

github.com/urfave/cli.HandleAction.func1(0xc8201032e8)

	/go/src/github.com/opencontainers/runc/Godeps/_workspace/src/github.com/urfave/cli/app.go:478 +0x38e

panic(0x7ddea0, 0xc820145500)

	/usr/local/go/src/runtime/panic.go:443 +0x4e9

github.com/opencontainers/runc/libcontainer.(*LinuxFactory).StartInitialization.func1(0xc820102bf8, 0xc82001a090, 0xc820102d08)

	/go/src/github.com/opencontainers/runc/Godeps/_workspace/src/github.com/opencontainers/runc/libcontainer/factory_linux.go:259 +0x136

github.com/opencontainers/runc/libcontainer.(*LinuxFactory).StartInitialization(0xc820059450, 0x7f505cbb1650, 0xc820145500)

	/go/src/github.com/opencontainers/runc/Godeps/_workspace/src/github.com/opencontainers/runc/libcontainer/factory_linux.go:277 +0x5b1

main.glob.func8(0xc820076a00, 0x0, 0x0)

	/go/src/github.com/opencontainers/runc/main_unix.go:26 +0x68

reflect.Value.call(0x7448a0, 0x8f0bd0, 0x13, 0x839998, 0x4, 0xc820103268, 0x1, 0x1, 0x0, 0x0, ...)

	/usr/local/go/src/reflect/value.go:435 +0x120d

reflect.Value.Call(0x7448a0, 0x8f0bd0, 0x13, 0xc820103268, 0x1, 0x1, 0x0, 0x0, 0x0)

	/usr/local/go/src/reflect/value.go:303 +0xb1

github.com/urfave/cli.HandleAction(0x7448a0, 0x8f0bd0, 0xc820076a00, 0x0, 0x0)

	/go/src/github.com/opencontainers/runc/Godeps/_workspace/src/github.com/urfave/cli/app.go:487 +0x2ee

github.com/urfave/cli.Command.Run(0x83c828, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x8d0180, 0x51, 0x0, ...)

	/go/src/github.com/opencontainers/runc/Godeps/_workspace/src/github.com/urfave/cli/command.go:191 +0xfec

github.com/urfave/cli.(*App).Run(0xc820001800, 0xc82000a100, 0x2, 0x2, 0x0, 0x0)

	/go/src/github.com/opencontainers/runc/Godeps/_workspace/src/github.com/urfave/cli/app.go:240 +0xaa4

main.main()

	/go/src/github.com/opencontainers/runc/main.go:137 +0xe24

lurch · 2017-08-14T15:45:08Z

@jviotti I assume we'll pick this up again when the local CI machines that @brownjohnf is setting up for us are live?

jviotti · 2017-08-14T15:45:51Z

@lurch What do you think about merging the changes to the Makefile, etc, but delay making the CI services actually build this target?

lurch · 2017-08-14T15:57:39Z

Haha, I was just pondering exactly the same thing myself... :-D

jviotti · 2017-08-14T15:59:23Z

Haha, check my latest changes! I think this should already be merge-able

lurch · 2017-08-14T16:01:59Z

If we're only changing the Makefile as you suggested, then I'm not sure if we should be changing .travis.yml too or the Dockerfiles?

jviotti · 2017-08-14T16:07:08Z

Ah, there was an extra .travis.yml change I missed. Regarding the Dockerfiles, I guess we can keep that so people can actually build it without using an actual ARM device. What do you think?

lurch · 2017-08-14T16:27:59Z

Are we sure the Dockerfiles actually work locally? (I could test myself, but quicker to ask @jviotti 😉 ) Remember that none of the instructions we provide actually refer to Docker.
I'll do some testing this evening, if I remember / get time.

...although if people don't have an actual ARM device, why would they want to build the ARM version of Etcher? 😆

This commit makes use of the `resin/armv7hf-debian` Docker image to test and generate armhf builds. We needed to add a slash before `build` in `.gitignore` given that git was refusing to include any changes on `scripts/build` otherwise. Signed-off-by: Juan Cruz Viotti <jv@jviotti.com>

jviotti · 2017-08-21T23:59:26Z

I can confirm it works on misc1, but its slow as hell.

...although if people don't have an actual ARM device, why would they want to build the ARM version of Etcher?

I was thinking people would want to build it on a more powerful host, but ARM on Docker seems to be painfully slow anyway :P

lurch · 2017-08-22T00:22:05Z

Makefile

@@ -138,6 +82,62 @@ $(error Can't build $(TARGET_ARCH) binaries on a $(HOST_ARCH) host)
 endif

 # ---------------------------------------------------------------------
+# Application configuration


Huh, why this massive change to the Makefile? Or is it just GH going crazy again?

This snippet uses TARGET_ARCH, which is declared a bit above, so we needed to move down the whole section

brownjohnf

Looks fine to me

jviotti force-pushed the armv7hf-builds branch from aa8ae3e to 4ce8d3c Compare May 30, 2017 14:52

jviotti force-pushed the armv7hf-builds branch from 4ce8d3c to 15d1ac5 Compare May 31, 2017 13:44

lurch reviewed May 31, 2017

View reviewed changes

jviotti force-pushed the armv7hf-builds branch 2 times, most recently from 312d5bd to d87baee Compare May 31, 2017 14:58

jviotti changed the title ~~chore: build armv7hf on GNU/Linux~~ chore: build armhf on GNU/Linux May 31, 2017

lurch reviewed May 31, 2017

View reviewed changes

jviotti force-pushed the armv7hf-builds branch from d87baee to 6008112 Compare June 1, 2017 19:45

lurch reviewed Jun 1, 2017

View reviewed changes

jviotti force-pushed the armv7hf-builds branch from 6008112 to 77932b3 Compare June 1, 2017 20:48

jviotti force-pushed the armv7hf-builds branch 3 times, most recently from 90dd633 to 3403c8c Compare June 10, 2017 17:40

jviotti force-pushed the armv7hf-builds branch from 3403c8c to 976d229 Compare June 12, 2017 18:39

jviotti force-pushed the armv7hf-builds branch 3 times, most recently from 0c36617 to 70c88a0 Compare June 26, 2017 15:25

jviotti force-pushed the armv7hf-builds branch from 70c88a0 to 6249fae Compare July 20, 2017 18:37

This was referenced Aug 9, 2017

Wishlist: etcher-cli build for ARM platform (Raspberry Pi Raspbian OS) #1683

Closed

Etcher Arm Architecure #1688

Closed

jviotti force-pushed the armv7hf-builds branch from 6249fae to b9d46f4 Compare August 14, 2017 15:55

jviotti force-pushed the armv7hf-builds branch from b9d46f4 to c5ba59e Compare August 14, 2017 16:06

jviotti force-pushed the armv7hf-builds branch from c5ba59e to 18f24d0 Compare August 15, 2017 15:15

jviotti force-pushed the armv7hf-builds branch from 18f24d0 to d355dd0 Compare August 15, 2017 15:58

lurch reviewed Aug 22, 2017

View reviewed changes

brownjohnf reviewed Aug 22, 2017

View reviewed changes

jviotti merged commit 488f281 into master Aug 28, 2017

jviotti deleted the armv7hf-builds branch August 28, 2017 15:26

jviotti mentioned this pull request Dec 1, 2017

doc(MAINTAINERS): Elaborate on the process of releasing #1876

Merged

lurch mentioned this pull request Feb 26, 2018

Use amd64 and i386 as architectures in the build system #1486

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chore: build armhf on GNU/Linux #1482

chore: build armhf on GNU/Linux #1482

jviotti commented May 30, 2017 •

edited

lurch commented May 31, 2017 •

edited

jviotti commented May 31, 2017

jviotti commented May 31, 2017

lurch commented May 31, 2017

jviotti commented May 31, 2017

lurch May 31, 2017

jviotti May 31, 2017

lurch May 31, 2017

jviotti Jun 1, 2017

lurch Jun 1, 2017 •

edited

jviotti Jun 1, 2017

lurch Jun 1, 2017

lurch Jun 1, 2017

jviotti Jun 1, 2017

lurch Jun 2, 2017

alexandrosm commented Jun 1, 2017 via email

jviotti commented Jun 1, 2017 via email

alexandrosm commented Jun 1, 2017 via email

jviotti commented Jun 12, 2017 •

edited

lurch commented Jun 12, 2017

jviotti commented Jun 12, 2017

lurch commented Jun 12, 2017 •

edited

jviotti commented Jun 15, 2017

lurch commented Aug 14, 2017

jviotti commented Aug 14, 2017

lurch commented Aug 14, 2017

jviotti commented Aug 14, 2017

lurch commented Aug 14, 2017

jviotti commented Aug 14, 2017

lurch commented Aug 14, 2017

jviotti commented Aug 21, 2017

lurch Aug 22, 2017

jviotti Aug 22, 2017

brownjohnf left a comment

chore: build armhf on GNU/Linux #1482

chore: build armhf on GNU/Linux #1482

Conversation

jviotti commented May 30, 2017 • edited

lurch commented May 31, 2017 • edited

jviotti commented May 31, 2017

jviotti commented May 31, 2017

lurch commented May 31, 2017

jviotti commented May 31, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lurch Jun 1, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexandrosm commented Jun 1, 2017 via email

jviotti commented Jun 1, 2017 via email

alexandrosm commented Jun 1, 2017 via email

jviotti commented Jun 12, 2017 • edited

lurch commented Jun 12, 2017

jviotti commented Jun 12, 2017

lurch commented Jun 12, 2017 • edited

jviotti commented Jun 15, 2017

lurch commented Aug 14, 2017

jviotti commented Aug 14, 2017

lurch commented Aug 14, 2017

jviotti commented Aug 14, 2017

lurch commented Aug 14, 2017

jviotti commented Aug 14, 2017

lurch commented Aug 14, 2017

jviotti commented Aug 21, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brownjohnf left a comment

Choose a reason for hiding this comment

jviotti commented May 30, 2017 •

edited

lurch commented May 31, 2017 •

edited

lurch Jun 1, 2017 •

edited

jviotti commented Jun 12, 2017 •

edited

lurch commented Jun 12, 2017 •

edited