Using the Application Activation Manager coclass. Its threading model
is marked as 'both', so it can be instantiated in any apartment type
without marshaling.
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.
If stdout is the Journal but stderr is not, then we probably only want
to redirect stdout, or vice versa.
Signed-off-by: Simon McVittie <smcv@collabora.com>
I want to use this in gio-launch-desktop, but gio-launch-desktop
doesn't depend on GLib, so I can't just call g_log_writer_is_journald().
Signed-off-by: Simon McVittie <smcv@collabora.com>
This prevents a launched process's output from being mixed up with the
output of the parent process, which can lead to the wrong program being
blamed for warning messages.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is an internal helper executable, which users shouldn't invoke
directly (see glib#1633).
When building for a single-architecture distribution, we can install
it as ${libexecdir}/gio-launch-desktop.
When building for a multiarch distribution, installing it into an
architecture-specific location and packaging it alongside the GLib
library avoids the problem discussed in glib#1633 where it would either
cause a circular dependency between the GLib library and a common
cross-architecture package (libglib2.0-bin in Debian), or require a
separate package just to contain gio-launch-desktop, or cause different
architectures' copies to overwrite each other.
Signed-off-by: Simon McVittie <smcv@collabora.com>
gio-launch-desktop was removed before checking GIO for potentially
unsafe environment variable references, so reverting its removal brought
this one back. If a setuid program is using GAppInfo then something is
probably already horribly wrong, but let's be careful anyway.
Signed-off-by: Simon McVittie <smcv@collabora.com>
