summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Handle 'versions' key when finding local related reffix-uninstall-unused-versionsAlexander Larsson2019-09-101-61/+77
| | | | | | | | | | | We were only handling the old single-value 'version' key, even though we handled the 'versions' key when finding remote related refs. The result of this was that some extensions, such as the 19.08 opengl default one was installed by default (as it was found as remote related) yet still removed with --unused (as it was not locally related). Fixes https://github.com/flatpak/flatpak/issues/3004
* Fix leak in flatpak_dir_find_remote_related_for_metadataAlexander Larsson2019-09-101-1/+1
| | | | | This puts the checksum autoptr in the inner scope of the loop where it gets assigned to avoid leaking all but the last iteration value.
* tests: Add a test for uninstall --unusedMatthew Leeds2019-09-091-1/+11
| | | | | Closes: #3067 Approved by: alexlarsson
* common: Make uninstalls robust to a missing remoteMatthew Leeds2019-09-093-153/+206
| | | | | | | | | | | | | | | | | | | Currently if you delete a remote when it still has installed apps (using --force), you're then unable to uninstall those orphaned apps (or runtimes). This commit makes the uninstall operation succeed despite the missing remote. Since we don't need a FlatpakRemoteState for an uninstall operation, just avoid calling flatpak_ensure_remote_state(). Also, do some refactoring in flatpak_transaction_real_run() that should improve readability and allows us to add a g_return_val_if_fail() in the helper function, which ensures that only uninstall operations are allowed to not have remote state. This also includes a unit test for uninstalling with a missing remote. Fixes https://github.com/flatpak/flatpak/issues/1982 Closes: #3067 Approved by: alexlarsson
* Make finding related refs tolerant of missing refsMatthew Leeds2019-09-091-7/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | This is similar to the last commit in that it's making flatpak_dir_find_local_related_for_metadata() tolerant of a condition that happens in the wake of the user running "flatpak remote-delete --force ...". Since that command deletes refs tied to the remote being deleted but leaves behind installed apps/runtimes, and find_local_related_for_metadata() uses flatpak_repo_resolve_rev() to check for extensions' existence, it misses any that are associated with a deleted remote. The effect of this is that if I run "flatpak remote-delete --force kdeapps" followed by "flatpak uninstall org.kde.okular", org.kde.okular is removed but org.kde.okular.Locale is left behind. So this commit makes find_local_related_for_metadata() check for a deploy of each extension if it can't find its ref, and finding either one is reason enough to return it to the caller (which for an uninstall operation means it will be deleted). We can't just check for the deploy, because as evidenced by the "deployed" argument of flatpak_dir_find_local_related(), the ref in question is not always deployed (which presumably means the extension can't be expected to be deployed either). Closes: #3067 Approved by: alexlarsson
* Make finding related refs tolerant of missing remotesMatthew Leeds2019-09-093-16/+57
| | | | | | | | | | | | | | | | | | As a step toward the goal of making uninstalls work when the corresponding remote is missing, this commit makes flatpak_dir_find_local_related_for_metadata() tolerant of the specified remote being missing. To do this we get the collection ID from the commit metadata rather than the remote config, which is more robust anyway since in some cases the commit's collection may not match that of the remote (see https://github.com/flatpak/flatpak/issues/1477). This commit also changes the call sites of flatpak_dir_find_local_related_for_metadata() so they pass in the commit to be used, which means resolving transaction operations to a commit even for uninstall operations (just the current installed commit). Closes: #3067 Approved by: alexlarsson
* common: Fix misordering of branch and arch argumentsMatthew Leeds2019-09-094-11/+11
| | | | | | | | | | | | | | | | | | flatpak_dir_collect_deployed_refs() has the order of its "branch" and "arch" arguments wrong, as does its only caller flatpak_list_deployed_refs(). When flatpak_list_deployed_refs() is called by add_extension() the arch is put in the branch argument and vice versa. But then in the implementation the arch is used as if it's the branch and vice versa, so there's no functional bug here. Fix the order for readability. Similarly, flatpak_list_unmaintained_refs() has the order wrong, but the confusion is only within that function, since the order is correct in its caller add_extension() and in the function it uses, flatpak_dir_collect_unmaintained_refs(). So there's no functional bug there either, but fix the order. Closes: #3067 Approved by: alexlarsson
* app: Fix a use-after-free in flatpak_find_installed_pref()Matthew Leeds2019-09-091-6/+6
| | | | | | | | | | | | | | | | | | | Currently "flatpak --installation=default info ..." leads to an assertion failure: $ flatpak --installation=default info us.zoom.Zoom (flatpak info:24593): GLib-GObject-CRITICAL **: 10:01:36.040: g_object_ref: assertion 'G_IS_OBJECT (object)' failed This is because in flatpak_find_installed_pref(), we set "dir = installation_dir" but then installation_dir is freed by g_autoptr before we try to return dir. Fix the problem by stealing the pointer, and doing the same for the other places dir is set. Closes: #3077 Approved by: alexlarsson
* Use defined macro SYSTEM_DIR_DEFAULT_ID moreMatthew Leeds2019-09-094-9/+9
| | | | | | | Just replace hardcoded strings with the macro, no functional change. Closes: #3077 Approved by: alexlarsson
* dir: Construct default FlatpakDir with correct idMatthew Leeds2019-09-091-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the FlatpakDir object for the default system installation is constructed differently depending on where the construction is happening. In flatpak_dir_get_system_default() it's created with a NULL DirExtraData object which means flatpak_dir_get_id() returns NULL when called on it. But if constructed in flatpak_get_system_base_dir_locations(), the FlatpakDir object gets a DirExtraData object with the default values, including the id "default", so flatpak_dir_get_id() returns "default" for it. This commit changes flatpak_dir_get_system_default() so it constructs the default object consistently with the other construction. This means that in the places where the dir id is compared to "default" that check will work correctly. Practically this means for CLI transactions the "Proceed with these changes?" prompt will say "the system installation" rather than "the Default system installation". Also change flatpak_dir_get_system_by_id() so it returns the default dir when id == "default", but continue to also return it if id == NULL. This means the --installation=default CLI option will work correctly, but we can avoid breaking any software that might currently be calling flatpak_installation_new_system_with_id() with a NULL id. And finally change flatpak_dir_get_display_name() so it continues to return "Default system installation" for the default system installation. Closes: #3077 Approved by: alexlarsson
* CI: Install dbus-daemon rpmAlexander Larsson2019-09-091-1/+1
| | | | | Closes: #3088 Approved by: alexlarsson
* ci/libbuild.sh: Fix fedora release package issuesMatthew Leeds2019-09-091-0/+5
| | | | | | | | | Attempt to fix the CI failure when running "yum -y install @buildsys-build". This is copied from https://github.com/ostreedev/ostree/commit/d85366d52 Closes: #3088 Approved by: alexlarsson
* .papr.yml: Update to Fedora 30Matthew Leeds2019-09-091-2/+2
| | | | | | | | | | | | We need at least GLib 2.60.1 for this PR: https://github.com/flatpak/flatpak/pull/2797 Don't update the host distro for the docker run, since F30 Atomic doesn't exist yet. That's fine though, since the F30 container is available. Closes: #3088 Approved by: alexlarsson
* tests: Add tests for oci registries using labels instead of annotationsAlexander Larsson2019-09-065-16/+38
| | | | | Closes: #2978 Approved by: alexlarsson
* OCI: Handle NULL when marshalling manifest string mapsAlexander Larsson2019-09-061-3/+6
| | | | | | | | | This was happening for the org.opencontainers.image.ref.name annotation when we're in labels mode, but might as well be handled in a generic way. Closes: #2978 Approved by: alexlarsson
* OCI: Don't crash on mirroring an OCI repo without annotationsAlexander Larsson2019-09-061-0/+3
| | | | | | | | If we're using labels the annotations hashtable may be NULL, which was causing a crash. Just do an early check. Closes: #2978 Approved by: alexlarsson
* OCI: Handle manifests without annotations in index.jsonAlexander Larsson2019-09-066-10/+10
| | | | | | | | | | | When we export a manifest to the index, always pass the ref we're targeting instead of relying on the org.opencontainers.image.ref.name annotation, because that may not be set if we're using labels instead. This is no big deal, because we know what ref we're handling anyway. Closes: #2978 Approved by: alexlarsson
* OCI: Make use of labels or annotations configurableAlexander Larsson2019-09-061-1/+17
| | | | | | | | If repo uri has ?index=label then query for labels, otherwise keep querying for annotations like before. Closes: #2978 Approved by: alexlarsson
* build-bundle: Add --oci-use-labels switchAlexander Larsson2019-09-061-4/+8
| | | | | | | | | | This allows the user to pick at runtime whether to use annotations or labels as OCI metadata carrier. For historical reasons annotations is the default, but some registries don't support this and then you can use labels instead. Closes: #2978 Approved by: alexlarsson
* OCI: Use labels as commit metadata source as well as annotationsAlexander Larsson2019-09-066-5/+54
| | | | | | | | | | | | We now pull the image config as well as the manifest and fall back on the labels field if the keys we're looking for are not in the annotations field. This lets us support docker manifests too, which don't have annotations (but do have labels). Closes: #2978 Approved by: alexlarsson
* OCI: Don't crash if mediaType field missing in flatpak_oci_versioned_from_jsonAlexander Larsson2019-09-061-3/+6
| | | | | Closes: #2978 Approved by: alexlarsson
* OCI: Add flatpak_oci_registry_load_image_config helperAlexander Larsson2019-09-065-0/+51
| | | | | | | | We can't use load_versioned() for images because in the docker case there is no mediatype field. Closes: #2978 Approved by: alexlarsson
* OCI: Accept docker v2 manifests as well as OCI manifestsAlexander Larsson2019-09-062-4/+6
| | | | | Closes: #2978 Approved by: alexlarsson
* OCI: Add docker v2 media type definesAlexander Larsson2019-09-061-0/+2
| | | | | Closes: #2978 Approved by: alexlarsson
* oci: Query for org.flatpak.ref label instead of annotationAlexander Larsson2019-09-061-1/+1
| | | | | | | | This is not compatible with the old stuff, but works with registries that only support the docker manifest format. Closes: #2978 Approved by: alexlarsson
* oci: Allow reading metadata from labels tooAlexander Larsson2019-09-061-8/+22
| | | | | Closes: #2978 Approved by: alexlarsson
* oci: Always generate a history, quay needs thisAlexander Larsson2019-09-063-0/+33
| | | | | Closes: #2978 Approved by: alexlarsson
* Put annotations also in the labelsAlexander Larsson2019-09-061-0/+3
| | | | | Closes: #2978 Approved by: alexlarsson
* oci: Add an easy api to set the labels in the image manifestAlexander Larsson2019-09-062-0/+9
| | | | | Closes: #2978 Approved by: alexlarsson
* OCI: Break out the annotation generation code into a helperAlexander Larsson2019-09-061-54/+78
| | | | | | | | This doesn't change the behaviour, it just breaks out everything related to flatpak-specific annotations into one place where it can be resued. Closes: #2978 Approved by: alexlarsson
* Add English (UK)Zander2019-08-301-0/+4834
| | | | | Closes: #3068 Approved by: mwleeds
* Add en_GBZander2019-08-301-0/+1
| | | | | Closes: #3068 Approved by: mwleeds
* Default end-of-life-rebase prompt to yesBartłomiej Piotrowski2019-08-201-1/+1
| | | | | Closes: #3063 Approved by: mwleeds
* Avoid installing empty dirs with --disable-selinux-moduleHeiko Becker2019-08-161-1/+1
| | | | | ...by moving everything selinux specific into the scope of the if.
* flatpak-installation: Handle an unconfigured remote when listing remotesPhilip Withnall2019-08-161-4/+10
| | | | | | | | | | This prevents a crash in flatpak_installation_list_remotes_by_type() if the `FlatpakDir` can’t ensure it has a repo configured. Signed-off-by: Philip Withnall <withnall@endlessm.com> Closes: #3028 Approved by: alexlarsson
* Trim unused shared library linkages from the session helperDebarshi Ray2019-08-1614-101/+181
| | | | | | | | | | | | | | | | | | | | The org.freedesktop.Flatpak user D-Bus service isn't just used by flatpak(1) or applications running as Flatpaks. It's also used by toolbox(1) for similar reasons: * To keep various configuration files inside the container synchronized with the host * To let the container request certain commands to be run on the host The org.freedesktop.Flatpak D-Bus service itself doesn't need much in the way of dependencies, but inherits a lot of unused shared library linkages through the libflatpak-common.la convenience library. Removing these unused shared libraries reduces the footprint of toolbox(1) for those who care about such things. eg., Fedora CoreOS. This commit brings down the number of shared libraries to 19 from 62. Closes: #3052 Approved by: alexlarsson
* common, session-helper: Make the session helper more self-containedDebarshi Ray2019-08-162-5/+5
| | | | | | | | | | ... by moving the definition of FlatpakHostCommandFlags from the 'common' sub-directory to 'session-helper'. It hasn't been used by anything else ever since flatpak-builder was moved to a separate repository in commit 52bd14656151fe63. Closes: #3052 Approved by: alexlarsson
* build: Link against libxml only when necessaryDebarshi Ray2019-08-162-2/+4
| | | | | | | | | | The libxml API is used in a relatively few places inside the 'common' sub-directory. It's definitely not as widespread as GLib. A subsequent commit will leverage this to prevent unused shared libraries from being linked to the session helper. Closes: #3052 Approved by: alexlarsson
* build: Link against libarchive only when necessaryDebarshi Ray2019-08-162-2/+4
| | | | | | | | | | The libarchive API is used in a relatively few places inside the 'common' sub-directory. It's definitely not as widespread as GLib. A subsequent commit will leverage this to prevent unused shared libraries from being linked to the session helper. Closes: #3052 Approved by: alexlarsson
* Update Ukrainian translationYuri Chornoivan2019-08-151-195/+200
| | | | | Closes: #3056 Approved by: alexlarsson
* OCI: correctly handle locally present iconsOwen W. Taylor2019-08-151-2/+7
| | | | | | | | | | | | If the download URL for an icon was already cached locally, the HTTP code returned FLATPAK_OCI_ERROR_NOT_CHANGED - this was treated as a real error, and after downloading missing icons, all present icons were deleted! See https://bugzilla.redhat.com/show_bug.cgi?id=1683375 Closes: #3048 Approved by: alexlarsson
* build-bundle: Fix resolving refsMatthew Leeds2019-08-152-20/+67
| | | | | | | | | | | | | | | | | | | | | | | | | Unfortunately in commit 253fcc6e3 I broke the build-bundle command so that it is unable to resolve remote refs (as opposed to local ones). This means in the normal case of building a bundle for an app installed from a remote it fails: $ flatpak build-bundle /var/lib/flatpak/repo gnome-calculator.flatpak org.gnome.Calculator stable error: Refspec 'app/org.gnome.Calculator/x86_64/stable' not found This is because flatpak_repo_resolve_rev() interprets a NULL remote name to mean the ref is local (in refs/heads/) but in this case we just don't know which remote it's from. This commit fixes the issue by using ostree_repo_resolve_rev() directly which searches refs/heads/ and refs/remotes/, and if that fails falling back to iterating over refs returned by ostree_repo_list_collection_refs() to catch collection-refs that may be in refs/mirrors/. Also, add a unit test that fails without this patch. Fixes https://github.com/flatpak/flatpak/issues/3026 Closes: #3032 Approved by: alexlarsson
* dir: Don't overzealously rewrite an errorMatthew Leeds2019-08-151-5/+1
| | | | | | | | | | | | | It's an error to call g_set_error() on an error that's already set, and flatpak_dir_get_deploy_data() already sets FLATPAK_ERROR_NOT_INSTALLED for us when necessary, so just pass on any errors to the caller of flatpak_dir_get_origin(). In the case that the error is something else, that should be treated as an error, because we never expect the deploy directory to exist but not have a deploy file (see the implementations of flatpak_dir_deploy() and flatpak_dir_undeploy()). Closes: #3032 Approved by: alexlarsson
* common: Use correct flag for ostree_repo_resolve_rev_ext()Matthew Leeds2019-08-151-1/+1
| | | | | | | | Use the correct NONE flag, although both are 0 so this change won't make any functional difference. Closes: #3032 Approved by: alexlarsson
* common: Fix branch validation docsMatthew Leeds2019-08-151-1/+1
| | | | | | | | | | | | | | | The docs for flatpak_is_valid_branch() say branch names can't start with a digit but the implementation doesn't enforce this, and we have lots of branches out in the wild that start with a digit (e.g. "3.32" and "5.12"). So make the docs imply that branches can start with a digit. The implementation also disallows "." as the leading character for a branch, so add that to the docs. I'm just guessing that "." was intended to be disallowed but it makes sense; otherwise the file we create named with the branch would be hidden. Closes: #3023 Approved by: alexlarsson
* installation: Fix a small leak of a FlatpakCollectionRefPhilip Withnall2019-08-031-1/+11
| | | | | | | Signed-off-by: Philip Withnall <withnall@endlessm.com> Closes: #3031 Approved by: mwleeds
* cli-transaction: Fix some leaksAndre Moreira Magalhaes2019-07-231-2/+2
| | | | | | | Signed-off-by: Andre Moreira Magalhaes <andre@endlessm.com> Closes: #3025 Approved by: matthiasclasen
* transaction: Append bundle to correct list on ↵Andre Moreira Magalhaes2019-07-231-1/+1
| | | | | | | | | flatpak_transaction_add_install_bundle() Signed-off-by: Andre Moreira Magalhaes <andre@endlessm.com> Closes: #3025 Approved by: matthiasclasen
* doc/flatpak-kill: Add a hint about flatpak psMatthew Leeds2019-07-211-1/+2
|
* doc/flatpak-enter: Make a few minor improvementsMatthew Leeds2019-07-211-3/+9
|
View Lorry Controller Status