[Summary]
The package is small and doesn't have much that would conflict with our
policies. It doesn't even trigger any of the checkboxes that would imply
a security review.
The only drawback is that it is severely outdated and our Delta not upstreamed
I'd ask you to work on that, once that is done it should be fine to be promoted.

Required TODOs:
=> The current release should be packaged (0.1.15 ours is two years outdated)
   Along that please upstream our Delta and then remerge the result of that.

Recommended TODOs:
=> Given what the services are doing I wonder if they should not be of
   type=oneshot. I'd ask to spend some time and maybe discuss with the upstream
   to ensure this works as we'd want. Currently we have one "simple" and one
   "forking" but both seem to run a few commands and then exit.
   What states are these services in on a booted RPi, would it be more
   reasonable with type oneshot.

MIR Team Ack (under the constraint of being updated)

List of specific binary packages to be promoted to main: pi-bluetooth



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

[Dependencies]
OK:
- no other Dependencies to MIR due to this except those already in progress
- 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 (continuous) 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
- The package has a team bug subscriber
- no translation present, but none needed for this case (user visible)?
- not a python/go package, no extra constraints to consider int hat regard
- no new python2 dependency
- Python package that is using dh_python
- Go package that uses dh-golang

Problems:
- does have a test suite that runs at build time
- does have a test suite that runs as autopkgtest
=> This was already outlined in the report (thanks) and is covered by the
   regular tests of the devices cert team.

[Packaging red flags]
OK:
- Ubuntu does carry a delta, but it is reasonable and maintenance under control
- symbols tracking not applicable for this kind of code.
- Upstream update history is (good/slow/sporadic)
- Debian/Ubuntu update history is (good/slow/sporadic)
- 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

Problems:
- d/watch is not present and might be a reason updating was missed
- the current release is packaged
  0.1.10 which we have is two years old by now, but there are 5 later releases
  which read like valid improvements fixes.

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (only service/udev/shell)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- 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