GNOME issueshttps://gitlab.gnome.org/groups/GNOME/-/issues2021-06-10T15:30:25Zhttps://gitlab.gnome.org/GNOME/vte/-/issues/2484Obscured VteTerminals may become non-responsive until clicked on2021-06-10T15:30:25ZBugzillaObscured VteTerminals may become non-responsive until clicked on## Submitted by Debarshi Ray `@debarshir`
**[Link to original bug (#794214)](https://bugzilla.gnome.org/show_bug.cgi?id=794214)**
## Description
It's from this RHEL 6 bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1546615
Access ...## Submitted by Debarshi Ray `@debarshir`
**[Link to original bug (#794214)](https://bugzilla.gnome.org/show_bug.cgi?id=794214)**
## Description
It's from this RHEL 6 bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1546615
Access is currently restricted, so I will describe it myself.
Spawning a lot of VteTerminals, in the order of a few hundred, under a non-composited X session, with one widget per process (similar to "gnome-terminal --disable-factory") may leave some of the widgets in an inactive state where it is no longer polling for incoming bytes from the pseudo-terminal master. See the attached reproducer.
My understanding is that the code that disables the pseudo-terminal handling when the widget is fully obscured doesn't restore it to the list of active widgets when it is no longer active. If the timings are just about right, then the widget will stop updating until some other event causes the pseudo-terminal master's file descriptor to be added back to the GMainContext. An example of such an event is to click the inactive widget. VTE will interpret the button press as a potential attempt to select text, and once the button is released it will restore the file descriptor to the GMainContext.
I believe that having just one VteTerminal instance per process increases the chances of reproducing the bug because it's easier to reset the list of active terminals to NULL. Similarly, it's necessary to have a non-composited X session because GtkWidget::visibility-notify-event doesn't work under composited windowing systems.
Version: 0.50.x
Resolution: RESOLVED FIXEDhttps://gitlab.gnome.org/GNOME/vala/-/issues/624Move GLib basic types in to glib-2.0-basic-types.vapi2021-07-04T22:48:22ZBugzillaMove GLib basic types in to glib-2.0-basic-types.vapi## Submitted by Al Thomas `@astavale`
**[Link to original bug (#794213)](https://bugzilla.gnome.org/show_bug.cgi?id=794213)**
## Description
Created attachment 369518
glib-2.0: move basic types into glib-2.0-basic-types.vapi
This p...## Submitted by Al Thomas `@astavale`
**[Link to original bug (#794213)](https://bugzilla.gnome.org/show_bug.cgi?id=794213)**
## Description
Created attachment 369518
glib-2.0: move basic types into glib-2.0-basic-types.vapi
This patch moves the definitions for int, etc. that are in the Vala global namespace from glib-2.0.vapi to their own VAPI. The patch is more for discussion than inclusion. It aims to be a model for including basic types from other platforms. For example if we wanted to exclude the GLib types and target POSIX:
valac my_source.vala --nostdpkg --pkg posix --pkg posix-basic-types
It is an example of targeting platforms at a low level without the need to introduce "profiles" in to the Vala codegen. In my view it is a more flexible approach. For example it would be fairly easy to add a Windows basic types binding. From https://msdn.microsoft.com/en-us/library/windows/desktop/aa373562(v=vs.85).aspx it looks like that is in Rpcndr.h.
Strangely this patch causes make check to fail. For the valadoc/test/drivers test I get:
G_DEBUG=fatal_warnings ./driver
**
ERROR:drivers/generic-api-test.c:15456:test_driver: code should not be reached
Makefile:1131: recipe for target 'check-TESTS' failed
make[6]: *** [check-TESTS] Aborted (core dumped)
**Patch 369518**, "glib-2.0: move basic types into glib-2.0-basic-types.vapi":
[0001-glib-2.0-move-basic-types-into-glib-2.0-basic-types..patch](/uploads/be0ad508000d4842f82874d3198c6621/0001-glib-2.0-move-basic-types-into-glib-2.0-basic-types..patch)1.0https://gitlab.gnome.org/GNOME/evince/-/issues/883textareas and textfields should have a non-white background to notice fields ...2021-10-31T11:56:24ZBugzillatextareas and textfields should have a non-white background to notice fields in a form## Submitted by Jonee
**[Link to original bug (#794212)](https://bugzilla.gnome.org/show_bug.cgi?id=794212)**
## Description
As it is in Evince, you cannot see a textarea or textfield. It should have a different background so you ca...## Submitted by Jonee
**[Link to original bug (#794212)](https://bugzilla.gnome.org/show_bug.cgi?id=794212)**
## Description
As it is in Evince, you cannot see a textarea or textfield. It should have a different background so you can easily determine if it is an area where you should type text.
Thanks!
Version: 3.18.xhttps://gitlab.gnome.org/GNOME/rhythmbox/-/issues/1629crash when deleting podcast feed and files caused by assertion failure2021-03-24T16:58:01ZBugzillacrash when deleting podcast feed and files caused by assertion failure## Submitted by Paul Sanfilippo
**[Link to original bug (#794211)](https://bugzilla.gnome.org/show_bug.cgi?id=794211)**
## Description
VERSION:
rhythmbox 3.4.1-2ubuntu amd64
PROCEDURE:
- Click Podcasts -> right click on a podcast a...## Submitted by Paul Sanfilippo
**[Link to original bug (#794211)](https://bugzilla.gnome.org/show_bug.cgi?id=794211)**
## Description
VERSION:
rhythmbox 3.4.1-2ubuntu amd64
PROCEDURE:
- Click Podcasts -> right click on a podcast and select "Delete Feed" -> in dialog window select "Delete Feed and Files"
- Program hangs and then crashes with no output. Feed does not get deleted.
- "Delete feed only" also causes crash with same cause.
PODCAST SOURCE:
https://itunes.apple.com/us/podcast/the-memory-palace/id299436963?mt=2&uo=4
"the memory palace"
POSSIBLE DUPLICATE:
[bug 321956](https://bugzilla.gnome.org/show_bug.cgi?id=321956)
DEBUGGER OUTPUT:
RhythmDB:ERROR:rhythmdb-tree.c:1731:rhythmdb_tree_entry_delete: assertion failed: (g_hash_table_remove (db->priv->entries, entry->location))
Thread 1 "rhythmbox" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
BACKTRACE:
```
(gdb) bt
#0 0x00007ffff62e20bb in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ffff62e3f5d in __GI_abort () at abort.c:90
#2 0x00007ffff691b81d in g_assertion_message () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007ffff691b8aa in g_assertion_message_expr ()
at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007ffff7b2b04f in () at /usr/lib/x86_64-linux-gnu/librhythmbox-core.so.10
#5 0x00007ffff7b124a1 in rhythmdb_entry_delete ()
at /usr/lib/x86_64-linux-gnu/librhythmbox-core.so.10
#6 0x00007ffff7ae55b1 in rb_podcast_manager_remove_feed ()
at /usr/lib/x86_64-linux-gnu/librhythmbox-core.so.10
#7 0x00007ffff7adfb74 in () at /usr/lib/x86_64-linux-gnu/librhythmbox-core.so.10
#8 0x00007ffff6bd0041 in g_cclosure_marshal_VOID__BOOLEANv ()
at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9 0x00007ffff6bce1d6 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x00007ffff6be979f in g_signal_emit_valist ()
at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#11 0x00007ffff6be9ecf in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#12 0x00007ffff6bce1d6 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#13 0x00007ffff6be979f in g_signal_emit_valist ()
at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#14 0x00007ffff6be9ecf in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#15 0x00007ffff6f3f55d in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#16 0x00007ffff6f3f5b5 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#17 0x00007ffff6bce1d6 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#18 0x00007ffff6be979f in g_signal_emit_valist ()
at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#19 0x00007ffff6be9ecf in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#20 0x00007ffff6f3da10 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#21 0x00007ffff1130e18 in ffi_call_unix64 () at /usr/lib/x86_64-linux-gnu/libffi.so.6
#22 0x00007ffff113087a in ffi_call () at /usr/lib/x86_64-linux-gnu/libffi.so.6
#23 0x00007ffff6bceb8d in g_cclosure_marshal_generic_va ()
---Type <return> to continue, or q <return> to quit---
ect-2.0.so.0
#24 0x00007ffff6bce1d6 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#25 0x00007ffff6be979f in g_signal_emit_valist ()
at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#26 0x00007ffff6be9ecf in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#27 0x00007ffff6ffbc51 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#28 0x00007ffff6bd0ea8 in g_cclosure_marshal_VOID__BOXEDv ()
at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#29 0x00007ffff6bce1d6 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#30 0x00007ffff6be979f in g_signal_emit_valist ()
at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#31 0x00007ffff6be9ecf in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#32 0x00007ffff6ff8ece in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#33 0x00007ffff6ffa4bb in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#34 0x00007ffff6ffd1be in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#35 0x00007ffff6fca571 in gtk_event_controller_handle_event ()
at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#36 0x00007ffff718debb in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#37 0x00007ffff70455a7 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#38 0x00007ffff6bce1d6 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#39 0x00007ffff6be916d in g_signal_emit_valist ()
at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#40 0x00007ffff6be9ecf in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#41 0x00007ffff7190174 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#42 0x00007ffff704243e in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#43 0x00007ffff70445b8 in gtk_main_do_event () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#44 0x00007ffff535d9a5 in () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#45 0x00007ffff538f172 in () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#46 0x00007ffff68f4fb7 in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#47 0x00007ffff68f51f0 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#48 0x00007ffff68f527c in g_main_context_iteration ()
at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#49 0x00007ffff3829c4d in g_application_run () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#50 0x00007ffff7a9ae37 in rb_application_run ()
at /usr/lib/x86_64-linux-gnu/librhythmbox-core.so.10
#51 0x0000555555554d97 in main ()
```
Version: 3.4.xhttps://gitlab.gnome.org/GNOME/mutter/-/issues/60Gnome cheats in fullscreen benchmarks (gives smaller than requested window)2020-03-30T07:08:20ZGhost UserGnome cheats in fullscreen benchmarks (gives smaller than requested window)Setup:
* FullHD monitor (1920x1080 resolution)
* Ubuntu 18.04 with Gnome/mutter 3.28.1, on top of X
* GfxBench benchmark suite from Kishonti: https://gfxbench.com/ (one of the most common 3D benchmarks supporting Linux)
Example test-cas...Setup:
* FullHD monitor (1920x1080 resolution)
* Ubuntu 18.04 with Gnome/mutter 3.28.1, on top of X
* GfxBench benchmark suite from Kishonti: https://gfxbench.com/ (one of the most common 3D benchmarks supporting Linux)
Example test-case:
* bin/testfw_app --gfx glfw --gl_api desktop_core --width 1920 --height 1080 --fullscreen 1 --test_id gl_manhattan
Expected outcome:
* Benchmark renders always in full monitor resolution, like happens with all other desktops (Unity, XFCE, KDE)
Actual outcome:
* There's a black bar at the top of the screen and benchmark content is vertically scaled to smaller size
Same thing happens also with Ubuntu 16.04 version of Mutter (v3.18.3), so this isn't a new issue.
I assume that any other similar test-case which:
* requests full resolution fullscreen window
* uses window size that it gets from the WM
* but doesn't support resizing the window afterwards
Would have the same issue.
From xwininfo, xev and apitrace output I can see following:
* Window is created in correct resolution
* app sets some window properties
* WM reparents it
* WM maps window's parent to screen
* WM resizes window's parent a smaller size
* I think this is the point when the application thinks that's the final window size and sets its GL viewport accordingly
* Some _NET_WM properties are set by WM
* WM resizes window's parent back to correct size, which is apparently too late for this application
When comparing this to what Unity does:
* Unity or app sets properties after reparenting
* There's an extra intermediate window between the resized parent and the benchmark window
* Resizing of the parent window to smaller size happens **before** that window is mapped on screen. **I assume this means that the application doesn't get window resize event for the wrong window size**
* extra _NET_WM properties are set after parent is re-sized back to correct size -> this probably makes the time window with wrong window size shorterhttps://gitlab.gnome.org/GNOME/vala/-/issues/623Solve the "empty file problem"2021-09-22T12:59:04ZBugzillaSolve the "empty file problem"## Submitted by Al Thomas `@astavale`
**[Link to original bug (#794210)](https://bugzilla.gnome.org/show_bug.cgi?id=794210)**
## Description
The "empty file problem" is an indication of Vala's current dependence on GLib, even when t...## Submitted by Al Thomas `@astavale`
**[Link to original bug (#794210)](https://bugzilla.gnome.org/show_bug.cgi?id=794210)**
## Description
The "empty file problem" is an indication of Vala's current dependence on GLib, even when there is no code in the Vala source file. It currently has three things that need solving:
1. An empty Vala files compiled to C will have includes for `glib.h` and `glib-object.h`. The C file should be empty
2. There is currently nothing in the test infrastructure to check C output from valac. A test should be implemented to check that an empty source file produces an empty C file
3. Compiling an empty Vala source file with `--nostdpkg` produces an error "The namespace name `GLib' could not be found". It should produce an empty C file
At present an empty Vala files produces something like:
```
/* empty_vala_source.c generated by valac 0.39.92.14-46f76-dirty, the Vala compiler
* generated from empty_vala_source.vala, do not modify */
#include <glib.h>
#include <glib-object.h>
```
The includes don't need to be there. There is currently no option to not have the comment at the beginning, but that is probably fine. Any test mechanism would need to take account of the comment.https://gitlab.gnome.org/GNOME/mutter/-/issues/59gnome keyboard and mouse are extremely slow with Matrox graphics controllers2023-10-10T02:38:06ZDrewgnome keyboard and mouse are extremely slow with Matrox graphics controllersThe gnome desktop keyboard and mouse on the server are extremely slow responding with many systems. This includes several new purley-based systems and older broadwell/haswell systems as well. All of these system use Matrox graphics contr...The gnome desktop keyboard and mouse on the server are extremely slow responding with many systems. This includes several new purley-based systems and older broadwell/haswell systems as well. All of these system use Matrox graphics controllers; using sles 15 beta/rc releases.
The graphics slow response happens before it is even logged in. Here is the output of loginctl:
foo-system-pxeuefi:/var/log # loginctl
SESSION UID USER SEAT TTY
1 0 root seat0 tty1
c1 465 gdm seat0 tty7
2 0 root seat0 tty3
3 sessions listed.
foo-system-pxeuefi:/var/log # loginctl show-session c1
Id=c1
User=465
Name=gdm
Timestamp=Fri 2018-01-26 11:10:44 MST
TimestampMonotonic=732441280
VTNr=7
Seat=seat0
TTY=tty7
Remote=no
Service=gdm-launch-environment
Scope=session-c1.scope
Leader=3582
Audit=0
Type=wayland
Class=greeter
Active=no
State=online
IdleHint=yes
IdleSinceHint=1516991193737850
IdleSinceHintMonotonic=1681737850
LockedHint=no
If you change the login to "Gnome on Xorg" during login, the slowness problem is solved.
Issue https://gitlab.gnome.org/GNOME/mutter/issues/57 is similar.https://gitlab.gnome.org/GNOME/glib/-/issues/1351gdbus does not support Windows SSPI authentication2023-07-17T00:40:20ZBugzillagdbus does not support Windows SSPI authentication## Submitted by LRN `@ruslanizhb`
**[Link to original bug (#794206)](https://bugzilla.gnome.org/show_bug.cgi?id=794206)**
## Description
GDBus only supports EXTERNAL, SHA1 and ANONYMOUS authentication mechanisms.
SHA1 depends on fi...## Submitted by LRN `@ruslanizhb`
**[Link to original bug (#794206)](https://bugzilla.gnome.org/show_bug.cgi?id=794206)**
## Description
GDBus only supports EXTERNAL, SHA1 and ANONYMOUS authentication mechanisms.
SHA1 depends on filesystem access rights being set up correctly (not sure whether it works on Windows).
EXTERNAL depends on passing credentials as a side-metadata along with a byte sent over a UNIX socket, so this is not doable on Windows (dbus has a hacky way of achieving something similar, but hardly worth copying).
ANONYMOUS is...anonymous.
Therefore, i propose to use SSPI to perform authentication.https://gitlab.gnome.org/GNOME/vala/-/issues/622Replace G_BEGIN_DECLS and G_END_DECLS macros with #ifdef __cplusplus2018-11-05T08:12:31ZBugzillaReplace G_BEGIN_DECLS and G_END_DECLS macros with #ifdef __cplusplus## Submitted by Al Thomas `@astavale`
**[Link to original bug (#794205)](https://bugzilla.gnome.org/show_bug.cgi?id=794205)**
## Description
Created attachment 369507
Replace G_BEGIN_DECLS and G_END_DECLS macros with #ifdef __cplusp...## Submitted by Al Thomas `@astavale`
**[Link to original bug (#794205)](https://bugzilla.gnome.org/show_bug.cgi?id=794205)**
## Description
Created attachment 369507
Replace G_BEGIN_DECLS and G_END_DECLS macros with #ifdef __cplusplus
If there is a desire to generate code that is not dependant on GLib, e.g. Posix only, then this keeps the #ifdef __cplusplus extern "C" { #endif.
A small attempt to reduce the number of if..else statements in https://git.gnome.org/browse/vala/commit/?h=wip/profile-posix&id=3faa6800d542770962324ee638857a2d5fdedda9
**Patch 369507**, "Replace G_BEGIN_DECLS and G_END_DECLS macros with #ifdef __cplusplus":
[0001-codegen-replace-G_BEGIN_DECLS-and-G_END_DECLS-with-i.patch](/uploads/afba7fa686581e475bc0af7c3664cc8f/0001-codegen-replace-G_BEGIN_DECLS-and-G_END_DECLS-with-i.patch)0.44https://gitlab.gnome.org/GNOME/gnome-builder/-/issues/424Tiny typo2018-03-12T06:35:03ZBruce CowanTiny typodata/gsettings/org.gnome.builder.editor.language.gschema.xml:43
"How to apply spaces when reformating text." should be "How to apply spaces when reformatting text."data/gsettings/org.gnome.builder.editor.language.gschema.xml:43
"How to apply spaces when reformating text." should be "How to apply spaces when reformatting text."https://gitlab.gnome.org/GNOME/gdm/-/issues/366gdm logs with wrong syslog identifier2020-04-24T17:29:39ZBugzillagdm logs with wrong syslog identifier## Submitted by Lukas Grossar
**[Link to original bug (#794202)](https://bugzilla.gnome.org/show_bug.cgi?id=794202)**
## Description
gdm logs to the journal with a wrong SYSLOG_IDENTIFIER.
gdm identifies itself wrong with the "gdm-p...## Submitted by Lukas Grossar
**[Link to original bug (#794202)](https://bugzilla.gnome.org/show_bug.cgi?id=794202)**
## Description
gdm logs to the journal with a wrong SYSLOG_IDENTIFIER.
gdm identifies itself wrong with the "gdm-password]" string, which has an added "]" char at the end.
This bug has also been reported in the Fedora/Red Hat bug tracker [1], but somehow a fix was never released upstream.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1266879
Version: 3.26.xhttps://gitlab.gnome.org/GNOME/yelp-xsl/-/issues/24Port to meson build system2018-09-03T21:44:12ZBugzillaPort to meson build system## Submitted by Martin Blanchard `@martinblanchard`
**[Link to original bug (#794201)](https://bugzilla.gnome.org/show_bug.cgi?id=794201)**
## Description
meson is a build system focused on speed an ease of use, which helps speeding...## Submitted by Martin Blanchard `@martinblanchard`
**[Link to original bug (#794201)](https://bugzilla.gnome.org/show_bug.cgi?id=794201)**
## Description
meson is a build system focused on speed an ease of use, which helps speeding up the software development [1].
Porting attempt development branch is on GitLab [2].
[1] https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting
[2] https://gitlab.gnome.org/martinblanchard/yelp-xsl/tree/wip/mablanch/meson
Version: git master
### Blocking
* [Bug 782980](https://bugzilla.gnome.org/show_bug.cgi?id=782980)https://gitlab.gnome.org/GNOME/gnome-software/-/issues/323Should always reflect the correct state of a package2018-06-21T02:39:02ZKen VanDineShould always reflect the correct state of a packageCurrently, if you install a snap on the command line gnome-software will miss a transition and no longer reflect the correct state.
Mar 09 12:19:30 x230 gnome-software[16854]: State change on system/snap/Snap Store/desktop/gnome-charact...Currently, if you install a snap on the command line gnome-software will miss a transition and no longer reflect the correct state.
Mar 09 12:19:30 x230 gnome-software[16854]: State change on system/snap/Snap Store/desktop/gnome-characters/* from available to installed is not OKRobert AncellRobert Ancellhttps://gitlab.gnome.org/GNOME/gitg/-/issues/113The description in github is bad (it has a old url)2024-02-11T17:58:55ZBugzillaThe description in github is bad (it has a old url)## Submitted by Miguel
**[Link to original bug (#794198)](https://bugzilla.gnome.org/show_bug.cgi?id=794198)**
## Description
The actual description in github (https://github.com/GNOME/gitg) is:
"""
gitg is a GitX clone for GNOME/g...## Submitted by Miguel
**[Link to original bug (#794198)](https://bugzilla.gnome.org/show_bug.cgi?id=794198)**
## Description
The actual description in github (https://github.com/GNOME/gitg) is:
"""
gitg is a GitX clone for GNOME/gtk+. It aims at being a small, fast and convenient tool to visualize git history and actions that benefit from a graphical presentation. http://trac.novowork.com/gitg
"""
And the url is old, the last archived web in archive.org is (year 2010):
http://web.archive.org/web/20100219234841/http://trac.novowork.com:80/gitg/
I think the gitg description in github can be:
"""
gitg is a GitX clone for GNOME/gtk+. It aims at being a small, fast and convenient tool to visualize git history and actions that benefit from a graphical presentation. https://wiki.gnome.org/Apps/Gitg
"""
Version: git masterhttps://gitlab.gnome.org/GNOME/meld/-/issues/169Cannot copy paths from meld window2018-03-09T20:11:26ZGhost UserCannot copy paths from meld windowIn meld version 1.8.4 I can highlight parts of the paths to the displayed files and paste it into an xterm with the middle mouse button. In 3.14.2 this functionality no longer works.
This regression has been observed in both Ubuntu LTS ...In meld version 1.8.4 I can highlight parts of the paths to the displayed files and paste it into an xterm with the middle mouse button. In 3.14.2 this functionality no longer works.
This regression has been observed in both Ubuntu LTS and Debian Testing thus I am reporting it here rather than against a specific distribution.https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/197Permanent errors being transient2018-03-10T20:25:56ZДилян Палаузовgit-dpa@aegee.orgPermanent errors being transientBuiling 1.54.1 I get with `make`:
GISCAN GObject-2.0.gir
/usr/local/include/glib-2.0/gobject/gobject-autocleanups.h:24: syntax error, unexpected identifier in 'G_DEFINE_AUTOPTR_CLEANUP_FUNC(GClosure, g_closure_unref)' at 'G_DEFINE_A...Builing 1.54.1 I get with `make`:
GISCAN GObject-2.0.gir
/usr/local/include/glib-2.0/gobject/gobject-autocleanups.h:24: syntax error, unexpected identifier in 'G_DEFINE_AUTOPTR_CLEANUP_FUNC(GClosure, g_closure_unref)' at 'G_DEFINE_AUTOPTR_CLEANUP_FUNC'
g-ir-scanner: GObject: warning: 19 warnings suppressed (use --warn-all to see them)
GISCAN GModule-2.0.gir
g-ir-scanner: GModule: warning: 2 warnings suppressed (use --warn-all to see them)
GISCAN Gio-2.0.gir
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:24: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GAction *GAction_autoptr;' at 'GAction_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:25: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GActionMap *GActionMap_autoptr;' at 'GActionMap_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:26: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GAppInfo *GAppInfo_autoptr;' at 'GAppInfo_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:27: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GAppLaunchContext *GAppLaunchContext_autoptr;' at 'GAppLaunchContext_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:28: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GAppInfoMonitor *GAppInfoMonitor_autoptr;' at 'GAppInfoMonitor_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:29: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GApplicationCommandLine *GApplicationCommandLine_autoptr;' at 'GApplicationCommandLine_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:30: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GApplication *GApplication_autoptr;' at 'GApplication_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:31: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GAsyncInitable *GAsyncInitable_autoptr;' at 'GAsyncInitable_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:32: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GAsyncResult *GAsyncResult_autoptr;' at 'GAsyncResult_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:33: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GBufferedInputStream *GBufferedInputStream_autoptr;' at 'GBufferedInputStream_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:34: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GBufferedOutputStream *GBufferedOutputStream_autoptr;' at 'GBufferedOutputStream_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:35: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GBytesIcon *GBytesIcon_autoptr;' at 'GBytesIcon_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:36: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GCancellable *GCancellable_autoptr;' at 'GCancellable_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:37: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GCharsetConverter *GCharsetConverter_autoptr;' at 'GCharsetConverter_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:38: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GConverter *GConverter_autoptr;' at 'GConverter_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:39: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GConverterInputStream *GConverterInputStream_autoptr;' at 'GConverterInputStream_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:40: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GConverterOutputStream *GConverterOutputStream_autoptr;' at 'GConverterOutputStream_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:41: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GCredentials *GCredentials_autoptr;' at 'GCredentials_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:42: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GDatagramBased *GDatagramBased_autoptr;' at 'GDatagramBased_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:43: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GDataInputStream *GDataInputStream_autoptr;' at 'GDataInputStream_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:44: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GDataOutputStream *GDataOutputStream_autoptr;' at 'GDataOutputStream_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:45: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GDBusActionGroup *GDBusActionGroup_autoptr;' at 'GDBusActionGroup_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:46: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GDBusAuthObserver *GDBusAuthObserver_autoptr;' at 'GDBusAuthObserver_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:47: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GDBusConnection *GDBusConnection_autoptr;' at 'GDBusConnection_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:48: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GDBusInterface *GDBusInterface_autoptr;' at 'GDBusInterface_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:49: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GDBusInterfaceSkeleton *GDBusInterfaceSkeleton_autoptr;' at 'GDBusInterfaceSkeleton_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:50: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GDBusMenuModel *GDBusMenuModel_autoptr;' at 'GDBusMenuModel_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:51: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GDBusMessage *GDBusMessage_autoptr;' at 'GDBusMessage_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:52: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GDBusMethodInvocation *GDBusMethodInvocation_autoptr;' at 'GDBusMethodInvocation_autoptr'
/usr/local/include/glib-2.0/gio/gio-autocleanups.h:53: syntax error, unexpected typedef-name, expecting identifier or '(' in 'typedef GDBusNodeInfo *GDBusNodeInfo_autoptr;' at 'GDBusNodeInfo_autoptr'
and so on. Doing `make` again I see no errors.
If this is an error, repeating `make` shall repeat the error, otherwise it shall be called `warning`.
Next question is how to resolve the errors.https://gitlab.gnome.org/GNOME/shotwell/-/issues/4912Viewer fails to save a JPEG with non-JPEG filename extension2021-05-19T15:12:52ZBugzillaViewer fails to save a JPEG with non-JPEG filename extension## Submitted by Jani Uusitalo
**[Link to original bug (#794195)](https://bugzilla.gnome.org/show_bug.cgi?id=794195)**
## Description
== Steps to reproduce ==
1. Download https://upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Car_...## Submitted by Jani Uusitalo
**[Link to original bug (#794195)](https://bugzilla.gnome.org/show_bug.cgi?id=794195)**
## Description
== Steps to reproduce ==
1. Download https://upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Car_crash_1.jpg/193px-Car_crash_1.jpg?download
2. Open the image in Shotwell Viewer: $ shotwell 193px-Car_crash_1.jpg
3. Select File > Save As...
4. Keep/set Format as "Current", don't change any other parameters
5. Enter "193px-Car_crash_1.png" (without quotes) as the filename, select OK
== What happens ==
The viewer now displays a black screen, with the text "Photo source file missing:" followed by the (.png-ending) image path entered in the dialog. The file has not been saved.
== What I expect to happen ==
For the (now misnamed) .png-ending file to have been saved, and be opened in the Viewer.
== Other notes ==
* If an image file with the .png ending already exists, and I choose to overwrite it with the JPEG, the black error screen does not appear; instead the previously-existing PNG image file is then opened in the viewer.
* I'm (intentionally) not doing an actual Format change in the first Save As dialog here. If I do select PNG as the format, then saving the file does work as expected (using any filename extension).
* I used .png just as an example here. Using any variant of /jpe?g/i as the extension seems to work as expected (i.e. the file is saved under the new name), whereas anything else (.gif, .foo etc.) results in the same "file missing" error as above.
* If the original file is a PNG file, saving it with .jpg (or any other extension for that matter) seems to work as expected (i.e the file is saved under the new name, with the now-incorrect extension).
(My original report at Launchpad: https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/1710641#. I tweaked some details for the report above, with Shotwell 0.27.4 currently in Bionic.)
Version: 0.27.xhttps://gitlab.gnome.org/GNOME/nautilus/-/issues/288directory content no more auto-refreshed automatically2019-08-19T22:35:23ZBaptiste Mille-Mathiasdirectory content no more auto-refreshed automaticallySince 3.26 at least the directory view is not refreshed when a file is created / renamed / ...
still present on 3.27.x
If I can provided any information, please ask.
regardsSince 3.26 at least the directory view is not refreshed when a file is created / renamed / ...
still present on 3.27.x
If I can provided any information, please ask.
regardshttps://gitlab.gnome.org/GNOME/totem/-/issues/239totem cannot play webm screencast video files in Wayland2023-01-12T03:25:34ZBugzillatotem cannot play webm screencast video files in Wayland## Submitted by Takao Fujiwara `@fujiwarat`
**[Link to original bug (#794193)](https://bugzilla.gnome.org/show_bug.cgi?id=794193)**
## Description
1. Type Ctrl-Shift-Alt-r in Wayland gnome-shell and start the screencast.
2. Type Ctr...## Submitted by Takao Fujiwara `@fujiwarat`
**[Link to original bug (#794193)](https://bugzilla.gnome.org/show_bug.cgi?id=794193)**
## Description
1. Type Ctrl-Shift-Alt-r in Wayland gnome-shell and start the screencast.
2. Type Ctrl-Shift-Alt-r again and stop the screencast.
3. Run totem $HOME/Videos/Screencast\ from \ $DATE.wbem
totem does not show any windows.
I play totem 3.26.0 in gnome-shell 3.27.91 Wayland in Fedora 28 in a VirtualBox guest.
I have no problem in Xorg gnome-shell.
Version: 3.26.xhttps://gitlab.gnome.org/GNOME/libdazzle/-/issues/10Object_animate is not introspectable2018-03-09T20:59:16ZRobert RothObject_animate is not introspectableI have seen that dazzle has nice property-based animations, and wanted to write a simple example to expand the "examples" directory with. Started with js, but found that object_animate is marked as `introspectable="0"` in the GIR. Is the...I have seen that dazzle has nice property-based animations, and wanted to write a simple example to expand the "examples" directory with. Started with js, but found that object_animate is marked as `introspectable="0"` in the GIR. Is there any special reason for that, can I help with something to make it introspectable and make it usable using gobject introspection, or should I simply use C?