DBus 1.10

[Iain Lane]

We should move to dbus 1.10

  http://cgit.freedesktop.org/dbus/dbus/tree/NEWS

upstream recommend that we package "release candidates" in the distro.

There's a development release in experimental that we could put in a PPA.

Notes:

  - Move dbus-uuidgen unit file patch to using a tmpfiles.d snippet ("L /var/lib/dbus/machine-id - - - - /etc/machine-id") as if we're booting systemd then we have /etc/mamchine-id
  - Move our patches to {system,session}.conf to /usr/share/dbus-1/s*.d/ubuntu.conf if they are still necessary
  - Can drop all apparmor patches except for aa-get-connection-apparmor-security-context.patch

[Tyler Hicks (tyhicks)]

IMPORTANT: We can drop all but *one* AppArmor patch. aa-get-connection-apparmor-security-context.patch must stay until we've switched everything over to the new API that was taken upstream.

Also, it looks like another patch, unrelated patch, may be dropped. See bug 1479771.

[Iain Lane (laney)]

On Thu, Jul 30, 2015 at 02:51:17PM -0000, Tyler Hicks wrote:
> IMPORTANT: We can drop all but *one* AppArmor patch. aa-get-connection-
> apparmor-security-context.patch must stay until we've switched
> everything over to the new API that was taken upstream.

Where is this work tracked?

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

[Tyler Hicks (tyhicks)]

On 2015-07-30 15:03:37, Iain Lane wrote:
> On Thu, Jul 30, 2015 at 02:51:17PM -0000, Tyler Hicks wrote:
> > IMPORTANT: We can drop all but *one* AppArmor patch. aa-get-connection-
> > apparmor-security-context.patch must stay until we've switched
> > everything over to the new API that was taken upstream.
>
> Where is this work tracked?

We can't switch anything over to the new D-Bus API until libapparmor
2.10 is available in Wily. That upload should hopefully happen today and
then I can create a bug against all of the packages that need to be
switched over. I will leave a link to the new bug in this bug's
comments.

[Simon McVittie (smcv)]

> - Move dbus-uuidgen unit file patch to using a tmpfiles.d snippet ("L /var/lib/dbus/machine-id - - - - /etc/machine-id") as if we're booting systemd then we have /etc/mamchine-id

I'll probably do that in the next dbus upload to Debian.

[Simon McVittie (smcv)]

I've released 1.9.20, which I'm treating as 1.10 rc1. 1.10 will hopefully be identical to 1.9.20 except for versioning and NEWS.

> - Move dbus-uuidgen unit file patch to using a tmpfiles.d snippet

Done in Debian experimental (1.9.20-1).

[Iain Lane (laney)]

On Fri, Aug 07, 2015 at 12:06:40PM -0000, Simon McVittie wrote:
> I've released 1.9.20, which I'm treating as 1.10 rc1. 1.10 will
> hopefully be identical to 1.9.20 except for versioning and NEWS.
>
> > - Move dbus-uuidgen unit file patch to using a tmpfiles.d snippet
>
> Done in Debian experimental (1.9.20-1).

Thanks. Will try to merge it in next week, g++5 fun notwithstanding.

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

[Iain Lane (laney)]

Going to work on this tomorrow and over the next few days as a side task at Debconf, FWIW.

[Simon McVittie (smcv)]

Great. As far as I'm concerned, I can ship a 1.10 that is functionally identical to 1.9.20 any time; for now, I've been holding off on actually doing that to give the biggest user of D-Bus-with-AppArmor a chance to try it :-)

I've been avoiding uploading to Debian unstable because the release team asked people not to (as you said, g++-5 fun), but eventually I'll time out and upload it anyway.

[Iain Lane (laney)]

Done, test packages in ppa:laney/experimental. I was able to drop most of our delta - the remaining few things are attached. aa-get-connection-apparmor-security-context.patch should be able to go too once all users are ported off it.

Let me know if you see anything wrong. I'd like to upload in a couple of days (feature freeze is Thursday) if possible.

[Simon McVittie (smcv)]

As far as I'm concerned, ship it! (Subject to whatever QA is needed within Ubuntu.) I'm glad the delta has got smaller.

If you badly need 1.10.0 tomorrow, that can happen. It will likely be functionally identical to 1.9.20, so that should be an easy freeze exception in any case.

Regarding your changes:

The patch for LP: #1438612 was rejected upstream: Lennart said it's wrong, and the systemd author's opinion seems relevant here. Accordingly, I'm not going to take that in Debian or upstream. If it's necessary in Ubuntu, that's your call.

dbus.user-session.upstart seems way more complicated than it needs to be, but it's what you have now, so it isn't going to be any worse than 1.8.

User session bits for future reference:

If Upstart is still a first class citizen, and you only need one socket per XDG_RUNTIME_DIR, I would recommend using unix:path=$XDG_RUNTIME_DIR/bus like dbus-user-session does under systemd, instead of doing weird things with abstract sockets. libdbus, sd-bus and recent (2.45.x) GLib will try that address by default if DBUS_SESSION_BUS_ADDRESS is not set, although I still recommend setting it for backwards compat.

