[Backport release-25.05] teleport_17: 17.5.3 -> 17.5.4; teleport_16: 16.5.11 -> 16.5.13#423289
Conversation
Changelog: https://github.com/gravitational/teleport/releases/tag/v17.5.4 Diff: gravitational/teleport@v17.5.3...v17.5.4 (cherry picked from commit 1916a8a)
Changelog: https://github.com/gravitational/teleport/releases/tag/v16.5.13 Diff: gravitational/teleport@v16.5.11...v16.5.13 (cherry picked from commit da3853e)
|
| version = "16.5.13"; | ||
| hash = "sha256-X9Ujgvp+2dFCoku0tjGW4W05X8QrnExFE+H1kMhf91A="; | ||
| vendorHash = "sha256-0+7xbIONnZs7dPpfpHPmep+k4XxQE8TS/eKz4F5a3V0="; | ||
| pnpmHash = "sha256-waBzmNs20wbuoBDObVFnJjEYs3NJ/bzQksVz7ltMD7M="; |
There was a problem hiding this comment.
| pnpmHash = "sha256-waBzmNs20wbuoBDObVFnJjEYs3NJ/bzQksVz7ltMD7M="; | |
| pnpmHash = "sha256-IISTLreZSBrF1VDmXSDK6EFpn0o9sOxQDgDmwFNocRA="; |
There was a problem hiding this comment.
Thanks. Was gone without laptop, so didn't have the capabilities to check.
But: Why?
There was a problem hiding this comment.
@techknowlogick, you own a aarch64-darwin machine. Could you please double-check?
There was a problem hiding this comment.
I suggest, this is similar to #407982 (comment) (and following links).
So a review on real hardware (not GHA runner) is really appreciated.
There was a problem hiding this comment.
See my nixpkgs-review run. Does that mean pnpm.fetchDeps is not reproducible?
There was a problem hiding this comment.
Ping @gepird and @Scrumplex who fixed some pnpm.fetchDeps reproducibility issue earlier this year.
Edit: Ah, found #422975 now, which could hopefully fix it?
There was a problem hiding this comment.
#422975 fixes the permission mismatch when using pnpm.fetchDeps on different environments. If this is the cause, you'll be able to fix it by opting into a newer version:
# file: pkgs/by-name/te/teleport/package.nix
pnpmDeps = pnpm_10.fetchDeps {
inherit src pname version;
hash = pnpmHash;
fetcherVersion = 2;
};I'm getting the sha256-waBzmNs20wbuoBDObVFnJjEYs3NJ/bzQksVz7ltMD7M= hash, it would be helpful if you could share your pnpm deps with the sha256-IISTLreZSBrF1VDmXSDK6EFpn0o9sOxQDgDmwFNocRA= hash :)
There was a problem hiding this comment.
It seems the only time the other hash appeared is in the GHA run in #423289 (comment) - so I think nobody has access to the actual result with the other hash.
Although I wonder whether the fact that this seems to be the only case where the sandbox was fully enabled (sandbox = true) plays a role? I assume all other tests were with a relaxed sandbox.
There was a problem hiding this comment.
Is it possible for either of you to run it with fully enabled sandbox? I sadly don't have access to a Mac, so I cannot help here.
|
|
|
Since there is no reason to assume that this hash is consistent on the release branch right now and the inconsistencies only introduced here, I think we should merge this with the current hash. That's no worse than what we already have, I think. The "other" hash was only observed in a GHA run, so far. Everybody else had the hash that is currently in the code. Once this hits hydra (and assuming that hydra will be able to build it), this hash will then substitute the same FOD for everyone. Thus, we should not block this PR on the instability of the fetcher. Any objection to merging, anyone? |
JuliusFreudenberger
left a comment
There was a problem hiding this comment.
Let's do the merge.
needs to be solved elsewhere
Bot-based backport to
release-25.05, triggered by a label in #422238.