BlueZ release 5.71

Updated source files are attached above. And the source is in:
https://git.launchpad.net/~bluetooth/bluez/log/

I very much dislike reviewing packages this way. For a package to be in the sponsorship queue, it needs to have a debdiff, not a debian.tar.xz. I understand that it's a new upstream release, but that does not excuse the need for a debdiff, even if you *also* include these files.

I'm uploading this as a courtesy to you and the Desktop Team. Please, don't do it like this again, as I will reject it.

Here's the debdiff. We don't usually use them for major updates though because of the size. 34174 lines in this case is not plausibly reviewable.

It's usually Seb sponsoring these, but he's on vacation. To avoid any future complaints in case he's away again I will also include debdiffs in future.

> 34174 lines in this case is not plausibly reviewable.

I typically use filterdiff to get the packaging changes, and review specific source files as necessary (including copyright changes in the diff, which can be important, even if you're just using a script for it).

Thanks for your help here. I apologize for any undue stress. I will review this in the morning, unless someone else would like the opportunity to fix this sooner.

The build is failing:
https://launchpad.net/ubuntu/+source/bluez/5.71-0ubuntu1

But I don't know how to reproduce the failure. Certainly it builds on both noble and mantic, and installs, and works for me. Is this because Launchpad is using a focal toolchain?

Daniel, systemd was updated today in noble-proposed. It includes changes as part of Debian's ongoing usrmerge work. In particular this commit: https://salsa.debian.org/systemd-team/systemd/-/commit/ee83b5721

Here is a Debian commit to adapt to the change:
https://salsa.debian.org/bluetooth-team/bluez/-/commit/f4d76255cdfa

Something like this could be simpler though:
https://salsa.debian.org/DebianOnMobile-team/modemmanager/-/commit/367180c3

Daniel, if you'd like to iterate on this (a debdiff for an ubuntu2 upload), it would be appreciated.

If you don't have the time, say the word, this looks like a simple fix.

...on everything but i386. What's up with that?

Turns out it's not as simple as the above comments suggest.

> https://salsa.debian.org/systemd-team/systemd/-/commit/ee83b5721
> https://salsa.debian.org/DebianOnMobile-team/modemmanager/-/commit/367180c3

udev changes are not relevant to the failures in https://launchpad.net/ubuntu/+source/bluez/5.71-0ubuntu1 AFAICT

> https://salsa.debian.org/bluetooth-team/bluez/-/commit/f4d76255cdfa

Our dh doesn't seem to understand "${env:" in *.install, so using the same approach as Debian doesn't seem to work. It always treats "${env:..." as a literal path. And yes I did remember to export the variable from debian/rules.

Just hard coding the service file paths to /usr would probably work for Launchpad builds, but is not something I'm willing to do right now since the path change hasn't graduated from proposed yet and I can't test it locally. I'm only willing to upload changes I have tested locally so it can wait till systemd has migrated... In the meantime, can anyone tell me why "${env:..." isn't understood? Is it the compatibility level?

I don't understand why bluez packaging can't be merged with the debian fixes and continues to follow some logic of "never update to newer dh or compat".
Also patches from Debian are never received, as well as new binaries not installed.

I did some really little cleanup and the package now builds sanely, the variables are used and looks "better". But as sponsor I would refuse to continue to upload this useless and old packaging, and force somebody to really cleanup this maintenance burden that increased over time.

Also, why is the tarball different from the Debian one?

I'm attaching a debian directory that builds fine, not tested at all.

The reason I essentially blindsponsored this was out of faith and courtesy for the Desktop Team.

Lubuntu does similar things, but we have a merge party from Debian once a cycle. If your response would be "we don't follow Debian," *I get it*, but once or twice a cycle a merge should really be looked at.

I'm hoping Daniel, Jeremy, and Sebastien can help get this solved for us. Respectfully, permissiveness will not be present in future uploads.

> Also, why is the tarball different from the Debian one?

At least for 5.71, it looks as if Ubuntu are using the tar.xz from the kernel.org download url in the debian/watch file, while debian are fetching or making a tar from the git.kernel.org (or gihub mirror) bluez repo.

Rik mentioned a common mistake that I've been trying harder to catch (but didn't in this case, to my great frustration)...

