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 [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dbus in Ubuntu. https://bugs.launchpad.net/bugs/1477086 Title: DBus 1.10 Status in dbus package in Ubuntu: Triaged Bug description: 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1477086/+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
