GitLab

Now that we are showing them sorted, it's clear that sometimes they're
repeated on distros that there's less of a 1:1 mapping on resources
(e.g. KDE Neon).

Make sure then that we only print them once.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

Makes it easier to see if a specific package is being upgraded.

GIT_SILENT

GIT_SILENT

As discovered by Piotr, attempting to update some KNewStuff originated
packages in Discover results in the update not in fact being updated,
without anything happening in Discover apart from the update just
staying around in the UI. This patch forwards an error from
KNSCore::Engine which gives some further information as to what the user
can do to perform this update.

This is a half-solution to the problem, as the TODO added in here
suggests, but it seems to me better to be explicit about the problem to
our users, rather than just not doing anything, and informing them how
they can fix it themselves. Until we have a full query system for
Discover's transactions, this seems likely to be the best we can do (and
actually implementing that system will take some time to get right, and
we don't want to just ignore the problem until them).

BUG:430812

Should make the instances much lighter, which is important as there's
tons of them.

BUG: 431364

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

If the user was gambling his luck by trying to uninstall the "System
Upgrade" entry we create for offline upgrade, now they'll get an error
message rather than a crash.

Instead of creating a new one when preparing a new update. It would get
confused and crash sometimes. Not pretty.

Backends will need to make sure that no wrong resources are offered.
This is necessary because when we query by appstream id we might have to
return some resources where we match on their alternative names rather
than the actual.

BUG: 427243

Only do it when we need it instead of fetching them all at start.

There should at least be a package to upgrade to consider it.

The message will already appear as a system notification and the updates
page will request to reboot (and offer a button). We do not need yet
another dialog pressuring us.

It makes libflatpak (libsoup internally) go bonkers. It also makes the
whole startup much slower (understandably).
By using FlatpakRemoteRef instead of querying the FlatpakInstallation we
have the opportunity for some optimisations since we're querying the
FlatpakRemoteRef twice for some (most?) available packages.

It doesn't make sense to pass the installation together with the
resoruce because the resource already knows its installation (and it's
constant at that).

It's not very useful to create the cancellable when we won't be able to
use it. Pass the one from the backend so we can cancel jobs upon closing
at least.

Fix annoying warning when connecting to a nullptr emitter

Thanks valgrind!

Makes the process a bit more fluid, as apps look for runtimes

On some cases we were passing the wrong installation and it broke our
installation.
It's better to just rely on the installation that the resource already
knows it has.

There is no need for it. Makes the operation more expensive and it makes
the output too verbose when there's problems.

So we don't block on it.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"