Comment 30 for bug 2047780

At first I was just going to say, ell-dev isn't built on i386 and it's not arch:all, of course it will need an i386 allowlist entry! However, this is the output I'm getting:

```
$ check-mir
Checking support status of build dependencies...
 * debhelper-compat does not exist (pure virtual?)
 * libell-dev binary and source package is in universe
 * check binary and source package is in universe

Checking support status of binary dependencies...
 * default-dbus-system-bus does not exist (pure virtual?)
  ... alternative dbus-system-bus does not exist (pure virtual?)

Please check https://wiki.ubuntu.com/MainInclusionProcess if this source package needs to get into in main/restricted, or reconsider if the package really needs above dependencies.
```

I'm going to fix check-mir itself so it ignores debhelper-compat (that is certainly a false flag since debhelper is in main, and I don't want to see anyone waste time on this red herring), `libell-dev` and `check` are valid points. Both of those seem like reasonably small libraries that could be MIRed, especially ell for embedded devices. That being said, we did not have these dependencies before, so this is much lower on my priority list. I would highly encourage someone to beat me to it.

That being said, I've been listening to music with no issue with the updated bluez, which is what I would expect to be the baseline for a "working" bluez. The only quirk I noticed is that despite my device (Beats Flex) being set to autoconnect, I needed to manually connect (to the already saved device). Connected promptly, no stuttering issues (from YouTube Music/Firefox Nightly snap), audio is as good/loud as I would expect it to be, and volume control works smoothly. I'm not noticing anything particularly different on the blueman configuration front.

tl;dr: Uploaded Gianfranco's diff to Noble with slight modifications. This will need to go through binary NEW.