If you have a requirement for multiple login sessions (with their own buses) per XDG_RUNTIME_DIR, you could use the closest possible, unix:path=$XDG_RUNTIME_DIR/$YOUR_SESSION_ID.bus or $XDG_RUNTIME_DIR/login-$YOUR_SESSION_ID/bus or something.

In the systemd --user world, I recommend the new dbus-user-session package as the best way to get a bus per XDG_RUNTIME_DIR. It is currently useless on non-systemd, but should be harmless there.

I do not plan to support dbus-launch on non-X11, and I hope it can wither into irrelevance over time. I would like to be able to say that Wayland and Mir systems will always use XDG_RUNTIME_DIR/bus for their D-Bus socket.

[Tyler Hicks (tyhicks)]

From the AppArmor perspective, the 1.9.20 debdiff gets the green light. I installed the packages from your ppa and then was able to successfully run the dbus_*.sh tests in the AppArmor regression test suite (http://bazaar.launchpad.net/~apparmor-dev/apparmor/master/files/head:/tests/regression/apparmor/). Also, the AppArmor mediation tests in the QRT test-dbus.py script (http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/view/head:/scripts/test-dbus.py) passed.

The test-dbus.py script did catch something unrelated to AppArmor. First, the test/tap-test.sh.in file isn't shipped in the release tarball (https://bugs.freedesktop.org/show_bug.cgi?id=91684) so `make check` will always fail. However, even after pulling in that file from the git tree, `make check` is still failing on the test-bus.sh test. It probably isn't worth blocking the upload over but I wanted to mention it.

[Tyler Hicks (tyhicks)]

Test log from the failed test-bus test.

[Tyler Hicks (tyhicks)]

I forgot to mention that I manually tested the GetConnectionAppArmorSecurityContext and GetConnectionCredentials bus methods. Both work as expected.

[Iain Lane (laney)]

On Tue, Aug 18, 2015 at 05:05:10PM -0000, Simon McVittie wrote:
> As far as I'm concerned, ship it! (Subject to whatever QA is needed
> within Ubuntu.) I'm glad the delta has got smaller.
>
> If you badly need 1.10.0 tomorrow, that can happen. It will likely be
> functionally identical to 1.9.20, so that should be an easy freeze
> exception in any case.

No. We can upload bug fixes for a while yet, so whenever 1.10 happens
we'll just take it.

>
> Regarding your changes:
>
> The patch for LP: #1438612 was rejected upstream: Lennart said it's
> wrong, and the systemd author's opinion seems relevant here.
> Accordingly, I'm not going to take that in Debian or upstream. If it's
> necessary in Ubuntu, that's your call.

I don't know much about this patch myself, but I guess we need to go
around and add the After= annotations before we can get rid of it. Maybe
we should grab pitti and ask.

> dbus.user-session.upstart seems way more complicated than it needs to
> be, but it's what you have now, so it isn't going to be any worse than
> 1.8.
>
> User session bits for future reference:
>
> If Upstart is still a first class citizen, and you only need one socket
> per XDG_RUNTIME_DIR, I would recommend using
> unix:path=$XDG_RUNTIME_DIR/bus like dbus-user-session does under
> systemd, instead of doing weird things with abstract sockets. libdbus,
> sd-bus and recent (2.45.x) GLib will try that address by default if
> DBUS_SESSION_BUS_ADDRESS is not set, although I still recommend setting
> it for backwards compat.
>
> If you have a requirement for multiple login sessions (with their own
> buses) per XDG_RUNTIME_DIR, you could use the closest possible,
> unix:path=$XDG_RUNTIME_DIR/$YOUR_SESSION_ID.bus or
> $XDG_RUNTIME_DIR/login-$YOUR_SESSION_ID/bus or something.

I don't think we have such a requirement - will try to simplify this
later on (and will ask for review then).

> In the systemd --user world, I recommend the new dbus-user-session
> package as the best way to get a bus per XDG_RUNTIME_DIR. It is
> currently useless on non-systemd, but should be harmless there.
>
> I do not plan to support dbus-launch on non-X11, and I hope it can
> wither into irrelevance over time. I would like to be able to say that
> Wayland and Mir systems will always use XDG_RUNTIME_DIR/bus for their
> D-Bus socket.

Don't know about Mir, but ideally we would just use the same thing
there.

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

[Iain Lane (laney)]

Uploaded, btw.

[Simon McVittie (smcv)]

> However, even after pulling in that file from the git tree, `make check` is still failing on the test-bus.sh test.

I think this might actually be a bug in libcap-ng older than 0.7.7: <https://bugs.debian.org/796167>. Workaround and more analysis available on <https://bugs.freedesktop.org/show_bug.cgi?id=91684>.

[Launchpad Janitor (janitor)]

This bug was fixed in the package dbus - 1.9.20-1ubuntu2

---------------
dbus (1.9.20-1ubuntu2) wily; urgency=medium

  * debian/dbus.postinst: Check if /run/dbus exists before writing to a file
    there. If it doesn't then the system bus isn't running so we don't have
    anything to restart anyway.

 -- Iain Lane <email address hidden> Thu, 20 Aug 2015 11:09:58 +0100

[Simon McVittie (smcv)]

1.10.0 is now available upstream and will reach Debian experimental shortly. Packaging is in Debian git as usual.

I fixed the two issues that Tyler reported in upstream dbus, and applied Iain's /run/dbus fix in the Debian packaging.