This issue is being filed for blocker tracking purposes. For description of upstream issue see https://gitlab.gnome.org/GNOME/snapshot/-/issues/132 Problem is fixed in Snapshot 46.rc, but F40 has Snapshot 45.2 Reproducible: Always
Proposed as a Blocker for 40-final by Fedora user catanzaro using the blocker tracking app because: This violates the default application functionality criterion.
Indeed the live display shows only a pink image when webcam is enabled, but snapshots and recording works as expected and I can browse the files and see them successfully.
This needs a new gstreamer. The sink has been ported away from GskGLShader, which is not supported by the new default GTK renderer.
Discussed during the 2024-03-18 blocker review meeting: [1] The decision to classify this bug as a AcceptedBlocker (Final) was made: "It is a violation of the requirement for Workstation that all preinstalled apps must "start successfully and withstand a basic functionality test" - https://fedoraproject.org/wiki/Fedora_40_Final_Release_Criteria#Default_application_functionality." [1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-03-18/f40-blocker-review.2024-03-18-16.01.log.html
So the *resolution* to this is confusing me a bit. mcatanzaro said "problem is fixed in Snapshot 46.rc", but mclasen said "This needs a new gstreamer", and on the upstream issue, Robert Mader said "This should only happen if you use the new/upcoming gtk version but not the lastest release of the gtk4paintablesink / gst-plugins-rs." so...which is it, exactly? :D What do we need to do to fix this?
I'll reassign this to David King who's taking care of updating GNOME packages this cycle.
gst-plugin-gtk4 is indeed not at the latest and greatest version yet: https://bugzilla.redhat.com/show_bug.cgi?id=2263422 Though I'm a bit confused here. The latest version of gst-plugin-gtk4 would require updating the Rust GTK / GStreamer bindings to the latest version, but snapshot itself isn't even using the latest and greatest version of the Rust bindings for GTK / GStreamer.
I don't know the answer to this.
This is a Final blocker, so we need somebody to figure it out...
CC Kalev and Fabio for the gstreamer-rust bits. There seems to be a confusing forest of packages there, all of which seem to be outdated (they seem to be 0.21.2 where the current upstreams are 0.22.x).
Ah, yeah, so trying to build snapshot 46.0 fails with a whole bunch of missing buildrequires, which seem the same on F40 and Rawhide: DEBUG util.py:461: Problem 1: nothing provides requested (crate(ashpd/default) >= 0.8.0 with crate(ashpd/default) < 0.9.0~) DEBUG util.py:461: Problem 2: nothing provides requested (crate(ashpd/gtk4) >= 0.8.0 with crate(ashpd/gtk4) < 0.9.0~) DEBUG util.py:461: Problem 3: nothing provides requested (crate(ashpd/tracing) >= 0.8.0 with crate(ashpd/tracing) < 0.9.0~) DEBUG util.py:461: Problem 4: nothing provides requested (crate(gst-plugin-gtk4) >= 0.12.0 with crate(gst-plugin-gtk4) < 0.13.0~) DEBUG util.py:461: Problem 5: nothing provides requested (crate(gst-plugin-gtk4/gtk_v4_14) >= 0.12.0 with crate(gst-plugin-gtk4/gtk_v4_14) < 0.13.0~) DEBUG util.py:461: Problem 6: nothing provides requested (crate(gst-plugin-gtk4/wayland) >= 0.12.0 with crate(gst-plugin-gtk4/wayland) < 0.13.0~) DEBUG util.py:461: Problem 7: nothing provides requested (crate(gst-plugin-gtk4/x11egl) >= 0.12.0 with crate(gst-plugin-gtk4/x11egl) < 0.13.0~) DEBUG util.py:461: Problem 8: nothing provides requested (crate(gst-plugin-gtk4/x11glx) >= 0.12.0 with crate(gst-plugin-gtk4/x11glx) < 0.13.0~) DEBUG util.py:461: Problem 9: nothing provides requested (crate(gstreamer-pbutils/default) >= 0.22.0 with crate(gstreamer-pbutils/default) < 0.23.0~) DEBUG util.py:461: Problem 10: nothing provides requested (crate(gstreamer-video/default) >= 0.22.0 with crate(gstreamer-video/default) < 0.23.0~) DEBUG util.py:461: Problem 11: nothing provides requested (crate(gstreamer/default) >= 0.22.0 with crate(gstreamer/default) < 0.23.0~) DEBUG util.py:461: Problem 12: nothing provides requested (crate(gstreamer/v1_20) >= 0.22.0 with crate(gstreamer/v1_20) < 0.23.0~) DEBUG util.py:461: Problem 13: nothing provides requested (crate(gtk4/default) >= 0.8.0 with crate(gtk4/default) < 0.9.0~) DEBUG util.py:461: Problem 14: nothing provides requested (crate(gtk4/gnome_45) >= 0.8.0 with crate(gtk4/gnome_45) < 0.9.0~) DEBUG util.py:461: Problem 15: nothing provides requested (crate(libadwaita/default) >= 0.6.0 with crate(libadwaita/default) < 0.7.0~) DEBUG util.py:461: Problem 16: nothing provides requested (crate(libadwaita/v1_4) >= 0.6.0 with crate(libadwaita/v1_4) < 0.7.0~) Do we have time to get all of those (and any chained deps) bumped for F40 Final?
Ah. This information was missing for me. I wasn't able to update the GStreamer bindings because snapshot currently still depends on the old version. Nobody told me that snapshot 46.0 final bumped the dependency. I can try to prioritize updating the Rust GStreamer / GLib / GTK4 bindings. It's a lot of work (something like 40 packages + creating compat packages for the current version for some of them), so it would have been great if I knew this earlier ...
Ah, sorry, I only just linked up all the dots also.
Previously I've tried to aggressively help bring the Rust GStreamer / GLib / GTK4 bindings up to date around the time of Fedora beta releases in order to make it possible to update GNOME packages (they always require the latest bindings), but this cycle it's been David handling GNOME builds instead of me so I haven't looked at this at all. David, have you already started looking at updating the GNOME rust bindings by any chance? One way to get things updated is to add compat packages for all the rust bindings that get updated, which avoids having to update the apps in lock step. This is quite a bit of extra work, but in some cases can make things easier by decoupling the bindings and app updates. Adding compat packages also allows updating the bindings in older Fedora releases (while keeping e.g. snapshot at 45.x in F39) which can be a plus, but note that this is in the order of 100 compat packages when updating all of gstreamer/glib/gtk stacks, so quite a bit of work. Another option might be to bundle the bindings and all the other rust deps in the apps, similarly to how it's done for RHEL builds.
Proposal to get things un-stuck: 1) snapshot 46.0 (and loupe 46.0?) are temporarily built with vendored dependencies. This should allow for easier triaging of the bug in question here. 2) I work on getting the GStreamer / GTK4 / GLib bindings for Rust updated ASAP. Can happen in parallel to 1). 3) snapshot and loupe disable building with vendored dependencies again as soon as 2) is done.
Thanks, Fabio! Sounds like a good plan to me, but let's see what David thinks.
FWIW, I've already started working through preparing the gtk-rs stack update, so it should be ready within the next few days regardless.
Both snapshot built with vendored dependencies *and* the updated gtk-rs stack should be ready ... But I upgraded to Fedora 40, and I can't seem to be able to get snapshot to work at all, so I can't test this. Either snapshot segfaults due to a stack overflow, or it doesn't find my camera. Launching the "snapshot" executable from a terminal works better (it at least *looks* like it's searching for camera hardware) than launching it from the shell (just immediately gives up) ... Maybe the race condition between the portal asking for camera permission (which is denied for applications that don't have windows) and the window appearing is back?
Thanks a lot for working on that. I will see if I get any better luck trying to use it here.
FEDORA-2024-a18f8e83b4 (snapshot-46.1-1.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-a18f8e83b4
https://bodhi.fedoraproject.org/updates/FEDORA-2024-a18f8e83b4/edit should fix this, but it still does not work great for me. Out of three tries, snapshot crashed twice and claimed there was no camera once. The crash backtrace seems to be *huge* and indicate that maybe there's an infinite recursion bug? It's over 4000 frames - I ctrl-c'ed my gdb when it got past frame 4096 because I didn't think it would ever stop. I'll file a new bug and attach the trace I got so far as it went.
Filed https://bugzilla.redhat.com/show_bug.cgi?id=2273497 .
(In reply to Fedora Update System from comment #20) > FEDORA-2024-a18f8e83b4 (snapshot-46.1-1.fc40) has been submitted as an > update to Fedora 40. > https://bodhi.fedoraproject.org/updates/FEDORA-2024-a18f8e83b4 With this update the bug is fixed on my testing setup. I can take snapshots and the preview works fine. using the integrated webcan from my notebook.
I can also verify it's fixed for me. Let's consider this particular bug resolved, and we can talk about the crashes in bug 2273497.
FEDORA-2024-a18f8e83b4 (snapshot-46.1-1.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days