| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we verify the checksum of indexed summary files (which have
.sub file names) before writing them to the on-disk cache, so in theory
as long as the disk I/O is successful the data integrity should be
intact when we use it via the flatpak-variant-impl-private.h helpers
generated by variant-schema-compiler. However in practice people
sometimes hit assertion failures which are what you would expect to see
if the data is corrupt, since GVariant stores some metadata such as the
"offset size" toward the end of the data, and if we read this from
serialized user data instead it will obviously be incorrect. In one case
I was able to acquire the flathub.idx, flathub.idx.sig, and
flathub-x86_64-fad08cfb10713e749f02a0e894b5d577b7e9c4931fdf9d2fdc50364c002bc925.sub
files which reproduce one of the assertion failures, and the sub file
appears to be incomplete, like the writing of it was interrupted.
We use g_file_replace_contents() when saving these to the disk, and when
not replacing an existing file that function writes directly to the
final filename, so if interrupted it would be expected to leave an
incomplete file.
This commit changes the summary file handling so that we verify the
checksum of any indexed subsummary again after reading it from disk. If
it doesn't match we delete the on-disk cache and try fetching from the
network.
Fixes #4127
|
| |\
| |
| | |
Make test suite logs prettier
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes a few issues with the unit test logs that make them ugly:
1. Currently some lines of output from a command will appear after the
line from xtrace which has the next command, since the command was
printing to stdout and xtrace uses stderr. E.g. "Installation complete."
will appear after "+ flatpak --user install -y ..." but it is from the
previous install command.
2. Lines of output have many spaces after them to pad them to the table
width but this is not needed for non-fancy output.
3. Lines of output are mixed with output from httpd since they don't end
with a newline character, e.g. "Installing… ▊
4%127.0.0.1 - - [16/Nov/2021 00:18:24] "GET /..."
|
| |/
|
|
|
| |
This way the flatpak command is more consistently run under valgrind
when that is enabled.
|
| |\
| |
| | |
Update hi.po
|
| | | |
|
| |\ \
| | |
| | | |
Change how automatic pinning is implemented (option 2)
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit re-works how we automatically "pin" runtimes that are
explicitly installed, to prevent them from being removed automatically.
In this implementation we do the update to the config as part of the
deploy, which has the following advantages:
(1) It ensures that there's never a confusing polkit prompt about
configuring the software installation when the user asked for a runtime
to be installed (https://github.com/flatpak/flatpak/issues/4200)
(2) It means we don't have to rely on the code on the error path of
flatpak_transaction_real_run() to un-pin the runtime in case something
went wrong with the installation, since we pin it almost atomically with
the deploy.
Fixes #4200
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On two different code paths we were using the "Title" field in
flatpakref files as the title of a remote, which is incorrect. In most
cases, the remote added via the RuntimeRepo key will be the same as the
remote the app is from, so when the remote is added for the runtime, its
title will be correctly set using the Title value from the flatpakrepo
file and the app will therefore have an origin remote with a title set.
This is not currently true for flatpakref files that use
SuggestRemoteName=, see https://github.com/flatpak/flatpak/pull/4513
For flatpakref files that use a different remote than the RuntimeRepo,
we don't currently have a way for the title to be set automatically;
perhaps we should (https://github.com/flatpak/flatpak/issues/4512).
Fixes https://github.com/flatpak/flatpak/issues/4499
|
| | |
| |
| |
| | |
Signed-off-by: Guido Günther <agx@sigxcpu.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is similar to what is done for desktop files and allows
applications to use a flatpak's metainfo to retrieve e.g. required
input controllers or the supported screen sizes. Similar to what can be
done for non-flatpak'ed apps by looking at
/usr/share/{metainfo,appdata}.
Since flatpak moves the metadata from metainfo/ to appdata/ during build
we only need to export files from that single directory.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Many of the fields allowed in flatpakrepo files are not allowed in
flatpakref files, e.g. Comment, Description, Homepage, etc. So there is
no straightforward way to ensure those are set correctly when the user
installs something with a flatpakref file. However in most cases the
repo specified by the RuntimeRepo key is also the repo providing the
main ref, so in those cases it makes sense to utilize all the metadata
provided in the flatpakrepo file when creating a remote to provide
updates for the app being installed. We were already doing this when the
SuggestRemoteName key was unset; this commit makes it so that we utilize
that metadata also when SuggestRemoteName is present.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It can happen that a related ref is installed from a different remote
than the thing it's related to. We always want to update things from
their origin remote. However as of now FlatpakTransaction resolves the
commit of a related ref to the one available from the main ref origin,
and later sets the remote for the operation to the installed origin (see
commit 6793d90b8). In case there is a newer commit in the main ref
origin than the installed origin, this leads to an update operation
being erroneously created, only to then error out with an HTTP 404
error, because the commit from the main ref origin is being pulled from
the installed ref origin. For specific steps to reproduce see
https://github.com/flatpak/flatpak/issues/3128#issuecomment-948948040
So, ensure that when a FLATPAK_TRANSACTION_OPERATION_INSTALL_OR_UPDATE
operation is created for something that's installed, whether it's a
related ref or something else, the remote used is always the origin. And
ensure that the remote is set correctly before the stage where the op is
resolved to a commit, to avoid the situation described above. This is
essentially a re-implementation of the fix in commit 6793d90b8.
Also, add a unit test for this behavior.
This commit also makes a few changes to documentation to make it clear
that this related-ref-different-origin situation is possible.
Fixes #3128
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently if the user specifies a ref to install that has been renamed
via the end-of-life-rebased mechanism, for example "flatpak install
com.visualstudio.code.oss", Flatpak erroneously tries to install both
the old and new versions of the app. This happens because the code
handling end-of-life-rebase conditions is written assuming the rebased
app is being updated rather than installed for the first time.
Specifically, in FlatpakCliTransaction and FlatpakQuietTransaction, in
end_of_lifed_with_rebase(), we treat a failure of
flatpak_transaction_add_uninstall() as fatal and return FALSE from the
signal handler, which means that the install operation that triggered
the signal will not be skipped (see the docs for
FlatpakTransaction::end-of-lifed-with-rebase).
So, instead check for the FLATPAK_ERROR_NOT_INSTALLED error code and
ignore it, so that the installation of the old version of the renamed
app will be properly cancelled.
Fixes https://github.com/flatpak/flatpak/issues/3754
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The original commit (9865ed8989befe9653fb3cd919fb5518b09274d2) disabling
it claimed it fixed OCI downloads. This no longer seems to be a problem.
This has also exposed new bugs as some servers will send
gzip compressed data when the client does not send Accept-Encoding.
If we leave this enabled that issue goes away.
|
| | |
| |
| |
| | |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
| | |
| |
| |
| |
| |
| |
| | |
This is placed at the same location that would be used by
the --persist=.local/state option.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
| | |
| |
| |
| | |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
| | |
| |
| |
| | |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
| | |
| |
| |
| | |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
| | |
| |
| |
| | |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This gives new support for the new XDG_STATE_HOME addition to XDG_BASE_DIRS
which allows applications to use this without breaking because they would
assume $HOME/.local/state which may be unavailable to the flatpak
This adds it as .local/state as to make --persist=.local/state the same behaviour
as in new flatpak. This in turn means that the transition should be seamless between
old and new flatpak.
This also has the benefit of working if the application doesn't follow XDG spec thanks
to --persist=.local/state.
This fixes https://github.com/flatpak/flatpak/issues/4477
[smcv: Don't call nonexistent g_get_user_state_dir(); fix a reference
to XDG_STATE_DIR]
|
| | |
| |
| |
| |
| | |
Spotted this by code inspection. Ignoring such refs was clearly the
intended behavior based on the comment.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Technically, Fish users can already make this work using
https://github.com/edc/bass, but it's also nice to have this working on
an out-of-the-box Flatpak installation.
Fixes #3109.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
flatpak_fancy_output() determines whether the output we write is
intended for e.g. a tty or e.g. a log file, the latter being "not
fancy". Currently we write carriage return characters in the not fancy
case, but change that to new lines, which are interpreted correctly by
editors such as vim (whereas a carriage return shows up as ^M since it
is not the correct newline character on Unixy operating systems).
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
The <bundle> element in the appstream data unambiguously provides the
full four-part flatpak ref, so use it to determine the app ID. But fall
back to using the <id> element, since that is required to be present.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This commit changes the search command to properly output the app ID for
IDs that end in .desktop, e.g. to print org.telegram.desktop rather than
org.telegram.
Fixes https://github.com/flatpak/flatpak/issues/4535
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit is a follow-up to "Fix implementation of xa.noenumerate
remote option" since that turned out to break
flatpak_installation_fetch_remote_ref_sync() in some cases. I didn't see
it at the time, but flatpak_decomposed_get_collection_id() explains that
the collection ID shouldn't be set on FlatpakDecomposed objects, even
when the remote has a collection ID set, unless they are being used to
enumerate refs from a file:// URI rather than a configured remote. So
this commit changes list_remote_refs() and list_all_remote_refs() to
keep the xa.noenumerate implementation working and to get
fetch_remote_ref_sync() working again (since the latter uses
flatpak_decomposed_new_from_parts() and thus doesn't set a collection ID
on the FlatpakDecomposed object used for comparison).
|
| | |
|
| |
|
|
| |
These are just based on a cursory reading of the spec.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/ServerStrings/
says:
> If the string starts with / or unix: the remaining address string is taken as
> UNIX socket name.
but previously the string was only taken to be a UNIX socket name if it began
with "unix:".
This is an issue in practice with WSLg <https://github.com/microsoft/wslg>
which sets $PULSE_SERVER to "/mnt/wslg/PulseServer", without a "unix:" prefix.
|
| |\
| |
| | |
Update hi.po
|
| |/ |
|
| |\
| |
| | |
Update hi.po
|
| |/
|
|
| |
Fixing errors and correcting them.
Correction of translation for the interface.
|
| | |
|
| |\
| |
| | |
tests: Drop some unneeded CFLAGS/LDADD
|
| |/ |
|
| |\
| |
| | |
Update hi.po
|
| |/
|
| |
Corrections.
|
| |\
| |
| | |
Update hi.po
|
| |/
|
| |
Minor fixes
|
| |\
| |
| | |
Add Hindi translation
|
| |/ |
|
| |\
| |
| | |
Add checkbox to issue template
|
| |/ |
|
| | |
|
| |\
| |
| | |
dir: Don't mask the main ref of a noenumerate remote
|
