Description of problem: Opening Totem, it crashes Version-Release number of selected component: totem-1:3.38.0-5.fc34 Additional info: reporter: libreport-2.14.0 backtrace_rating: 4 cgroup: 0::/user.slice/user-1000.slice/user/app.slice/dbus-:1.2-org.gnome.Totem cmdline: /usr/bin/totem --gapplication-service crash_function: luaD_throw executable: /usr/bin/totem journald_cursor: s=993bf6b5f2be4f19a6197d5cf137ee26;i=59618;b=aa1af54d170240dab36db4dbcbdfdb5c;m=4f6a2f0b;t=5c15673a36e84;x=1e484160af1440c0 kernel: 5.11.17-300.fc34.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000
Created attachment 1778568 [details] File: backtrace
Created attachment 1778569 [details] File: core_backtrace
Created attachment 1778570 [details] File: cpuinfo
Created attachment 1778571 [details] File: dso_list
Created attachment 1778572 [details] File: environ
Created attachment 1778573 [details] File: limits
Created attachment 1778574 [details] File: maps
Created attachment 1778575 [details] File: mountinfo
Created attachment 1778576 [details] File: open_fds
Created attachment 1778577 [details] File: proc_pid_status
Created attachment 1778578 [details] File: var_log_messages
Similar problem has been detected: Start totem only (from terminal or Nautilus) reporter: libreport-2.14.0 backtrace_rating: 4 cgroup: 0::/user.slice/user-1000.slice/user/app.slice/dbus-:1.2-org.gnome.Totem cmdline: /usr/bin/totem --gapplication-service crash_function: luaD_throw executable: /usr/bin/totem journald_cursor: s=b7d839f8004c402c91c2b2a2341e737d;i=29e1;b=bb09b46d16e54b2b9e6bfe2c2e73aca6;m=776c8bb72;t=5c131f324e466;x=a4f6771c58e84980 kernel: 5.11.16-300.fc34.x86_64 package: totem-1:3.38.0-5.fc34 reason: totem killed by SIGABRT rootdir: / runlevel: N 5 type: CCpp uid: 1000
Similar problem has been detected: Totem just stop working, cannot see any video, only alternative video players work (vlc, mpv, firefox/chrome, any other than totem in right-click open-with menu in nautilus) reporter: libreport-2.14.0 backtrace_rating: 4 cgroup: 0::/user.slice/user-1000.slice/user/app.slice/dbus-:1.2-org.gnome.Totem cmdline: /usr/bin/totem --gapplication-service crash_function: luaD_throw executable: /usr/bin/totem journald_cursor: s=1117a15bb29b4e7c8d2c0b01a97ef1e9;i=739c9a;b=7bd3db3caad74030addc518c1feec8eb;m=4591deda7;t=5c11dab3e87fc;x=7f49c596803ade82 kernel: 5.11.17-300.fc34.x86_64 package: totem-1:3.38.0-5.fc34 reason: totem killed by SIGABRT rootdir: / runlevel: N 5 type: CCpp uid: 1000
I think we may be seeing this in Rawhide. Are affected folks using updates-testing? Do you have lua-5.4.3-1.fc34 installed?
Yeah, it looks to me like the lua update caused it. If I downgrade lua to 5.4.2-2.fc34, totem runs fine. I've yanked the lua update from F34 for now. Spot, can you look into it? Thanks.
It's a bug in grilo-plugins: https://gitlab.gnome.org/GNOME/grilo-plugins/-/merge_requests/108
*** Bug 1955951 has been marked as a duplicate of this bug. ***
*** Bug 1955991 has been marked as a duplicate of this bug. ***
I'll backport the fix mentioned in comment #16
(In reply to Victor Toso from comment #19) > I'll backport the fix mentioned in comment #16 Build is on the making by Bastien https://src.fedoraproject.org/rpms/grilo-plugins/c/bc37337cc406b7f69ff37688c53ba9611467aefc?branch=rawhide
FEDORA-2021-277d4f7496 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-277d4f7496
The same lua update that triggered this bug is in testing for f33, please build this fix for F33 too.
Thanks, but in future please don't submit a separate update :/ It would have been much more convenient to just add the grilo-plugins build to the lua update. That way they would be "internally consistent" and could be pushed together. Now, to avoid breaking totem in stable, we have to manually remember we cannot push the lua update until the grilo-plugins update is pushed. Permissions can be an issue, but there are plenty of provenpackagers who can help to edit updates if necessary (e.g. me). I'll see if we can fix this up somehow. At worst I can just do a bump-n-rebuild of grilo-plugins.
FEDORA-2021-52f259786a has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-52f259786a
I built the fix for F33 and edited it into the F33 update. For F34 I did a no-change bump-n-rebuild of grilo-plugins and edited it into the lua update; the other grilo-plugins update is now obsoleted.
FEDORA-2021-52f259786a has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-52f259786a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-52f259786a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Adam Williamson from comment #23) > Thanks, but in future please don't submit a separate update :/ It would have > been much more convenient to just add the grilo-plugins build to the lua > update. That way they would be "internally consistent" and could be pushed > together. > > Now, to avoid breaking totem in stable, we have to manually remember we > cannot push the lua update until the grilo-plugins update is pushed. > > Permissions can be an issue, but there are plenty of provenpackagers who can > help to edit updates if necessary (e.g. me). > > I'll see if we can fix this up somehow. At worst I can just do a > bump-n-rebuild of grilo-plugins. It's a bug in grilo-plugins, which I fixed. It just so happens that the new lua version shows the bug more prominently, but it's a bug whether or not lua gets updated. Is there a bug filed about the need to dance around the update tool to group builds like you did, doing new builds when they're clearly unneeded?
"It's a bug in grilo-plugins, which I fixed. It just so happens that the new lua version shows the bug more prominently, but it's a bug whether or not lua gets updated." Sure, but the worst scenario is the lua update getting pushed stable before the grilo-plugins update, which would cause Totem to crash on startup for everyone who installed the update. As long as they're separate updates that is possible (and likely, since the lua update was submitted first and probably people don't know that grilo-plugins is an important package, or what it does, and so they're unlikely to karma it). If they're bundled together it is impossible. "Is there a bug filed about the need to dance around the update tool to group builds like you did, doing new builds when they're clearly unneeded?" It's been a known limitation approximately forever, I don't remember offhand if a bug is filed but lots of people definitely know about it. It's somewhat hard to fix, I think, because the problem is we don't really want to allow updates to be deleted entirely, which is the easiest way to "fix" this. If an update was created we want it to remain in existence at some level. What would probably be needed is a new permanent state for updates called 'archived' or something, where their existence is recorded but they are not pushed to any repository and cannot be pushed to any repository (and the status cannot be changed short of someone going and editing the database). And then Bodhi would need to allow builds from updates in that state to be added to other updates.
FEDORA-2021-52f259786a has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.