[00:25] <wgrant> cjohnston: How'd you go today?
[00:27] <cjohnston> wgrant: so I'm a little confused about how we want to do this...
[00:28] <cjohnston> From talking to cprov, my understanding is that LP just gets diff's as plain text from librarian...
[00:28] <wgrant> Correct.
[00:28] <cjohnston> so LP doesn't have the notion of hunks...
[00:28] <wgrant> Correct.
[00:28] <cjohnston> He mentioned there may be code in bzrlib that we could reuse..
[00:29] <cjohnston> But other than that, I'm not even really sure how we want to go about attempting to do this?
[00:30] <wgrant> What do you mean by that last bit?
[00:30] <wgrant> bzrlib has some useful patch parsing utilities, eg in bzrlib.patches.
[00:30] <wgrant> It may be worth using them, but parsing manually isn't terribly difficult if not.
[00:30] <cjohnston> We had initially discussed emailing out relevant hunks for IC's
[00:30] <wgrant> Yes.
[00:31] <cjohnston> so if only one hunk has an IC, only email the one hunk
[00:31] <cjohnston> If it's plain text that LP has, how do we determine what one hunk is?
[00:32] <wgrant> The same way the 'patch' tool does.
[00:32] <wgrant> Diffs have a machine-readable format; that's what they're for.
[00:32] <wgrant> So we can work out what a hunk is.
[00:32] <wgrant> bzrlib.patches has utilities to do that, but the format is obviously simple enough that it's not a huge challenge to do it ourselves.
[00:32] <cjohnston> ok
[00:33] <wgrant> So we probably need to work out where the hunk dividers are, then map the comments we have onto hunks, so we can work out which hunks we care about.
[00:33] <cjohnston> ok..
[00:33]  * cjohnston will bbiab, guest just showed up
[00:39] <StevenK> I *think* codehosting has some code using bzrlib.patches for detecting hunks.
[10:08] <wgrant> cjwatson: Why didn't you use multiprocessing again?
[10:08] <wgrant> Also, os._exit? :)
[11:17] <cjwatson> wgrant: Because hell on earth getting the file descriptors set up properly
[11:17] <cjwatson> wgrant: os._exit is the correct thing to use in forked-but-not-execed child processes
[11:18] <cjwatson> I think the particular problem was that multiprocessing kind of wants you to use a Queue to pass things around between processes, and I couldn't make that work - I was getting can't-write-to-closed-fileobj IOErrors all over the place
[11:18] <cjwatson> and it was taking an unnecessarily long time to debug
[11:19] <wgrant> Hrm, OK.
[11:20] <cjwatson> I use os._exit in this kind of situation because I don't want double calls to atexit-registered functions happening under my feet
[11:21] <cjwatson> It just requires care to make sure that any fds that have been written to are flushed or closed first
[11:21] <wgrant> Yeah.
[11:24] <cjwatson> Wow, these constant hwdb test failures aren't incredibly annoying at all.
[11:26] <wgrant> Not at all!
[11:26] <wgrant> I deferred investigating them because we had approval to remove hwdb, but then that was sadly rescinded.
[11:27] <cjwatson> Sigh
[11:27] <wgrant> So maybe it's worth actually working out what's going on there at some point.
[11:27] <cjwatson> Didn't remove it fast enough :)
[11:27] <wgrant> At least it's not like polls, where we removed it and then had to put it back.
[11:29] <cjwatson> I'll spend a bit of time testing the apt source-caching backport today, I think.
[11:29] <cjwatson> 16:26 <cjwatson> yeah, I was going to just feed it a different db path
[11:29] <cjwatson> 16:27 <cjwatson> copy in the binary dbs and time source generation, then compare Packages/Sources
[11:29] <cjwatson> 16:27 <cjwatson> then time cached source generation
[11:30] <wgrant> :)
[11:30] <cjwatson> Built the tip of http://anonscm.debian.org/gitweb/?p=apt/apt.git;a=summary on precise, on advice from Michael; if that works then he'll do a backport to trusty
[11:30] <cjwatson> And then I think we'll SRU that into trusty and build the same source for precise
[11:30] <cjwatson> Until such time as pepo is on trusty
[11:31] <cjwatson> Michael wants to get most of this code into precise for other reasons, but since this is the riskiest bit of the trusty upgrade we might as well QA it in one step
[11:40] <wgrant> Agreed, a-f is the most problematic and least testable bit of the upgrade historically.
[12:35] <jtv> Does anyone know why "bzr branch lp:ubuntu/trusty/apache2" breaks?
[12:36] <jtv> This post says that lowering bzr's output verbosity works around the problem!  http://bridge.grumpy-troll.org/2014/06/four-miscellaneous-things/
[12:45] <jtv> I hit the same problem with lp:ubuntu/trusty/firefox but not with some other branches.
[12:48] <wgrant> jtv: Breaks with an error about LazyParentGraphCacheSomething having no such revision?
[12:49] <wgrant> Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))
[12:52] <jtv> Yup.
[12:52] <wgrant> https://bugs.launchpad.net/bzr/+bug/888615
[12:52] <_mup_> Bug #888615: UDD branch freshness checker breaks on incomplete history <Bazaar:Confirmed> <https://launchpad.net/bugs/888615>
[12:53] <jtv> Nasty.  It's clearly not just the freshness checker...
[12:53] <wgrant> It is.
[12:53] <wgrant> If you disable it, it'll work fine.
[12:54] <jtv> Oh, and the verbosity setting controls that?
[12:54] <wgrant> I assume it makes it sufficiently quiet that the freshness checker doesn't bother running, as it won't display its message.
[16:21]  * cjwatson deploys germinate parallelisation