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? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/2047780 Title: BlueZ release 5.71 Status in bluez package in Ubuntu: Fix Committed Bug description: Release BlueZ 5.71 to noble. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/2047780/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
