gnome-software:uajain/set-launchable-as-id

Last commit made on 2019-11-08
Get this branch:
git clone -b uajain/set-launchable-as-id https://git.launchpad.net/gnome-software

Branch merges

Branch information

Name:
uajain/set-launchable-as-id
Repository:
lp:gnome-software

Recent commits

634e527... by Umang Jain <email address hidden> on 2019-10-10

appstream: Override <id> with <launchable type="desktop-id"> while parsing appdata files

Problem statement:
This has been a recurring problem since a long time now, where
apps have started to drop the ".desktop" suffix from their <id>
tag present in their appdata. Reasoning for this change is given
as the ".desktop" is not really a part of the app-id. Also,
it's been seen as better aligning with flatpak ref-ids as
dropping this suffix makes the app-id equivalent to the flatpak
ref-id.

However, this breaks the mapping between the app's appdata and
it's desktop file. GNOME Software parses both of these, to merge
the metadata (ideally) under one GsApp object during refines.
The appdata supplies information like description and categories
whereas desktop files supplies information like icon, NoDisplay
and so on.

So, things will break if metadata parsing of appdata and desktop
file doesn't converge under one GsApp object. What happens here
is gnome-software creates an app from a desktop file but could
not relate to it's appdata file (because ".desktop" mismatch) and
it ends up creating two GsApp objects, neither of which has full
metadata from appdata and desktop file. Hence, anyone of these can
bubble up in the UI with missing icons or info etc.

Solution:
Apps dropping .desktop suffix adds a <launchable type="desktop-id">
tag to the appdata. Check for the presence of this tag and override
the <id> tag, if it doesn't match the <launchable> tag. This makes
sure that the appdata can still relate to it's desktop file component.

https://phabricator.endlessm.com/T27779

e1d131a... by Philip Withnall <email address hidden> on 2019-11-06

ci: Build libmalcontent dependency on Fedora CI

This means we start to get a test matrix where Fedora builds with
libmalcontent, and Debian builds without.

Signed-off-by: Philip Withnall <email address hidden>

Fixes: #825

fec6768... by Philip Withnall <email address hidden> on 2019-11-06

ci: Run a custom D-Bus daemon for the tests in the CI

This was needed in the old CI, and is inexplicably also needed in the
new CI, otherwise the `flatpak` tests fail. I haven’t investigated
further why it’s needed.

Signed-off-by: Philip Withnall <email address hidden>

Helps: #825

8aed6eb... by Philip Withnall <email address hidden> on 2019-11-06

ci: Disable the fwupd tests

They don’t pass on CI for some reason; they were, however, run on the
previous CI setup. They need to be investigated further.

Signed-off-by: Philip Withnall <email address hidden>

Helps: #825

0f3a23d... by Philip Withnall <email address hidden> on 2019-11-06

ci: Disable the PackageKit tests

They don’t pass on CI (and weren’t run on the previous CI setup).

Signed-off-by: Philip Withnall <email address hidden>

Helps: #825

f6f8f22... by Philip Withnall <email address hidden> on 2019-11-06

ci: Rework the CI to support multiple Docker images

This is a major reworking of the CI system. Rather than downloading all
the build dependencies on every CI run, we now build a couple of Docker
images with all the relevant build dependencies pre-installed. Rather
than building only on Fedora, we now build on Fedora *and* Debian
Stable.

To update one of the Docker images, update the `.Dockerfile`, then run
```
.gitlab-ci/run-docker.sh build --base=fedora --base-version=2
.gitlab-ci/run-docker.sh push --base=fedora --base-version=2
```

The `--base-version` should be incremented each time you produce a new
Docker image (i.e. once per MR which touches the `Dockerfile`s). This
means you will end up with multiple versions of each Docker image in the
registry, which is necessary as old MRs will only be run against the
version which was listed in `.gitlab-ci.yml` when they branched.

Once a new Docker image is pushed, it needs to be referenced from the
`image:` keys in `.gitlab-ci.yml`.

It includes a script, `meson-junit-report.py`, which takes the JSON
test report and converts it to a Cobertura format suitable for GitLab to
understand and summarise.

It’s worth noting the FIXME comment in `run-tests.sh` at the
moment: tests can only be run as root. That seems like an unnecessary
restriction which implies that the tests need further sandboxing and
more mock D-Bus services added to them.

Signed-off-by: Philip Withnall <email address hidden>

Helps: #825

3a44354... by Philip Withnall <email address hidden> on 2019-11-06

build: Add test suites to test() calls

This makes it easier to run certain sets of tests and not others.

Signed-off-by: Philip Withnall <email address hidden>

Helps: #825

8228641... by Philip Withnall <email address hidden> on 2019-11-06

build: Bump Meson dependency to 0.47.0

Our required dependencies require Meson 0.47.0, so there’s no point in
gnome-software languishing on an older version.

Signed-off-by: Philip Withnall <email address hidden>

67a5bff... by Richard Hughes on 2019-11-06

Remove the app folder functionality

This is now present in GNOME Shell and is the logical place for it.

1eab1ca... by Richard Hughes on 2019-11-06

Set the shell extension origin correctly in all cases

Fixes https://gitlab.gnome.org/GNOME/gnome-software/issues/842