9.7.0:
macOS:
https://nodejs.org/dist/v9.7.0/node-v9.7.0.pkg
I am receiving the following error when I try to run the macOS installer for Node.js 9.7.0.
The operation couldn鈥檛 be completed. (com.apple.installer.pagecontroller error -1.)
couldn't open node-v9.7.0.pkg
I do as well!
+1
cc @nodejs/platform-macos
+1
Don't +1, that sends email to 100+ people. Use the upvote button.
Sorry
+1
cc/ @rvagg
So I think this is what happened:
scp -p node-v9.7.0.pkg node-www:nodejs/release/v9.7.0/node-v9.7.0.pkg
Killed by signal 15.
lost connection
make: *** [pkg-upload] Error 1
Build was aborted
I'd assume the easiest way to fix is to manually push the right pkg file to the server, @rvagg resigns and promotes it, and it's done.
Alternately we could rerun the build just for that job.
cc/ @nodejs/release , not sure what we should do here
doh!
I think we can justify pushing a fixed .pkg for just this one, the shasum will only change for that file, any objections @nodejs/release?
SGTM, to be clear the pkg from the first build (https://ci-release.nodejs.org/job/iojs+release/3130/nodes=osx1010-release-pkg/) looks good, direct link https://ci-release.nodejs.org/job/iojs+release/3130/nodes=osx1010-release-pkg/artifact/node-v9.7.0.pkg.
yeah, OK, I could manually put that into staging and promote it, will stage it now and wait a little while to see if there are any objections
As an aside, I thought we added download tests to catch this sort of thing?
STGM
The download test validates the non-installer packages https://ci.nodejs.org/view/Node.js%20Daily/job/validate-downloads/
It would be good to validate the installers too, but that would be more complex as it would require jobs to run each of the target platforms.
I'm ok with it. Lmk when this is ready to go and I'll promote and sign the new .pkg
Oh wait 9.7.0 that was released by @addaleax, they would likely need to promote / sign
@MylesBorins no, @addaleax prepared it, I released it, I also did the screw-up with the second build which I started because it looked like one of the Windows builders had stalled, but I cancelled the second build when the Windows builder righted itself.
Was it released with the bad .PKG? Does the signed Sha match the corrupted pkg?
If not do we have the original .PKG anywhere that we could republish?
I'm almost inclined to say we should published 9.7.1 rather than edit the sha
Was it released with the bad .PKG? Does the signed Sha match the corrupted pkg?
Yes
If not do we have the original .PKG anywhere that we could republish?
Yes, it's here: https://ci-release.nodejs.org/job/iojs+release/3130/nodes=osx1010-release-pkg/artifact/node-v9.7.0.pkg.
c11d128c923c09d2cf63789f4d03d3347345c934901301604fce95fee80fc6ab node-v9.7.0-ci-release.pkg
5247a2467c4722bd8697ede7e4aa2b26be3b77a92c51243451252753f61a6482 node-v9.7.0-dist.pkg
AFAICT https://ci.nodejs.org/view/Node.js%20Daily/job/validate-downloads/ does look at the installer packages, but all it does is validate that it matches the SHA (so in this case does not catch the problem as the published SHA was for the corrupted pkg).
I'm almost inclined to say we should published 9.7.1 rather than edit the sha
Come to think of it, I have a vague recollection that we tried to update the sha once in the past and it caused problems resulting in a new patch release.
Edit: It was v6.9.3/v6.9.4 https://github.com/nodejs/node/pull/10640
We accidentally published over assets in the past and didn't have backups. So we opted to do a new release rather than replace Shas.
ok, I'll push a new release now then
released, if you have this problem with 9.7.1 then .. well ... (I did check the .pkg prior to publishing btw!)
Thank you very much @rvagg for this quick fix!
Most helpful comment
ok, I'll push a new release now then