=== slank is now known as slank_away [00:16] Failed example: [00:16] print concrete_one_zero.files[0].libraryfile.read() [00:16] Differences (ndiff with -expected +actual): [00:16] + None [00:16] :-( [00:21] wgrant: From what I can see, everything should be okay, but why does read() return None :-( [00:26] StevenK: You sure you opened it? You might even need to call read() on the object that gets returned from open() [00:26] read() will autoopen [00:26] (And autoclose, which is handy) [00:27] StevenK: Is it using a real librarian? [00:27] If you break in the test, can you see the file? [00:27] Have you checked the librarian log? [00:27] It's a doctest, breaking is hard [00:28] you could fix that [00:28] pdb inside a doctest has always broken [00:28] And the only way I know to fix it is to destroy all doctests [00:29] It'll break [00:29] It just won't have useful context [00:29] You can still poke around outside it [00:31] (Pdb) p self._datafile [00:31] [00:31] (Pdb) p self._datafile.read() [00:31] 'None' [00:31] Did that make a request to the librarian? [00:31] Can you seek? [00:31] What does it mean for it to return None? [00:31] *** ForbiddenAttribute: ForbiddenAttribute('seek', ) [00:32] wgrant: Ah, but it isn't None, it's the string None [00:32] Ah, true [00:33] So maybe your code is buggy :) [00:33] Yes, I'm checking [00:34] (Pdb) p fs['file_content'] [00:34] MiniFieldStorage('file_content', 'first attachment file content \xff') [00:34] (Pdb) p fs['file_content'].file [00:34] None [00:42] wgrant: http://pastebin.ubuntu.com/1618379/ [00:42] wgrant: Does that address your concerns? [00:43] StevenK: Can you confirm that the test fails if you go back to the code that I reverted? [00:43] ie. without the reretrieval [00:43] I have already confirmed before I pasted the diff [00:43] Great [00:43] Sounds reasonable, then [00:45] wgrant: I thought those were your two concerns? A XXX in the function itself, and a test [00:52] wgrant: The MP is updated [01:03] StevenK: Looking [01:07] StevenK: Oh [01:07] StevenK: What about signature_content? [01:08] I think that one is immune [01:08] Let me check [01:11] In [6]: l.files[0].signature.read() [01:11] Out[6]: '-----BEGIN PGP... [01:11] It's ASCII-armored, so coercing to unicode will not negatively impact it [01:12] In [8]: f = open('/tmp/f.tar.gz.asc').read() [01:12] In [9]: lfa == f [01:12] Out[9]: True [01:13] StevenK: Yeah, but still [01:14] ASCII-armored sigs are designed to survive exactly this sort of thing, but we should probably apply this hack to all lazr.restful file inputs [01:14] you could fix zope. [01:14] * lifeless waits for the laughter [01:14] s/laughter/stabbage/ [01:16] wgrant: http://pastebin.ubuntu.com/1618447/ [01:18] StevenK: :) [01:19] I can add a \xff to the signature content if you wish [01:20] Just to be sure [01:21] Might as well [01:21] * wgrant lunches [02:48] wgrant: Back from lunch? [02:53] StevenK: Yeah [02:53] wgrant: Should I take the Branch:+register-merge critical? [02:54] StevenK: Worth a try [02:55] wgrant: So the method to find a branch needs a rewrite and new indicies? [02:55] StevenK: Don't think of it as a rewrite and new indices [02:55] Think of it as a redesign approximately from scratch [02:55] It may or may not need new indices [02:56] But the search method needs to be rethought with performance over more than 1000 branches in mind === Ursinha_ is now known as Ursinha [06:19] wgrant: https://code.launchpad.net/~stevenk/launchpad/destroy-private-projects-feature-flags/+merge/147022 [06:27] StevenK: r=me [06:27] wgrant: And my QA is done [06:27] wgrant: You want a NDT? [06:28] StevenK: Please :) [06:28] The indices are there now [06:28] So we should be good to go [06:30] And kills 4 criticals [06:30] You have a lock on LPS? [06:33] StevenK: Apparently. It's yours [06:33] I sadly can't really close the vocab critical [06:33] It's still pretty awful for bad names [06:33] Depending on the number of builds [06:33] Aww [07:41] wgrant: Are you going to land 7? [07:46] StevenK: Not just yet [07:46] Going to wait and see if the world ends [07:46] Fair enough [07:46] It's still safe to back out the ndt at this point. [07:46] Mmmm, 7 is the point of no return [07:46] Exactly [07:47] It's probably landable and deployable tomorrow [07:47] That's the plan [07:47] It's a good plan [07:47] Hm, I should fix tuolumne === wgrant changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: - | Firefighting: - | Critical bugs: <130 [08:48] good morning [09:06] Good morning adeuring [09:07] hi jtv! [09:08] Nice weather today. Let me just check if any of my mangoes are ripe yet. [09:45] hi === yofel_ is now known as yofel [09:45] where should stale vcs mirrors be reported these days [09:46] https://code.launchpad.net/~testing-cabal/testtools/trunk only tracks up to the 24th jan [09:47] there have been 27 or so commits since spread over the interveneing period [09:47] * wgrant guesses it's a https github import [09:47] Indeed it is [09:51] wgrant: is there an open bug re that? [09:52] jml: Yes [09:53] wgrant: got it. ta. [09:54] https://bugs.launchpad.net/bugs/1072461 [09:54] <_mup_> Bug #1072461: Code import from github does not take latest commits < https://launchpad.net/bugs/1072461 > === slank_away is now known as slank === teknico___ is now known as teknico === teknico__ is now known as teknico [15:07] Is there a way to get a list of branches for a user/project via the api? I'd like to grab the equivalient of code.lp.n/~user/project === teknico_ is now known as teknico === teknico_ is now known as teknico [16:51] slank: I don't know of a way to do that without filtering client side [16:52] james_w: that's probably ok. perhaps there's a way to get branches for a user? I haven't found that either. [16:53] slank: user.getBranches() [16:53] slank: I can't link directly, but the second "Custom GET method" under https://launchpad.net/+apidoc/devel.html#person [16:55] james_w: ah. thanks! === slank is now known as wedgwood === matsubara is now known as matsubara-afk === mwhudson_ is now known as mwhudson