Exact pin of `GR_jll`

[t-bltg]

trafficstars

This is too critical to be left floating (unfortunately, we cannot pin the build number: GR_jll = "=0.69.1+0" is not allowed by Pkg). A new release of GR_jll should trigger a new version of GR.jl, on after being tested through CI.

Sorry if that seems too strict, but the recent breaking changes should never have landed in common users space, and worse, landed in Plots.

Xref https://github.com/jheinen/GR.jl/issues/486, https://github.com/jheinen/GR.jl/issues/487.

As @mkitti pointed out, there is a kind of sporadic race condition in volume plots (windows ci) causing a segfault:

Please submit a bug report with steps to reproduce this fault, and any error messages that follow (in their entirety). Thanks.
Exception: EXCEPTION_ACCESS_VIOLATION at 0x28fcbed8 -- ray_casting_thread at C:\Users\runneradmin\.julia\artifacts\e40afe22fcfc9fe1caea4af17a4016e7ef36cd66\bin\libGR.dll (unknown line)
in expression starting at none:1
ERROR: LoadError: Package GR errored during testing (exit code: 3221225477)
Stacktrace:

[codecov-commenter]

Codecov Report

Base: 43.25% // Head: 43.28% // Increases project coverage by +0.03% :tada:

Coverage data is based on head (7f5a68c) compared to base (8b18b19). Patch has no changes to coverable lines.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #488      +/-   ##
==========================================
+ Coverage   43.25%   43.28%   +0.03%     
==========================================
  Files           8        8              
  Lines        2890     2890              
==========================================
+ Hits         1250     1251       +1     
+ Misses       1640     1639       -1     

Impacted Files	Coverage Δ
src/preferences.jl	86.27% <0.00%> (+0.98%)	:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

[jheinen]

For our installation this is sub-optimal - I had put the new GR_jll build on all platforms today so we can use system-wide GR distributions (/usr/local/gr).

What are the problems with Plots.jl (again)?

[t-bltg]

The problem was windows + vscode (again), after https://github.com/JuliaPackaging/Yggdrasil/pull/5784. I had thus to yank latest GR_jll in https://github.com/JuliaRegistries/General/pull/71554, before it got out of hand. It is not acceptable to break everyone's workflow like this (Plots is widely used by beginners): we should be able to release a new GR_jll, without it going immediately in the wild. We must first test a new GR_jll build in GR.jl, then test Plots.jl ci through a PR, and only thereafter, if everything is green, bump versions and update [compat] bounds.

https://discourse.julialang.org/t/vs-code-1-7-1-2-and-plots-jl-not-working/87960/13 https://discourse.julialang.org/t/plots-package-not-working-in-pluto-using-windows-11/89709/4 https://discourse.julialang.org/t/plots-jl-gr-jl-broken-due-to-gr-jll-v0-69-1-1/89708 https://github.com/jheinen/GR.jl/issues/486 https://github.com/jheinen/GR.jl/issues/487

[jheinen]

The problem was windows + vscode (again), after [JuliaPackaging/Yggdrasil#5784]

I don't understand, why all SVG tests on Windows are successful, but creating SVGs in VSCode would fail!?

[t-bltg]

The new GR_jll not only svg caused failures, but also png ones (cairo) on windows.

This should be fixed by https://github.com/jheinen/GR.jl/commit/ea529f5534d6cdffa4ffbbc1615b6263cd1f22a8 (see https://github.com/jheinen/GR.jl/issues/486), but until this is released in GR.jl 0.70.0, GR_jll breaks the whole Plots ecosystem (broken ci run this morning: https://github.com/JuliaPlots/Plots.jl/actions/runs/3384673137/jobs/5621906622#step:9:759), because it doesn't run on GR#master but [email protected].

This is why I suggest pinning GR_jll to avoid these problems in the future.

[jheinen]

Will hopefully tag a new GR version tomorrow which will offer debug capabilities (GR_DEBUG, GKS_DEBUG and GRM_DEBUG environment variables). Once the new run-time is built, I'd like to tag a new GR.jl version (0.70.0).

We have a suspicion that there is a memory leak in the volume code which may be related to the Windows segfault mentioned above.

[mkitti]

I'm not sure if this exact pin will be sufficient. We may also need to retroactively pin prior versions of GR.jl to have an upper bound on the version of GR_jll.jl.

[t-bltg]

Ideally, I would also pin the build number +X, but it's not possible :/

[mkitti]

I'm proposing a retroactive pinning of GR to the corresponding GR_jll of the same minor version here:

https://github.com/JuliaRegistries/General/pull/71976