Fix build and runtime failures of snap #3172
Conversation
Signed-off-by: Dilyn Corner <[email protected]>
automake requires autoconf, and most systems using autotools require both Signed-off-by: Dilyn Corner <[email protected]>
cp will bail just in case source=dest, and in that case we do not care if dest is overwritten. Signed-off-by: Dilyn Corner <[email protected]>
For instance, there are a lot of these types of messages when building: |
Thank you very much for these patches.
I'm just running
Curiously I've not seen this error. If you want to examine a successfully built snap using Node.js 10.24.1 as per the initial snapcraft.yaml provided by @ogra1 you can install it using Apart from this I run WebThings Gateway locally with Node.js 10 all the time in development and that's what the current stable 1.1 release is using, so it should run fine.
No I mean I literally created a new local clone of the GitHub repo and ran
Hmm, OK.
Yes these are just warnings and this is normal. The upgrade to Node.js 20 should eventually get rid of all these warnings. |
|
With the patches in this PR I have successfully been able to locally build the snap and can confirm that it runs. I can also confirm that without the commit which bumps the Node.js version the snap fails to start. In which log did you find the error In the meantime I'm going to land these patches because they do seem to fix the snap and I don't particularly mind upgrading the snap to Node.js 12 given I'm trying to upgrade to Node.js 20 anyway. However, that does diverge from the main build target of current master and I find it disconcerting that a snapcraft.yaml which was previously working for both me and @ogra1 has suddenly stopped working. Let's see if landing this PR gets the remote builds working on other platforms. Thanks |
I saw this printed to stdout after doing the following: I had the idea to increase the verbosity simply because the messages being given weren't actually meaningful errors, rather just indicating that there is an error. E.g., Isn't actually a meaningful message in my experience; I would expect some additional message in the 22 lines.
The only hunch I had as to why you weren't seeing this issue is somehow a different Node had gotten injected into the snap somehow, hence my questions about destructive mode (Node from host somehow finding its way into I do agree that this is disconcerting and I will try to reach out to the snapcraft folx to see if they have any ideas for what could be happening. I can't think of any changes which would have happened in the last few months which would impact this, though. |
|
I discussed with the team and they think it may have had something to do with this change, as it aligns with your experience time-wise and what you were previously doing (and potentially explains the most recent slew of snapcraft.io/build failures). |
Done! 🫡
Closes #3171
Closes #3167
That's interesting. I'm not familiar enough with Node or JS to explain how that's the case.
They shouldn't be different. How are you building the snap locally? I'm building with snapcraft 8.x (various versions) with
--use-lxd, I'm trying now with snapcraft 7.5.5 in a Jammy container with--destructive-modeto compare.(Just ran a build in a Jammy LXD container using snapcraft 7.5.5 with
snapcraft --destructive-modeand installed the snap with--dangerous, I get the same error message of2024-10-08T21:39:41Z webthings-gateway.webthings-gateway[4792]: ReferenceError: globalThis is not defined).The build environment shouldn't really impact this, as this is a runtime problem; indeed, this problem should have always existed, as snapcraft will always fetch the node version you specify (as part of the npm plugin).
Indeed it is!
Does this mean that you are building with
--destructive-mode?The real reason the failure happens is if you build, don't clean, and attempt a rebuild; the file already exists in the target location, and for some reason snapcraft is rerunning the build step for that part again. But
cpwill refuse to overwrite the same file, and returns withexit 1; because of that nonzero exit code, snapcraft considers a step to have failed and stops the build.In this specific instance, overwriting is safe. Generally speaking, overwriting is usually the behavior you would want (for instance, many
Makefiles will usecp -f,rm -f,ln -f, etc.).