[10:45] <mitya57> doko: both qtwebengine and kdb are now fixed in -proposed
[10:47] <doko> mitya57: ta
[11:40] <doko> jamespage: please merge/sync python-testtools, bzr is dep-wait on it.
[11:41] <doko> it's Debian openstack package
[11:47] <doko> jbicha, seb128: udisks2 needs another merge, gnome-disk-utility is dep-wait
[12:02] <LocutusOfBorg> jbicha, gnome-shell is a "please steal it from me"
[12:18] <seb128> doko, right, that's known but blocked on libblockdev that needs to be MIRed first
[13:12] <jbicha> LocutusOfBorg: I already did ;)
[13:41] <LocutusOfBorg> <3 jbicha
[13:42] <jbicha> LocutusOfBorg: but if you want that gnome-shell/virtualbox bug SRU'd to artful, you'll need to add the SRU template to the bug description
[13:56] <LocutusOfBorg> jbicha, I don't even know if it is worth the fix or not
[13:56] <LocutusOfBorg> and if it fixed at the end completely the issue
[13:56] <LocutusOfBorg> vbox in bionic is utterly broken it seems
[13:56] <jbicha> I haven't had much of a problem with VirtualBox
[13:58] <LocutusOfBorg> host or guest?
[13:59] <LocutusOfBorg> setting up a bionic or artful machine is painful
[13:59]  * Faux uses virtualbox pretty heavily on an artful host.
[14:00] <LocutusOfBorg> Faux, what is the guest
[14:00] <Faux> XP, Win7.
[14:00] <jbicha> I have bionic guest on artful host, doesn't feel very painful here
[14:04] <LocutusOfBorg> Faux, the problem seems to be wayland or so
[14:04] <LocutusOfBorg> and new kernels
[14:05] <Faux> Aha. As an nvidia user, I will never get to use wayland on the host.
[14:31] <LocutusOfBorg> jbicha, why not merging from Debian?
[14:31]  * LocutusOfBorg gnome-shell is context
[14:49] <jbicha> because there is substantial diff and I wanted to get the 3.26.2 SRU started sooner
[18:47] <TJ-> nacc: whilst you're looking at my fixes for ycmd  maybe you'd look at couple of other papercuts fixes (related to vim) I've prepared debdiffs for: bug #1575802  and bug #1726441
[18:48] <nacc> TJ-: i'll add them to my list :) they are lower priority generally for me right now, but i should be able to sponsor them sometime soon
[18:53] <nacc> TJ-: I promise I will at least look tonight
[18:53] <nacc> TJ-: if i read the ycmd bug, it needs a xenial only task? can you help make sure that there is a comment in each (if it's already there, it's fine) saying where the fix is needed (including 16.04, 17.04, 17.10, 18.04 as possiblities) and where ot?
[18:54] <nacc> *not
[20:03] <TJ-> nacc: will do :)
[20:03] <nacc> TJ-: thanks!
[20:06] <TJ-> nacc: argh! my membership of bug-control has lapsed. I'll have to re-join
[20:07] <nacc> TJ-: if you do the nomination, i can approve them
[20:07] <nacc> I believe anyone can nominate, at least
[20:07] <nacc> TJ-: i just want to make sure the bug stat is right
[20:10] <nacc> *status, sorry
[20:29] <TJ-> nacc: no nomination links for me :(
[20:30] <nacc> TJ-: ok, can you add comments with the relevant info?
[20:39] <TJ-> will do; sorting out my bugcontrol membership too
[21:27] <niedbalski> bdmurray, ping
[21:27] <bdmurray> niedbalski: howdy
[21:28] <niedbalski> bdmurray, hey bryan, sorry to pester you about this, could you check the verification for LP: #1657256? also, not sure why the Trusty patch wasn't moved into -proposed (it's currently seating in unapvd).
[21:31] <bdmurray> niedbalski: There are some autopkgtest failures for zesty w/ diaspora-installer
[21:32] <niedbalski> bdmurray, where I can look for those errors?
[21:33] <bdmurray> https://people.canonical.com/~ubuntu-archive/pending-sru.html
[21:37] <niedbalski> bdmurray, hard to tell if those failures are related to the change though.
[22:31] <superm1> Hi all.  I was interested in fixing autopkgtest for a package I maintain (fwupd).  I've got it working on debci now, but on Ubuntu it fails with an error i'm not sure how to properly fix.  http://autopkgtest.ubuntu.com/packages/fwupd/bionic/amd64 the particular error is "Failed to restart dbus.service: Operation refused, unit dbus.service may be requested by dependency only (it is configured to refuse manual start/stop)." which yes,
[22:31] <superm1> I'm trying to manually start dbus because it's needed in the test environment. ....  The debian/tests i'm using is here: https://github.com/hughsie/fwupd/tree/master/contrib/debian/tests
[22:33] <infinity> superm1: Depending on dbus should be all that's required to have it started in the test environment.
[22:34] <superm1> infinity: really?  OK well that's an easy enough fix, thanks
[22:34] <infinity> superm1: "The test enviornment" is a regular system (in a VM or container, depending on arch).  So, yes, depending on daemons should start them the same way it would on your desktop or laptop.
[22:35] <infinity> superm1: Not like a build chroot, where we intentionally hamstring daemons.
[22:35] <superm1> Alright, thanks
[22:39] <infinity> superm1: Oh, but looking at the script, it seems the intent there wasn't to start dbus, but maybe to reload your config?
[22:39] <infinity> superm1: If so, it wanted to be reload, not restart.
[22:40] <superm1> no, it was to start dbus
[22:40] <infinity> superm1: (and reload does work)
[22:40] <infinity> superm1: Kay.  If the intent was to use restart to start, indeed, dbus should alread be started.
[22:40] <superm1> I just had this thought that it needed explicit starting since that's how i'm used to working in chroots and stuff like travis CI
[22:41] <infinity> superm1: Yeah, debci is (IMO) better than that, in the sense that it's really testing how your stuff behaves on a real non-hobbled Debian/Ubuntu system.
[22:41] <infinity> superm1: If you have to do any synthetic setup after installing your packages, it's a pretty crap test of how your package works, after all.
[22:41] <superm1> infinity: yeah true
[22:42] <superm1> the peculiar thing to me though; why was I not hitting this in debian's debci?
[22:42] <superm1> It's been working just fine there
[22:44] <infinity> Their dbus service might not block restart like ours does.
[22:45] <superm1> ah yeah; that looks to be the case: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1540282
[22:47] <infinity> Yeahp, just checked in a sid chroot, they don't block restart.  They really should, for the same reasons.
[22:47] <infinity> dbus restart is amazingly harmful.
[22:48] <infinity> I'm going to blame pitti, who probably should have committed that back to Debian. :P