Not able to use "hard" way to build firmware

[paidforby]

Trying to build the extender node firmware using the old, hard way. The readme says I have to first build the home node firmware, unclear why, but when I try to do this it throws an "operation not permitted error" (see screenshot, probably dependencies, hence the docker container method). Is there a better more up-to-date way to build the extender node firmware, can we add this as an option in the "easy", docker method of building.

[paidforby]

Looking at issue #103 it might have to do with my distro of ubuntu. I might try on my debian part, which had previously worked with the the old build script (but that may have been using docker?). Or I will just try running the extender node build script from within the same docker container I used to build the home node firmware. Hopefully the build scripts still point to the right directories since the extender node script needs to reference the home node build.

[paidforby]

Think the problem is with entrypoint.sh. Will update to allow option for building extender node, currently only provides option for ar71xx arch. (this change should allow building from within docker)

[andrewdollard]

ar71xx is the default, but if you pass a different architecture as the last argument to `docker run` it will build that one instead

…

On Tue, Apr 25, 2017 at 3:18 PM, gcgallo ***@***.***> wrote: Think the problem is with entrypoint.sh. Will update to allow option for building extender node, currently only provides option for ar71xx arch. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#105 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABDy8CC51SR51m_7um_OwCbt41LfKDGyks5rznExgaJpZM4NH-ml> .

[paidforby]

Tried passing ar71xx.extender-node but it didn't like that. The extender nodes are weird because they aren't a different architecture, but require a different build script. Was going to add a condition that if you execute docker run -v $PWD/firmware_images:/firmware_images sudowrt ar71xx.extender-node it will point to the build_extender-node script instead, assuming that script works within docker.

[paidforby]

Cannot run command posted in previous comment after running the home node build because the docker container where the build runs does not persist. To solve this I am trying to run both commands one after another in the same docker session like so,
docker run -v $PWD/firmware_images:/firmware_images sudowrt ar71xx; $PWD/firmware_images:/firmware_images sudowrt ar71xx.extender-node;
Assuming this works, we should come up with a better way of doing this so you don't have to rerun the entire build just to build the extender node. Maybe figure how to allow the docker container to persist? Or copy the necessary files out of the docker container after running the first build?

[paidforby]

It seems the command I posted in the previous comment will not work because a docker container will not run multiple entrypoints without a supervisor. Instead, I plan on modifying the entrypoint so it can take multiple arguments and then loop through the build script for each argument. Should look something like this:
docker run -v $PWD/firmware_images:/firmware_images sudowrt ar71xx.home-node ar71xx.extender-node

[jhpoelen]

@paidforby @andrewdollard I've boiled down entrypoint.sh to its essentials and removed the entrypoint_old.sh and just started a build. Hoping to report back in a bit.

[jhpoelen]

Found #113 when attempting a build and don't have access to network bandwidth now, so having a hard time to reproduce/fix. I think that having a #111 would help to figure out how to build the firmware reliably. Perhaps we can break the process up into steps - (1) create a 14.04 based image with dependencies with push to docker hub, (2) create image and populate a pre-make image with all external deps ready to go (e.g., get repos, apply patches, import feeds). With image (2) pushed to docker hub, I imagine it might be easier to reproduce and make errors without having to download the entire interwebs each time. And, with some luck we'd be able to setup travis loops for (1) and (2).

Hoping to experiment with this soon and curious to hear thoughts.

[andrewdollard]

I think this is generally the right approach, although I think it's the `make` part of the process that actually takes the longest, and if possible we should find a way to cache most of that. We also want to make sure that the seams in the build are well-though-out, so that the most common updates (like e.g. tweaks to the babel config, or the dashboard) can make use of most of the cache, and only rarer changes (like changing the OpenWRT version) require a deeper rebuild of the cache.

…

On Wed, Nov 8, 2017 at 7:45 AM, Jorrit Poelen ***@***.***> wrote: Found #113 <#113> when attempting a build and don't have access to network bandwidth. I think that having a #111 <#111> would help to figure out how to build the firmware reliably. Perhaps we can break the process up into steps - (1) create a 14.04 based image with dependencies with push to docker hub, (2) create image and populate a pre-make image with all external deps ready to go (e.g., get repos, apply patches, import feeds). With image (2) pushed to docker hub, I imagine it might be easier to reproduce and make errors without having to download the entire interwebs each time. And, with some luck we'd be able to setup travis loops for (1) and (2). Hoping to experiment with this soon and curious to hear thoughts. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#105 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABDy8CIcW00Vy_YYHD2I5RA0KwmNHVcrks5s0cyXgaJpZM4NH-ml> .

[jhpoelen]

I've documented a first pass at building firmware as discussed, see #111 (comment) . Please reproduce.

[jhpoelen]

I was able to successfully build and run firmware (see #111 (comment)) . Please re-open if you can't reproduce.