<torhex-pasmul[m]>
Interesting. After doctoring mongod and node, the standard build sucessfully starts.
<torhex-pasmul[m]>
The custom build exhibits the can't-read-from-urandom behavior, the standard one does not
<isd>
Does the standard build not work normally for you? I'm running it on nixos myself.
<isd>
normally == without doctoring
<torhex-pasmul[m]>
Interesting. No mongodb and node didn't start without patchelf
<isd>
(it shouldn't really care about anything but the kernel; the sandstorm executable is statically linked, and the bundle should be entirely self-contained).
<torhex-pasmul[m]>
ok. I'm going to blow away /opt/sandstorm and see what i get when I reinstall, just to be sure I'm not fooling myself
<torhex-pasmul[m]>
OK, no, when run from the official release tarball it does fine.
<torhex-pasmul[m]>
For some reason whatever I built has problems.
<torhex-pasmul[m]>
welp, I guess that's enough to discourage me from further progress for a while, since I really can't guess where this build process let the gremlins in (and there seems to be more than one)
<isd>
Yeah, I think this will be something of a slog; hopefully eventually we'll work it out. Thank you for the progress you've made.
<isd>
I might poke at it in the next couple days to see if I can figure it out; I haven't delved into it much myself.
<torhex-pasmul[m]>
It was educational!
<isd>
Ok, yeah the hash mismatch I was getting - I get a different hash each time I run it.
<Corbin>
I can answer Nix questions, but it looks like this isn't really a situation where Nix knowledge would help.
<isd>
I mean, if you want to pull torhex-pasmul ⚡️'s branch and see if you find anything...
<torhex-pasmul[m]>
Right. Meteor is generating a random value to put in package names as far as I can see.
<Corbin>
I already read through the PR. It looks alright. I don't have space to build something like this right now, but I don't think that that would add anything.
<torhex-pasmul[m]>
I asked on meteor slack about reproducible builds but nobody there seemed aware of the concept.
<isd>
Want to do a brain dump on the issue of what you've figured out before calling it quits? At least documenting how you worked out the random value thing will probably help whoever takes a whack at it next.
<torhex-pasmul[m]>
I did 'nix-build -K' on the shell-meteor-deps derivation twice then compared the resulting trees. The packages had different names.
<isd>
What does -K do? (it doesn't seem to be documented in the man page...)
<isd>
(The "clean" solution to this might be talking the meteor developers into not doing that. But we'd have to wait until we deal with the mongo migration issue for that to help, since we can't actually update to the latest meteor right now anyway)
<Corbin>
(It sounds like maybe Meteor should be patched for reproducibility. This doesn't require upstream Meteor consent, just more Nix and maybe some sed.)
<torhex-pasmul[m]>
it's `--keep-failed` and yes nix spreads its build options across too many documents
<isd>
ah.
<isd>
I don't suppose you figured out why they're doing that?
<torhex-pasmul[m]>
For instance, one has `sandstorm-shell-src/meteor-home/.meteor/packages/mongo/.1.12.0.11ofdgq.15ji++os+web.browser+web.browser.legacy+web.cordova` and the other has `sandstorm-shell-src/meteor-home/.meteor/packages/mongo/.1.12.0.e1ofwu.7yyg9++os+web.browser+web.browser.legacy+web.cordova`
<torhex-pasmul[m]>
I haven't dug into how it chooses filenames.
<isd>
Fair enough.
digitalcircuit has quit [Quit: Signing off from Quassel - see ya!]
<Corbin>
Looks like sed time. I'd look for "randomToken" and replace that entire line with "isopack.buildArchitectures();" but I am lazy and maybe overly optimistic.
<torhex-pasmul[m]>
It's Sunday, good day to be lazy and optimistic.
<ocdtrekkie>
Alright, Ian, I admit I am probably definitely abusing the CI now.