User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/112.0 Build Identifier: Since webkitgtk 2.41.2 landed in Rawhide, yelp (the GNOME help viewer) never shows any content. When run from a console, these errors are shown: libEGL warning: egl: failed to create dri2 screen KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied Failed to create GBM buffer of size 1280x721: Permission denied KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied Failed to create GBM buffer of size 1280x721: Permission denied Failed to create EGL images for DMABufs with file descriptors -1 and -1 The problem can be worked around by running `WEBKIT_DISABLE_DMABUF_RENDERER=1 yelp` - in that case, no messages are shown, and the help content is visible. Reproducible: Always Steps to Reproduce: 1. Ensure you have webkit2gtk4.1-2.41.2-1.fc39 and yelp installed. 2. Run yelp. Actual Results: You get a blank window. Expected Results: You should get a window with some help content. This is very similar to upstream https://bugs.webkit.org/show_bug.cgi?id=254807 , but that report claims it only affects multiple GPU cases; for me, the problem reproduces in a libvirt VM with virtio graphics, no multiple GPUs required.
Proposing as an F39 Final blocker as a violation of https://fedoraproject.org/wiki/Fedora_38_Final_Release_Criteria#Installer_help - "Any element in the installer interface(s) which is clearly intended to display 'help' text must do so correctly when activated."
We're hoping https://koji.fedoraproject.org/koji/buildinfo?buildID=2188308 will fix this when it's finally done.
OK, fix confirmed. The aarch64 build seems to be stuck for some reason, though. Checking with CPE on that.
That's expected. We have extremely limited build capacity for aarch64 and it can take a day or two to get scheduled if there are Chromium jobs in progress. Just got to be patient. Other architectures are in good shape.
Lately we actually are supposed to have much more capacity for aarch64, we put more powerful builders online. These days my aarch64 jobs usually finish first out of all arches.
Per nirik the problem is the invention of a "heavybuilder" channel for big packages: there are two "heavybuilder" boxes for aarch64, and six builds in the queue (five chromium builds, and this webkitgtk build). Fun.
Yes, problem is we kept hitting OOM errors last year when using wimpy builders. I'd much rather wait for the build to be scheduled and see it complete reliably than go back to the OOM lottery. The status quo is slow but at least it's stable.
This finished a couple days back, fix is all good.