If we're doing a merge and an orig tarball already exists in Debian, always always ALWAYS grab that one instead of using uscan or finding the tarball yourself. It breaks tooling otherwise.

This is now blocking a Lubuntu feature goal. I tested this locally with my bluetooth earbuds, and have been streaming audio with no problems.

Uploaded Gianfranco's packaging with some minor tweaks.

Please, we *need* to merge this from Debian *this* cycle. The Security Team will NOT be happy when they have to patch this.

E: bluez: depends-on-obsolete-package Depends: lsb-base
W: bluez source: illegal-runtime-test-name bluez_response [debian/tests/control:1]
W: bluez: maintainer-script-should-not-use-dpkg-maintscript-helper "dpkg-maintscript-helper" [postinst:11]
W: bluez: maintainer-script-should-not-use-dpkg-maintscript-helper "dpkg-maintscript-helper" [postinst:14]
W: bluez: maintainer-script-should-not-use-dpkg-maintscript-helper "dpkg-maintscript-helper" [postinst:21]
W: bluez: maintainer-script-should-not-use-dpkg-maintscript-helper "dpkg-maintscript-helper" [postinst:25]
W: bluez: maintainer-script-should-not-use-dpkg-maintscript-helper "dpkg-maintscript-helper" [postinst:28]
W: bluez: maintainer-script-should-not-use-dpkg-maintscript-helper "dpkg-maintscript-helper" [postinst:31]
W: bluez: maintainer-script-should-not-use-dpkg-maintscript-helper "dpkg-maintscript-helper" [postinst:5]
W: bluez: maintainer-script-should-not-use-dpkg-maintscript-helper "dpkg-maintscript-helper" [preinst:11]
W: bluez: maintainer-script-should-not-use-dpkg-maintscript-helper "dpkg-maintscript-helper" [preinst:14]
W: bluez: maintainer-script-should-not-use-dpkg-maintscript-helper "dpkg-maintscript-helper" [preinst:21]
W: bluez: maintainer-script-should-not-use-dpkg-maintscript-helper "dpkg-maintscript-helper" [preinst:28]
W: bluez: maintainer-script-should-not-use-dpkg-maintscript-helper "dpkg-maintscript-helper" [preinst:32]
W: bluez: maintainer-script-should-not-use-dpkg-maintscript-helper "dpkg-maintscript-helper" [preinst:35]
W: bluez: maintainer-script-should-not-use-dpkg-maintscript-helper "dpkg-maintscript-helper" [preinst:38]
W: bluez: maintainer-script-should-not-use-dpkg-maintscript-helper "dpkg-maintscript-helper" [preinst:5]
W: bluez: no-manual-page [usr/bin/avinfo]
W: bluez-meshd: no-manual-page [usr/bin/mesh-cfgclient]
W: bluez-meshd: no-manual-page [usr/bin/meshctl]
W: bluez-tests: no-manual-page [usr/bin/b1ee]
W: bluez-tests: no-manual-page [usr/bin/bnep-tester]
W: bluez-tests: no-manual-page [usr/bin/btvirt]
W: bluez-tests: no-manual-page [usr/bin/gap-tester]
W: bluez-tests: no-manual-page [usr/bin/hci-tester]
W: bluez-tests: no-manual-page [usr/bin/hfp]
W: bluez-tests: no-manual-page [usr/bin/ioctl-tester]
W: bluez-tests: no-manual-page [usr/bin/iso-tester]
W: bluez-tests: no-manual-page [usr/bin/l2cap-tester]
W: bluez-tests: no-manual-page [usr/bin/mesh-tester]
W: bluez-tests: no-manual-page [usr/bin/mgmt-tester]
W: bluez-tests: no-manual-page [usr/bin/rfcomm-tester]
W: bluez-tests: no-manual-page [usr/bin/sco-tester]
W: bluez-tests: no-manual-page [usr/bin/smp-tester]
W: bluez-tests: no-manual-page [usr/bin/userchan-tester]
W: bluez: systemd-service-file-refers-to-unusual-wantedby-target bluetooth.target [usr/lib/systemd/system/bluetooth.service]
W: bluez-meshd: systemd-service-file-refers-to-unusual-wantedby-target bluetooth.target [us...

Following the dependency chain through to the cause for the i386 builds, binfmt-support should be added to the i386 allowlist. This may be a bug in evolution-data-server in the case libebook-contacts-1.2-4 can build without libphonenumber8-protobuf32 - for now, blanket-disabling that dependency in bluez's debian/control.

...Debian doesn't even have this build dependency in their bluez packaging, why do we have it in ours? If we need to have it, why isn't that a bug in Debian, and why aren't we working with the Debian Bluetooth maintainers to fix this?

Simon, I think it would be better to get libphonenumber fixed correctly instead of working around it.

https://launchpad.net/ubuntu/+source/libphonenumber/8.12.57+ds-4build1

https://ubuntu-archive-team.ubuntu.com/proposed-migration/noble_uninst.txt

In other words, asking an Archive Admin to build binfmt-support on i386. I suspect that it would need to be special-cased something like this, because jarwrapper is arch:all

https://code.launchpad.net/~jbicha/ubuntu-archive-tools/+git/ubuntu-archive-tools/+merge/457360

> In other words, asking an Archive Admin to build binfmt-support on i386.

I have stopped short of this so far because I'm entirely unsure if we still need that build dependency in the first place. Debian doesn't have it, and I'm not sure I see rationale on our end for it.

There is probably something I'm missing, but I don't have the justification myself to make such a request.

evolution-data-server still has uninstallable binaries on i386. You can ignore bluez for the binfmt-support issue.

However, for bluez, Ubuntu uses --enable-phonebook-ebook . There are other phonebook options; maybe what Debian uses works for Debian.

I appreciate everyone is frustrated. BlueZ isn't really staffed, it's just something I look at once or twice a year. The diff to Debian is shrinking over the long term, but again that's something I don't look at very often.

The justification for Ubuntu using a separate process for the past 6 years or so is documented in:
https://wiki.ubuntu.com/DesktopTeam/Bluetooth/BluezGit

Mostly it was because Debian was failing to release new BlueZ versions when I took over around 2017. And Ubuntu had already diverged from Debian in nontrivial ways. I've slowly been reducing the diff over time. That's a problem I did not create, but have been trying to solve, so please don't shoot the messenger.

If the Ubuntu process for this becomes contentious then I am happy for other people to own BlueZ and remove myself from ~bluetooth.

It looks like most of you are members of ~bluetooth already via ~ubuntu-core-dev so feel free to commit directly to https://git.launchpad.net/~bluetooth/bluez in future.

Thank you for working over the weekend on this. I would have resolved it myself on the Monday if someone answered the question in comment #11.

Also I've sent a bug report to Debian about their orig tarball not matching the upstream release tarball. I feel that's a discussion they need to have with upstream: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060242

Daniel, I don't want you to feel burned over this. That wiki page does seem quite rational, and I appreciate that you linked it. I'm reading some mixed feelings, so let me be clear: thank you for the work you *are* able to put into this.

Both Gianfranco and I are Ubuntu Core Developers but are also Debian Developers. An expectation of working with Debian is #3 of the Social Contract, "Don't Hide Problems" https://www.debian.org/social_contract
If Debian has problems in their packaging that do exist, please file a bug. If the maintainer is non-responsive in Debian, there is a process for non-maintainer uploads (and I would personally help you with this). My point of disagreement is not how we are addressing the Ubuntu uploads as much as how we are working with Debian to fix them. If the Debian team is non-collaborative, that should be addressed with the appropriate governance board. Either way, there should be a clear diff, whether the community has to help or not.

That being said, considerateness is part of Ubuntu's CoC. I will push my commits there in the morning. I do apologize again for any undue stress. I would rather address this head on, because it means a better Bluetooth package for our users.

Jeremy, the reason evolution-data-server has uninstallable binaries is because of the binfmt-supoort i386 allowlist issue at hand. Please confirm whether you have a customer story that will be impacted by this, or if we think a user will seriously need this support on i386 in 2024. I may be an Ubuntu Core Developer, but I respect that it's not my call alone to make, and the last thing I want to do is regress something for a customer. That's why I'm being up front about these issues.

Hello Daniel!

>Thank you for working over the weekend on this. I would have resolved it myself on the Monday if someone >answered the question in comment #11.

This is what a team does, help other people.
In this case I started answering to comment #11, I did fix->fix->fix DH_VERBOSE, fix something more, read manpage to check if compat level was the culprit, and found nothing on manual... So I just started looking at incorporating some dh fixes from debian packaging, and after 6 uploads on my ppa, the variables started being correctly parsed.

I still don't have an answer for that question, this is why I came up with a frustrated answer :)

Thanks for your work, and I hope with our suggestions in the future the maintenance of the package will become easier, with help of MoM.

For example your Debian bug #1060242 is already acked and confirmed, so I would say there is an extremely good cooperation with Debian, and I'm pretty sure with some Debian bugs, the maintenance for Ubuntu will become less and less painful. For example all this kind of issues would have been not a problem if the package would have been merged from Debian years ago.
This is why the best way to move forward is to me to just do a merge, and then use MoM in the future to grab new fixes and new releases. If we need a new upstream version, we can still help Debian package it, and then merge. This will make the current packaging a lot easier for the benefit of the community and sponsors (including fixing some bugs in Debian too)

This bug was fixed in the package bluez - 5.71-0ubuntu3

---------------
bluez (5.71-0ubuntu3) noble; urgency=medium

  * Denylist libebook1.2-dev on i386.

 -- Simon Quigley <email address hidden> Sat, 06 Jan 2024 14:25:13 -0600

Hello, I did the merge from Debian, now the packaging is really simpler, please have a look and upload if possible.

two patches are now with Debian bugs
<BTS> Opened #1060393 in bluez 5.67-1 by Gianfranco Costamagna (locutusofborg) «please update patch work-around-Logitech-diNovo-Edge-keyboard-firmware-i.patch». https://bugs.debian.org/1060393
<BTS> Opened #1060395 in bluez by Gianfranco Costamagna (locutusofborg) «please add simple testsuite from Ubuntu». https://bugs.debian.org/1060395

and ell-dev needs a i386 whitelist, not sure

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.

Simon, ell already has a recent approved MIR LP: #1971738

Ideally please open a new bug for the merge. This bug should remain Fix Released because we're already past the point in time when it was released to Noble.

Please also remember to commit proposed changes to https://git.launchpad.net/~bluetooth/bluez

BTW, having the previous Ubuntu version 5.71-0ubuntu3 on line 415 of the changelog doesn't feel ideal for people wanting to read the Ubuntu release history.

I'm pretty shocked, I ran a local sbuild with this and yet it still FTBFS. Doing an ubuntu2 upload as a fixup.

I would think that because we use the published tarball and not the upstream source like Debian does, that would affect our ability to ship the -test package.

Something's up with my local setup. I'll figure it out, fix it, and allow us to move forward here.

> Please also remember to commit proposed changes to https://git.launchpad.net/~bluetooth/bluez

Force pushing my local commits over, sorry not sorry. :)

> Simon, ell already has a recent approved MIR LP: #1971738

Er, the binary packages in question don't.

> Force pushing my local commits over, sorry not sorry. :)

Yeah it's fine this time. :)

next time we should make sure the changelog lists all the delta from Debian :)
But with the same tarball it will be easier to find it out

ell had an approved MIR but the only thing it was used for was iwd which is not currently in main. After the MIR is approved, something in main needs to depend on it (or add it to a main seed) and then the Archive Admins can promote it to main.

It looks like I was overly strict with the MIR compliance, which sort of balances out this bug as a whole. :)

After it migrates, Gianfranco or myself will try reverting ubuntu2 to see if we can push those two packages forward.

Let me know when it's safe to start work on LP: #2049352 for 5.72 or if someone else wants to do it.