GNOME issueshttps://gitlab.gnome.org/groups/GNOME/-/issues2023-11-13T09:39:55Zhttps://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2722Date and time: the label of the switch to show week numbers is unclear2023-11-13T09:39:55ZLukas RuzickaDate and time: the label of the switch to show week numbers is unclear### Affected version
gnome-shell-45.0-1.fc39.x86_64
### Bug summary
When trying to switch on showing the week numbers in the date and time field in the middle of the screen, the switch is responding, i.e. you can switch it, but nothin...### Affected version
gnome-shell-45.0-1.fc39.x86_64
### Bug summary
When trying to switch on showing the week numbers in the date and time field in the middle of the screen, the switch is responding, i.e. you can switch it, but nothing happens and no week numbers are shown in the Date and Time field. Other options work correctly.
### Steps to reproduce
Open **Settings**, go to **Date and Time** and try to switch on the week numbers.
### What happened
Nothing happens.
### What did you expect to happen
The week number should have been shown in that field.
### Relevant logs, screenshots, screencasts etc.
[Screencast_from_2023-10-30_13-00-34](/uploads/53b21eedc49eecd1cb3a24d60ce877b3/Screencast_from_2023-10-30_13-00-34.webm)https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1117Explicitly mention account name in the sources labels/tooltips in Quick Add p...2024-03-14T14:39:00ZÉloi RivardExplicitly mention account name in the sources labels/tooltips in Quick Add popover, ics Import dialog, and "Manage Calendars" dialogNextcloud creates a calendar named "Personal" by default for each account. Users with several nextcloud accounts have good chances to have several calendars with the same "Personal" name.
As of gnome-calendar 45, the quick add popover d...Nextcloud creates a calendar named "Personal" by default for each account. Users with several nextcloud accounts have good chances to have several calendars with the same "Personal" name.
As of gnome-calendar 45, the quick add popover displays the calendar name without referring the target account. This ambiguity in the calendar name make users have to click on the calendar menu to check if the selected calendar is indeed the intended one.
Without consideration for the current refactoring of this popover, I think a simple solution would be to display the account name in pale grey near the calendar name. Tooltips would be OK but probably not super useful on mobile devices.
Related to #90 and !362https://gitlab.gnome.org/GNOME/nautilus/-/issues/3142Recents: opening parent folder from File Properties window doesn't work2024-01-09T23:30:52ZAutomeris naranjaRecents: opening parent folder from File Properties window doesn't work<!--
Please test if the issue has already been fixed in the Nightly version.
You can install the Nightly version in parallel with the regular version with these instructions:
1. Make sure that Flatpak is installed (see http...<!--
Please test if the issue has already been fixed in the Nightly version.
You can install the Nightly version in parallel with the regular version with these instructions:
1. Make sure that Flatpak is installed (see https://flatpak.org/setup )
2. Copy and run the following command in a Terminal:
flatpak install --from https://nightly.gnome.org/repo/appstream/org.gnome.NautilusDevel.flatpakref
3) The Nightly version can now be launched from Activities, or with this command: flatpak run org.gnome.NautilusDevel
-->
# Affected versions
- Nightly flatpak: 46.alpha.0-8add7b891
- Other: nautilus-45.0-1.fc39.x86_64
# Steps to reproduce
<!--
Explain in detail the steps on how the issue can be reproduced.
-->
1. Go to Recents
2. Right click on a file > Properties
3. Press the folder icon from the Parent Folder row
# Current behavior
<!-- Describe the current behavior. -->
The file gets selected in the Recents view.
# Expected behavior
<!-- Describe the expected behavior. -->
Nautilus opening the actual file location.
# Additional information
<!--
Provide more information that could be relevant.
If the issue is a crash, provide a stack trace following the steps in:
https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces
-->
<!-- Ignore the text under this line. -->https://gitlab.gnome.org/GNOME/gtk/-/issues/6177RFE: Make text buffer of gtk4-demo-application default focus2023-11-26T14:18:28ZTakao FujiwaraRFE: Make text buffer of gtk4-demo-application default focus<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
## Steps to reproduce
<!--
Please, explain the sequence of actions necessary to reproduce t...<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/CONTRIBUTING.md
-->
## Steps to reproduce
<!--
Please, explain the sequence of actions necessary to reproduce the
bug
-->
1. Run `gtk4-demo-application` from gnome-terminal
2. Type some characters
Another case:
1. Run `gtk4-demo-application`
2. Press Alt-a keys and open "Application" menu and press Arrow keys and focus on the "Open" menu item and Press Enter key
3. The Open dialog is launched
4. Press some Escape keys and close the dialogs and focus on the gtk4-demo-application again
5. Type some characters
<!--
You should try and reproduce with the demos applications available
under the `demos` directory, or the test programs in the `tests` directory.
Alternatively, please attach a *small and self-contained* example
*written in C* that exhibits the issue.
-->
## Current behavior
The typed characters are ignored by gtk4-demo-application.
<!--
Please describe the current behaviour
-->
## Expected outcome
The text buffer is the default input focus and typed characters are inserted to the text buffer.
<!--
Please describe the expected outcome
-->
## Version information
GTK 4.12.3
<!--
- Which version of GTK you are using
- What operating system and version
- For Linux, which distribution
- If you built GTK yourself, the list of options used to configure the build
-->
## Additional information
I tried to insert `<property name="receives_default">False</property>` in the menu.ui file but could not change the behavior.
<!--
- Screenshots or screen recordings are useful for visual errors
- Attaching a screenshot or a video without explaining the current
behavior and the actions necessary to reproduce the bug will lead
to the bug being closed
- Please report any warning or message printed on the terminal
-->https://gitlab.gnome.org/GNOME/gitg/-/issues/428Confirmation dialog for deleting a branch should use the "Destructive action"...2023-12-12T03:48:39ZJeff FortinConfirmation dialog for deleting a branch should use the "Destructive action" button styling instead of "Suggested action"When you want to delete a branch, you get this blue button in the confirmation dialog:
![image](/uploads/d424c1644d6443000401208eddeb72f5/image.png)
...but presumably it should be the "destructive" action [HIG button style](https://dev...When you want to delete a branch, you get this blue button in the confirmation dialog:
![image](/uploads/d424c1644d6443000401208eddeb72f5/image.png)
...but presumably it should be the "destructive" action [HIG button style](https://developer.gnome.org/hig/patterns/controls/buttons.html#button-styles) instead?
Bonus points: that dialog's text could be improved to not have everything duplicated/redundant between title and contents. Maybe the title should be "Confirm branch deletion" and leave the branch name to the description, and use some quotation marks and markup (ex: `<i>"%s"</i>`) for the branch name?
---
Tested with the 45.alpha version from flathub.GNOME 46TiagoTiagohttps://gitlab.gnome.org/GNOME/gnome-builder/-/issues/2121Running app is missing icons2024-01-04T17:59:53ZJulianRunning app is missing iconsWhen using an icon theme other than Adwaita (such as [MoreWaita](https://github.com/somepaulo/MoreWaita)), and running an app (such as [Flare](https://gitlab.com/schmiddi-on-mobile/flare)) through GNOME Builder, you will notice some icon...When using an icon theme other than Adwaita (such as [MoreWaita](https://github.com/somepaulo/MoreWaita)), and running an app (such as [Flare](https://gitlab.com/schmiddi-on-mobile/flare)) through GNOME Builder, you will notice some icons are missing.
Screenshot:
![Bildschirmfoto_vom_2023-10-17_19-08-08](/uploads/0a9a9268b792e59ea74c9cacd94ce34a/Bildschirmfoto_vom_2023-10-17_19-08-08.png)Backloghttps://gitlab.gnome.org/GNOME/nautilus/-/issues/3137Close tab icon position should respect position settings2023-12-08T12:15:07ZPavel ChmykhClose tab icon position should respect position settings# Affected version
- Nightly flatpak: Can't test it
- Other: archlinux with nautilus 45, fedora with nautilus 45.0
# Steps to reproduce
1. Open gnome-tweaks app
2. Choose left position of titlebar buttons
3. It does not affect close tab...# Affected version
- Nightly flatpak: Can't test it
- Other: archlinux with nautilus 45, fedora with nautilus 45.0
# Steps to reproduce
1. Open gnome-tweaks app
2. Choose left position of titlebar buttons
3. It does not affect close tab buttons of Nautilus.
# Current behavior
When titlebar buttons placement chosen to be on the left with gnome-tweaks app, it doesn't affect tabs of the Nautilus. Also It doesn't affect gnome-terminal, but looks like gnome-terminal is dependent of Nautilus behavior.
# Expected behavior
Left titlebar buttons placement should affect Nautilus close tab button, as close tab buttons of gnome-web affected, details in attached screenshot.
# Additional information
Please check screenshot with red underlined buttons and examples in attachment.
<!--
Provide more information that could be relevant.
If the issue is a crash, provide a stack trace following the steps in:
https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces
-->![Pasted_image](/uploads/8a0ee3f6bdfdbdcef1a4bbae43c77842/Pasted_image.png)
<!-- Ignore the text under this line. -->https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1114Provide easily copy-pastable bug reporting information in the About dialog, w...2024-02-20T06:29:42ZJeff FortinProvide easily copy-pastable bug reporting information in the About dialog, with version numbers of libraries it most depends onTo make it easier for casual testers to make better bug reports in GNOME Calendar or elsewhere (ex: when we find a bug in GTK), GNOME Calendar's about dialog should provide its version numbers for the most critical libraries it depends o...To make it easier for casual testers to make better bug reports in GNOME Calendar or elsewhere (ex: when we find a bug in GTK), GNOME Calendar's about dialog should provide its version numbers for the most critical libraries it depends on:
* GTK
* LibAdwaita
* Evolution Data Server
* GNOME Online Accounts
* libsoup
And whether the user is running on GNOME or not, on Wayland or not, etc.
There are of course various other libraries mentioned in the [dependencies](https://gitlab.gnome.org/GNOME/gnome-calendar/-/blob/main/meson.build), but compared to the ones mentioned above, they usually don't cause much trouble.
[Tuba](https://tuba.geopjr.dev/) is an example of an application that provides a nice convenient UI for this in its About dialog:
![image](/uploads/6f1daee996b6a41f5761cd9078272b84/image.png) ![image](/uploads/e01268ebabfb7ec24d670bf90e008640/image.png)GNOME 46Felipe KinoshitaFelipe Kinoshitahttps://gitlab.gnome.org/GNOME/gnome-weather/-/issues/355Default window geometry (width and height) not used on first startup2023-12-28T17:37:40ZJeff FortinDefault window geometry (width and height) not used on first startupAs part of #298 with !126, we made it so that the default window size, particularly its height, is bigger by default so that the visualizations can be seen. That part worked on its own when I tested it.
In commit 5a2dfa428b, @cleomeneze...As part of #298 with !126, we made it so that the default window size, particularly its height, is bigger by default so that the visualizations can be seen. That part worked on its own when I tested it.
In commit 5a2dfa428b, @cleomenezesjr made it so that the app would also remember the user's preferred window width and height, which is great! Except that there must be some bug in that code (presumably), because version 45.0 as shipped in Fedora 39 now ignores the default values I had set, when there are no user-set values... so the window shows up too small by default again.
To reproduce:
1. Reset the `org.gnome.Weather window-height` gsetting (to `-1`)
2. Reset the `org.gnome.Weather window-width` gsetting (to `-1`)
3. Launch GNOME Weather
4. Notice that it shows up too small to show the visualisations, the window shows up "as small as possible" and its height dynamically gets bumped up for minimum height by the widgets themselves, instead of using the (bigger) default window width and heighthttps://gitlab.gnome.org/GNOME/meld/-/issues/803Meld forgets multi-selection when right clicking, making it impossible to cop...2023-10-21T05:15:05Zcedric airMeld forgets multi-selection when right clicking, making it impossible to copy multiple files from left to rightSummary: Meld forgets multi-selection when right clicking, making it impossible to copy multiple files from left to right
Steps to reproduce:
1) Select two folders in the file manager, right-click and choose Meld. Now Meld starts, and ...Summary: Meld forgets multi-selection when right clicking, making it impossible to copy multiple files from left to right
Steps to reproduce:
1) Select two folders in the file manager, right-click and choose Meld. Now Meld starts, and shows two trees of files.
2) Click on one of the files on the right side. Now the file is selected.
3) hold shift, and click on a file 5 files further down. Now the 5 files are selected.
4) Right click on one of the selected files. Now only one of the files is selected, and a menu pops up with the option to copy files from left to right.
5) Choose Copy to right. Now only the selected file is copied.
Wanted behavior:
4\. Right click on one of the selected files. Now the files selected in step 3 stay selected, and a menu pops up with the option to copy files from left to right.
5\. All the selected files are copied from left to right.
Versions: Meld 3.22.0
$ uname -a Linux cedric-work-laptop 6.5.5-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 23 Sep 2023 22:55:13 +0000 x86_64 GNU/Linuxhttps://gitlab.gnome.org/GNOME/mutter/-/issues/3078src/backends/meta-fd-source.c calls close() without there being a prior decla...2023-12-15T18:01:01ZDaniel Kolesasrc/backends/meta-fd-source.c calls close() without there being a prior declaration (via unistd.h)On musl and llvm 16.x, this will result in a hard error about implicit declaration of `close()`. I guess you probably get it accidentally through another include on glibc. I worked around it by including `unistd.h` in `src/backends/meta-...On musl and llvm 16.x, this will result in a hard error about implicit declaration of `close()`. I guess you probably get it accidentally through another include on glibc. I worked around it by including `unistd.h` in `src/backends/meta-fd-source.c` but I'm not sure if that is where you want it.https://gitlab.gnome.org/GNOME/evince/-/issues/1985Documents should not automatically re-enter fullscreen mode on startup2023-11-14T12:10:22ZJeff FortinDocuments should not automatically re-enter fullscreen mode on startupA bit similar in spirit to #674, but for normal fullscreen.
To reproduce, with version 44.3 (and also 45.x, if I recall correctly):
1. Open a PDF document in Evince, fullscreen it (with `F11`)
2. Quit Evince / close the document, with ...A bit similar in spirit to #674, but for normal fullscreen.
To reproduce, with version 44.3 (and also 45.x, if I recall correctly):
1. Open a PDF document in Evince, fullscreen it (with `F11`)
2. Quit Evince / close the document, with `Ctrl+W` or `Alt+F4`
3. From Nautilus, reopen the same document later
Result: the app is fullscreened and it is impossible to manipulate its window, but is not clear that it is fullscreened because:
* the toolbar is shown (as it does not autohide, #1607), and
* there is no "Exit fullscreen" button (#1137) nor visual distinction from regular maximized state, except that the GNOME Shell panel does not show (but it has often been the case that, due to a Mutter bug, the panel shows underneath the applications, so it's not sufficient as a visual indicator)
I spent a couple of minutes wondering why I could not tile/unmaximize/move the window, until I realized it was unexpectedly fullscreened.
While the fullscreened toolbar UI could be made different as per the points above, I believe that fullscreen state should not be remembered/set on startup anyway, especially for regular non-slideshow documents that don't request fullscreen as part of their metadata. Overall, it should be an action explicitly triggered by the user, otherwise it can lead to confusing situations like what I experienced today.https://gitlab.gnome.org/GNOME/epiphany/-/issues/2200Enhancement: "Install as Web App" menu needs url override option2024-03-07T13:48:35ZCaden MitchellEnhancement: "Install as Web App" menu needs url override optionWhen a user tries to install a web page as an application, they are greeted with this simple menu:
![Screenshot_from_2023-10-09_04-12-07](/uploads/6b30b02f2db0e18c8778afab2614266a/Screenshot_from_2023-10-09_04-12-07.png)
The problem:
...When a user tries to install a web page as an application, they are greeted with this simple menu:
![Screenshot_from_2023-10-09_04-12-07](/uploads/6b30b02f2db0e18c8778afab2614266a/Screenshot_from_2023-10-09_04-12-07.png)
The problem:
Some web pages will instantly redirect the user, or just contain garbage like ref links or tokens. It isn't always possible to prevent these things from being in the current URL. Therefor, where that text is stating the URL, there should probably be an edit-able text box instead. This would allow me to change the url from `discord.com/channels/@me`, for instance, to `discord.com/app` which was the intended URL. This would go a long way, as there are many more websites that have uncontrollable URL behaviour that a user wouldn't want as the landing page for their webapp.https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2690Incorrect wording for always-show-universal-access-status2023-11-29T16:13:43ZkramoIncorrect wording for always-show-universal-access-statusThe row for toggling `org.gnome.desktop.a11y always-show-universal-access-status` has the following title and description:
"Accessibility Menu"
"Display menu for Accessibility settings in top bar"
This would lead one to believe that ...The row for toggling `org.gnome.desktop.a11y always-show-universal-access-status` has the following title and description:
"Accessibility Menu"
"Display menu for Accessibility settings in top bar"
This would lead one to believe that it is a toggle for enabling/disabling the menu, when that is only true if no accessibility setting is currently active. Otherwise, the menu is shown regardless if the state of the key.
A correct description would be something like, as the name of the key suggests, "Always show menu for Accessibility settings in top bar".https://gitlab.gnome.org/GNOME/glib/-/issues/3134glib incompatible with Python 3.12 due to distutils usage2023-12-06T07:38:32ZHarmen Stoppelsglib incompatible with Python 3.12 due to distutils usageThis line
https://gitlab.gnome.org/GNOME/glib/-/blame/main/gio/gdbus-2.0/codegen/utils.py#L22
```
import distutils.version
```
breaks compatibility with Python 3.12. See https://peps.python.org/pep-0632/#migration-advice
Notice that ...This line
https://gitlab.gnome.org/GNOME/glib/-/blame/main/gio/gdbus-2.0/codegen/utils.py#L22
```
import distutils.version
```
breaks compatibility with Python 3.12. See https://peps.python.org/pep-0632/#migration-advice
Notice that distutils is sometimes shipped with setuptools, but please don't believe popular belief that installing setuptools is sufficient to make `import distutils` work. setuptools has some ugly hacks that magically make `import distutils` work, provided that setuptools is installed as a system site-package. That's not an assumption you can make. So best to drop the dependency on distutils altogether.https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1108Improve the README.md file and other documentation files for marketing and te...2023-10-08T23:02:38ZJeff FortinImprove the README.md file and other documentation files for marketing and testers documentation, to survive the demise of the wikiMany years ago, there was an initial attempt at improving the wiki page's documentation in #194.
Fast forward many years, in 2023 I rewrote / improved / updated most of the pages in https://wiki.gnome.org/Apps/Calendar/
However the GNO...Many years ago, there was an initial attempt at improving the wiki page's documentation in #194.
Fast forward many years, in 2023 I rewrote / improved / updated most of the pages in https://wiki.gnome.org/Apps/Calendar/
However the GNOME Foundation wants to kill the wiki: https://discourse.gnome.org/t/wiki-gnome-org-retirement-feedback-wanted/17314
...so we'll need to migrate stuff to gitlab (unless we make a dedicated website for GNOME Calendar). Note that while markdown is the primary format commonly used in GitLab, we _might_ not be limited only to markdown, I am told we can use HTML too... but if you do, let's please not make a nasty unmaintainable messy blob (if we wanted that, we could use a CMS).
---
Recently there was a spontaneous attempt by a newcomer to tweak the readme file's documentation in !363, but none of us had a particular opinion of what it should look like for starters...
Personally, I suspect maybe migrating some of the contents from the various pages from [the wiki](https://wiki.gnome.org/Apps/Calendar/) to it would already be a decent approach, since we will have to salvage those contents "somehow" when GNOME decides to kill the wiki infrastructure soon...
---
I currently don't have time to be doing copywriting, so anyone who feels inspired to achieve something equal or better than what was on the wiki is welcome to, but you'll probably have to figure out how to best merge the wiki and readme's documentation in a way that makes sense; it's hard for me to be explaining my writing style, because it would take me longer to explain than to write :)
Up for grabs / help wanted.
In addition to the text, visuals need to be updated too:
* Screenshots on the wiki page are outdated
* Screenshots on https://apps.gnome.org/Calendar/ are not "nicely representative of real-world usage examples", either
It might also be nice to explain to testers/early-adopter users how to build/test branches and merge requests to help with GNOME Calendar's development. There are some tips about that in the comments there: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1106#note_1855644https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2354Port to AdwSwitchRow2023-10-09T04:57:10ZAutomeris naranjaPort to AdwSwitchRow[AdwSwitchRow](https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.SwitchRow.html) is a new widget introduced with libadwaita 1.4. It replaces AdwActionRows containing GtkSwitches with a single widget.[AdwSwitchRow](https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.SwitchRow.html) is a new widget introduced with libadwaita 1.4. It replaces AdwActionRows containing GtkSwitches with a single widget.https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2353Provide new scalable default app icon2024-03-20T18:03:23ZSidProvide new scalable default app iconWe don't want to see `image-missing` icon in gnome-software UI.
I think it's not the right default / fallback for an app icon in GS.
We can use a new scalable `default-app-icon`, when an app icon is not available for some reason.
- Re...We don't want to see `image-missing` icon in gnome-software UI.
I think it's not the right default / fallback for an app icon in GS.
We can use a new scalable `default-app-icon`, when an app icon is not available for some reason.
- Refer https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2200
- Refer https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2196
- https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2197
![gs-missing-icon](/uploads/85fe46497a76074c63e9cffb52c3f6ab/gs-missing-icon.png)46.1https://gitlab.gnome.org/GNOME/gnome-usage/-/issues/114Missing search features2024-02-12T01:44:32ZkramoMissing search featuresThere are a couple of UX improvements that should be made to search:
- Escape should close the search bar
- When the search bar is closed either via Esc/Ctrl+F/the button, the search query should be cleared
- [key_capture_widget](https:...There are a couple of UX improvements that should be made to search:
- Escape should close the search bar
- When the search bar is closed either via Esc/Ctrl+F/the button, the search query should be cleared
- [key_capture_widget](https://docs.gtk.org/gtk4/method.SearchEntry.set_key_capture_widget.html) should be setUsage 46Markus GöllnitzMarkus Göllnitzhttps://gitlab.gnome.org/GNOME/glib/-/issues/3124Possible SEGV (null pointer deref) in list_resources_cb()2023-10-02T15:21:49ZGregory DuckPossible SEGV (null pointer deref) in list_resources_cb()There seems to be a possible NULL pointer dereference in [`list_resources_cb()`](https://gitlab.gnome.org/GNOME/glib/-/blob/41c9c51080a8aaf1c24c3d402453725034b8cb77/gio/gresource-tool.c#L279):
```
static gboolean list_resources_cb (...)...There seems to be a possible NULL pointer dereference in [`list_resources_cb()`](https://gitlab.gnome.org/GNOME/glib/-/blob/41c9c51080a8aaf1c24c3d402453725034b8cb77/gio/gresource-tool.c#L279):
```
static gboolean list_resources_cb (...)
{
...
resource = resource_from_section (shdr, d->fd);
list_resource (resource, "/",
d->section ? "" : section,
d->path,
d->details);
...
}
```
The problem is that [`resource_from_section()`](https://gitlab.gnome.org/GNOME/glib/-/blob/41c9c51080a8aaf1c24c3d402453725034b8cb77/gio/gresource-tool.c#L222) (or `g_resource_new_from_data()`) can return NULL on an error condition (e.g., corrupt ELF file). However, `list_resource()` does not expect the resource to be NULL, and will eventually [crash](https://gitlab.gnome.org/GNOME/glib/-/blob/41c9c51080a8aaf1c24c3d402453725034b8cb77/gio/gresource.c#L978).
Example stack trace:
```
Program terminated with signal SIGSEGV, Segmentation fault.
#0 g_resource_enumerate_children (resource=resource@entry=0x0,
path=path@entry=0x55c4d26c5077 "/",
lookup_flags=lookup_flags@entry=G_RESOURCE_LOOKUP_FLAGS_NONE,
error=error@entry=0x7ffcead737e8) at ../../../gio/gresource.c:978
978 children = gvdb_table_list (resource->table, path_with_slash);
#0 g_resource_enumerate_children (resource=resource@entry=0x0, path=path@entry=0x55c4d26c5077 "/", lookup_flags=lookup_flags@entry=G_RESOURCE_LOOKUP_FLAGS_NONE, error=error@entry=0x7ffcead737e8) at ../../../gio/gresource.c:978
#1 0x000055c4d26c3a26 in list_resource (resource=resource@entry=0x0, path=path@entry=0x55c4d26c5077 "/", section=section@entry=0x55c4d3982214 "gnome_calculator", prefix=0x55c4d26c510f "", details=0) at ../../../gio/gresource-tool.c:88
#2 0x000055c4d26c3f7b in list_resources_cb (shdr=<optimized out>, section=<optimized out>, data=0x7ffcead73920)
at ../../../gio/gresource-tool.c:280
#3 0x000055c4d26c3dc2 in elf_foreach_resource_section (elf=elf@entry=0x55c4d397fde0, callback=callback@entry=0x55c4d26c3f10 <list_resources_cb>, data=data@entry=0x7ffcead73920)
at ../../../gio/gresource-tool.c:216
#4 0x000055c4d26c4165 in elf_list_resources (details=0, path=0x55c4d26c510f "", section=0x0, fd=3, elf=0x55c4d397fde0)
at ../../../gio/gresource-tool.c:307
#5 cmd_list (file=<optimized out>, section=0x0, path=<optimized out>, details=0)
at ../../../gio/gresource-tool.c:419
#6 0x000055c4d26c379a in main (argc=<optimized out>, argv=0x7ffcead73ac8)
at ../../../gio/gresource-tool.c:661
```