All of these warnings indicate programmer error, so critical is most
appropriate here.
Exceptions: deprecation warnings are just warnings. Also, warnings that
are worded with uncertainty can remain warnings rather than criticals.
glib_debug is an auto option. This is clever because it allows us to
guess the best default based on the build type, while also allowing an
easy way to override if the guess is not good. Sadly, the attempt to
guess based on the build type does not work well. For example, it
considers debugoptimized builds to be debug builds, but despite the
name, it is definitely a release build type (except on Windows, which
we'll ignore here). The minsize build type has the exact same problem.
The debug option is true for both build types, but this only controls
whether debuginfo is enabled, not whether debug extras are enabled.
The plain build type has a different problem: debug is off, but the
optimization option is off too, even though plain builds are distro
builds are will almost always use optimization.
I've outlined an argument for why we should make these changes here:
https://blogs.gnome.org/mcatanzaro/2022/07/15/best-practices-for-build-options/
Specifically, Rule 4 shows all the build types and whether they
correspond to release builds or debug builds. Rule 6 argues that we
should provide good defaults for plain builds.
A file-descriptor was created with the introduction of pidfd_getfd() but
nothing is closing it when the source finalizes. The GChildWatchSource is
the creator and consumer of this FD and therefore responsible for closing
it on finalization.
The pidfd leak was introduced in !2408.
This fixes issues with Builder where anon_inode:[pidfd] exhaust the
available FD limit for the process.
Fixes#2708
gio tool has support for deleting attributes of the file. To delete attribute user
should specify type '--type="unset"'. This is not mentioned in help and therefore not
intuitive. By adding '-d' option, we make this process more obvious.
closes#2588
man pcre2_pattern_info says that the 3rd argument must
point to uint32_t variable (except for some 2nd argument value),
so correctly use it. Especially using wrong size can cause
unexpected result on big endian.
closes: #2699
The prefix for GMarkupParseFlags enumeration members is G_MARKUP; this
means that G_MARKUP_PARSE_FLAGS_NONE gets split into
GLib.MarkupParseFlags.PARSE_FLAGS_NONE by the introspection scanner.
The `/*< nick=none >*/` trigraph attribute is a glib-mkenum thing, and
does not affect the introspection scanner; it would also only affect the
GEnumValue nickname, which is not used by language bindings to resolve
the name of the enumeration member. Plus, GMarkupParseFlags does not
have a corresponding GType anyway.
The prefix is G_TLS_CERTIFICATE, not G_TLS_CERTIFICATE_FLAGS. Having
G_TLS_CERTIFICATE_FLAGS_NONE leads to a FLAGS_NONE nick in the GType,
and a FLAGS_NONE member name in the introspection data.
Enumeration members should either have the name of the type as their
prefix, or they should all have the same prefix.
The "default flags" enumeration member for GApplicationFlags is
unfortunately named G_APPLICATION_FLAGS_NONE, while every other member
of the same type has a G_APPLICATION prefix. The result is that the nick
name of the enumeration member is "flags-none", and that language
bindings will have to use something like
Gio.ApplicationFlags.FLAGS_NONE.
To fix this API wart, we can deprecate the FLAGS_NONE member, and add a
new DEFAULT_FLAGS.
