GitLab

The current os_update_box looks a bit weird, because the left and right
margin is missing.

I've added a 18px left&right margin. Now it looks better.

#317

I managed to get a 1000 line message printed as an in-app notification
when a distro upgrade transaction depsolve failed with out of space
errors. This took about a minute to render ...

As a fix, this limits the notification to two lines: one from
gnome-software, and one from the GError.

... so that instead of "Unable to upgrade to Fedora: not enough disk
space", we show "Unable to upgrade to Fedora 28: not enough disk space".

We don't have any UI in the app row to cancel an ongoing install/remove
operation.

As per https://raw.githubusercontent.com/gnome-design-team/gnome-mockups-software/master/wireframes/app-install-remove.png

We were trying to construct a link out of repo names when asking whether
to enable a enabled_metadata=1 repo, but we didn't actually have the
data for the link target, so clicking on the link did nothing. This
removes the href to avoid confusing people with unclickable links.

When installing unavailable packages and enabling a repo, we have (for
reasons unknown to me) a 3 second sleep before calling into PK again to
install the package. This commit moves the state change earlier so that
we can show in the UI that we've moved on to installing while still in
the 3 second delay.

There was a comment left by mistake (copy&paste) indicating that
flatpak_installation_list_installed_refs_for_update doesn't do any
no network I/O which is false.

We don't show them anywhere in the UI and translators keep asking why
they aren't marked for translation.

Thanks to Piotr Drąg for pointing it out!

When removing a repo-release package, use "Remove All" to show that it
removes all repos that come from that package.

Origin is supposed to be the repo name where packages come from. This
does not always match with appstream metadata origin 1:1; e.g. in Fedora
we have one single appstream source that covers all of standard repos.

Instead of having the appstream and packagekit plugins fight over the
origin field, this commit moves appstream origin to a separate field.

https://bugzilla.redhat.com/show_bug.cgi?id=1440331

This makes it possible to store package repo origin and appstream origin
separately. On a regular Fedora install, we have a single appstream
metadata file (/usr/share/app-info/xmls/fedora.xml.gz) that covers all
of Fedora repos, and doesn't have a 1:1 matching with the repo
names.

We can get PK_STATUS_ENUM_UPDATE while installing a package if the
dependency resolution causes us to update a dependency.

This makes resolving i686 compat arch packages work on x86_64 machines.

This works around an issue where the appstream plugin incorrectly
refines package GsApps with repo metadata when their source packages
match.

... as per latest mockups.

We used to incorrectly mark packages where the epoch-version-release
changed from e.g. "234-9" -> "234-10" as downgrades. This commit fixes
this by splitting up the EVR string and comparing each part separately.

https://bugzilla.redhat.com/show_bug.cgi?id=1549958

We need a separate plugin so that we can order it to run after the
"repos" plugin; regular packagekit-refine plugin is currently ordered to
run before the repos plugin.

The way it works is that first the repos plugin sets
repos::repo-filename metadata key, and then in the next pass
packagekit-refine-repos uses the key to figure out what packages these
belong to.

These changes avoid a race when apps are refined from within a
different thread, as their properties' notification were being
emitted (and thus triggering) code from those.

Specifically there was a race when setting up the CSS for the
background tile as this code was not getting run from the main
loop.

Thanks to Piotr Drąg for pointing this out!