[00:50] huh found a bug [00:51] blr: In what? [00:51] _validateImportExternal, validate_import_url was only called with one argument [00:52] The tests didn't catch that? [00:52] not until now apparently... [00:52] just fixing up all the doctests I've broken with +setbranch -> +configure-code [00:52] There may indeed be a few. [04:57] cjwatson: the str(line) was needed as line is a Context/RemoveLine [05:20] cjwatson: have a working failing test, you were correct, thanks [05:20] "working failing test" ... [05:31] blr: Beware that there are in fact more test failures than buildbot reports. Search for "failure:" in the run's stdio to find them all. [05:31] blr: The subunit stream has been corrupted. [05:31] ah some unittests too, thanks [05:33] hmm, any idea what's going on with the product-registry doctest? [05:33] Which? [05:33] xx-project-registry.txt, the "..." matcher doesn't appear to be matching "api.luanchpad.dev/beta" [05:34] Oh, you put too much faith in doctests. [05:34] All ... will show as mismatches in the difference output. [05:34] You need to ignore them and find the real different; in this case that inferred_vcs was added. [05:35] ah of course, thanks [05:53] wgrant: should I be concerned that we're bumping query limits? [05:54] fairly rhetorical question.. but something I should think about? [05:54] blr: I'm not sure why it would be doing that there. Is something invoking inferred_vcs, perhaps? Should it be? [05:55] wgrant: slightly confused that it blew up on blueprints [05:56] also, what an excellent idea, wasn't aware of these tests. [05:57] have fixed everything, will --testfix after dinner [07:44] wgrant: could you have a look over this please when convenient https://code.launchpad.net/~blr/launchpad/ui-project-setbranch/+merge/262942 [07:48] blr: Did you work out what the extra queries were? [07:48] Oh, it'll be inferred_vcs in the embedded JSON representation, of course. [07:48] blr: r=me, thanks. [07:53] yep [07:53] thanks [08:44] missed one -_- [08:59] wgrant: will just top-approve this one, hope that's okay (small fix) [09:02] blr: Yep, trivial testfixes are fine to self-approve unless they're stupid :) [09:18] wgrant: Hm, https://launchpad.net/ubuntu/+source/libmoox-cmd-perl/0.013-2/+build/7541385 should have been a dep-wait, surely? [09:20] wgrant: Oh, no, never mind, that's uninstallability more than one level deep [09:22] wgrant: This is maybe a little unfortunate, because I think it really is just that one. Probably an sbuild bug in that it should be using "apt-get build-dep". [09:23] Yeah, everything's fine in that build-dependency set apart from the version restriction [09:27] Tempting to do http://paste.ubuntu.com/11772424/ [09:56] cjwatson: Will that reliably cope with alternatives? [09:56] There are some complexities there. [09:58] build-dep should in general cope better than install. The only reason I didn't do it in the first place in that code was that I was being conservative when fixing up cross handling. [09:58] But it certainly makes sense to check that. [09:58] Hm, it's perhaps possible that it would break the --no-resolve-alternatives case ... [10:00] * cjwatson leaves an XXX comment for himself to check that later [11:21] wgrant: https://code.launchpad.net/~cjwatson/launchpad/side-by-side-diff/+merge/262768 should be worth another look now. === dpm_ is now known as dpm [20:56] morning [22:22] cjwatson: if you're about by any chance, added a test and fixed that bug. [22:50] wgrant: do you know if there's a way to influence which ssh key is used for sftp dput uploads? Unless there's a sneaky thing in bzrlib I can't see one :( [22:52] bigjools: just make sure the right one is in your ssh agent [22:53] lifeless: what if there's no agent? [22:53] bigjools: then as long as its in the search path of default keys [22:53] bigjools: or you can put it in the ssh command as an explicit parameter [22:53] bigjools: (see bzr help config) [22:53] lifeless: there's not much configuration you can do for dput though [22:54] the plugin does: t = bzrlib.transport.get_transport("sftp://%s@%s/%s" % (login, fqdn, incoming)) [22:55] bigjools: yes, that doesn't invalidate what I said [22:56] lifeless: there's no ssh command though and I can't see how to select a specific key [23:08] digging [23:11] lifeless: It looks like the bzrlib sftp transport ignores the .ssh/config but it should not according to what I read elsewhere :/ [23:11] bigjools: if its using paramiko rather than openssh that could happen [23:11] I believe it's paramiko, yes [23:11] well [23:11] we always use some bits of paramiko [23:12] but [23:12] its whether the channel setup is paramiko or ssh [23:13] bigjools: see bzr help authentication [23:13] bigjools: it might help, I haven't re-read it all [23:13] cheers, reading [23:15] looks great, but nothing about keys :( [23:16] ahha [23:16] BZR_SSH [23:16] BZR_SSH Path to SSH client, or one of paramiko, openssh, sshcorp, [23:16] plink or lsh. [23:17] try setting that to openssh [23:17] it may cause an error but then you'll know why paramiko was being used [23:17] aha! [23:17] (bzr help env-variables) [23:17] I found the bzrlib code that only uses id_dsa or id_rsa :( [23:17] yeah, thats in the paramiko channel setup [23:18] which TBH you don't want to use anyway [23:23] just trying it out, will let you know shortly [23:25] and it worked! thanks a million lifeless [23:28] de nada [23:28] cider++