GLib issueshttps://gitlab.gnome.org/GNOME/glib/-/issues2024-03-28T10:16:44Zhttps://gitlab.gnome.org/GNOME/glib/-/issues/3305GFileEnumerator takes much longer to list PNG files or files with unrecognize...2024-03-28T10:16:44ZGaël BonithonGFileEnumerator takes much longer to list PNG files or files with unrecognized extensionsI noticed this when trying to open my thumbnails directory `~/.cache/thumbnails/normal` in ristretto, Xfce's image viewer, which uses GFileEnumerator. This took a long time, whereas I knew ristretto could open directories containing 10,0...I noticed this when trying to open my thumbnails directory `~/.cache/thumbnails/normal` in ristretto, Xfce's image viewer, which uses GFileEnumerator. This took a long time, whereas I knew ristretto could open directories containing 10,000 to 20,000 images in a few seconds.
So I copied 10,000 thumbnails into a test directory and used this reproducer to run a few tests:
```c
#define N_FILES 100
#define N_ITERS 10
GTimer *timer;
GMainLoop *loop;
gint iters;
static void
next_files_finish (GObject *source_object,
GAsyncResult *res,
gpointer user_data)
{
GFileEnumerator *enumerator = G_FILE_ENUMERATOR (source_object);
GList *infos = g_file_enumerator_next_files_finish (enumerator, res, NULL);
g_printerr ("%.2f ms\n", g_timer_elapsed (timer, NULL) * 1000);
g_timer_reset (timer);
if (infos == NULL || ++iters >= N_ITERS)
{
g_object_unref (enumerator);
g_main_loop_quit (loop);
return;
}
g_list_free_full (infos, g_object_unref);
g_file_enumerator_next_files_async (enumerator, N_FILES, G_PRIORITY_DEFAULT, NULL, next_files_finish, NULL);
}
static void
enumerate_children_finish (GObject *dir,
GAsyncResult *res,
gpointer user_data)
{
GFileEnumerator *enumerator = g_file_enumerate_children_finish (G_FILE (dir), res, NULL);
if (enumerator == NULL)
{
g_main_loop_quit (loop);
return;
}
g_file_enumerator_next_files_async (enumerator, N_FILES, G_PRIORITY_DEFAULT, NULL, next_files_finish, NULL);
}
gint main (gint argc, gchar **argv)
{
GFile *file = g_file_new_for_path ("/home/user/td");
loop = g_main_loop_new (NULL, FALSE);
timer = g_timer_new ();
g_file_enumerate_children_async (file, "standard::name,standard::content-type",
G_FILE_QUERY_INFO_NONE, G_PRIORITY_DEFAULT, NULL,
enumerate_children_finish, NULL);
g_main_loop_run (loop);
g_main_loop_unref (loop);
g_object_unref (file);
g_timer_destroy (timer);
}
```
With the constants defined above, it lists 1,000 files in blocks of 100 and displays the time taken for each block. Here's what it does for me with the thumbnails left as they are, i.e. with the extension `.png`:
```
$ echo 1 | sudo tee /proc/sys/vm/drop_caches && ~/p
895.36 ms
638.79 ms
744.88 ms
585.45 ms
566.91 ms
597.58 ms
561.13 ms
724.62 ms
629.97 ms
707.85 ms
```
And here's what it looks like renaming all thumbnails to `.jpg`:
```
$ rename .png .jpg ~/td/*
$ echo 1 | sudo tee /proc/sys/vm/drop_caches && ~/p
322.37 ms
16.88 ms
13.37 ms
22.03 ms
17.92 ms
25.42 ms
34.72 ms
16.31 ms
10.55 ms
8.59 ms
```
So I tried a few other extensions without finding the same PNG times, except by setting an unknown extension, for example `.xxx`:
```
$ rename .jpg .xxx ~/td/*
$ echo 1 | sudo tee /proc/sys/vm/drop_caches && ~/p
608.39 ms
715.27 ms
553.15 ms
602.00 ms
538.21 ms
481.52 ms
589.34 ms
509.56 ms
460.72 ms
784.75 ms
```
Perhaps it's normal for the processing time to vary a little depending on the file extension, but is it normal for it to vary so much?
GLib 2.80.0 on Arch Linuxhttps://gitlab.gnome.org/GNOME/glib/-/issues/3304[CI] Pipeline on 'main' failed for commit 0888d8d52024-03-26T10:44:31ZGLib Issue BOT[CI] Pipeline on 'main' failed for commit 0888d8d5
## Summary
Pipeline [658396](https://gitlab.gnome.org/GNOME/glib/-/pipelines/658396) on 'main' failed for commit 0888d8d5.
Failed job(s):
- [valgrind](https://gitlab.gnome.org/GNOME/glib/-/jobs/3728839)
- [G_DISABLE_ASSERT](https://gi...
## Summary
Pipeline [658396](https://gitlab.gnome.org/GNOME/glib/-/pipelines/658396) on 'main' failed for commit 0888d8d5.
Failed job(s):
- [valgrind](https://gitlab.gnome.org/GNOME/glib/-/jobs/3728839)
- [G_DISABLE_ASSERT](https://gitlab.gnome.org/GNOME/glib/-/jobs/3728827)
## Instructions
Please create a new issue (or multiple issues) and link
them to this issue.
Tip: you can create a related issue directly by clicking
the vertical ellipsis in the top right hand corner of this issue
and clicking "New related issue". See the documentation on
[managing issues](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#from-another-issue-or-incident)
for more information.
When investigation begins, update the label to ~"pipeline failure::under investigation".
-----
_Created by [issue-bot](https://gitlab.com/gitlab-org/distribution/issue-bot) via [this job](https://gitlab.gnome.org/GNOME/glib/-/jobs/3728843)._https://gitlab.gnome.org/GNOME/glib/-/issues/3302TRUE, FALSE and math macros are no longer documented with gi-docgen2024-03-25T18:59:46ZMichael WebsterTRUE, FALSE and math macros are no longer documented with gi-docgenAffects TRUE, FALSE, MAX, MIN, ABS, CLAMP.
I didn't perform an exhaustive check of other macros, though I did test a few additional ones in gmacros.h and they seemed ok.
I'm not sure if maybe the `#undef/#ifndef` directives are confusi...Affects TRUE, FALSE, MAX, MIN, ABS, CLAMP.
I didn't perform an exhaustive check of other macros, though I did test a few additional ones in gmacros.h and they seemed ok.
I'm not sure if maybe the `#undef/#ifndef` directives are confusing it there.
Thanks!https://gitlab.gnome.org/GNOME/glib/-/issues/3301consider glib development binaries usable without external python modules2024-03-28T07:03:21ZLuis Caro Camposconsider glib development binaries usable without external python moduleshttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/3740 and https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3752 introduced a dependency on a Python module that is not part of a standard/minimal python3 interpreter. This introduce...https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3740 and https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3752 introduced a dependency on a Python module that is not part of a standard/minimal python3 interpreter. This introduces a dependency both at glib build time, but also a runtime dependency for users that need to run `gdbus-codegen`
The `gdbus-codegen` script has a shebang that is typically `#!/usr/bin/env python3`. Even if the dependency on the `packaging` python module is handled by a package manager, leaving it to use an interpreter from the environment does *not* guarantee that the interpreter will be able to resolve the dependency, for example is the user is invoking this utility with an arbitrary python3 virtual environment activated on their shell, where `packaging` is not installed. Distro maintainers will have to patch the shebang to point to the distro-managed python distribution, e.g. Debian/Ubuntu have this as `/usr/bin/python3`, but others may not (examples: homebrew, msys2).
Prior to the changes, which were motivated by Python 3.12 removing `distutils` - the `gdbus-codegen` was mostly self contained, and it was overwhelmingly likely that any minimal python3 distribution would run the script. Now it requires an "external" python module, complicating the package distribution story, as `gdbus-codegen` is now dependent not only on a Python 3 interpreter, but on a python distribution with additional dependencies.
I would consider some options to mitigate this - such as using distutils for Python interpreters < 3.12 (which does not solve the problem completely), or implementing/vendoring in code with the required functionality: it appears only a small slice of `packaging` is required for this.
From https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3976#note_2062035 and https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3976#note_20621652.82https://gitlab.gnome.org/GNOME/glib/-/issues/3300since2024-03-25T12:09:07ZericLemanissiersincehttps://gitlab.gnome.org/GNOME/glib/-/issues/3299gdbus-codegen: Warning: Lfb: Couldn't find 'X_finish' for the corresponding a...2024-03-25T11:27:01ZDark Dragongdbus-codegen: Warning: Lfb: Couldn't find 'X_finish' for the corresponding async function: 'X'The [gnome meson module](https://mesonbuild.com/Gnome-module.html) version used in the GNOME 46 Flatpak runtime (I was told it's `1.3.0`), produces the following warning:
```
data/lfb-gdbus.h:171: Warning: Lfb: Couldn't find 'new_finish'...The [gnome meson module](https://mesonbuild.com/Gnome-module.html) version used in the GNOME 46 Flatpak runtime (I was told it's `1.3.0`), produces the following warning:
```
data/lfb-gdbus.h:171: Warning: Lfb: Couldn't find 'new_finish' for the corresponding async function: 'new'
data/lfb-gdbus.h:190: Warning: Lfb: Couldn't find 'new_for_bus_finish' for the corresponding async function: 'new_for_bus'
```
The code is produced via the following Meson snippet ([source](https://source.puri.sm/Librem5/feedbackd/-/blob/7588ecab91b509861c5b12af3d258dc8dcf9c9d5/data/meson.build#L9-L16)):
```
gnome = import('gnome')
generated_dbus_sources += gnome.gdbus_codegen('lfb-gdbus',
sources : dbus_interfaces,
object_manager : false,
docbook : 'libfeedback',
interface_prefix : prefix,
install_header : true,
install_dir : join_paths(get_option('includedir'), libname),
namespace : namespace)
```
As warnings are treated as errors in this project, the build fails.
Reference
- PR: https://github.com/flathub/org.gnome.Calls/pull/221
- Build log: https://buildbot.flathub.org/#/builders/6/builds/109595https://gitlab.gnome.org/GNOME/glib/-/issues/3298glib-compile-resources crashes on Linux 4.9.3372024-03-25T10:56:09ZMarcus Comstedtglib-compile-resources crashes on Linux 4.9.337When trying to build software using glib resources, like VTE, I get a crash in glib-compile-resources like the following:
```
[92/207] /usr/bin/glib-compile-resources ../vte-0.74.2/src/app/app-gtk3.gresource.xml --sourcedir src/app --so...When trying to build software using glib resources, like VTE, I get a crash in glib-compile-resources like the following:
```
[92/207] /usr/bin/glib-compile-resources ../vte-0.74.2/src/app/app-gtk3.gresource.xml --sourcedir src/app --sourcedir ../vte-0.74.2/src/app --c-name app --internal --generate --target src/app/resources-gtk3.cc.c --dependency-file src/app/resources-gtk3.cc.c.d
FAILED: src/app/resources-gtk3.cc.c
/usr/bin/glib-compile-resources ../vte-0.74.2/src/app/app-gtk3.gresource.xml --sourcedir src/app --sourcedir ../vte-0.74.2/src/app --c-name app --internal --generate --target src/app/resources-gtk3.cc.c --dependency-file src/app/resources-gtk3.cc.c.d
(glib-compile-resources:303): GLib-WARNING **: 09:46:19.731: ../glib-2.78.3/glib/gmain.c:5934: waitid(pid:304, pidfd=4) failed: Invalid argument (22). See documentation of g_child_watch_source_new() for possible causes.
../vte-0.74.2/src/app/app-gtk3.gresource.xml: Child process exited abnormally.
```
If I downgrade to glib 2.76.4, then everything works fine.
I traced the issue to commit f615eef4bafaa2fbe11530c0f66f7d28a28a58a9. Apparently this pidfd solution does not work on 4.9.337, which I suppose is expected since the commit message talks about >=5.3. The problem is that the selection of implementation is done compile-time using the cpp symbol `HAVE_PIDFD`, which is set by the following `meson.build` code:
```
if cc.links('''#include <sys/syscall.h>
#include <sys/wait.h>
#include <linux/wait.h>
#include <unistd.h>
int main (int argc, char ** argv) {
siginfo_t child_info = { 0, };
syscall (SYS_pidfd_open, 0, 0);
waitid (P_PIDFD, 0, &child_info, WEXITED | WNOHANG);
return 0;
}''', name : 'pidfd_open(2) system call')
glib_conf.set('HAVE_PIDFD', 1)
endif
```
So this only checks that the code can be compiled, not that it actually works on the system. And even if this was a `cc.run`, there would still be a problem with the choice being made compile time if the resulting binary was moved to a different system with a different kernel version. For this to be portable between kernel versions there would have to be some sort of runtime check.https://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/3296ImportError: DLL load failed while importing _giscanner2024-03-27T11:46:57ZDan YeawImportError: DLL load failed while importing _giscannerOn Windows, I am trying to build GLib with introspection by first building it with it disabled, then building gobject-introspection, and then again with it enabled per https://docs.gtk.org/glib/building.html. I am getting `ImportError: D...On Windows, I am trying to build GLib with introspection by first building it with it disabled, then building gobject-introspection, and then again with it enabled per https://docs.gtk.org/glib/building.html. I am getting `ImportError: DLL load failed while importing _giscanner: The specified module could not be found.` when trying to build the GLib-2.0.gir file.
```
[467/675] Generating girepository/introspection/GLib-2.0.gir with a custom command (wrapped by meson to set PATH, to set env)
FAILED: girepository/introspection/GLib-2.0.gir
"C:\gtk-build\github\gvsbuild\.venv\Scripts\python.exe" "C:\gtk-build\tools\meson-1.4.0\meson.py" "--internal" "exe" "--unpickle" "C:\gtk-build\build\x64\release\glib\_gvsbuild-meson\meson-private\meson_exe_python.exe_fb9f7d4990021cc3865e2ec61e1ed1f934359b15.dat"
while executing ['C:\\gtk-build\\github\\gvsbuild\\.venv\\Scripts\\python.exe', 'C:/gtk-build/gtk/x64/release/bin/../bin/g-ir-scanner', '--quiet', '--no-libto
ol', '--namespace=GLib', '--nsversion=2.0', '--warn-all', '--output', 'girepository/introspection/GLib-2.0.gir', '--c-include=glib.h', '--quiet', '-DGLIB_COMP
ILATION', '-DGETTEXT_PACKAGE="dummy"', '--symbol-prefix=glib', '--library-path=C:/gtk-build/build/x64/release/glib/_gvsbuild-meson/girepository/introspection'
, '--library=gobject-2.0', '-IC:/gtk-build/build/x64/release/glib/girepository/introspection', '-IC:/gtk-build/build/x64/release/glib/_gvsbuild-meson/gireposi
tory/introspection', '-IC:/gtk-build/build/x64/release/glib/.', '-IC:/gtk-build/build/x64/release/glib/_gvsbuild-meson/.', '--filelist=C:/gtk-build/build/x64/
release/glib/_gvsbuild-meson/glib/glib-2.0-0.dll.p/GLib_2.0_gir_filelist', '--symbol-prefix=g', '--identifier-prefix=G', '--pkg-export=glib-2.0', '--cflags-be
gin', '-D_GNU_SOURCE', '-DUNICODE', '-D_UNICODE', '-DG_DISABLE_CAST_CHECKS', '-IC:/gtk-build/build/x64/release/glib/.', '-IC:/gtk-build/build/x64/release/glib
/_gvsbuild-meson/.', '-IC:/gtk-build/gtk/x64/release/bin/../include', '-IC:/gtk-build/build/x64/release/glib/gobject', '-IC:/gtk-build/build/x64/release/glib/
_gvsbuild-meson/gobject', '-IC:/gtk-build/build/x64/release/glib/glib', '-IC:/gtk-build/build/x64/release/glib/_gvsbuild-meson/glib', '-IC:/gtk-build/gtk/x64/
release/bin/../include/gobject-introspection-1.0', '-IC:/gtk-build/gtk/x64/release/bin/../include/glib-2.0', '-IC:/gtk-build/gtk/x64/release/bin/../lib/glib-2
.0/include', '--cflags-end', '--add-include-path=C:/gtk-build/gtk/x64/release/bin/../share/gir-1.0', '-LC:/gtk-build/build/x64/release/glib/_gvsbuild-meson/go
bject', '-LC:/gtk-build/build/x64/release/glib/_gvsbuild-meson/glib', '-LC:/gtk-build/gtk/x64/release/bin/../lib', '--extra-library=gobject-2.0', '--extra-lib
rary=glib-2.0', '-LC:/gtk-build/build/x64/release/glib/_gvsbuild-meson/glib', '--library', 'glib-2.0', '-LC:/gtk-build/gtk/x64/release/bin/../lib', '--extra-l
ibrary=intl', '-LC:/gtk-build/gtk/x64/release/bin/../lib', '--extra-library=pcre2-8', '--extra-library=ws2_32', '--extra-library=winmm', '--extra-library=ffi'
, '--extra-library=girepository-1.0', '--extra-library=gobject-2.0', '--extra-library=glib-2.0', '--sources-top-dirs', 'C:/gtk-build/build/x64/release/glib/', '--sources-top-dirs', 'C:/gtk-build/build/x64/release/glib/_gvsbuild-meson/']
--- stdout ---
--- stderr ---
Traceback (most recent call last):
File "C:\gtk-build\gtk\x64\release\bin\g-ir-scanner", line 103, in <module>
from giscanner.scannermain import scanner_main
File "C:\gtk-build\gtk\x64\release\lib\gobject-introspection\giscanner\scannermain.py", line 35, in <module>
from giscanner.ast import Include, Namespace
File "C:\gtk-build\gtk\x64\release\lib\gobject-introspection\giscanner\ast.py", line 27, in <module>
from .sourcescanner import CTYPE_TYPEDEF, CSYMBOL_TYPE_TYPEDEF
File "C:\gtk-build\gtk\x64\release\lib\gobject-introspection\giscanner\sourcescanner.py", line 34, in <module>
from giscanner._giscanner import SourceScanner as CSourceScanner
ImportError: DLL load failed while importing _giscanner: The specified module could not be found.
```https://gitlab.gnome.org/GNOME/glib/-/issues/3295A core dump occurs in g_object_notify_queue_thaw2024-03-23T14:00:58ZbanjiuqingshanA core dump occurs in g_object_notify_queue_thawThis is an occasional problem. The nmcli command is executed twice every minute, and a core dump is triggered every two to three weeks.The corresponding version is glib2-2.72.2 and NetworkManager-1.32.12.
The core file output is as follo...This is an occasional problem. The nmcli command is executed twice every minute, and a core dump is triggered every two to three weeks.The corresponding version is glib2-2.72.2 and NetworkManager-1.32.12.
The core file output is as follows:
![image](/uploads/80be0a22d75768ce13ef77aff680d4af/image.png)https://gitlab.gnome.org/GNOME/glib/-/issues/3294[CI] Pipeline on 'main' failed for commit 5b9dac542024-03-19T13:02:43ZGLib Issue BOT[CI] Pipeline on 'main' failed for commit 5b9dac54
## Summary
Pipeline [655354](https://gitlab.gnome.org/GNOME/glib/-/pipelines/655354) on 'main' failed for commit 5b9dac54.
Failed job(s):
- [valgrind](https://gitlab.gnome.org/GNOME/glib/-/jobs/3708597)
- [G_DISABLE_ASSERT](https://gi...
## Summary
Pipeline [655354](https://gitlab.gnome.org/GNOME/glib/-/pipelines/655354) on 'main' failed for commit 5b9dac54.
Failed job(s):
- [valgrind](https://gitlab.gnome.org/GNOME/glib/-/jobs/3708597)
- [G_DISABLE_ASSERT](https://gitlab.gnome.org/GNOME/glib/-/jobs/3708588)
- [hurd-i386](https://gitlab.gnome.org/GNOME/glib/-/jobs/3708585)
## Instructions
Please create a new issue (or multiple issues) and link
them to this issue.
Tip: you can create a related issue directly by clicking
the vertical ellipsis in the top right hand corner of this issue
and clicking "New related issue". See the documentation on
[managing issues](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#from-another-issue-or-incident)
for more information.
When investigation begins, update the label to ~"pipeline failure::under investigation".
-----
_Created by [issue-bot](https://gitlab.com/gitlab-org/distribution/issue-bot) via [this job](https://gitlab.gnome.org/GNOME/glib/-/jobs/3708601)._https://gitlab.gnome.org/GNOME/glib/-/issues/3293Misleading "invalid byte sequence in conversion input" output message2024-03-18T11:03:20ZM1KEMEXMisleading "invalid byte sequence in conversion input" output messageHi,
I'm an end-user, I hope I'm filing this bug properly because I've never done this before.
I'm using the text editor 'Geany' version 2.0 under Windows 11. According to the "About" dialog, Geany version 2.0 is based on GLib 2.78.0.
...Hi,
I'm an end-user, I hope I'm filing this bug properly because I've never done this before.
I'm using the text editor 'Geany' version 2.0 under Windows 11. According to the "About" dialog, Geany version 2.0 is based on GLib 2.78.0.
I'm trying to convert a large UTF-8 encoded text file into ISO-8859-1 because I'm not skilled enough to properly handle UTF-8 strings in a program I'm making and I currently do not need to support anything but Spanish. However, when I attempt to change the file encoding, it throws an error during save:
`GLib.GException: Hay una secuencia de bytes no válida en la entrada de conversión.`
The supposedly bad character is:
```
'ἀ'
'Greek Small Letter Alpha with Psili'
U+1F00
UTF-8 bytes: 0xE1 0xBC 0x80
```
This is correct. The file I'm processing contains linguistic information and contains a lot of unusual characters such as Greek letters. I've verified the file by hand in an hex editor and the bytes are properly encoded. Therefore, I've determined that this must be a bug in the GLib library. Or, at least, in the way Geany handles GLib exceptions.
My hypothesis is that this particular character is outside the range of characters ISO-8859-1 supports. Therefore, not finding an 1:1 equivalent, it throws a warning to alert the program it's going to lose information in the conversion process. What I don't understand is why it says "There is an invalid byte sequence in the conversion input" if the sequence is actually valid. If I'm right, it should use a different message.https://gitlab.gnome.org/GNOME/glib/-/issues/3292Invalid read in g_utf8_collate_key() for short strings2024-03-19T14:30:11ZSebastian DrögeInvalid read in g_utf8_collate_key() for short strings```
==1382082== Invalid read of size 32
==1382082== at 0x4E59A2E: __wcpncpy_avx2 (strncpy-avx2.S:85)
==1382082== by 0x4DBB560: wcsxfrm_l (strxfrm_l.c:679)
==1382082== by 0x4B3D957: g_utf8_collate_key (gunicollate.c:408)
==138208...```
==1382082== Invalid read of size 32
==1382082== at 0x4E59A2E: __wcpncpy_avx2 (strncpy-avx2.S:85)
==1382082== by 0x4DBB560: wcsxfrm_l (strxfrm_l.c:679)
==1382082== by 0x4B3D957: g_utf8_collate_key (gunicollate.c:408)
==1382082== Address 0x5099f50 is 0 bytes inside a block of size 8 alloc'd
==1382082== at 0x484280F: malloc (vg_replace_malloc.c:442)
==1382082== by 0x4B0CB8D: g_malloc (gmem.c:100)
==1382082== by 0x4B3EC25: _g_utf8_normalize_wc (gunidecomp.c:399)
==1382082== by 0x4B3D91A: g_utf8_collate_key (gunicollate.c:402)
```
I'm not entirely sure if this is GLib's fault or glibc's (2.38 from F39). It feels more like the latter but this function surely can't be that broken in glibc... or for some reason this is fine? `__wcpncpy_avx2` seems to assume for some reason that the input is at least one AVX register large.
The following patch to GLib works around it. I can't find anything in the `wcsxfrm()` docs that would suggest requiring a minimum buffer size.
```diff
diff --git a/glib/gunidecomp.c b/glib/gunidecomp.c
index 5c2d41b1d..bea75f50a 100644
--- a/glib/gunidecomp.c
+++ b/glib/gunidecomp.c
@@ -396,7 +396,7 @@ _g_utf8_normalize_wc (const gchar *str,
p = next;
}
- wc_buffer = g_new (gunichar, n_wc + 1);
+ wc_buffer = g_new (gunichar, MAX (n_wc + 1, 32));
last_start = 0;
n_wc = 0;
```
Any ideas?https://gitlab.gnome.org/GNOME/glib/-/issues/3289readlink -f fails in CI on macOS2024-03-16T10:25:09ZPhilip Withnallreadlink -f fails in CI on macOSFrom #3284:
> * [macos-x86_64](https://gitlab.gnome.org/GNOME/glib/-/jobs/3683884)
Various shell-based tests failing with:
```
readlink: illegal option -- f
usage: readlink [-n] [file ...]
(test program exited with status code 1)
```
...From #3284:
> * [macos-x86_64](https://gitlab.gnome.org/GNOME/glib/-/jobs/3683884)
Various shell-based tests failing with:
```
readlink: illegal option -- f
usage: readlink [-n] [file ...]
(test program exited with status code 1)
```
which is odd because this has [apparently worked fine for a few weeks](https://gitlab.gnome.org/GNOME/glib/-/jobs/3621925) on macOS.https://gitlab.gnome.org/GNOME/glib/-/issues/3287Devhelp does not show indexes for GLib, GIO, or GObject2024-03-18T21:31:03ZMichael CatanzaroDevhelp does not show indexes for GLib, GIO, or GObjectUsing Devhelp 43.0 from Flathub and GLib 2.79.1, the help indexes for GLib, GIO, and GObject are all unavailable in Devhelp, as if they're not installed at all. But they are installed (e.g. the GLib index is at `/usr/share/doc/glib-2.0/g...Using Devhelp 43.0 from Flathub and GLib 2.79.1, the help indexes for GLib, GIO, and GObject are all unavailable in Devhelp, as if they're not installed at all. But they are installed (e.g. the GLib index is at `/usr/share/doc/glib-2.0/glib/glib.devhelp2`).
My assumption is that something is wrong with the indexes, but since Devhelp doesn't display any error message, and no error is printed on the command line, we cannot know what is wrong and cannot fix GLib. Devhelp should indicate why it doesn't load any of GLib's indexes.
fyi: @pwithnall2.80.1Philip WithnallPhilip Withnallhttps://gitlab.gnome.org/GNOME/glib/-/issues/3286g_strrstr, g_strrstr_len, g_strstr_len return ownership note is incorrect2024-03-22T00:10:01ZMichael Websterg_strrstr, g_strrstr_len, g_strstr_len return ownership note is incorrectThese functions have always returned a pointer to a position in `haystack`, even though their return type would imply otherwise.
The Return description appears unchanged in gstrfuncs.c, but in the actual documentation it ends up appendi...These functions have always returned a pointer to a position in `haystack`, even though their return type would imply otherwise.
The Return description appears unchanged in gstrfuncs.c, but in the actual documentation it ends up appending that it needs to be freed (based on the return type):
```
Type: gchar*
A pointer to the found occurrence, or NULL if not found.
The caller of the function takes ownership of the data, and is responsible for freeing it.
The value is a NUL terminated UTF-8 string.
```
Observed in 2.79.2 (Ubuntu 24.04) but it looks like docs.gtk.org documentation has this as well.
Thanks2.82Philip WithnallPhilip Withnallhttps://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/3284[CI] Pipeline on 'main' failed for commit 9bba53cf2024-03-13T17:13:24ZGLib Issue BOT[CI] Pipeline on 'main' failed for commit 9bba53cf
## Summary
Pipeline [651973](https://gitlab.gnome.org/GNOME/glib/-/pipelines/651973) on 'main' failed for commit 9bba53cf.
Failed job(s):
- [valgrind](https://gitlab.gnome.org/GNOME/glib/-/jobs/3683888)
- [macos-x86_64](https://gitlab...
## Summary
Pipeline [651973](https://gitlab.gnome.org/GNOME/glib/-/pipelines/651973) on 'main' failed for commit 9bba53cf.
Failed job(s):
- [valgrind](https://gitlab.gnome.org/GNOME/glib/-/jobs/3683888)
- [macos-x86_64](https://gitlab.gnome.org/GNOME/glib/-/jobs/3683884)
- [G_DISABLE_ASSERT](https://gitlab.gnome.org/GNOME/glib/-/jobs/3683874)
- [hurd-i386](https://gitlab.gnome.org/GNOME/glib/-/jobs/3683871)
## Instructions
Please create a new issue (or multiple issues) and link
them to this issue.
Tip: you can create a related issue directly by clicking
the vertical ellipsis in the top right hand corner of this issue
and clicking "New related issue". See the documentation on
[managing issues](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#from-another-issue-or-incident)
for more information.
When investigation begins, update the label to ~"pipeline failure::under investigation".
-----
_Created by [issue-bot](https://gitlab.com/gitlab-org/distribution/issue-bot) via [this job](https://gitlab.gnome.org/GNOME/glib/-/jobs/3683894)._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/3282Win32 regression: assertion failed when opening a gtkfontchooser2024-03-13T15:03:39ZgwillemsWin32 regression: assertion failed when opening a gtkfontchooserWhen testing a recent GLib on Win32 (debug build), I observed a systematic assert crash from `weak_ref_data_ref` every time I open a gtkfontchooser on Win32:
```
assertion failed: (wrdata)
```
Here a backtrace from `gtk4-widget-factory...When testing a recent GLib on Win32 (debug build), I observed a systematic assert crash from `weak_ref_data_ref` every time I open a gtkfontchooser on Win32:
```
assertion failed: (wrdata)
```
Here a backtrace from `gtk4-widget-factory` : [backtrace.txt](/uploads/7425d7274b8b5bf8640ae7566c4dca2a/gdb_fontchooser.txt)
I bisected the regression on GLib side, it was introduced by !3834
(commit 5f12851312f is good, 2638f97b3e8 is bad)
I can't tell if something is wrong on pangowin32 side, or if the new assert on GLib side is overzealous...
## Additional info
Windows 10, msys2-ucrt64, debug build from sources.
- GLib: 2.79.1 + see commits above
- Gtk: 4.14-rc + ea0cfed7
- Pango: 1.52 + dd8da7cf