GLib issueshttps://gitlab.gnome.org/GNOME/glib/-/issues2024-01-13T13:11:21Zhttps://gitlab.gnome.org/GNOME/glib/-/issues/3095Error handling of invalid GKeyFile string escape sequences changed in GLib 2....2024-01-13T13:11:21ZD3vil0p3rError handling of invalid GKeyFile string escape sequences changed in GLib 2.77.3I have the following .desktop file:
```
[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=SecLists
Comment=SecLists
Icon=kali-bettercap-128x128.png
Exec=kitty -e /usr/bin/bash -c "if test -d /usr/share/payloads/SecLists; then cd /usr/...I have the following .desktop file:
```
[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=SecLists
Comment=SecLists
Icon=kali-bettercap-128x128.png
Exec=kitty -e /usr/bin/bash -c "if test -d /usr/share/payloads/SecLists; then cd /usr/share/payloads/SecLists;bash;else echo \"SecLists not found. I'm retrieving it for you...\";sudo git clone https://github.com/danielmiessler/SecLists /usr/share/payloads/SecLists;cd /usr/share/payloads/SecLists;bash;fi;"
Terminal=false
Categories=Tags;Describing;Application
```
With the latest GNOME update, the system is not able to escape the \" near the echo command and the environment returns the message:
![image](/uploads/be19bb1fa464b541563e80555d0a57cd/image.png)
Please fix.2.78.0Philip WithnallPhilip Withnallhttps://gitlab.gnome.org/GNOME/glib/-/issues/3297GTK namespace in GLib errors ( GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark )2024-03-25T10:37:13ZSidGTK namespace in GLib errors ( GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark )It's odd to see the name `gtk` being mentioned in a console application (a.k.a command-line executable)
### Example:
```sh
$ pkcon offline-trigger
Command failed: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._pk_2dengine_2derror_2dqu...It's odd to see the name `gtk` being mentioned in a console application (a.k.a command-line executable)
### Example:
```sh
$ pkcon offline-trigger
Command failed: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._pk_2dengine_2derror_2dquark.Code1: Prepared update not found: /var/lib/PackageKit/prepared-update
```
Can we use a new namespace for GLib errors ?https://gitlab.gnome.org/GNOME/glib/-/issues/3285Install python packaging directly from meson2024-03-13T15:03:01ZUilian RiesInstall python packaging directly from mesonHello! When building GLib using a CI service, where this CI service is protected to changes and only can run the build steps, installing extra dependencies could be a real challenge.
Since GLib 2.79, the python package `packaging` is ma...Hello! When building GLib using a CI service, where this CI service is protected to changes and only can run the build steps, installing extra dependencies could be a real challenge.
Since GLib 2.79, the python package `packaging` is mandatory in case building the project with meson: https://gitlab.gnome.org/GNOME/glib/-/commit/e597b189c36651d83dd72dfdc8530682c80fc235#9f621eb5fd3bcb2fa5c7bd228c9b1ad42edc46c8_1_204
However, installing that package is really difficult for us due CI limitations. So, I would like to ask to meson be in charge of installing that package instead. Something like:
```meson
diff --git a/meson.build b/meson.build
index 7534542..180272d 100644
--- a/meson.build
+++ b/meson.build
@@ -2419,7 +2419,18 @@ endif
glib_conf.set('HAVE_PROC_SELF_CMDLINE', have_proc_self_cmdline)
+python = import('python')
+packaging_dep = python.find_installation('packaging', required: false)
+if not packaging_dep.found()
+ install_command = ['pip', 'install', 'packaging']
+ install_result = run_command(install_command, check: true, capture: true)
+ if install_result.returncode() != 0
+ error('Failed to install packaging library using pip')
+ endif
+endif
+
python = import('python').find_installation(modules: ['packaging'])
+
# used for '#!/usr/bin/env <name>'
python_name = 'python3'
```
First check if `packaging` is installed already, then install via pip in case negative. Yes, bit fragile because does not use the asked version of packaging, but can be improved.
I could open a merge request in case the maintainers agree in accepting this change.https://gitlab.gnome.org/GNOME/glib/-/issues/3283GUnixFDList looks like it is platform-specific, but it is not2024-03-16T01:32:06ZPhilip ChimentoGUnixFDList looks like it is platform-specific, but it is notUnlike all the other symbols starting with `GUnix` or `g_unix_`, GUnixFDList is not platform-specific. From the [documentation](https://docs.gtk.org/gio/class.UnixFDList.html):
> Before 2.74, `<gio/gunixfdlist.h>` belonged to the UNIX-s...Unlike all the other symbols starting with `GUnix` or `g_unix_`, GUnixFDList is not platform-specific. From the [documentation](https://docs.gtk.org/gio/class.UnixFDList.html):
> Before 2.74, `<gio/gunixfdlist.h>` belonged to the UNIX-specific GIO interfaces, thus you had to use the `gio-unix-2.0.pc` pkg-config file when using it.
>
> Since 2.74, the API is available for Windows.
Since 2.80 the platform-specific symbols are in a separate GioUnix introspection namespace, although they are also preserved in the original Gio namespace for backwards compatibility (see !3892.)
We'd like to encourage GJS users to migrate their code (see gjs!918.) This exception for GUnixFDList means that we can't easily document for users how to migrate, because the rule is not simply `Gio.UnixFoo` → `GioUnix.Foo`.
Is there anything to be done about this? If the answer is "no," then it is what it is, but in that case is GUnixFDList the only API for which an exception needs to be made?https://gitlab.gnome.org/GNOME/glib/-/issues/3178gobject: possible memory leak during finalize() due to freeze_notify()2023-11-28T00:36:43Z鑫 石gobject: possible memory leak during finalize() due to freeze_notify()Hello, I have just started using glib2 and I have encountered an issue now:
When user's finalize() does not use GObjectClass' g_object_finalize(), the memory allocated by freeze_notify() will not be released.
Here is my test:
+ test 01
...Hello, I have just started using glib2 and I have encountered an issue now:
When user's finalize() does not use GObjectClass' g_object_finalize(), the memory allocated by freeze_notify() will not be released.
Here is my test:
+ test 01
+ version: 2.72 (without patch [1ec331266ac5782223d3dafa6c9176eaeefcebae](https://gitlab.gnome.org/GNOME/glib/-/commit/1ec331266ac5782223d3dafa6c9176eaeefcebae))
+ result: normal
+ test 02
+ version: 2.72
+ result: memory leak
+ test file: [alpha.c](/uploads/a5dd74a71ebcd7e6e7da9fadc54e0dcd/alpha.c)
+ abnormal result:
```
~ #
~ # ps -ef | grep alpha
root 2536 2503 34 00:39 pts/1 00:00:04 ./alpha
root 2538 2511 0 00:40 pts/2 00:00:00 grep alpha
~ # pmap -x 2536 > time01.txt
~ # pmap -x 2536 > time02.txt
~ # diff -u time01.txt time02.txt
--- time01.txt
+++ time02.txt
@@ -3,7 +3,7 @@
000055556e8b6000 8 8 8 r-x-- alpha
000055556e8c7000 4 4 4 r---- alpha
000055556e8c8000 4 4 4 rw--- alpha
-000055557f10b000 664 636 636 rw--- [ anon ]
+000055557f10b000 864 772 772 rw--- [ anon ]
00007fff94f94000 32 32 32 r-x-- libffi.so.8.1.0
00007fff94f9c000 60 0 0 ----- libffi.so.8.1.0
00007fff94fab000 4 4 4 r---- libffi.so.8.1.0
@@ -39,4 +39,4 @@
00007fff954e9000 8 8 8 rw--- ld-linux-aarch64.so.1
00007fffc6324000 132 24 24 rw--- [ stack ]
---------------- ------- ------- -------
-total kB 5320 3604 3600
+total kB 5520 3740 3736
```https://gitlab.gnome.org/GNOME/glib/-/issues/3166Gdbus message type checking error.2023-11-03T11:46:52ZGauravGdbus message type checking error.```
GDBusMessage *
g_dbus_message_new_method_error_literal (GDBusMessage *method_call_message,
const gchar *error_name,
const gchar *error_message)
{
...```
GDBusMessage *
g_dbus_message_new_method_error_literal (GDBusMessage *method_call_message,
const gchar *error_name,
const gchar *error_message)
{
GDBusMessage *message;
const gchar *sender;
g_return_val_if_fail (G_IS_DBUS_MESSAGE (method_call_message), NULL);
g_return_val_if_fail (g_dbus_message_get_message_type (method_call_message) == G_DBUS_MESSAGE_TYPE_METHOD_CALL, NULL);
```
The above method could be called during error reply also like g_dbus_method_invocation_return_dbus_error.
So, type can be G_DBUS_MESSAGE_TYPE_METHOD_RETURN or G_DBUS_MESSAGE_TYPE_ERROR ?https://gitlab.gnome.org/GNOME/glib/-/issues/3150g_dbus_proxy_new_for_bus_sync should return appropriate values2023-10-19T15:26:07Zmouseg_dbus_proxy_new_for_bus_sync should return appropriate values```NULL``` should be returned when the ```Dbus``` interface does not exist
C test code
```
#include <gtk/gtk.h>
int main(int argc, char *argv[])
{
gtk_init (&argc, &argv);
g_autoptr(GDBusProxy) proxy = NULL;
g_autoptr (GEr...```NULL``` should be returned when the ```Dbus``` interface does not exist
C test code
```
#include <gtk/gtk.h>
int main(int argc, char *argv[])
{
gtk_init (&argc, &argv);
g_autoptr(GDBusProxy) proxy = NULL;
g_autoptr (GError) error = NULL;
proxy = g_dbus_proxy_new_for_bus_sync (G_BUS_TYPE_SYSTEM,
G_DBUS_PROXY_FLAGS_DO_NOT_LOAD_PROPERTIES |
G_DBUS_PROXY_FLAGS_DO_NOT_CONNECT_SIGNALS |
G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START,
NULL,
"a.b.c",
"/a/b/c",
"a.b.c",
NULL,
&error);
if (proxy == NULL)
{
g_print ("g_dbus_proxy_new_for_bus_sync is error:%s \n", error->message);
}
gtk_main ();
return 0;
}
```
No matter whether the ```Dbus``` interface name exists or not, it will not return ```NULL```https://gitlab.gnome.org/GNOME/glib/-/issues/3147timer reference count differs when removing a timer with G_SOURCE_REMOVE or g...2023-10-20T14:56:27ZNorbert van Bolhuistimer reference count differs when removing a timer with G_SOURCE_REMOVE or g_source_removeIf a timer (created and started with g_timeout_source_new, g_source_set_callback and g_source_attach) ends by returning G_SOURCE_REMOVE from the callback function the GDestroyNotify function is called with a timer reference count of 3 (+...If a timer (created and started with g_timeout_source_new, g_source_set_callback and g_source_attach) ends by returning G_SOURCE_REMOVE from the callback function the GDestroyNotify function is called with a timer reference count of 3 (+1 for timer itself, +1 for timeout callback, +1 for attachment to main context).
If a timer (created and started with g_timeout_source_new, g_source_set_callback and g_source_attach) ends by stopping it with g_source_remove the callback function the GDestroyNotify function is called with a timer reference count of 2 (+1 for timer itself, +1 for attachment to main context).
This is confusing regarding whether to call g_source_unref in the GDestroyNotify function. It looks like g_source_unref is not necessary in both cases, but I'm not sure and this is not clear from the documentation.
I'll attach a simple case that shows the issue. The question is: is line 40 needed, in other words: is it needed to do g_source_unref in the "G_SOURCE_REMOVE" case? and, if no, where is this documented?
Btw. the use-case is a dynamic repetitive adaptive timer. The timer needs to be restarted (with possibly a new interval) since it is repetitive and adaptive. In other cases the timer needs to be stopped and restarted (e.g. due to external/other states).https://gitlab.gnome.org/GNOME/glib/-/issues/3139Text files are considered as "application/octet-stream"2023-10-14T21:00:27ZSidText files are considered as "application/octet-stream"```
(gdb) call (int) g_content_type_is_a ("text/plain", "application/octet-stream")
$5 = 1
``````
(gdb) call (int) g_content_type_is_a ("text/plain", "application/octet-stream")
$5 = 1
```https://gitlab.gnome.org/GNOME/glib/-/issues/3094bugreport: regex escape2024-01-13T09:03:38ZGitLab Support Botbugreport: regex escapeHi
I think have found a bug while using Midnight Commander's extension/file
matching feature.
It seems that the glib 2.76.4->2.76.5 upgrade broke a
regex-filematching. (Same goes for 2.77.2->2.77.3)
Example:
mc.ext.ini:
[something]
...Hi
I think have found a bug while using Midnight Commander's extension/file
matching feature.
It seems that the glib 2.76.4->2.76.5 upgrade broke a
regex-filematching. (Same goes for 2.77.2->2.77.3)
Example:
mc.ext.ini:
[something]
Regex=\.my_extension$
Open=echo "opening: " %f
This does not match anymore for asdf.my_extension. The problem is the "\.".
git bisect points me to these commits on both minor versions:
2.76.4->5: 3fd1b6345 2023-08-29 15:32:27 +0200 | gkeyfile: Fix
overwriting of GError
2.77.2->3: 71b7efd08 2023-08-29 15:32:27 +0200 | gkeyfile: Fix
overwriting of GError
On first glance it has something to do with backslashes, but it might be
a midnight commander bug after all.
core/glibc 2.38-3
extra/mc 4.8.30-1
core/linux 6.4.12.arch1-1
Br,
Tibor2.78.0https://gitlab.gnome.org/GNOME/glib/-/issues/3078Regression in GKeyFile top comment handling2023-08-31T10:20:33ZDavid BremnerRegression in GKeyFile top comment handlingAs can be seen with the attached sample (at least in my tests on Debian testing), certain sequences of updates cause the top-of-file comment to be lost. This behaviour seems to be new as of release 2.77.1. I'd hazard it was the related G...As can be seen with the attached sample (at least in my tests on Debian testing), certain sequences of updates cause the top-of-file comment to be lost. This behaviour seems to be new as of release 2.77.1. I'd hazard it was the related GKeyFile changes, but I didn't have a chance to bisect.
[kfile.c](/uploads/bdf13be0a4d9d8af6af5452f7a6f6d09/kfile.c)2.77.3https://gitlab.gnome.org/GNOME/glib/-/issues/2803g_variant_builder_add leaks variant builder and type in case of error2022-11-03T10:34:28ZJens Georgg_variant_builder_add leaks variant builder and type in case of errorThis is probably minor, I just noticed it while debugging something else:
Example:
```c
#include <glib.h>
int main(int argc, char **argv) {
g_auto(GVariantBuilder) vb = G_VARIANT_BUILDER_INIT(G_VARIANT_TYPE("a{sv}"));
g_varian...This is probably minor, I just noticed it while debugging something else:
Example:
```c
#include <glib.h>
int main(int argc, char **argv) {
g_auto(GVariantBuilder) vb = G_VARIANT_BUILDER_INIT(G_VARIANT_TYPE("a{sv}"));
g_variant_builder_add(&vb, "{sv}", "key", NULL);
GVariant *v = g_variant_ref_sink(g_variant_builder_end(&vb));
g_variant_unref(v);
return 0;
}
```
Valgrind report:
```
==257148== 5 bytes in 1 blocks are definitely lost in loss record 6 of 21
==257148== at 0x484586F: malloc (vg_replace_malloc.c:381)
==257148== by 0x48C2911: g_malloc (gmem.c:130)
==257148== by 0x491D99F: g_variant_type_copy (gvarianttype.c:400)
==257148== by 0x490E221: g_variant_builder_init (gvariant.c:3424)
==257148== by 0x491166E: g_variant_valist_new (gvariant.c:5277)
==257148== by 0x4911AF8: g_variant_new_va (gvariant.c:5458)
==257148== by 0x4911E0B: g_variant_builder_add (gvariant.c:5615)
==257148== by 0x4011FF: main (in /home/jens/b)
==257148==
==257148== 108 (16 direct, 92 indirect) bytes in 1 blocks are definitely lost in loss record 19 of 21
==257148== at 0x484A464: calloc (vg_replace_malloc.c:1328)
==257148== by 0x48C2984: g_malloc0 (gmem.c:163)
==257148== by 0x48C2C6B: g_malloc0_n (gmem.c:404)
==257148== by 0x490E4B1: g_variant_builder_init (gvariant.c:3493)
==257148== by 0x491166E: g_variant_valist_new (gvariant.c:5277)
==257148== by 0x4911AF8: g_variant_new_va (gvariant.c:5458)
==257148== by 0x4911E0B: g_variant_builder_add (gvariant.c:5615)
==257148== by 0x4011FF: main (in /home/jens/b)
```https://gitlab.gnome.org/GNOME/glib/-/issues/2738Unnecessarily wasteful padding between lines of output at terminal.2022-10-11T20:35:50Z`{third: "Beedell", first: "Roke"}`{.JSON5}suybnd6r@rokejulianlockhart.addy.ioUnnecessarily wasteful padding between lines of output at terminal.When invoking [czkawka](https://flathub.org/apps/details/com.github.qarmin.czkawka),
```
(czkawka_gui:2): GLib-GIO-CRITICAL **: 16:18:32.451: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (obje...When invoking [czkawka](https://flathub.org/apps/details/com.github.qarmin.czkawka),
```
(czkawka_gui:2): GLib-GIO-CRITICAL **: 16:18:32.451: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
(czkawka_gui:2): GLib-GIO-CRITICAL **: 16:18:32.451: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
(czkawka_gui:2): GLib-GIO-CRITICAL **: 16:18:32.452: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
(czkawka_gui:2): GLib-GIO-CRITICAL **: 16:18:32.452: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
(czkawka_gui:2): GLib-GIO-CRITICAL **: 16:18:32.452: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
(czkawka_gui:2): GLib-GIO-CRITICAL **: 16:18:32.452: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
(czkawka_gui:2): GLib-GIO-CRITICAL **: 16:18:32.452: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
(czkawka_gui:2): GLib-GIO-CRITICAL **: 16:18:32.452: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
(czkawka_gui:2): GLib-GIO-CRITICAL **: 16:18:32.452: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
(czkawka_gui:2): GLib-GIO-CRITICAL **: 16:18:32.454: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
(czkawka_gui:2): Gtk-CRITICAL **: 16:18:32.457: Unable to register the application: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer: unit failed.
```
appears, whereas it should be
```
(czkawka_gui:2): GLib-GIO-CRITICAL **: 16:18:32.451: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
(czkawka_gui:2): GLib-GIO-CRITICAL **: 16:18:32.451: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
(czkawka_gui:2): GLib-GIO-CRITICAL **: 16:18:32.452: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
(czkawka_gui:2): GLib-GIO-CRITICAL **: 16:18:32.452: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
(czkawka_gui:2): GLib-GIO-CRITICAL **: 16:18:32.452: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
(czkawka_gui:2): GLib-GIO-CRITICAL **: 16:18:32.452: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
(czkawka_gui:2): GLib-GIO-CRITICAL **: 16:18:32.452: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
(czkawka_gui:2): GLib-GIO-CRITICAL **: 16:18:32.452: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
(czkawka_gui:2): GLib-GIO-CRITICAL **: 16:18:32.452: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
(czkawka_gui:2): GLib-GIO-CRITICAL **: 16:18:32.454: g_dbus_connection_emit_signal: assertion 'object_path != NULL && g_variant_is_object_path (object_path)' failed
(czkawka_gui:2): Gtk-CRITICAL **: 16:18:32.457: Unable to register the application: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer: unit failed.
```
because the 2nd version is more easy to parse/read, and utilizes less space without any disadvantage.https://gitlab.gnome.org/GNOME/glib/-/issues/2722Epiphany ignores /etc/hosts and /etc/hostname on Pinephone / Mobian2022-08-20T22:50:37ZJean Luc BIELLMANNEpiphany ignores /etc/hosts and /etc/hostname on Pinephone / MobianI currently writing several webapps on the Pinephone using the last version of Mobian.
On the server side, i use a self-signed certificate to handle my websocket in wss://mobian:2020, using Node.js.
On the client side, my webapps are al...I currently writing several webapps on the Pinephone using the last version of Mobian.
On the server side, i use a self-signed certificate to handle my websocket in wss://mobian:2020, using Node.js.
On the client side, my webapps are all running ok with Firefox, using the URLs "https://mobian/app" or "https://mobian.local/app".
When the Pinephone is connected using an external RJ45 adapter, Epiphany find my webapps too, using "https://mobian/app" or "https://mobian.local/app".
BUT when the Pinephone is disconnected of any networks (neither WiFi not BT, xG, RJ45), Epiphany fail to find the "mobian" and "mobian.local" hostnames, with "Error resolving "mobian": Name or service unknown".
Ok for the "mobian.local" : it's a zeroconf/bonjour hostname.
But for "mobian" alone, Epiphany should find the host without troubles...
And of course, i checked that "mobian" is present in /etc/hostname, and i even tried to add it in /etc/hosts on 127.0.0.1 - same result. When the phone is disconnected.
Whith phone still disconnected, i use a terminal to ping "mobian" host, i get 127.0.0.2, which is ok for Firefox.
So it seems that your browser simply ignores to check /etc/hosts and /etc/hostname, which is very annoying in my case, while developping webapps which should work with and without external networks.
Another trouble, with no links with this bug (i don't want to open an external bug report for that) is that Epiphany doesn't record the access to the websocket one for all (https://mobian:2020 in my case). I just mention it here so you can perhaps tell your team that this behaviour is especially annoying for people like me, trying to simplify the access for non-powered users. Thanks in advance. And thanks for your browser.https://gitlab.gnome.org/GNOME/glib/-/issues/2396gio mount nfs fails/ nautilus fails to connect to NFSv4 share2021-05-03T10:15:44ZMorgangio mount nfs fails/ nautilus fails to connect to NFSv4 share<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/master/CONTRIBUTING.md
-->
## Steps to reproduce
<!--
Please, explain the sequence of actions necessary to reproduce...<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/master/CONTRIBUTING.md
-->
## Steps to reproduce
<!--
Please, explain the sequence of actions necessary to reproduce the
bug
-->
1. set up nfs share so that it mounts with, for example:
`$ sudo mount frontserver.lan:/mnt/RAID1-699GiB/nfs-share /mnt/nfs-share`
2. then try, for example:
`$ gio mount nfs://frontserver.lan/mnt/RAID1-699GiB/nfs-share`
`gio: nfs://frontserver.lan/mnt/RAID1-699GiB/nfs-share: Mount point does not exist`
3. enter 'nfs://frontserver.lan/mnt/RAID1-699GiB/nfs-share' in the nautilus 'Other Locations' 'Connect to Server' field and receive '"Unable to access location" "Mount point does not exist" "Close"' error dialogue.
<!--
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
<!--
Please describe the current behaviour
-->
Opening nfs shares via gvfs/ gio fails
## Expected outcome
<!--
Please describe the expected outcome
-->
Opening nfs shares via gvfs/ gio succeeds
## Version information
<!--
- 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
-->
$ uname -a
Linux mymachine 4.19.0-16-amd64 gtk#1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux
Debian Stable
$ sudo apt install libgtk-3-0
Reading package lists... Done
Building dependency tree
Reading state information... Done
libgtk-3-0 is already the newest version (3.24.5-1).
...
## Additional information
<!--
- 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
-->
This seems the same as this bug, gtk#1476 - but that bug was closed 2 years ago...https://gitlab.gnome.org/GNOME/glib/-/issues/2131GThreadPool thread-spawning thread breaks GThreadPool usage across fork()2020-08-25T11:06:17ZSebastian DrögeGThreadPool thread-spawning thread breaks GThreadPool usage across fork()[This is only here for informational reasons and so we have it documented as a known issue and can link to here]
Since 2.64 `GThreadPool` is using a thread for spawning new threads on non-exclusive, shared thread pools to make sure that...[This is only here for informational reasons and so we have it documented as a known issue and can link to here]
Since 2.64 `GThreadPool` is using a thread for spawning new threads on non-exclusive, shared thread pools to make sure that all threads in the pool have the same thread settings (especially priority-related) and do not accidentally inherit these from where a new task was pushed on the thread pool. Inheriting can be dangerous as it might cause real-time priorities to be inherited and then such a thread can also be used in one of the other non-exclusive, shared thread pools.
This new thread is [created](https://gitlab.gnome.org/GNOME/glib/-/blob/a2e215663cf66a999b354387b07eff97ed546c7f/glib/gthreadpool.c#L606-618) on the first creation of a non-exclusive, shared thread pool and only created if there is no special system support for setting thread properties correctly.
So much for the background. This new thread has the side-effect that it's now not possible anymore to use `fork()` or similar API after a non-exclusive, shared thread pool is created. The child process would have everything initialized like the parent process but the thread would not actually run, so trying to run anything on the thread pool would simply deadlock forever.
This is not a new problem and also applies e.g. to the `gmain.c` worker thread or the `GDbus` background thread, however it's a new problem people were actually running into after updating GLib to 2.64 (see [[1]](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/531)).
This also can't safely be worked around with tools like `pthread_atfork()` as we can't know in the callbacks what the current state of the application is, especially with regards to mutexes being locked. Also we can't print a warning on fork there because that would also trigger if a new process is started (one of the `exec()` functions after `fork()`).
Generally it's unsafe to use `fork()` in GLib applications and this was documented since a long time, there's now just another case that can cause problems.https://gitlab.gnome.org/GNOME/glib/-/issues/2086With or without padding g_base64_decode different results2023-02-10T16:17:31ZDhiogo BozaWith or without padding g_base64_decode different results## Description
The `g_base64_decode` function is returning different results for the base64 string "YW" with or without padding:
- Calling `g_base64_decode("YW==")` returns "a"
- Calling `g_base64_decode("YW")` returns ""
## System inf...## Description
The `g_base64_decode` function is returning different results for the base64 string "YW" with or without padding:
- Calling `g_base64_decode("YW==")` returns "a"
- Calling `g_base64_decode("YW")` returns ""
## System information
- Glib version: 2.56.4
- System: Ubuntu 18.04.4https://gitlab.gnome.org/GNOME/glib/-/issues/1689symlink on read-only NFS share redirects homedirectory -- prevents thunar to ...2019-05-15T05:41:39ZRené Genzsymlink on read-only NFS share redirects homedirectory -- prevents thunar to paste to homedirectoryThis is a bug report coming from downstream Xfce Thunar: https://bugzilla.xfce.org/show_bug.cgi?id=14718
Andre Miranda asked me to report the issue here. He is almost sure it's a GLib issue, because GLib is wrongly reporting the home d...This is a bug report coming from downstream Xfce Thunar: https://bugzilla.xfce.org/show_bug.cgi?id=14718
Andre Miranda asked me to report the issue here. He is almost sure it's a GLib issue, because GLib is wrongly reporting the home directory to be read-only.
**Required environment**
USER's home directory:
* is served over NFS
* is a symlink
The symlink is located on a share of one server. This share is mounted read-only to USER's computer. The symlink points to a different local path with another symlink. That symlink can point to a different server.
**Information about environment**
I can reproduce the problem with Fedora 28 (and 29) x86_64 with this GLibc version:
$ rpm -q glibc
glibc-2.27-37.fc28.x86_64
**The problem**
Copy-pasting a file with content from the Desktop to the USER's home directory is denied with error message: "The destination is read-only."
A guide to reproduce the problem step-by-step is available: https://bugzilla.xfce.org/show_bug.cgi?id=14718#c5
I am happy to test and help. Thank you for your help.