[04:52] <pitti> Good morning
[04:53] <pitti> infinity: the machinery already auto-retries three times (with 5 mins waiting in between), so this is a consistent failure
[04:53] <Unit193> pitti: Howdy.  So do you also speak Klingon?
[04:53] <pitti> infinity: cleaning up now, apparently some hung VM which is eating quota
[04:54] <pitti> infinity: queues are notoriously long right now due to lcy01 being down
[04:54] <pitti> Unit193: Qapla' !
[04:54] <pitti> Unit193: nuQneH?
[04:55] <Unit193> I do not, no.
[04:57] <pitti> Unit193: "nuQneH" is the usual greeting -- it's literally "what do you want?" (Klingons don't have anything more polite)
[04:57] <Unit193> Aha!  I see.  Nice!  I saw you on LP with it listed, wondered.
[05:01] <pitti> infinity: ah! I see the bug how this could happen ("Multiple server matches found for 'adt-wily-amd64-nvidia-graphics-drivers-304-20150914-155306', use an ID to be more specific")
[05:05] <pitti> infinity: filed as bug 1495788 in case you care
[07:10] <dholbach> good morning
[08:34] <Mirv> chrisccoulson: can you check bug #1482219 - upstream has released a new version and gotten it signed, and unaware what more they could do
[08:35] <Mirv> chrisccoulson: mailing list message http://lists.puimula.org/pipermail/libvoikko/2015-September/000820.html (feel free to reply)
[08:36] <Mirv> since Firefox release is next week, it's a bit in a hurry now because the new mozvoikko would need to be distributed for LTS users too
[08:37] <Mirv> or it simply stops working
[09:58] <doko> jamespage, ceilometer, glance, heat are still dep-wait. for the latter two I can't find any packages
[09:58] <jamespage> doko, nope - they are pending acceptance into Debian exp first - they are in the queue tho
[09:58] <jamespage> for ceilometer I need to raise the MIR for jsonpath-rw-ext - on my list for today
[09:59] <jamespage> castellan and magnumclient still pending
[09:59]  * pitti watches the trusty bcmwl test install lts-vivid kernel
[10:01] <pitti> preparing the instance now takes achingly long -- but oh well, we have infinite capacity to run in parallel, don't we :)
[10:01] <pitti> err sorry, ECHAN
[10:01] <pitti> apw: ^ that was for you
[10:03] <apw> heh
[10:30] <pitti> Riddell: just FYI (in lieu of email notifications), new packagekit is stuck, apparently aptdaemon needs some porting
[10:34] <Riddell> mm yes
[10:34] <Riddell> mvo: any input on that? ^^
[10:35] <Riddell> for some reason it works on arm and powerpc but not on i386 and amd64.  failures are usually the other way around
[10:40] <ogra_> Riddell, just drop these deprecated arches then ;)
[10:41] <Laney> looks like it failed everywhere to me
[10:44] <Riddell> Laney: where are you looking? the aptdaemon line here says only on those two arches http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#packagekit
[10:47] <Laney> Riddell: oh, I went http://autopkgtest.ubuntu.com/packages/a/aptdaemon/
[10:47] <Laney> ^to
[10:47] <Laney> I wonder why those say pass
[10:48] <Riddell> mm right they all fail, but at least it's all the same failure
[11:23] <mdeslaur> @pilot in
[14:16]  * dholbach hugs Laney
[14:18] <Laney> nobody tell him that I just sneakily moved my patch pilot shift from now to tomorrow :-)
[14:18]  * Laney hugs dholbach back
[14:19] <dholbach> Laney, I really never meant the schedule to nail people to a certain date or time :)
[14:19] <Laney> yeah I know, I don't usually mind moving it
[14:40] <flexiondotorg> cyphermox, Thanks for your help yesterday.
[14:41] <flexiondotorg> cyphermox, I'd like to make a small change to the network manager packaging. Which repo should I grab to submit a merge proposal to just the 'debian/' folder?
[14:43] <cyphermox> lp:~network-manager/network-manager/ubuntu
[14:46] <flexiondotorg> cyphermox, Thanks.
[14:49] <cyphermox> lemme know, there may have to be some patching too
[14:54] <flexiondotorg> cyphermox, Actually, it is network-manager-applet I need to change.
[14:54] <Odd_Bloke> infinity: cjwatson: Once we have built an image on Launchpad, we pull it down, unpack it, and then 'purge linux-* grub-*' and create a tarball from that.
[14:54] <flexiondotorg> Only debian/control.
[14:56] <Odd_Bloke> infinity: cjwatson: I've been playing around with doing it in a hook by copying the chroot and modifying that, but I'm hitting problems with uninstalling kernels inside the chroot (because it tries to update MBR etc.).
[14:56] <pitti> bdmurray: hmm, didn't we use to have test results (or at least failures) on http://people.canonical.com/~ubuntu-archive/pending-sru.html?
[14:56] <Odd_Bloke> infinity: cjwatson: Is there a more live-build-y way I could do this, or shall I try doing what we do at the moment (with mounting the image and modifying it as a properly mounted partition)?
[14:57] <cjwatson> Odd_Bloke: If you're just going to purge kernels and boot loaders, I'm not sure why you're going to the effort of installing them in the image in the first place?
[14:57] <Odd_Bloke> cjwatson: We ship both the image (with kernel and boot loaders) and the tarball (without).
[14:58] <bdmurray> pitti: Yes we did
[14:58] <cyphermox> flexiondotorg: then lp:~network-manager/network-manager-applet/ubuntu although it looks like it's missing revision -0ubuntu7
[14:59] <cjwatson> Odd_Bloke: Can you make use of lb_binary_rootfs, perhaps, which I believe is called before the kernel and boot loader are installed?
[14:59] <hallyn> is there a known bug about dhclient (run by hand) in wiliy not updating the nameserver list?  is /etc/resolv.conf.d/tail supposed to be a symlink to nonexistent 'original' file?
[14:59] <hallyn> (had to add 8.8.8.8 to /etc/resolv.conf myself)
[15:01] <pitti> bdmurray: was that taken down deliberately, or did some change in britney break this?
[15:01] <pitti> bdmurray: are you parsing the html for that, or the yaml? (the latter seems much easier)
[15:01] <bdmurray> pitti: nothing has changed with sru-report afaik, the yaml
[15:02] <bdmurray> pitti: https://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/sru-report#L614
[15:03] <infinity> Odd_Bloke: Yeah, you could be building both the image and the tarball as artifacts of your live-build process.
[15:03] <infinity> Odd_Bloke: Sure, it doubles the size of the LP bits, but also, it means your bits are all in one place, which is lovely.
[15:06] <seb128> Riddell, hey, did you notice that your packagekit update breaks aptdaemon (I guess https://bugs.launchpad.net/ubuntu/+source/aptdaemon/+bug/1494891 is due to the new version) and is blocked in proposed due to that?
[15:06] <seb128> https://bugs.launchpad.net/ubuntu/+source/aptdaemon/+bug/1494891
[15:07] <bdmurray> pitti: 'reason' seems to be empty in most of the entries in the yaml file for vivid
[15:09] <pitti> bdmurray: indeed; it's there for wily, but not for stables
[15:09] <bdmurray> pitti: it used to be there though...
[15:10] <pitti> bdmurray: yeah; thanks for the pointer, I'll file a britney bug for it and pile it on my list
[15:11] <pitti> bug 1496020
[15:12] <Riddell> seb128: yep, most annoying this aptdaemon, I'm trying to recreate the issue and see if I can fix it
[15:13] <seb128> Riddell, the autopkgtest are failing so that should be fairly easy to reproduce
[15:13] <seb128> also if that the lp bug I pointed it's probably some obvious issue, attributes that got removed
[15:14] <Odd_Bloke> cjwatson: linux-image and grub are installed in to the chroot.
[15:15] <pitti> seb128: isn't that an API break?
[15:16] <seb128> pitti, I guess it is
[15:16] <cjwatson> Odd_Bloke: Perhaps you can arrange to install them in one of the lb_binary stages instead?  Or is that too difficult due to dependencies?
[15:16] <pitti> (wrt. "needs full transition", FFE, examination of what is affected, etc.)
[15:16] <seb128> pitti, yeah, it should probably require a ffe, quite some things changed in packagekit
[15:16] <seb128> even if that version is not the one dropping support for plugins yet
[15:17] <seb128> Riddell, ^
[15:25] <mdeslaur> @pilot out
[15:31] <pitti> mdeslaur, infinity, stgraber, slangasek, kees: TB meeting reminder in 30 mins -- perhaps you can have a look at my SRU policy proposals before?
[15:31] <mdeslaur> pitti: ack
[15:53] <tedg> pitti: Is there a way to make dbusmock use a direct dbus connection instead of a bus?
[15:53] <pitti> tedg: what is a "direct" connection? to a private bus?
[15:54] <pitti> tedg: dbusmock is essentially just syntactic sugar around dbus-python; you can put the mocks on any bus, not just the system or session one
[15:54] <tedg> pitti: Hmm, okay. And basically set the connection in init.
[15:56] <pitti> tedg: unless you use DBusTestCase's convenience functions to start a private sytsem/session bus, it's the caller's responsibility to create the bus connection, yes
[15:57] <pitti> tedg: if your test suite is python, then I still think it's much easier to use .start_session_bus() instead of bothering with the setup of your own
[15:57] <pitti> but if your test suite is !python, you have to anyway
[15:58] <tedg> pitti: Trying to test with a private connection instead of a full bus. The full bus case I know works, but it seems the private connection case is broken. Well, I don't know, but I don't have coverage on it currently, so it is suspect.
[15:58] <tedg> pitti: The test suite is C++ using libdbustest to start the bus, which is easy enough. But this is a bit different.
[15:58] <pitti> tedg: a private connection still needs to go to a full bus; it just won't be the "well-known" system/session/user one, but other than that it's just another bus? or what do you mean?
[15:58] <tedg> pitti: No, without a dbus-daemon, so no Hello.
[15:58] <dobey> tedg: you mean the p2p socket connection, versus the shared dbus connection?
[15:59] <tedg> Yes
[15:59] <pitti> tedg: ah -- that's the bit I'm not aware of (peer to peer)
[16:00] <tedg> Wish cgmanager was just on the system bus. But, eh, drop this code when we move to systemd for the session.
[16:01] <pitti> infinity, stgraber, kees: TB o'clock
[16:01] <infinity> pitti: Already there.
[16:36] <bdmurray> Laney: Do you know if the ubuntu-sponsoring code is pulled automatically?
[16:36] <Laney> bdmurray: I sure didn't do anything to make it get pulled
[16:36] <Laney> so it seems so :)
[16:37] <bdmurray> Laney: did you think about using any of the teams in the package to team mapping?
[16:39] <Laney> bdmurray: remind me of the link quickly?
[16:39] <Laney> the short answer is no, because the set information was already there
[16:40] <Laney> and it would have been more work to fetch package subscribers or the map itself
[16:40] <Laney> sounds like a good idea though
[16:42] <bdmurray> Laney: I'm suggesting reviewing the teams in it to add to the list of teams. It's output is here: http://people.canonical.com/~ubuntu-archive/package-team-mapping.json
[16:45] <Laney> bdmurray: those don't really map neatly to packagesets in the main
[16:45] <Laney> It would probably be nice as a data source though
[16:47] <Laney> I mean "to uploading teams"
[16:53] <tdaitx> bdmurray, dh-exec FTBFS in core because bats is in universe instead of main, I need an owning team, doko suggested to subscribe foundations and said you should be able to do it
[16:53] <tdaitx> bdmurray, https://bugs.launchpad.net/ubuntu/+source/bats/+bug/1496050
[16:54] <bdmurray> tdaitx: done
[16:55] <slangasek> bdmurray: should one of the team-subscribing scripts be added to ubuntu-qa-tools or somewhere?
[16:55] <tdaitx> bdmurray, thanks =)
[22:11] <doko> finally, firefox and thunderbird migrated to -release after five months
[22:12] <ogra_> gut ding will weile haben ;)
[23:00] <hallyn> slangasek: hey - i had pushed 0.39-2 cgmanager to mentors, but it seems to be gone.  did you sponsor it?  (I don't see it in the archive)
[23:01] <hallyn> or did i err somewhere.  i can re-push
[23:01] <slangasek> hallyn: I did not sponsor it; I also can't figure out mentors' web UI for the life of me, I assume that it's just broken beyond repair and wait for sponsorees to tell me where to download stuff
[23:03] <hallyn> slangasek: ok, lemme repush and post the .dsc url :)
[23:09] <hallyn> slangasek: http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.39-2.dsc
[23:09] <hallyn> should fix all the lintian warnings (and do nothing more)
[23:45] <slangasek> hallyn: if cgm-release-agent is a kernel callback, there's only one of them for the system; why install it in a multiarch directory?
[23:55] <slangasek> hallyn: ah I see, you were misled by debhelper's own default behavior for libexecdir, which was a terrible failure on my part
[23:57] <slangasek> hallyn: I see you added a lintian override for xs-testsuite; nack on this - either the field should be renamed from xs-testsuite to testsuite as the lintian message suggests, or it should be left un-overridden for future tracking.  And for the cgmanager-utils conflicts, I don't see any reason that Breaks would not suffice, can you explain?