GNOME issueshttps://gitlab.gnome.org/groups/GNOME/-/issues2022-09-29T14:30:53Zhttps://gitlab.gnome.org/GNOME/gimp/-/issues/8673Gradient on selection bug2022-09-29T14:30:53ZMagali de MorangiesGradient on selection bug### Environment/Versions
- GIMP version: 2.10.32
- Package: Installer from gimp.org downloaded on GIMP.org
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Windows 10 Pro
### Description of the bu...### Environment/Versions
- GIMP version: 2.10.32
- Package: Installer from gimp.org downloaded on GIMP.org
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Windows 10 Pro
### Description of the bug
I work a lot with GIMP both on Linux and Windows OS, and find few bugs on the version 2.10.32 (I did not upgrade to "2.10.32 revision 1" version yet) that I installed on my gaming computer running Win 10 Pro.
Both bugs concern the gradient tool (or occur when I use the gradient tool). First bug, when I want to fill a selected area on a layer or an image, sometimes (once every 4 ~ 5 times), the whole layer/image is filled, the gradient bypassing the limit of the selection like if there was no selection. I could take a screenshot of this, as it occurs regularly, not all the time but very often anyway.
Second bug, that occurs every time the situation is the following: I could normally fill a selected area with the gradient tool, without the bug one to happen, and I wish to un-select this area, but there, if the gradient tool is still highlighted when I click on "None" in the "Selection" menu, the gradient fills all the area when the selection is removed, and I can't step back, the history strangely shows, sometimes only my work on the gradient but no selection on and off anymore, other times only the selection on and off but no gradient steps anymore. I used a Windows tool to record these steps, and could extract shots from it.
### Reproduction
Is the bug reproducible?
- The 1st bug (gradient bypassing the selection) is happening 1 / 5 times, not ALL the time but very often though.
- The 2nd bug (un-select causing gradient extension to whole layer) happens always when the gradient tool is highlighted, but if I select another tool before un-selecting (even if I don't use this other tool) it doesn't happen.
Reproduction steps:
1st bug (gradient bypassing the selection) reproduction steps:
1. select an area on the layer/image.
2. pick the gradient tool.
3. click with the tool inside the selection and drag the tool out of selection, the gradient follows the cursor and bypass the selected area. if I release the tool (inside or outside the area) the whole layer/image is filled with the gradient. I made a screenshot if needed and can send it to anyone asking.
2nd bug (un-select causing gradient extension to whole layer)
1. select area in a layer/image.
2. pick gradient tool, click inside selected area and release outside the area. only the selected area is filled with gradient.
3. edit the first point of the gradient.
4. edit the second point of the gradient.
5. edit a middle point and push it toward the second point for effect I want to give, with "sinus" curve selection of this middle point.
6. click on the "Selection" menu of the menu bar, click on "None" in this menu, to un-select the full filled area (with gradient tool still highlighted, very important! as doesn't occur when another tool is highlighted).
7. immediately, the whole layer/image is filled with gradient as the selection is disabled).
Expected result:
1. I am quite sure the gradient tool is supposed to fill the selected area, and not to bypass the selection.
2. It is supposed to be activated when picked with a direct click or a shortcut, and not to auto-activate and fill the entire layer just because the selection is removed after use of the same gradient tool.
Actual result:
1. Once on 5 times, the gradient tool acts like if the selection was not existing.
2. When it fills the selection normally, to un-select when the gradient tool is still highlighted always causes the whole layer/image to be instantly filled by the gradient.
### Additional information
I made several screenshots of my steps and used the windows "record tool" to obtain the shots of the steps I couldn't get by the screenshot tool. I can send them on demand to anyone who ask me.https://gitlab.gnome.org/GNOME/vala/-/issues/1362Possibility of type inference of functions or methods2022-09-29T11:27:25ZZhou Qiankang (周 乾康)wszqkzqk@qq.comPossibility of type inference of functions or methodsIt's allowed to use keyword `auto` to declare functions in C++, but vala now cannot use `var` to do type inference for functions or methods. It may be possible to add this feature because vala's lambda functions can be used without type ...It's allowed to use keyword `auto` to declare functions in C++, but vala now cannot use `var` to do type inference for functions or methods. It may be possible to add this feature because vala's lambda functions can be used without type declaration.https://gitlab.gnome.org/GNOME/genius/-/issues/12xmlto validity errors when years used in translator-credits2022-09-29T11:37:55ZAnders Jonssonxmlto validity errors when years used in translator-creditsI ran into some problems running `update-xml-to-txt-html.sh` after having updated the Swedish help translation:
```
Running xmlto -o sv/html/ html sv/genius.xml
xmlto: /home/anders/git/genius/help/sv/genius.xml does not validate (status ...I ran into some problems running `update-xml-to-txt-html.sh` after having updated the Swedish help translation:
```
Running xmlto -o sv/html/ html sv/genius.xml
xmlto: /home/anders/git/genius/help/sv/genius.xml does not validate (status 3)
xmlto: Fix document syntax or use --skip-validation option
/home/anders/git/genius/help/sv/genius.xml:127: element othercredit: validity error : Element othercredit content does not follow the DTD, expecting (honorific | firstname | surname | lineage | othername | affiliation | authorblurb | contrib)+, got (personname email )
/home/anders/git/genius/help/sv/genius.xml:127: element othercredit: validity error : No declaration for attribute class of element othercredit
/home/anders/git/genius/help/sv/genius.xml:128: element personname: validity error : No declaration for element personname
Document /home/anders/git/genius/help/sv/genius.xml does not validate
```
More testing show that the line `itstool -m messages.mo -o sv/ C/genius.xml` changed the `help/sv/genius.xml` file to have xml not following the DTD.
Marking the string `translator-credits` as fuzzy works around the problem. Some more testing with the translation for that string show that the string `Anders Jonsson <anders.jonsson@norsjovallen.se>, 2016, 2021, 2022` now causes validity error, while just using `Anders Jonsson <anders.jonsson@norsjovallen.se>` is OK.
Workaround: don't use years in the translator string, and change the translator comment to reflect that. It is now:
```
Put one translator per line, in the form
NAME <EMAIL>, YEAR1, YEAR2
```
, but the years should now be removed.
Not sure where a real fix should be done, that string seems unstable if it's that easy to break the syntax.https://gitlab.gnome.org/GNOME/gvfs/-/issues/648GVFS MTP uploaded images are not indexed by Android gallery2022-11-09T08:59:07ZAlexandr TeliatnikovGVFS MTP uploaded images are not indexed by Android galleryIf image file are written to Android device via **fuse mount point**, they are **not indexed** correctly. They are **not visible** in **Gallery** and other apps, however file managers can see them. Then can also be selected directly, but...If image file are written to Android device via **fuse mount point**, they are **not indexed** correctly. They are **not visible** in **Gallery** and other apps, however file managers can see them. Then can also be selected directly, but not with Gallery.
Some tricks with _manual indexing/Rescan tools_ help.
If image files are sent to Android phone via **GUI (Nautilus)**, they immediately appear in **Gallery** and **are visible** for all apps.
The problem is caused by **mtpfile->filetype = LIBMTP_FILETYPE_UNKNOWN** in _gvfs/daemon/gvfsbackendmtp.c, do_create()_
It prevents android indexer from handling new files correctly.
Correct indexing happens when sending via GUI (Nautilus) which use **do_push()** with explicitly specified **mtpfile->filetype** derived from **mime type** of source file.
Other tools those upload files correctly and examples in **libmtp** set **mtpfile->filetype** according to **filename/extension**.
It would be great to implement such mechanism in GVFS MTP
adb logs:
```
09-29 14:44:41.838 19668 25267 D MtpServer: path: /storage/emulated/0/Download/DSCN1429.JPG parent: 17 storageID: 00010001
09-29 14:44:41.864 19668 25267 D skia : --- Failed to create image decoder with message 'unimplemented'
vs
09-29 14:49:25.575 19668 25267 D MtpServer: path: /storage/emulated/0/Download/DSCN1429.JPG parent: 17 storageID: 00010001
09-29 14:49:25.688 19668 25267 W ExifInterface: Skip the tag entry since tag number is not defined: 34864
09-29 14:49:25.688 19668 25267 W ExifInterface: Skip the tag entry since tag number is not defined: 2
09-29 14:49:25.688 19668 25267 W ExifInterface: Stop reading file since a wrong offset may cause an infinite loop: 0
09-29 14:49:25.689 19668 25267 I chatty : uid=10031(com.android.providers.media) MtpServer identical 2 lines
09-29 14:49:25.689 19668 25267 W ExifInterface: Stop reading file since a wrong offset may cause an infinite loop: 0
```https://gitlab.gnome.org/GNOME/rhythmbox/-/issues/2011Rhythmbox hangs at the end of playing some WMA files2022-09-29T12:30:11ZColin PitratRhythmbox hangs at the end of playing some WMA filesI have a folder full of WMA files on which Rhythmbox hangs after playing them.
When running with -d, I have the following output:
```
(13:23:10) <rhythmbox> [rb_shell_player_error] ../shell/rb-shell-player.c:2440: playback error while ...I have a folder full of WMA files on which Rhythmbox hangs after playing them.
When running with -d, I have the following output:
```
(13:23:10) <rhythmbox> [rb_shell_player_error] ../shell/rb-shell-player.c:2440: playback error while playing: Could not decode stream.
(13:23:10) <rhythmbox> [error_cb] ../shell/rb-shell-player.c:2544: exiting error hander
(13:23:10) <rhythmbox> [start_state_change] ../backends/gstreamer/rb-player-gst.c:398: changing state to NULL
```
Attaching an example file:
[09_Track_9_-_Typewriter__L._Anderson_.wma](/uploads/3407588a81d24992478736876481f0a0/09_Track_9_-_Typewriter__L._Anderson_.wma)
These are the only WMA files that I have, so not sure if this happens on all WMA files or if these have a defect.
But in any case, I don't expect the application to hang if it hits an issue with a file, just ignore it and continue.https://gitlab.gnome.org/GNOME/gnome-photos/-/issues/204Favorited photos from albums are shown as favorited only after app restart or...2023-03-10T11:50:26ZKamil PáralFavorited photos from albums are shown as favorited only after app restart or second attemptWhen I open an album, open a photo from that album, and favorite a photo using the star button, the photo is not marked as favorite (it doesn't have a star icon) when I go back to the album view. Also, in the Favorites tab, it is not vis...When I open an album, open a photo from that album, and favorite a photo using the star button, the photo is not marked as favorite (it doesn't have a star icon) when I go back to the album view. Also, in the Favorites tab, it is not visible. When I open the photo again, the photo is not marked as favorite at all.
The workarounds are:
a) close and reopen gnome-photos
-or-
b) mark the photo as favorite once again
In both cases, the photo is then correctly marked as favorite.
Please note, this bug doesn't occur when you open the photo from the Photos view. It only occurs when you open the photo from a existing Album.
Reproducer:
1. Open some album in Albums
2. Open some photo
3. Click the Star button
4. Click the Back button
5. See that the photo is NOT marked with a star
6. Go to Favorite tab
7. See that the photo is not there
8. a) Restart gnome-photos, see that the photo IS now marked as favorite
-or-
b) Repeat steps 1-6 for a second time, see that now the photo IS marked as favorite
Screencast:
![photos_bug](/uploads/97180f0eae11dee90238aac9e005b2e5/photos_bug.webm)
Versions:
```
Fedora 37 (pre-release)
gnome-photos-43.0-1.fc37.x86_64
tracker-3.4.0-1.fc37.x86_64
```https://gitlab.gnome.org/GNOME/gnome-photos/-/issues/205Memory exhaustion when editing a cropped photo2023-03-07T08:59:29ZKamil PáralMemory exhaustion when editing a cropped photoWhen **Shadows** or **Highlights** sliders are changed on a cropped photo, gnome-photos goes into an infinite cycle, consuming 100% cpu and all available memory. Once the memory is exhausted, it is then killed by an OOM killer. The afore...When **Shadows** or **Highlights** sliders are changed on a cropped photo, gnome-photos goes into an infinite cycle, consuming 100% cpu and all available memory. Once the memory is exhausted, it is then killed by an OOM killer. The aforementioned sliders work fine on uncropped photos, only cropped photos seem to be the problem.
Reproducer:
1. Open a photo
2. Edit the photo
3. Crop the photo, Save
4. Edit the photo again (either right now or after the app restart, doesn't matter)
5. Under **Colors**, change either **Shadows** or **Highlights**
6. gnome-photos goes unresponsive and exhaust all memory
Screencast:
![photos_memleak](/uploads/3d6e64e4ac2e7f8924c093d4d6736eea/photos_memleak.webm)
Versions:
```
Fedora 37 (pre-release)
gnome-photos-43.0-1.fc37.x86_64
tracker-3.4.0-1.fc37.x86_64
gegl04-0.4.38-1.fc37.x86_64
```https://gitlab.gnome.org/GNOME/mutter/-/issues/2447USB-C monitors connected to laptop sometimes become unresponsive if desktop i...2022-09-30T03:16:41ZJoshua StoneUSB-C monitors connected to laptop sometimes become unresponsive if desktop is locked and monitors are turned off<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
```
$ distro
Name: Fedora Linux 36.20220929.0 (Silverblue)
V...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
```
$ distro
Name: Fedora Linux 36.20220929.0 (Silverblue)
Version: 36
Codename:
$ rpm -q gnome-shell mutter
gnome-shell-42.5-1.fc36.x86_64
mutter-42.5-1.fc36.x86_64
$ echo $XDG_SESSION_TYPE
wayland
```
### Bug summary
I have a docking station setup comprising of two monitors (one is connected to the other with a Displayport cable and is in a portrait orientation), wireless keyboard, wireless mouse, webcam, and a USB DAC. My laptop connects to this with a single USB-C cable, and that cable connects to one of the monitors. I also have `~/.config/monitors.xml` set to disable the laptop screen when both of these monitors are connected.
My previous laptop was an X1 Carbon Gen6 running RHEL 8 with the Gnome Xorg session, and it worked reliably with this docking station. My new laptop (X1 Carbon Gen9) uses Fedora Silverblue 36 with the Gnome Wayland session, and so far it's been a smooth transition, with the one regression being that the Wayland session will sometimes be unresponsive in waking the the monitors back up after the screen locks even by using the external keyboard or moving the mouse. The workaround I've been doing is disconnecting and reconnecting the USB-C cable.
I'm not sure if this unresponsiveness originates from Mutter, or if there's an aggressive power saving feature being used by Fedora or in the laptop firmware.
### Steps to reproduce
1. Install Fedora Linux
2. Log into Gnome on Wayland session
3. Connect laptop to multi-monitor setup through USB-C cable
4. Wait for desktop session to lock the screen and turn the monitors off
### What happened
Monitors and peripherals have a chance of becoming unresponsive and won't do anything until the USB-C cable is disconnected and reconnected.
### What did you expect to happen
Monitors to power back on and show the lockscreen.
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-boxes/-/issues/856"Create virtual machine from file" silently fails on remote ISO2022-11-10T09:52:49ZBastien Nocera"Create virtual machine from file" silently fails on remote ISOSelecting an ISO on a remote Samba share fails silently. There are no errors in the UI.
```
Sep 29 17:04:39 classic gnome-boxes[468352]: index-page.vala:181: Failed to create installer media for path '/run/user/1000/gvfs/smb-share:server...Selecting an ISO on a remote Samba share fails silently. There are no errors in the UI.
```
Sep 29 17:04:39 classic gnome-boxes[468352]: index-page.vala:181: Failed to create installer media for path '/run/user/1000/gvfs/smb-share:server=diskstation.local,share=bastien/ISOs/Fedora-Workstation-Live-x86_64-36-1.5.iso': Medium is not supported
```
`gnome-boxes-43.0-1.fc37.x86_64`
I'm certain this used to work, as this is where I' used to store I've stored my install images for a long while. Let me know if you want me to test the Flathub version instead.https://gitlab.gnome.org/GNOME/gnome-boxes/-/issues/857Express installation of RHEL 9.2 stops at language selection screen2022-10-06T13:46:56ZBastien NoceraExpress installation of RHEL 9.2 stops at language selection screenUsing `gnome-boxes-43.0-1.fc37.x86_64` and `RHEL-9.2.0-20220927.0-x86_64-dvd1.iso`, the Express installation stops at the language selection screen.
(It's possible that https://gitlab.gnome.org/GNOME/gnome-boxes/-/issues/779 or https://...Using `gnome-boxes-43.0-1.fc37.x86_64` and `RHEL-9.2.0-20220927.0-x86_64-dvd1.iso`, the Express installation stops at the language selection screen.
(It's possible that https://gitlab.gnome.org/GNOME/gnome-boxes/-/issues/779 or https://gitlab.gnome.org/GNOME/gnome-boxes/-/issues/810 is the cause of it stopping not long after though).https://gitlab.gnome.org/GNOME/gimp/-/issues/8675Improve light/dark theme support with OS preferences lookup2024-01-25T17:58:17ZJehanImprove light/dark theme support with OS preferences lookupFollowup of #8509, but moved to GIMP 3.2 milestone, because it's not a priority right now and our dark theme support works quite OK so far.
Basically Freedesktop now has an API for light/dark style preferences:
* [Page on GNOME wiki](h...Followup of #8509, but moved to GIMP 3.2 milestone, because it's not a priority right now and our dark theme support works quite OK so far.
Basically Freedesktop now has an API for light/dark style preferences:
* [Page on GNOME wiki](https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/Dark-Style-Preference). Since we don't plan to use libadwaita or libhandy so far, the section of interest is the [other section](https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/Dark-Style-Preference#other) which has some useful C code sample to get inspired from.
* [Some blog post](https://blogs.gnome.org/alexm/2021/10/04/dark-style-preference/)
* [Some other blog post](https://blog.elementary.io/the-need-for-a-freedesktop-dark-style-preference/)
We should study a bit the rationale. I say this in particular as what is particularly interesting is that this is a 3-state settings: prefer-light, prefer-dark and default (I also wonder if there were cases where someone might set their OS to dark, but might want exceptionally GIMP to be light? Right now, this is not possible, but with such setting, it would). Yet in the second blog post, they say:
> Similarly, when communicating this preference to users, it likely shouldn’t be a choice between “light” and “dark.” Instead, it should be phrased as “prefer dark style” or similar.
Which kinda contradicts the 3-state logic. So we should look further on it.
Also there is the discussion about whether GIMP should follow the system settings as a default, or stay dark by default. Typically in the GNOME wiki link, their second case is:
> Apps that didn't have a preference but used dark appearance by default (e.g. **Photos** or **Videos**) should be dark unless the system prefers light appearance, such as for the high contrast mode. […]
Lastly, we should look how to set the theme to "prefer light". It's not clear to me how it's done with GTK+3 themes (the sample explains how to get the FD setting, not how to apply it to GTK themes). We have a trick to prefer the dark theme, not one to prefer the light themes (unlike for instance libadwaita where they apparently have a `ADW_COLOR_SCHEME_FORCE_LIGHT`).
Some TODOs:
* [ ] Study the Freedesktop settings rationale.
* [ ] Check how to force/prefer light theme with GTK+3 themes.
* [ ] Decide what should be GIMP default behavior regarding theme.
* [ ] Check how similar settings are handled in other OSes, and implement if possible at least a similar logic with macOS and Windows API (apparently they both have similar OS settings, though it might not be a 3-state, maybe it's just `prefer-dark` vs default for these).3.2https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5925Screen never sleeps after notification2023-04-22T17:05:15ZWill ShanksScreen never sleeps after notification<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
<!--
Provide at least the following information:
* Your OS an...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
<!--
Provide at least the following information:
* Your OS and version
* Affected GNOME Shell version (see https://wiki.gnome.org/Schedule for currently supported versions)
* Does this issue appear in XOrg and/or Wayland
-->
* OS: Fedora 36
* GNOME Shell version: 42.5-1
* Wayland
### Bug summary
<!--
Provide a short summary of the bug you encountered.
-->
### Steps to reproduce
1. In Privacy->Screen Lock, select a Blank Screen Delay other than "Never", disable Automatic Screen Lock and enable Show Notifications on Lock Screen
2. Wait for the screen to go blank
3. Trigger a notification (e.g. send an email to yourself if your email program generates notifications).
### What happened
Once the notification triggers the screen to wake up from being blanked, it never is blanked again until the system receives some input (a mouse movement or key press).
### What did you expect to happen
I expected the screen to blank again shortly after showing the notification, at least after the Blank Screen Delay but probably even sooner if there is no input to the system.
### Relevant logs, screenshots, screencasts etc.
I have been seeing this behavior since at least Fedora 34 (I remember hoping that the upgrades to 35 and 36 would fix it). It seems similar to what is described in #2475 and [the post here](https://askubuntu.com/questions/1416670/how-can-i-stop-notifications-from-keeping-my-monitor-awake). Perhaps it requires some uncommon configuration since more people have not complained about it.
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/mutter/-/issues/2449Emit event on full screen mode2022-11-01T16:49:26ZJenny TCEmit event on full screen mode### Feature summary
Emit dbus event on detecting full screen mode (direct scanout).
### How would you like it to work
A consumer like power-profiles-daemon can execute some power optimization settings on detecting a full screen mode.### Feature summary
Emit dbus event on detecting full screen mode (direct scanout).
### How would you like it to work
A consumer like power-profiles-daemon can execute some power optimization settings on detecting a full screen mode.https://gitlab.gnome.org/GNOME/gnome-builder/-/issues/1829Failed to start SSH session: Unable to ask for ssh-userauth service2022-10-01T19:30:21ZWilliam Roywroy@proton.meFailed to start SSH session: Unable to ask for ssh-userauth serviceBuilder is unable to clone via ssh although I can clone normally if I use the terminal:
![Screenshot_from_2022-09-30_10-03-09](/uploads/922d2aa467f6eae74e50aeb73ac8f21d/Screenshot_from_2022-09-30_10-03-09.png)
```
10:06:05.0169 ...Builder is unable to clone via ssh although I can clone normally if I use the terminal:
![Screenshot_from_2022-09-30_10-03-09](/uploads/922d2aa467f6eae74e50aeb73ac8f21d/Screenshot_from_2022-09-30_10-03-09.png)
```
10:06:05.0169 ide-subproces-supervisor[ 2]: TRACE: ENTRY: ide_subprocess_supervisor_start():222
10:06:05.0169 ide-subprocess-launcher[ 2]: TRACE: ENTRY: ide_subprocess_launcher_spawn_worker():265
10:06:05.0169 ide-subprocess-launcher[ 2]: DEBUG: Launching /app/libexec/gnome-builder-git [env ] [directory /home/wroy] inheriting parent environment
10:06:05.0194 ide-subprocess-launcher[ 2]: TRACE: EXIT: ide_subprocess_launcher_spawn_worker():359
10:06:05.0194 ide-subproces-supervisor[ 2]: TRACE: ENTRY: ide_subprocess_supervisor_set_subprocess():422
10:06:05.0194 ide-subproces-supervisor[ 2]: DEBUG: Setting subprocess to 46
10:06:05.0194 ide-simple-subprocess[ 2]: TRACE: ENTRY: ide_simple_subprocess_wait_async():141
10:06:05.0194 ide-simple-subprocess[ 2]: TRACE: EXIT: ide_simple_subprocess_wait_async():154
10:06:05.0194 gbp-git-client[ 2]: TRACE: ENTRY: gbp_git_client_subprocess_spawned():63
10:06:05.0196 gbp-git-client[ 2]: TRACE: EXIT: gbp_git_client_subprocess_spawned():122
10:06:05.0196 ide-subproces-supervisor[ 2]: TRACE: EXIT: ide_subprocess_supervisor_set_subprocess():446
10:06:05.0196 ide-subproces-supervisor[ 2]: TRACE: EXIT: ide_subprocess_supervisor_start():239
10:06:05.0224 ide-vcs-clone-request[ 2]: TRACE: EXIT: ide_vcs_clone_request_clone_async():655
10:06:05.0225 gbp-vcsui-clone-page[ 2]: TRACE: EXIT: clone_action():261
10:06:05.4363 ide-vcs-clone-request[ 2]: TRACE: ENTRY: ide_vcs_clone_request_clone_cb():579
10:06:05.4363 ide-vcs-clone-request[ 2]: TRACE: EXIT: ide_vcs_clone_request_clone_cb():593
10:06:05.4364 gbp-vcsui-clone-page[ 2]: TRACE: ENTRY: gbp_vcsui_clone_page_clone_cb():135
10:06:05.4364 ide-vcs-clone-request[ 2]: TRACE: ENTRY: ide_vcs_clone_request_clone_finish():679
10:06:05.4364 ide-vcs-clone-request[ 2]: TRACE: EXIT: ide_vcs_clone_request_clone_finish():686
10:06:05.4364 gbp-vcsui-clone-page[ 2]: MESSAGE: Failed to clone repository: The operation failed. The original error was "failed to start SSH session: Unable to ask for ssh-userauth service"
10:06:05.4365 gbp-vcsui-clone-page[ 2]: TRACE: GOTO: gbp_vcsui_clone_page_clone_cb():152 (failure)
10:06:05.4367 gbp-vcsui-clone-page[ 2]: TRACE: EXIT: gbp_vcsui_clone_page_clone_cb():170
```https://gitlab.gnome.org/GNOME/gnome-flashback/-/issues/84Color management removed from GNOME Settings Daemon2022-09-30T16:03:47ZAlberts Muktupāvelsalberts.muktupavels@gmail.comColor management removed from GNOME Settings Daemonhttps://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/merge_requests/278https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/merge_requests/278https://gitlab.gnome.org/GNOME/vala/-/issues/1363Valadoc: add option to specify stylesheet2022-09-30T21:31:19ZTristan RossValadoc: add option to specify stylesheetBy default Valadoc uses its own CSS file and it would be great to specify custom CSS files. This will be great for projects that wish to use their own styles to embed Valadoc generated documentation into their websites.By default Valadoc uses its own CSS file and it would be great to specify custom CSS files. This will be great for projects that wish to use their own styles to embed Valadoc generated documentation into their websites.https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5926Add option to disable certain extensions when using Power Saver mode2024-01-10T16:36:10ZJohnAdd option to disable certain extensions when using Power Saver modeI have a few extensions that I use mostly for aesthetic purposes, like wobbly windows and Desktop Cube. The problem is that when I need to conserve power, I'm happy to accept a slightly less customized experience to make my battery last ...I have a few extensions that I use mostly for aesthetic purposes, like wobbly windows and Desktop Cube. The problem is that when I need to conserve power, I'm happy to accept a slightly less customized experience to make my battery last as long as possible. This could also be used to disable extensions that provide extra features, like GSConnect.
It would be useful if, in the extensions app, users could set whether specific extensions should be disabled when Power Saver mode is enabled.
An option to disable _all_ extensions could be added instead, but that would interfere with extensions that some users consider essential to their workflows and break extensions added by distributions.https://gitlab.gnome.org/GNOME/gimp/-/issues/8683Critical gimp_size_entry_set_resolution when editing text2024-03-18T12:54:53ZMaksymilian CzaplewskiCritical gimp_size_entry_set_resolution when editing text
```
Edytor obrazów GIMP version 2.99.12
git-describe: GIMP_2_99_12
Build: org.gimp.GIMP.flatpak.dev rev 0 for linux
# C compiler #
Using built-in specs.
COLLECT_GCC=/usr/bin/cc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-unknown-linux-...
```
Edytor obrazów GIMP version 2.99.12
git-describe: GIMP_2_99_12
Build: org.gimp.GIMP.flatpak.dev rev 0 for linux
# C compiler #
Using built-in specs.
COLLECT_GCC=/usr/bin/cc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-unknown-linux-gnu/11.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/bin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --enable-deterministic-archives --enable-shared --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu lt_cv_sys_lib_dlsearch_path_spec=/usr/lib/x86_64-linux-gnu --target=x86_64-unknown-linux-gnu --disable-multilib --enable-multiarch --disable-bootstrap --with-build-sysroot=/cross-installation --enable-languages=c,c++,fortran,objc,obj-c++ --enable-default-pie --enable-default-ssp --with-isl --disable-libssp --enable-linker-build-id --disable-libstdcxx-filesystem-ts --enable-cet host_configargs=lt_cv_sys_lib_dlsearch_path_spec=/usr/lib/x86_64-linux-gnu target_configargs=lt_cv_sys_lib_dlsearch_path_spec=/usr/lib/x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.3.0 (GCC)
# Libraries #
using babl version 0.1.92 (compiled against version 0.1.92)
using GEGL version 0.4.38 (compiled against version 0.4.38)
using GLib version 2.72.3 (compiled against version 2.72.3)
using GdkPixbuf version 2.42.8 (compiled against version 2.42.9)
using GTK+ version 3.24.34 (compiled against version 3.24.34)
using Pango version 1.50.8 (compiled against version 1.50.8)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.17.6 (compiled against version 1.17.6)
# Flatpak info #
[Application]
name=org.gimp.GIMP
runtime=runtime/org.gnome.Platform/x86_64/42
[Instance]
instance-id=3232751149
instance-path=/home/mx/.var/app/org.gimp.GIMP
app-path=/home/mx/.local/share/flatpak/app/org.gimp.GIMP/x86_64/beta/fc43a98fcaa945e7d6590d034f0a1b80824573909e3fc4e4932db4b1f831398b/files
app-commit=fc43a98fcaa945e7d6590d034f0a1b80824573909e3fc4e4932db4b1f831398b
runtime-path=/var/lib/flatpak/runtime/org.gnome.Platform/x86_64/42/472b0f1f1b9d70b8e146872471c025bd1f8f04159ac48f36c0d56fbbc47f0a2e/files
runtime-commit=472b0f1f1b9d70b8e146872471c025bd1f8f04159ac48f36c0d56fbbc47f0a2e
runtime-extensions=org.gnome.Platform.Locale=0410f7cba8fd2070a5ea777efbbf549599df4b9740defae0ae9a89e11b35ec06;org.freedesktop.Platform.GL.default=71b235f9bcc488535725056d2ad8e76638188d1f8faf3e45ec3cc82324c86a5a;org.freedesktop.Platform.VAAPI.Intel=cb0d2eb9ab52401abc4f7fdf02a895113828d9c859d3940377bd557a77970a7c;org.freedesktop.Platform.openh264=73f998362a6fc0d57e0c7e83e928d32b0ec14d10d0d94291033976bdcecc6b6b
branch=beta
arch=x86_64
flatpak-version=1.12.6
session-bus-proxy=true
system-bus-proxy=true
[Context]
shared=network;ipc;
sockets=x11;wayland;fallback-x11;
devices=dri;
filesystems=host;xdg-config/GIMP;/tmp;xdg-config/gtk-3.0;xdg-run/gvfsd;xdg-run/gvfs;
[Session Bus Policy]
org.freedesktop.FileManager1=talk
org.gnome.Shell.Screenshot=talk
org.kde.kwin.Screenshot=talk
org.gtk.vfs.*=talk
[Environment]
GST_PLUGIN_SYSTEM_PATH=/app/lib/gstreamer-1.0:/usr/lib/extensions/gstreamer-1.0:/usr/lib/x86_64-linux-gnu/gstreamer-1.0
GI_TYPELIB_PATH=/app/lib/girepository-1.0
ALSA_CONFIG_DIR=/usr/share/alsa
XDG_DATA_DIRS=/app/share:/usr/share:/usr/share/runtime/share:/run/host/user-share:/run/host/share
ALSA_CONFIG_PATH=/usr/share/alsa/alsa-flatpak.conf
__EGL_EXTERNAL_PLATFORM_CONFIG_DIRS=/etc/egl/egl_external_platform.d:/usr/lib/x86_64-linux-gnu/GL/egl/egl_external_platform.d:/usr/share/egl/egl_external_platform.d
```
> GIMP-KRYTYCZNE: gimp_size_entry_set_resolution: assertion 'GIMP_IS_SIZE_ENTRY (gse)' failed
Stack trace:
```
/app/lib/libgimpbase-3.0.so.0(gimp_stack_trace_print+0x417) [0x7fac4b01c557]
gimp-2.99(gui_message+0x311) [0x55c5d4a98d01]
gimp-2.99(gimp_show_message+0xce) [0x55c5d4bd61be]
gimp-2.99(+0x104c91) [0x55c5d4a7dc91]
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_logv+0x242) [0x7fac4a9c1e22]
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_log+0x93) [0x7fac4a9c2123]
gimp-2.99(+0x16cd0c) [0x55c5d4ae5d0c]
gimp-2.99(+0x16eda6) [0x55c5d4ae7da6]
gimp-2.99(+0x16f836) [0x55c5d4ae8836]
gimp-2.99(gimp_tool_button_press+0xc9) [0x55c5d4aecde9]
gimp-2.99(gimp_display_shell_canvas_tool_events+0x1980) [0x55c5d4e9d790]
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0(+0xa6e81) [0x7fac49dc6e81]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x179) [0x7fac4a6f1569]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x2afbf) [0x7fac4a704fbf]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x9db) [0x7fac4a70b6fb]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x93) [0x7fac4a70bf83]
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0(+0x3a3e84) [0x7fac4a0c3e84]
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0(+0x23033f) [0x7fac49f5033f]
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0(gtk_main_do_event+0x7bc) [0x7fac49f51fec]
/usr/lib/x86_64-linux-gnu/libgdk-3.so.0(+0x418e2) [0x7fac49c558e2]
/usr/lib/x86_64-linux-gnu/libgdk-3.so.0(+0x9f2af) [0x7fac49cb32af]
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x19b) [0x7fac4a9b9cdb]
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x5a1e8) [0x7fac4a9ba1e8]
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0x83) [0x7fac4a9ba503]
gimp-2.99(app_run+0x37c) [0x55c5d4a7d8cc]
gimp-2.99(main+0x3a7) [0x55c5d4a7b057]
/usr/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7fac49430b80]
gimp-2.99(_start+0x2e) [0x55c5d4a7b1be]
```https://gitlab.gnome.org/GNOME/tracker/-/issues/381Vacuum currently only happens if database files exceed 4 GB, but should proba...2022-10-01T13:37:11ZJeff FortinVacuum currently only happens if database files exceed 4 GB, but should probably happen under more circumstancesThrough #379 I discovered that the reason tracker was using 2 GB for its Documents cache DB file was that it was indexing a big collection of about 2000 epub ebooks on my system, that I don't care to see indexed. My disk space is very li...Through #379 I discovered that the reason tracker was using 2 GB for its Documents cache DB file was that it was indexing a big collection of about 2000 epub ebooks on my system, that I don't care to see indexed. My disk space is very limited and precious and I try to keep my caches to a minimum, so I added "ebooks" and "epub" as folders to be ignored in the `ignored-directories` gsetting of `org.freedesktop.Tracker3.Miner.Files`. However, this did not result in the cache/database file shrinking. It was then pointed out that while tracker is supposed to vacuum on restarting the gnome session, tracker currently only considers vacuuming if the file exceeds 4 GB, because vacuuming can be an expensive operation.
Ideally, it should be a bit smarter than that. Maybe it could evaluate how much potential there is to save by vacuuming, by
* knowing how many entries are gone from the filesystem, or ignored, and determining the weight or percentage this represents?
* triggering a vacuum a while after the `ignored-directories` or `ignored-directories-with-content` or `ignored-files` or `max-bytes` gsettings have changed?
* considering how full the filesystem is?
* once every two weeks or something?
* upon new version upgrades?https://gitlab.gnome.org/GNOME/NetworkManager-vpnc/-/issues/9Connection failed alert does not say WHICH connection failed2022-10-01T13:50:39ZShawn HeiseyConnection failed alert does not say WHICH connection failedWhen a VPN connection fails, gnome has a popup alert saying the connection failed. But it doesn't say WHICH connection failed. I have a dozen VPN connections defined, which all use split tunneling so multiple connections can be active ...When a VPN connection fails, gnome has a popup alert saying the connection failed. But it doesn't say WHICH connection failed. I have a dozen VPN connections defined, which all use split tunneling so multiple connections can be active at the same time. When one fails, I want to know which one at a glance so I know which connection to bring back up with "nmcli con up NAME", and so that I have a mental inventory of which connections might be having problems just from seeing multiple failed alerts.
I put this in the NetworkManager-vpnc project because most of my VPNs are vpnc. But a few are openvpn. I think this should happen for any kind of network connection, not just VPNs.