Build of meteor 0.10.1 can't find fibers binary

[gischer]

I'm trying to upgrade my meteor/sandstorm app to Meteor 0.10.1. I get the following when I run it (using meteor-spk dev)

** Starting Meteor...
## There is an issue with `node-fibers` ##
`/programs/server/node_modules/fibers/bin/linux-x64-57-glibc/fibers.node` is missing.

Try running this to fix the issue: node /programs/server/node_modules/fibers/build

I see this issue with both the old meteor-spk (1.4.1) and the current one (1.5.1) with no difference.

However,

% ls .meteor-spk/bundle/programs/server/node_modules/fibers/bin
darwin-x64-64        linux-x64-64-glibc  repl           win32-x64-72
darwin-x64-72        linux-x64-64-musl   win32-ia32-64
linux-ia32-64-glibc  linux-x64-72-glibc  win32-ia32-72
linux-ia32-72-glibc  linux-x64-72-musl   win32-x64-64

So it appears that the version of node that's running was built against ABI 57, but that's not what the fibers build downloads, its too old.

I'm not sure where the node binary comes from, or how to change it. Any hints would be appreciated.

[ocdtrekkie]

I am guessing @xet7 might have good advice for you here. He's dealt with a lot of "can't find fibers" issues. Is the app one with source up on GitHub you can link?

[xet7]

Hmm, maybe I fixed it sometime. I added meteor-spk here: https://releases.wekan.team/meteor-spk/

For any CPU architecture you can build fibers like this: https://github.com/wekan/wekan/wiki/s390x#how-this-s390x-bundle-package-was-created

[xet7]

And here is maintainer script that converts x64 bundle to RasPi3/4 bundle arm64 linux: https://releases.wekan.team/raspi3/

[ocdtrekkie]

I was thinking about that I think you scripted an extra command or two to install fibers when building Sandstorm: https://github.com/wekan/wekan/blob/master/releases/release-sandstorm.sh

[gischer]

Unfortunately, no, my source is not publicly available. It's on a Gogs Meteor Server running on my Sandstorm site. I could wing an invite to you if needed.

I seem to be building lots of fibers binaries, just not the right ones. For instance, I just reran my process, and looked at the results in bundle/programs/server/node_modules/fibers:

~/build/secrets-of-toanium/.meteor-spk/bundle/programs/server/node_modules$ ls -l fibers/bin
total 52
drwxr-xr-x 2 gischer gischer 4096 Apr 30 16:50 darwin-x64-64
drwxr-xr-x 2 gischer gischer 4096 Apr 30 16:50 darwin-x64-72
drwxr-xr-x 2 gischer gischer 4096 Apr 30 16:50 linux-ia32-64-glibc
drwxr-xr-x 2 gischer gischer 4096 Apr 30 16:50 linux-ia32-72-glibc
drwxr-xr-x 2 gischer gischer 4096 Apr 30 16:50 linux-x64-64-glibc
drwxr-xr-x 2 gischer gischer 4096 Apr 30 16:50 linux-x64-64-musl
drwxr-xr-x 2 gischer gischer 4096 Apr 30 16:50 linux-x64-72-glibc
drwxr-xr-x 2 gischer gischer 4096 Apr 30 16:50 linux-x64-72-musl
-rwxr-xr-x 1 gischer gischer 1175 Oct 26  1985 repl
drwxr-xr-x 2 gischer gischer 4096 Apr 30 16:50 win32-ia32-64
drwxr-xr-x 2 gischer gischer 4096 Apr 30 16:50 win32-ia32-72
drwxr-xr-x 2 gischer gischer 4096 Apr 30 16:50 win32-x64-64
drwxr-xr-x 2 gischer gischer 4096 Apr 30 16:50 win32-x64-72

The trouble is, they aren't the right ones. They seem to be too recent, and when the app runs it looks for build 57 not 64 or 72. It looks to me like the node version running is too old. At my own command line I get:

node -v
v10.20.1

That seems kind of old as best I can tell, and yet it's what I get when I do a fresh install.

And furthermore, that isn't necessarily the version that runs inside the Vagrant instance. Maybe that one needs to be updated? After all if I run my app by typing "meteor" it runs fine. It only fails in Sandstorm mode. How would I check this? I'm a Vagrant noob.

[ocdtrekkie]

Vagrant shouldn't be involved at all if this is a meteor-spk build. Are you talking about trying to enter the grain sandbox?

That functionality exists in vagrant-spk, and while it could be generalized to any Sandstorm packaging, it currently only exists as part of that tool.

[gischer]

The reason I suspect Vagrant is that the application runs fine from the command line. It only fails when I try to run it in Sandstorm, inside the Vagrant container. At the very least, that tells me that something different is happening between these two scenarios. I just don't know what that is. I mean, it's likely that a different version of node is installed inside Vagrant, and that's why I'm having a problem.

So to follow this up, I blew away my init and redid meteor-spk init in this directory, but that didn't change anything.

I'll continue plugging away on building the fibers binaries by hand. I'm having other issues with that.

[ocdtrekkie]

The point of confusion I feel like you may have here: Sandstorm does not run apps inside Vagrant. The only time anything generally uses Vagrant is if you are packaging apps with the vagrant-spk tool specifically.

[gischer]

Wow. Thanks. I am confused about that. Or rather, I was confused about that.

[ocdtrekkie]

meteor-spk is using Meteor 1.10.1, so you should be on some Node 12 flavor, I believe? 12.16.1.6 is the "bundle version" set in Meteor 1.10.1, if that's informative.

[gischer]

I have resolved this. I believe the resolution was to download the new version of meteor-spk and use it correctly.

The old one 1.4.1 has an old node binary. The new one has a new binary, which matches the one used by Meteor. I'm not quite sure why my early attempt to use this failed, but I do know that for most of this morning, a minimized shell window was holding open a "meteor-spk dev" instance, so that my attempts to build new tries in another window were being ignored.

This makes me feel a bit dumb, but I feel it will be helpful to have this written down somewhere. The things I did today are:

1. Redid meteor-spk init I had to delete my sandstorm-pkgdef.capnp and then pull it back from git to do this.
2. Brought my system node up to the same version as the meteor node.
3. Reran with meteor-spk (version 1.5.1) after verifying that it, too has the same version of node. And now it's up and running.

Thanks for your help.

[ocdtrekkie]

Glad to hear you got it worked out, and thanks for contributing how you did so for any passers-by later!

[zenhack]

Related: https://github.com/sandstorm-io/sandstorm/issues/673

I feel like I've seen the behavior of silently ignoring the second session (rather than the more obscure error) too, so maybe the behavior has changed since then.