These are chat archives for nebrius/raspi-io

6th
Jun 2016
ajfisher
@ajfisher
Jun 06 2016 00:27
Cool - thanks. If you can document what you need to review (even loosely) then I can probably lend a hand there as I'm doing a lot of nodebotsy stuff with RPis now the RPI3 is so great out of the box...
Bryan Hughes
@nebrius
Jun 06 2016 00:46
Sooooo…raspi-io builds fine for me on Raspbian 2016-5-27 on node 6.2.1 built for armv7
and NAN is up to date
do you know which release of Raspbian you’re running, and which architecture Node was built for?
^^ @ajfisher
ajfisher
@ajfisher
Jun 06 2016 04:26
hmmm that's super weird @nebrius - Basically it was latest on Raspbian and Node. Notably I did install node using nvm though... I wonder if that caused it
Bryan Hughes
@nebrius
Jun 06 2016 04:27
oh yeah, nvm causes all kinds of weird issues because pathing doesn’t normally apply to anything run using sudo
(you have to manually monkey patch things to get it to work)
so yeah, don’t use nvm on the Pi
also, are you using armv6 or armv7 Node?
ajfisher
@ajfisher
Jun 06 2016 04:30
LOL - okay - I can make that work
ajfisher
@ajfisher
Jun 06 2016 04:38
Not sure re armv6 or armv7 - would just be whatever nvm pulls down when you grab it on nvm install 6.2.1 - I'll try a "proper" install not using nvm later. Having said that, on another RPi image, I am using nvm as well and that was working okay... will get more info
ajfisher
@ajfisher
Jun 06 2016 11:17

okay so the whole "don't use nvm" was where the issue was coming from. For reference this is what happened:

  • I used nvm on another image and was freely switching between 5.x and 6.x and it was working fine. "Yay!", says I, "nvm works fine"
  • I've then switched to using salt-stack to manage a number of RPis that I have to use for a workshop.
  • The combination of nvm + some oddities about how a salt-minion runs a command issued from the salt-master, and what type of shell it was executing under was causing some serious mangling of paths etc.
  • Specifically the nvm.sh config script wasn't being executed before hand.

Resolution was as simple as forcing the salt-minion to run the nvm.sh shell script and THEN execute npm install.

Fixed, and FYI, nvm appears to behave properly (that issue aside). Also Salt-Stack for managing your RPi "fleet" works a treat

Bryan Hughes
@nebrius
Jun 06 2016 17:36
@ajfisher does nvm work when you use sudo node script.js? It’s been a while since I tested, but last time I tried, nvm.sh wasn’t executed for the root user, and I got an “node: command not found” error
ajfisher
@ajfisher
Jun 06 2016 20:58
@nebrius no, but you can either put the path to the nvm node on the root path var or just call it explicitly (I just set up an alias)
Bryan Hughes
@nebrius
Jun 06 2016 20:59
that’s what I did when messing with it too, but when you switch node versions between the install (which is non-sudo), then you have to remember to update the path by hand, otherwise it’ll crash on startup (which is sudo) due to the native module being compiled for the wrong version
so if it’s something that I get wrong regularly, there’s no way in hell I’m supporting it for others ;-)
ajfisher
@ajfisher
Jun 06 2016 21:10
yeah that's totally fair enough - I wonder if there's a way to make it install machine wide rather than specific user...
Bryan Hughes
@nebrius
Jun 06 2016 21:10
Maybe hack nvm.sh into rc.local?
ajfisher
@ajfisher
Jun 06 2016 21:14
Maybe - or maybe just doing the nvm install in somewhere like /usr/local and make the nvm.sh script fire at /etc/profile or something... I'll have a play and see what I can come up with
not sure how multiple versions of node would work in this case though... ie how nvm install X would work...
Bryan Hughes
@nebrius
Jun 06 2016 21:14
I dunno, manually modifying auto-generated files makes me feel squicky.
ajfisher
@ajfisher
Jun 06 2016 21:15
I hear that
Bryan Hughes
@nebrius
Jun 06 2016 21:15
My feeling is hacking nvm to support this use case is just asking for trouble
so I do a sort of manual version of this that’s way more reliable for my use case
I install them to /usr/local/node/<version>/ then symlink the appropriate binaries to /usr/local/bin/
works for every user and is impossible to get out of sync
but still easily allows switching between versions
you can also symlink versions to /usr/local/node/current and then symlink binaries from there to /usr/local/node to make switching symlinks easier