Comments
nucleo
provided feedback
on clang-17.0.1-1.fc39, …
2 years ago
Make xdg-desktop-portal-kde as weak dependency https://bugzilla.redhat.com/show_bug.cgi?id=2240339
Please, make xdg-desktop-portal-kde as weak dependency
Built with llvm 16.0.6 but llvm-17.0.0~rc3-1.fc39 has been pushed to stable FEDORA-2023-de5276064a
Yes, chromium works after deleting GPUCache
I see many files left /var/tmp/rpm-tmp.XXXX. Is dnf5 leaves files tehre?
Bug https://github.com/yt-dlp/yt-dlp/issues/7367 fixed in yt-dlp 2023.06.22
Bug 2156906 reported for F37. Will be update also for F37?
libdfn5 installs /etc/dnf/dnf.conf but not owns /etc/dnf/
/var/cache/libdnf5 is not owned by any package but unused /var/cache/libdnf is owned by libdnf5
/var/lib/libdnf5 is not owned by any package but unused /var/lib/libdnf is owned by libdnf5
https://bugs.chromium.org/p/chromium/issues/detail?id=1442633#c14
It seems these are cases where Chromium can't invalidate cached shader blobs
because the GL_RENDERER string doesn't change across package updates even
though the update is clearly a breaking change. In #c0 GL_RENDERER is
"ANGLE (AMD, AMD Radeon Graphics (renoir LLVM 15.0.7 DRM 3.49 6.1.27-1-lts),
OpenGL 4.6 (Core Profile) Mesa 23.0.3)" - LLVM version is tagged as 15.0.7 so
I presume that's the same across 15.0.7-2 and 15.0.7-3 - there's no way for
Chromium to distinguish between the two.
So what I'd like to confirm is whether this hypothesis is true or not - please
attach chrome://gpu output from before and after the update to verify this.
If that is indeed the case, please file bugs downstream with the distro to either
1) not making breaking changes in minor point releases - easier said than done, or
2) somehow include the full version number in GL_RENDERER string - someone
more familiar with mesa would know how this is done. Another alternative is to
let us know if there's a more reliable string to use as the prefix for our shader
cache in GpuHostImpl::GetShaderPrefixKey here[1] - note that this only a prefix -
the other part of the key contains a SHA of GL specific state/limits we think
can affect a cached shader [2].
Errors:
link failed but did not provide an info log
[8932:8932:0526/131217.530754:ERROR:shared_context_state.cc(77)] Skia shader compilation error
------------------------
// Vertex SKSL
#extension GL_NV_shader_noperspective_interpolation: require
uniform float4 sk_RTAdjust;in float2 position;in half4 color;noperspective out half4 vcolor_S0;void main() {// Primitive Processor QuadPerEdgeAAGeometryProcessor
vcolor_S0 = color;sk_Position = position.xy01;}
// Fragment SKSL
#extension GL_NV_shader_noperspective_interpolation: require
noperspective in half4 vcolor_S0;void main() {// Stage 0, QuadPerEdgeAAGeometryProcessor
half4 outputColor_S0;outputColor_S0 = vcolor_S0;const half4 outputCoverage_S0 = half4(1);{ // Xfer Processor: Porter Duff
sk_FragColor = outputColor_S0 * outputCoverage_S0;}}
// Vertex GLSL
#version 300 es
#extension GL_NV_shader_noperspective_interpolation : require
precision mediump float;
precision mediump sampler2D;
uniform highp vec4 sk_RTAdjust;
in highp vec2 position;
in mediump vec4 color;
noperspective out mediump vec4 vcolor_S0;
void main() {
vcolor_S0 = color;
gl_Position = vec4(position, 0.0, 1.0);
gl_Position = vec4(gl_Position.xy * sk_RTAdjust.xz + gl_Position.ww * sk_RTAdjust.yw, 0.0, gl_Position.w);
}
// Fragment GLSL
#version 300 es
#extension GL_NV_shader_noperspective_interpolation : require
precision mediump float;
precision mediump sampler2D;
out mediump vec4 sk_FragColor;
noperspective in mediump vec4 vcolor_S0;
void main() {
mediump vec4 outputColor_S0;
outputColor_S0 = vcolor_S0;
{
sk_FragColor = outputColor_S0;
}
}
Chromium displays empty pages after this update. Works fine after downgrade to mesa 23.0.3-1.fc37
Bug 2184142 fixed
Bug 2184142 fixed
Problem was with systemd-251.13-3.fc37 with obsoletes systemd-udev < 251.13^
After update "bootctl update": Failed to open "/usr/lib/systemd/boot/efi": No such file or directory. Need to install systemd-boot-unsigned manually.