Comment 3 for bug 1932485

[Summary]
There are some digging to be done around tests, especially due to the ABI instability. Can we use the -test package for integration tests for instance?
Then, I’m happy to give a +1 from the MIR team. I don’t think security review is really needed here, as the security part is done on the callee side, and this is the caller one.

Required TODO:
- Investigating if we can expand the autopkgtests testsuite to be non trivial (including the -test package and do an API call).

Recommended TODO:
One copyright owner is missing:
libportal/portal-qt5.h: GNU Library General Public License v2 or later
  [Copyright: 2020 Jan Grulich]

[Duplication]
There is no other package in main providing the same functionality.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats
- does not open a port
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)

[Common blockers]
OK:
- does not FTBFS currently
- no special HW does prevent build/autopkgtest.
- no translation present, but none needed for this case
- not a python/go package, no extra constraints to consider in that regard

Problems:
- does not have a test suite that runs at build time. There are some autopkgtests though. This may be due to dbus-run-session? Could we inspect if we can have some tests running at build-time already?
- does have a trivial test suite that runs as autopkgtest. There is a -test package that is not used. Could we investigate on how we can exercise this code if possible? That would remove the need to rely on the other package to exercise the test via rdepends.

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking is in place
- d/watch is present and looks ok
- Upstream update history is good
- Debian/Ubuntu update history is good
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- Does not have Built-Using

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as I can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (usage is OK inside tests)
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks