Bump Node version to 4.1.2

[Student007]

@johnnyman727 A question at this point:

Is it possible to change the node version on the Tessel 2 itself by the prototyping user ?

Possible used case: Someone likes to use old code on Tessel as a IoT-Device. So it would be interesting he could do something like this: t2 provision --node 3.1 (e.g.)

I think it shouldn't be a big thing to do this if you are able to install node by hand like you did by this PR ?

[johnnyman727]

@Student007 Yes - this is more or less what the update command is for. We have not been doing a good job of putting out builds often but eventually I'd like to get at least every minor patch it its own update. Folks who need more granularity than that will have to build the OpenWRT version themselves.

[johnnyman727]

This PR is not compiling Node patches properly. See error below.

make[4]: Leaving directory `/vol/openwrt-tessel/upstream-packages/net/wget'
make[4]: Entering directory `/vol/openwrt-tessel/package/node/nodejs'
. /vol/openwrt-tessel/openwrt/include/shell.sh; gzip -dc /vol/openwrt-tessel/openwrt/dl/node-v4.1.2.tar.gz | tar -C /vol/openwrt-tessel/openwrt/build_dir/target-mipsel_24kec+dsp_uClibc-0.9.33.2/nodejs-v4.1.2/.. -xf -

Applying ./patches/010-uclib_execinfo.patch using plaintext:
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- a/deps/v8/src/base/logging.cc
|+++ b/deps/v8/src/base/logging.cc
--------------------------
No file to patch.  Skipping patch.
2 out of 2 hunks ignored
Patch failed!  Please fix ./patches/010-uclib_execinfo.patch!
make[4]: *** [/vol/openwrt-tessel/openwrt/build_dir/target-mipsel_24kec+dsp_uClibc-0.9.33.2/nodejs-v4.1.2/.prepared_7f65528bdff39a1133af650292635ac4] Error 1
make[4]: Leaving directory `/vol/openwrt-tessel/package/node/nodejs'
make[3]: *** [package/feeds/tessel/nodejs/compile] Error 2
make[3]: Leaving directory `/vol/openwrt-tessel/openwrt'
make[2]: *** [/vol/openwrt-tessel/openwrt/staging_dir/target-mipsel_24kec+dsp_uClibc-0.9.33.2/stamp/.package_compile] Error 2
make[2]: Leaving directory `/vol/openwrt-tessel/openwrt'
make[1]: *** [world] Error 2
make[1]: Leaving directory `/vol/openwrt-tessel/openwrt'
make: *** [world] Error 2

[johnnyman727]

@kevinmehall do you know if the patches mentioned above are even still relevant?

[LinusU]

Yes! I love this! :rocket:

[Student007]

@johnnyman727

Folks who need more granularity than that will have to build the OpenWRT version themselves.

Is there no way to have a remote build system and a script is called on the OpenWRT on the Tessel similar like Ubuntu-Node-Installation was done before some months ? That way it would be decoupled and also minor patches would be possible more or less automatically.

Or is there a wall I couldn't see at the moment (e.g. target platform isn't such stable as common Ubuntu servers) ?

[johnnyman727]

@Student007 yes, it is possible. But the reason I don't like adding more and more commands is because it makes the user experience for people unfamiliar with Tessel worse and worse. I would prefer to have as few commands as possible and then see if we get a critical mass of people requesting some command once T2 is in the wild. That will also allow the development team to focus on the issues that we know are unfinished like our binary modules server or Rust support.

[kevinmehall]

@johnnyman727 Not sure. At the very least, they'll have to be rebased against upstream changes. You can try building without them, and if it works, you don't need them...

[Student007]

@johnnyman727

But the reason I don't like adding more and more commands is because it makes the user experience for people unfamiliar with Tessel worse and worse.

:+1:

I would prefer to have as few commands as possible and then see if we get a critical mass of people requesting some command once T2 is in the wild

Usability is "not having questions" :wink:

I vote for creating an internal structure to be able to implement a command like this. If a lot of people ask for it, it is done fast.

But I only want to put my two cents in here. Maybe it makes you think to make useful changes :+1:

[johnnyman727]

I vote for creating an internal structure to be able to implement a command like this. If a lot of people ask for it, it is done fast.

Yes, I totally agree with you. Fortunately, we have the internal infrastructure all set up in this case (within t2 update).

[johnnyman727]

It looks like the second patch is no longer necessary because Node on master wraps the function in an #ifdef __POSIX__ block.

[kevinmehall]

I'd expect __POSIX__ to be set on OpenWrt; it's probably the added if (v8_is_profiling) { test that helps. Keep that in mind if you later encounter issues with profiling.

[johnnyman727]

@kevinmehall :+1: thanks for the pointer. The revert-pkg-config patch is much, much messier. Complete functions have been removed/renamed and I'm pretty sure that's the source of this issue.

[kevinmehall]

That's for telling it where to find zlib / libuv / openssl dependencies in the openwrt build environment. It's likely that you can make it work without that by passing the right options, or with a more minimal patch that would be accepted upstream. I was just lazy and added a patch that reverted the commit that broke the build script.

[johnnyman727]

@kevinmehall it looks like we are already passing in options to change the paths for those deps (except for libuv). Are you suggesting that we're just not using the correct options?

[kevinmehall]

The commit I reverted changes the parsing of those options, but I don't remember what the actual issue was / don't think I fully investigated it.

[johnnyman727]

@kevinmehall finally got it working. We are down to one patch!

[rwaldron]

Maybe just coincidentally, but today I attempted to update a T2 and the update did not complete and the device is now unresponsive. I tried both t2 update and then hardcore mode with the device in bootloader mode—no luck.

[johnnyman727]

@rwaldron it's definitely coincidental because I haven't put out a new release but do you have the logs from that update?

It sounds like somehow the update to OpenWRT failed if you can't fix it by flashing the co-processor. You can use this script to manually update Tessel 2 Flash and restore your T2. You'll need to provide the script a path to the OpenWRT image.