grafana: 8.0.5 -> 8.0.6 #130201
grafana: 8.0.5 -> 8.0.6 #130201
Conversation
ofborg
bot
requested review from
WilliButz,
globin,
Frostman,
fpletz,
Ma27,
kalbasit and
offlinehacker
ofborg
bot
added
10.rebuild-darwin: 0
|
Result of 1 package failed to build:1 suggestion:
Note that build failures may predate this PR, and could be nondeterministic or hardware dependent. Result of 1 package failed to build:1 suggestion:
Note that build failures may predate this PR, and could be nondeterministic or hardware dependent. |
|
How does this work when the tag was "last changed" two hours ago: https://github.com/grafana/grafana/releases/tag/v8.0.6 ? |
|
It cannot. The tag 8.0.6 was published yesterday and it seems it has been moved today 😐 |
|
Please update to the tag which was release a few hours ago then. |
LeSuisse
force-pushed
the
grafana-8.0.6
branch
2 times, most recently
from
3693c18 to
e1637da
Compare
|
Hum there is something strange happening here.
If I attempt to get the archive from another endpoint I get another archive with the SHA-256 I suspect something wrong happened with the release and there are some caches at play. I will try again in a few hours. For reference I have a diffoscope HTML report of the two archives I have retrieved can be found here: https://gist.github.com/LeSuisse/4d0f7e4a0866b42499276ed1ae2f5c20 |
|
Yeah I tried to reach out to them on Twitter without luck so far. I'm trying the contact form right now. |
|
Just to keep this ticket updated: at this time I have not heard back from Grafana Labs. I have created a thread in their community forum so hopefully someone will notice it https://community.grafana.com/t/grafana-oss-8-0-6-tarball-checksum-does-not-always-match/50785 |
|
I heard back from Grafana Labs, the issue should now be fixed.
I tested from different endpoints, I now get the expected tarball. |
Up until now, the frontend was taken from `srcStatic`, i.e. prebuilt from upstream. I recall at least three cases[1][2][3] where we got a hash mismatch eventually. Rather than spending time finding out whether or not it's a supply-chain attack or just a build issue, I decided to implement a source-build now with the following benefits: * It's now actually possible to apply patches for Grafana's frontend. * We rely a little less on third-party build systems. Of course, patching potential vulnerabilities in transitive frontend dependencies is still hard (let alone discovering that this package is affected!), but that's a fundamental issue we have in nixpkgs and I won't invent a half-baked solution just for this package, I still consider this a step into the right direction. The build itself mainly orients on the `yarn` commands used in the upstream Makefile[4]. However, we can't use `fetchYarnDeps` here because yarn v2 (a.k.a. `berry`) is in use which is why the same was done as in `hedgedoc`, writing a custom FoD that downloads all dependencies and writes the offline cache into `$out`[5]. Additionally there are two more notable differences to upstream: * We patch out every dependency to `@grafana/e2e` and `cypress`. The first is a dependency on the latter in another version and the latter downloads random blobs from the Internet in postInstall. Since it's a testing framework (and the `e2e` package apparently a testing library), I decided it's not worth the effort and patched it out everywhere. * There was a `zoneinfo.zip` in `$out/share/grafana/tools` that was installed from `srcStatic`. This only seems to be used on Windows[6] and that's not supported by this package, so I decided to drop it. [1] NixOS#251479 [2] NixOS#130201 [3] NixOS#104794 [4] https://github.com/grafana/grafana/blob/v10.3.1/Makefile [5] NixOS#245170 [6] https://github.com/grafana/grafana/blob/v10.3.1/pkg/setting/setting.go#L1012-L1014
Up until now, the frontend was taken from `srcStatic`, i.e. prebuilt from upstream. I recall at least three cases[1][2][3] where we got a hash mismatch eventually. Rather than spending time finding out whether or not it's a supply-chain attack or just a build issue, I decided to implement a source-build now with the following benefits: * It's now actually possible to apply patches for Grafana's frontend. * We rely a little less on third-party build systems. Of course, patching potential vulnerabilities in transitive frontend dependencies is still hard (let alone discovering that this package is affected!), but that's a fundamental issue we have in nixpkgs and I won't invent a half-baked solution just for this package, I still consider this a step into the right direction. The build itself mainly orients on the `yarn` commands used in the upstream Makefile[4]. However, we can't use `fetchYarnDeps` here because yarn v2 (a.k.a. `berry`) is in use which is why the same was done as in `hedgedoc`, writing a custom FoD that downloads all dependencies and writes the offline cache into `$out`[5]. Additionally there are two more notable differences to upstream: * We patch out every dependency to `@grafana/e2e` and `cypress`. The first is a dependency on the latter in another version and the latter downloads random blobs from the Internet in postInstall. Since it's a testing framework (and the `e2e` package apparently a testing library), I decided it's not worth the effort and patched it out everywhere. * There was a `zoneinfo.zip` in `$out/share/grafana/tools` that was installed from `srcStatic`. This only seems to be used on Windows[6] and that's not supported by this package, so I decided to drop it. [1] NixOS#251479 [2] NixOS#130201 [3] NixOS#104794 [4] https://github.com/grafana/grafana/blob/v10.3.1/Makefile [5] NixOS#245170 [6] https://github.com/grafana/grafana/blob/v10.3.1/pkg/setting/setting.go#L1012-L1014 (cherry picked from commit 608db26)
Motivation for this change
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)Result of
nixpkgs-reviewrun on x86_64-linux 11 package built: