Even though we are going to check all the `LC_*` environment variables,
if one of them is not set, we still need to consider LANGUAGE, LC_ALL
and LANG; there is no guarantee that *every* `LC_*` environment variable
is set (and in particular, during our build-time tests, they will usually
not be).
Resolves: https://github.com/flatpak/flatpak/issues/4471
Signed-off-by: Simon McVittie <smcv@collabora.com>
g_get_language_names() only returns the language names for the
LC_MESSAGES category, so mixed locale scenarios would result in missing
languages. Now, the languages are listed for each individual category.
Note that this issue was only present with the user installation. For
the system installation, the locales were queried from localed, and all
categories were checked.
In order to work on GLib versions < 2.58, the code to get language
names for a category has been backported.
Fixes#3712.
These functions were already annotated with G_GNUC_PRINTF, so gcc
can assume that the format string and arguments match up.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Without this change, validate_component() might free the "component"
variable, but then go on to keep using it. This change also makes the
code work as intended, to only have a flatpak-specific "bundle" in the
appstream xml (where here bundle does not mean "flatpak single-file
bundle").
If an argument takes a value, and the value is empty, then it's
misleading to quote `{"--foo", "--empty", "", "--bar"}` as
`--foo --empty --bar`. It's better to get `--foo --empty '' --bar`.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This has no practical effect (assuming environment variables are unique),
but it makes it easier to find an environment variable of interest
in a very long bwrap command-line.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes them easier to deal with when debugging. Otherwise, it's easy
for the bundled arguments to wrap across 50 or more lines, and with
linebreaks in arbitrary positions that becomes very hard to read.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In addition to the old summary.idx.sig we now create an identical file
in `summaries/$DIGEST.idx.sig`, where the digest is of the summary
index itself. This means it will have a unique name and there will
never be issues where downloading the index and signature will race
during an update.
We keep the new and the previous digested sigs every update to avoid
removing the previous one while its in use.
As suggested by simon in https://github.com/flatpak/flatpak/issues/3983
and https://github.com/ostreedev/ostree/issues/2250
Currently if a deploy file was created (because a flatpak is installed)
using an old Flatpak version (such as 0.10.1 that's in Endless 3.3.16),
it will not include every metadata key, such as "eol" and "eolr". Those
keys were added before deploy version 1. Then when the deploy file is
upgraded to version 3, the metadata is only copied so eol/eolr are still
missing even though they exist in the commit metadata.
So this commit adds deploy version 4 which ensures all metadata keys in
the deploy file are present (when they are present in the source data).
All existing deploy files will be upgraded with this code.
This change is important because we use the end-of-life information to
decide whether an unused runtime should be uninstalled, so without this
change we are not freeing up disk space that we should be.
When installing to an installation we need to find the runtime to use
for the apply-extra-data script from the installation we're targeting,
because that is the one that FlatpakTransaction guaranteed has the
required dependencies (although its possible they came from the
default dependency source too, i.e. the system repos).
In particular, we run into this issue if nothing is installed
anywhere, and then we install an extra-data app into a custom
directory. The transaction will download the runtime, and it
will not be anywhere else. Without this change flatpak only
looked for the dependency in the systam an regular user dirs
where it isn't.
The old summary had a ostree.commit.timestamp in the per-ref metadata
dict. However, since this was not used anymore by flatpak I removed it.
However, it turns out that flathub has infra that depends on this,
so I'm adding it back.
We reuse the data in the old summary for unchanged refs when
rebuilding the summary, to avoid having to read all the commits. In
the new world the new format summaries are used for this, which means
we have to keep the timestamp in that too. However, to not be
unnecessary large its now using a shorter key name, as this is
duplicated for each ref in the summary.
There was a bug in the extension point matcher which made it
install `org.gnome.Totem.Videosite.YouTubeDl.Sources` (in addition to
`org.gnome.Totem.Videosite.YouTubeDl`) for the `org.gnome.Totem.Videosite`
extension.
We just need to make sure we only match the extension prefix if there
is a single element in the extension name following the extension
name (i.e. '.YouTubeDl', not '.YouTubeDl.Sources').
This fixes https://github.com/flatpak/flatpak/issues/3973
In the main summaries we drop all the subset appstream branches.
In the subset summaries we use the relevant appstream branch and drop
the normal ones.
We also leave out the old compat branch completely from the subset
summaries because it will just be used for newer flatpaks that support
the new format.
flatpak-utils.c is getting large, and also I got some issues with
include order, so split out things that are purely handling ref stings
in various ways to its own file.
getters now have three forms:
const char *foo_peek() returns pointer into data and length
const char* foo_get() returns zero terminated pointer into data
char *foo_dup() returns allocated zero terminated pointer
Not everything has all of these (as that is not always possible), but
it is clear what each one does.
We also now support storing a collection id for a
FlatpakDecomposed. This is not typically done (as we use the source
remote to define the collecion id and don't expose this concept to the
user). However, for the case when directly listing a local repo (such as
a side-load repo) we need this.
We now validate the arch string. The valid chars are a-z, A-Z, 0-9 and
_. This was't previously verified, but no arches in existance have other
chars.
There is a new flatpak_decomposed_new_from_decomposed() which lets you
modify part of another ref. Say replace the arch or the branch and
keep the rest the same.
The st_mtime field is all we can guarantee to keep, so whenever we
write a new summary file for a repo we ensure it is newer than the old
by checking if st_mtime is equal (or less) and if so, use the old
st_mtime plus one.
This means sometimes the generated summary files will be in the future but
that only happens in the corner case of multiple changes inside one
second, and in that particular case we need this change.
This fixes some issues I had with the mtime chacking in the tests due to
the python httpd handling If-Modified-Since based on st_mtime.
These now take (optional) string length args:
flatpak_id_has_subref_suffix()
flatpak_levenshtein_distance()
flatpak_is_valid_name()
flatpak_is_valid_branch()
In addition to the old summary file we create a summary.idx and
a set of per-arch subsummaries (and extra copies of these if any commit
specify a subset). These are much smaller, and eventually we will also
get deltas for them.
We are not yet using these new formats, although the code is there
to use them once we start downloading them.
This drops the deltas from the summary and uses the per-commit
metadata field to add the cache data to avoid the need for the separate
xa.cache and xa.sparse-cache indexes. This way we avoid repeating the
refs in multiple places.
Nothing uses this format yet, but we still pass make check if we enable
it.
This moves the generation of the summary files completely into flatpak
allowing us to (later) customise what goes into it in more detail and
generate other forms of summaries.
commit 6b46d9a0ed that added DConf path
skewering to camelcase conversion only allowed it in one direction
(skewered path1 and camelcase path2).
That turned out to be not enough to allow /org/gnome/sound-juicer/ to
/org/gnome/SoundJuicer/ conversion as the caller had the
flatpak_dconf_path_is_similar() arguments the other way around.
This commit implements it both ways to avoid confusion which way it
should be called.
F: Ignoring D-Conf migrate-path setting /org/gnome/sound-juicer/
Allow a snake-case in the app-id to convert to a '-' or '_' in the
DConf path to be considered similar enough for DConf migration purposes.
This allows the org.gnome.SoundJuicer app-id to migrate its
/org/gnome/sound-juicer DConf path.
F: Ignoring D-Conf migrate-path setting /org/gnome/sound-juicer/
