The code checked the wrong flags. struct_props is the array of child
properties, so struct_props->flags is the flags of the first child
property. What we need to chech is the flags of the current property,
and if it contains FLATPAK_JSON_PROP_FLAGS_STRICT.
Copy and paste error which results in the default and explicit usage of
--clear-env to be inverted.
Fixes: f760f1b5 ("run: Add --clear-env option for clearing the outside environment")
It was accidentally parsed into the product union member but because it
has the same layout as the vendor one, this didn't turn into a bug in
practice, but it probably is UB.
As per g_type_ensure's documentation it is technically incorrect to mark
_get_type fns with G_GNUC_CONST since they have side-effects on their
first run.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/5223 for more
details.
This constraints the scope of the variables within instead of
unnecessarily creating global variables, and it makes it easier to keep
only a single sys.exit
coredumpctl is required for both subcommands, and likely will be for any
others added in the future, so we should just check for it in one place
at the start.
Reworks the interface of flatpak-coredumpctl to use subcommands
similar to those of coredumpctl. The new list subcommand is currently
non-functional, but will list all store coredumps from flatpak
applications, and the previous debugger functionality has been moved to
the debug subcommand.
flatpak-coredumpctl: Implement basic functionality for 'list' subcommand
Resolves#2002: 'flatpak-coredumpctl list' now lists coredumps
in a format similar to coredumpctl, except that it skips inaccessible
coredumps by default
flatpak-coredumpctl: Use a pager for list output
These less flags don't perfectly match coredumpctl because it uses
systemd's pager instead of less, but it's close enough
flatpak-coredumpctl: Match coredumpctl's text styling
The column titles are now underlined and missing/inaccessible coredumps
are grayed out.
This is probably just a little overengineered for what is needed, but I
wanted to make it easy to expand in the future if needed, and it is
still fairly minimal.
flatpak-coredumpctl: Add matches argument to list subcommand
Verify that the file object is valid before checking its cached path
to avoid a potential NULL pointer dereference.
Fixes: c4fce9e4 ("run: Error out if file forwarding of empty paths is attempted")
During a system install with the system helper enabled, the initial
network pull goes to a temporary repo and then via pull local from that
repo to the final system repo while during user install there is only
one pull from network to the final repo.
c672c55 set the logger to use the temporary repo path as installation
but the history command afc87ad since the same day filters the initial
pull out as the installation name will never match the temporary path.
This causes the initial pull operation to be never show up in flatpak
history when using system installs while they work for user installs as
`INSTALLATION=user`.
This is presumably also broken for custom installations as they
will similarly not match the temp repo path.
So don't pass the path at all to flatpak_dir_log and we can later
fall back via flatpak_dir_get_name_cached() which sets the correct
`INSTALLATION` for system installs ie. `INSTALLATION=system`.
This also allows us to remove the workaround of adding two different
expected history outputs from ad1ff6d as both branches log the pull.
Without system helper `flatpak install` needs to be executed as
priviledged to operate on system install so the initial pull was
always logged correctly for that branch.
Help messages were inconsistent about whether they ended with periods or
not. I chose to remove the periods from those that had them rather than
the other way around because the help messages automatically generated
by argparse do not have periods.
There are a couple related changes made here, with the intention of
making it easier to implement additional features in the future:
- Mutual exclusivity of --build-directory and app is better enforced
both through types and at runtime. The types will let type checkers
ensure that we cannot reach the run function without at least one of
them being valid. At runtime, it no longer allows both to be
specified, which could result in confusion over which takes
precedence.
- Instead of wrapping the entire program in a class, there is now only a
small class that handles validation of the arguments and holding the
data to be passed to run. This provides a better separation of
concerns, with the argument parsing now being a little less tied to
running the debugger.
-m with no argument currently results in coredumpctl_matches having a
value of "", which is exactly the same as if it weren't used at all. As
far as I can tell, allowing this does nothing useful, only making the
usage slightly less clear.
`emit_progress` is called from a thread while another thread could
unexport/close the GDbusInterfaceSkeleton. If that happens, the
connection becomes NULL which is illegal for
`g_dbus_connection_emit_signal` which results in dereferencing an unset
error.
The fix is to lock the UpdateMonitorData, and then only emit the signal
if it is not closed.
The file forwarding feature errors out when the path or URI does not
lead to an actual file that can be forwarded. The empty path never
describes an actual file, so we always have to error out.
Without the check, we would get a NULL path from
`flatpak_file_get_path_cached` and crash later.
Closes: #6689
* backports, local-alloc: Provide a backport of g_autofd
* build: Add meson.override_dependency('libglnx', libglnx_dep)
* fdio: Add support for name_to_handle_at
* chase: Add glnx_chase_and_mkdirat
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
1. Removed unnecessary punctuation to help with readability
2. Loop over RES elements directly instead of indexing
3. Declare COMPGEN_OPTS only once vs redeclaring on each iteration
A few global variables were being created unecessarily still. This makes
sure that users shell environments are not polluted by extra variables
and that the completion doesn't modify unrelated variables
We found that there is a common use case where we need to get a
subdirectory (potentially multiple levels) which might not exist yet.
Adding another flag for this to GlnxChaseFlags is what systemd has done,
but creating a directory takes a mode, so the flag creates directories
with a fixed mode. This approach instead takes the mode as argument.
It takes a callback which gets called every time we try to open the next
segment of the path. This allows implementing more specific and advanced
use cases to be implemented without adding more complexity to the chase
algorithm itself.
We were handling null properties the same as missing properties
*except* that the MANDATORY flag allowed null properties but
not missing properties. Fix this, so null is disallowed by
MANDATORY.
When checking signatures, the image identity could only have
been NULL if it was null in the input file - so replace a
conditional check on it being non-null with an assertion.
It's legitimate to have manifests listed in an image index that
have no platform object, and hence no architecture - avoid crashing
if we encounter such a manifest.
Mark all properties required by the OCI specification as required;
this eliminates a bunch of cases where we were assuming that
descriptor->digest was non-NULL, and potentially generating
critical errors from g_return_if_fail().
Both collect exports and flatpak_export_dir recursively export the
directories in their respective directory lists. Because of this,
including share/metainfo/releases when share/metainfo is already in the
lists is unnecessary and can cause exporting to fail because of
duplicate files.
Sebastian Wick