[01:04] <wgrant> Huh.
[01:04] <wgrant> test_initZopelessTwice fails with a recursion limit error.
[01:04] <wgrant> Because it adds a warning hook.
[01:04] <wgrant> Which uses failUnlessEqual.
[01:04] <wgrant> Which is deprecated.
[01:04] <wgrant> Which raises a deprecation warning...
[01:05] <mwhudson> whee
[01:15] <lifeless> win
[01:15] <lifeless> wgrant: so init zope less twice sends a warning ?
[01:15] <lifeless> wgrant: if so, as we don't init zopeless twice in the real world, perhaps make it raise an exception instead?
[01:21] <wgrant> Are you sure we don't?
[01:21] <wgrant> Trivial fix will do for now.
[01:21] <wgrant> Or not.
[01:21] <wgrant> 2.6 testcase doesn't have assertIs.
[01:21] <wgrant> testtools time, I guess.
[01:22] <lifeless> wgrant: I sure hope we don't.
[01:22] <wgrant> Why?
[01:22] <lifeless> because I want to nuke it entirely
[01:22] <wgrant> Sure.
[01:22] <lifeless> as unhygenic
[01:23] <spiv> After all, if it's been raising a warning when called twice then hopefully anyone doing that would have noticed the warning.
[01:23] <wgrant> spiv: We mostly just suppress warnings :)
[01:23] <StevenK> Then throw an exception
[01:26] <wgrant> dict ordering issue in launchpadlib, XMLRPCTestTransport borked, timeout.txt hanging in really bad ways. Apart from that all fixed.
[01:26] <StevenK> wgrant: It continues to pass with 2.6, so the fixes are landable?
[01:27] <wgrant> Yes.
[01:27] <wgrant> They're all small test issues, apart from one real bug.
[01:27] <wgrant> timeout.txt might be real too, I guess.
[01:27] <wgrant> But need to get pygdb onto it at some point.
[01:59] <stub> I'm getting sucky packetloss entering Los Angeles. This should affect most of Asia :-(
[02:00] <stub> level3 LA
[02:18] <wgrant> StevenK: Working fine for me.
[02:18] <wgrant> Er, stub.
[02:18] <wgrant> Maybe they've fixed it.
[02:18] <wgrant> Optus' international pipe has been fairly broken for the last 24 hours, though.
[02:19] <stub> Seems better now. Can't be sure it isn't my ISP messing up though - I think it is the first server on the US site, so might be entering the US/Asia cable that is screwed.
[02:19] <stub> nope... still messed. just not as bad.
[02:36] <poolie> lifeless: i'm seeing some udd failures due to bug 602647
[02:36] <poolie> hm
[02:36] <poolie> actually, no i'm not
[02:38] <wgrant> It's private?
[02:45] <poolie> is there another bug for internal xmlrpc flaking out and returning a 503?
[02:47] <wgrant> That sounds like a timeout.
[02:47] <poolie> https://bugs.launchpad.net/launchpad/+bug/294726 is pretty close
[02:47] <_mup_> Bug #294726: "ProtocolError for xmlrpc.lp.internal:8097/branchfilesystem" when pushing a branch <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/294726 >
[02:47] <poolie> probably
[02:49] <wgrant> poolie: Which bug number did you mean?
[02:49] <poolie> bug 602467
[02:49] <_mup_> Bug #602467: retry 503 errors on the LP directory service. <launchpad> <Bazaar:Confirmed> < https://launchpad.net/bugs/602467 >
[02:49] <wgrant> Ah
[02:51] <nigelb> Hi, when I hit launchpad.dev, its not hitting my local instance.
[02:51] <nigelb> Suggestions on where to look?
[02:51] <poolie> nigelb: i guess you need to start apache
[02:51] <poolie> or, connect direct to zope on port 8086
[02:52] <poolie> apache acts as a front end proxy
[02:52] <nigelb> poolie: There's a make run running
[02:52] <poolie> you need to run 'sudo service apache start' separately
[02:52] <poolie> assuming it was not started at boot time
[02:52] <poolie> (in your chroot, or vm or whatever, if you're using one)
[02:52] <nigelb> I just use my regular apache
[02:52] <nigelb> Nope
[02:52] <nigelb> no go
[02:53] <poolie> what happens?
[02:53] <nigelb> apache was already started
[02:53] <nigelb> but I still can't hit launchpad.dev from firefox
[02:53] <mwhudson> what happens when you try?
[02:54] <mwhudson> you get the apache 'it works' page?
[02:54] <nigelb> I get "Firefox can't establish a connection to the server at launchpad.dev."
[02:54] <mwhudson> launchpad.dev is in /etc/hosts?
[02:54] <poolie> are you using a chroot or something?
[02:55] <nigelb> The /etc/hosts is what I checked first, its there.
[02:55] <nigelb> poolie: Nope, just in my regular install
[02:55] <poolie> try telnet launchpad.dev 443
[02:55] <nigelb> oh grrar
[02:56] <nigelb> https://launchpad.dev works
[02:57] <poolie> hooray
[02:57] <poolie> congrats
[02:57] <nigelb> that further proves that its been a while since I've done this.
[02:58]  * nigelb should contribute more.
[03:42] <spiv> poolie: https://code.launchpad.net/~spiv/launchpad/bmp-inline-diffs/+merge/66634 is now ready for landing I believe
[03:43] <spiv> poolie: do you still want to send it in for me? :)
[03:46] <LPCIBot> Yippie, build fixed!
[03:46] <LPCIBot> Project devel build #901: FIXED in 5 hr 33 min: https://lpci.wedontsleep.org/job/devel/901/
[04:46] <wgrant> Oh yay, our JS is broken in IE again.
[04:47] <StevenK> Why are you using IE?
[04:47] <wgrant> Was testing the expanders.
[04:48] <StevenK> Ah.
[05:15] <huwshimi> wgrant: Is it lint issues again?
[05:18] <wgrant> It's not the usual comma at the end of a list.
[05:18] <wgrant> It may be a missing closing brace, I think.
[05:19] <StevenK> Just one?
[05:22] <wgrant> It occurs in the middle of json-parse.js, it seems.
[05:22] <wgrant> But that's YUI...
[05:23] <lifeless> and bug searches are back into timeout territory
[05:33] <lifeless> cute - http://elaforge.blogspot.com/2011/07/what-haskell-doesnt-have.html
[05:33] <lifeless> I really must do something nontrivial in haskell one of these days
[05:41] <wgrant> Indeed.
[05:41] <wgrant> It's a really nice language.
[06:18] <stub> I need to learn a new language one day. I think I've forgotten everything except Python and PL/SQL
[06:38] <spm> perl
[06:39] <lifeless> 'new language'
[06:41] <nigelb> I still think spm wins ;)
[06:41] <spm> hahahha
[06:41] <nigelb> lifeless: what bit about the function in https://code.launchpad.net/~nigelbabu/launchpad/spec-sub-sort/+merge/63315 do you want me to abstract?
[06:41] <nigelb> I got confused yesterday when I was trying.
[06:42] <lifeless> nigelb: I think the point was that the sort with a sort key function is something we could spell once abstractly
[06:43] <nigelb> I tried abstracting the sorted bit in there
[06:44] <nigelb> but then I realized that I also do sort() there.
[06:44] <nigelb> which is part of another function.
[06:46] <nigelb> Does that make sense?
[06:46] <lifeless> nope
[06:46] <lifeless> pastebin ?
[06:50] <nigelb> This is something jml wrote for me yesterday. http://paste.ubuntu.com/648007/
[06:50] <nigelb> Is this the level of abstraction you were looking for?
[07:13] <lifeless> nigelb: I think so, yes.
[07:15] <nigelb> oh, I can't link you to lines in a merge proposal's diff :/
[07:15] <nigelb> Well, line 19 of the diff in my MP is what's confusing me.
[07:15] <nigelb> I can't use that function there.
[07:20] <poolie> spiv, hi, i can send that for you
[07:20] <spiv> poolie: thanks!
[07:20] <poolie> one idea occurred to me, reading your latest update
[07:20] <poolie> (thanks for completing it)
[07:21] <poolie> and that was that rather than href="#" perhaps it should send people to the loggerhead view of the diff
[07:21] <poolie> in case they ctrl-click it or have a non-js browser
[07:21] <poolie> (i don't know what the policy is for supporting that)
[07:21] <poolie> i don't want to stall this though
[07:21] <spiv> If they have a non-js browser, the link won't be visible currently.
[07:21] <spiv> Well, if they have a non-js but with-css browser.
[07:25] <poolie> oh ok
[07:25] <poolie> anyhow, it was just an idea
[07:25] <lifeless> nigelb: property_cache.subscriptions = function_call()
[07:25] <poolie> spiv, so, i'll just send it?
[07:27] <spiv> It's a good idea, but it's a bit fiddly to implement AIUI.  At the least you'd need to use a less convenient API than expander.createByCSS I think.  Perhaps you'd enjoy making that patch? ;)
[07:27] <spiv> poolie: please do!
[07:27] <poolie> :P
[07:28] <poolie> huwshimi: is there actually a policy on non-js support?
[07:28] <nigelb> lifeless: ah, thanks. Brain seems to be turned off today :)
[07:29] <huwshimi> poolie: This is the only thing I can think of off the top of my head: https://dev.launchpad.net/GradedBrowserSupport
[07:29] <spiv> I'm a bit sick of staring at that code today, I spent longer than would be ideal discovering that one of the expander APIs grew a new positional parameter since I'd last merged, which of course resulted in a mysterious “nothing happens when I click” bug :/
[07:30] <spiv> poolie: oh hmm, I guess I misunderstood, and making that link go straight to loggerhead might not be so hard
[07:30] <spiv> poolie: but I think it's weird UI for the browser to indicate that a link will take me somewhere and then for clicking it to do something else.
[07:31] <poolie> i loved named/optional parameters when i first used python but now the bugs they lead to are one of my least favourite bits
[07:31] <poolie> in the sense that the status bar will show the lh url
[07:31] <spiv> named-only params would be nicer.
[07:31] <poolie> for nerds who look at the status bar
[07:31] <spiv> Like me :)
[07:31] <poolie> it's been a long branch, i don't want to make you do any more on it
[07:31] <poolie> it was just a thought when i saw your update
[07:32] <spiv> I've definitely been repeated annoyed by that sort of behaviour in the past, so I'd be pretty hesistant to implement it myself :)
[07:32] <poolie> in general links that point to # are i think a chance to consider whether there is somewhere better
[07:32] <spiv> I agree that's the experience I'd want non-JS browsers to get in the ideal world.
[07:32] <spiv> I'm not sure how best to arrange that without misleading the JS browsers.
[07:33] <spiv> (It does lead to the intruguing idea that the target of the href could be used as the input to the 'generate the link for raw diff to fetch' function.
[07:33] <spiv> )
[07:33] <poolie> i don't think browsers really handle the case of indicating what a js link will do
[07:33] <poolie> you typically either get '#' or some unreadable function lambda
[07:36] <poolie> spiv, ec2 wants to know if there's a bug for this branch
[07:36] <spiv> Yeah.  I might be wrong about how bad it would be, but I *have* encountered irritating behaviour with expander-like things and misleading ctrl-click behavour in LP before.
[07:36] <spiv> Not that I know of, probably a good time for me to take a quick look...
[07:39] <spiv> poolie: a few very vaguely related ones maybe, but no appropriate one
[07:42] <spiv> poolie: but it did lead me to notice a low-importance bug of yours that's a dupe of an older critical one!
[07:42] <poolie> heh
[07:42] <poolie> which?
[07:42] <spiv> bug 762355
[07:42] <_mup_> Bug #762355: would prefer to see mp with no diff when librarian fails, rather than no mp at all <code-review> <Launchpad itself:Triaged> < https://launchpad.net/bugs/762355 >
[07:43] <poolie> ok bug 813349 for the sake of qa'ing it
[07:43] <_mup_> Bug #813349: hard to get from mp to per-revision diffs <Launchpad itself:In Progress by spiv> < https://launchpad.net/bugs/813349 >
[07:44] <spiv> poolie: thanks!
[07:47] <poolie> ok, instance is booting, we should know tomorrow
[07:49] <adeuring> good morning
[08:16] <mrevell> Good morning
[08:42] <rvba> jtv: About your suggestion to clean my branch (removing the use of filtered_expanded): the code you propose was exactly what I wrote first but if candidates is [] then Or(*candidates) breaks the generated SQL.
[08:42] <jtv> rvba: then return if candidates is empty.  :)
[08:42] <jtv> Doesn't cost much to go through one more empty list comprehension.
[08:44] <rvba> jtv: but make_package_condition crashes if it's called with das=None.
[08:44] <jtv> But you won't be calling it.
[08:44] <rvba> ah ... right.
[08:44] <jtv> The extra "if" in the list comprehension prevents it from happening.
[08:44] <rvba> True.
[08:50] <jtv> cjwatson: you still have an approved but unlanded merge proposal for Launchpad open from last year.  What should happen with it?  https://code.launchpad.net/~cjwatson/launchpad/dpkg-xz-support-619152/+merge/32868
[08:51] <jtv> and jelmer, what's supposed to happen to https://code.launchpad.net/~jelmer/launchpad/publisher-use-debian-2/+merge/45011 ?
[08:52] <jtv> adeuring: you too have an ancient approved MP on the backlog: https://code.launchpad.net/~adeuring/launchpad/js-translation/+merge/55309
[08:52] <jtv> lifeless: approved-but-unlanded-MP reminder: https://code.launchpad.net/~lifeless/launchpad/bug-759467/+merge/58262
[08:55] <jelmer> jtv: thanks for the ping
[08:55] <jelmer> wgrant: hi
[08:56] <jelmer> jtv: IIRC cjwatson's branch was waiting on the installation of a newer dpkg package, IMBW
[08:56] <jtv> jelmer: thanks — it's been a while so probably a good time to check up on that
[09:01] <cjwatson> yes, it's due to land in lucid-updates in a couple of days
[09:01] <cjwatson> when it does, I'll propose meta-lp-deps changes, and then we can try landing dpkg-xz-support again
[09:01] <cjwatson> don't worry, I'm totally keeping track of this
[09:02] <cjwatson> (though I wasn't for a long time, I know)
[09:02] <cjwatson> it's actually newer apt and python-apt - didn't I comment on the MP or the bug about it?
[09:03] <cjwatson> yes, I did comment on the MP a week ago.
[09:03] <cjwatson> http://people.canonical.com/~ubuntu-archive/pending-sru.html - waiting for lucid/apt and lucid/python-apt there to hit 7 days before the next move in the game
[09:05] <rvba> jtv: landing the branch now. Thanks for the review!
[09:05] <lifeless> jtv: it bounced off of ec2; I haven't dug into ityet
[09:05] <jtv> rvba: np
[09:26] <cjwatson> thanks to whoever landed https://code.launchpad.net/~cjwatson/launchpad/germinate-ubuntustudio for me, without me having even got round to asking :)
[09:29] <lifeless> <-
[09:32] <poolie> cjwatson: hooray for patch piloting spirit
[09:33] <poolie> (presumably rum)
[10:06] <lifeless> wgrant: re namespace patches
[10:06] <lifeless> [Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"
[10:07] <lifeless> *packages*
[10:19] <wgrant> lifeless: That almost looks like not a complete mess.
[10:41] <henninge> wgrant: bzr log -r12957.1.6
[10:41] <henninge> wgrant: wrong ;-P
[10:53] <jelmer> is rabbitmq used for any core stuff yet?
[10:54] <jelmer> it's being set up for the codeimports, which (AFAIK) shouldn't need it
[10:58] <wgrant> jelmer: It's part of LaunchpadLayer, but only a couple of tests use it so far, and they're only to check that the layer setup is working.
[11:00] <wgrant> jelmer: If you still can't get it running, I guess you could hack LaunchpadLayer to not depend on RabbitMQLayer.
[11:01] <jelmer> wgrant: that's what I've just done :)
[11:01] <jelmer> I'll have a closer look at it later, but for the moment I just want to get some stuff done.
[11:20] <henninge> jtv1: Hi! I have a short and easy branch for you. ;-)
[11:20] <henninge> https://code.launchpad.net/~henninge/launchpad/bug-792092-build-now/+merge/68521
[11:35] <jtv1> henninge-lunch: reviewing.
[11:36] <wgrant> danilos: Hi.
[11:36] <wgrant> adeuring: Also hi.
[11:45] <jtv> henninge-lunch: done
[11:45] <wgrant> jtv: Are you going to be around to chase up the deployment this evening?
[11:46] <jtv> No.  It's planned, it's approved, it should be announced.
[11:46] <jtv> mrevell: did that work out by the way?
[11:46] <wgrant> It is announced.
[11:46] <jtv> I think he said so yesterday, but not sure.
[11:46] <wgrant> But it's still useful to have someone around who knows what's going on.
[11:46] <wgrant> You may wish to recruit a conveniently located maintenance person for this purpose.
[11:46] <mrevell> jtv, yeah, it's announce
[11:46] <mrevell> d
[11:47] <jtv> thanks
[11:50] <danilos> wgrant, hi
[11:51] <wgrant> danilos: We have another expander regression :(
[11:51] <wgrant> On prod this time.
[11:51] <danilos> wgrant, which one is it?
[11:51] <wgrant> (see #launchpad a few minutes back)
[11:51] <wgrant> When there is a conjoined bugtask, the expander hook for the conjoined slave crashes.
[11:51] <wgrant> Because there is no expander.
[11:52] <wgrant> This seems to break all remaining inline JS on the page.
[11:53] <danilos> wgrant, indeed, I'm looking into it
[11:54] <wgrant> danilos: Thanks.
[11:54] <wgrant> danilos: Hopefully the fix is smallish and can skip ec2 and we can deploy it in not too many hours.'
[11:55] <danilos> wgrant, yeah
[12:19] <danilos> wgrant, considering jtv is not around and I am the other OCR reviewer, can you perhaps approve https://code.launchpad.net/~danilo/launchpad/fix-bugtask-expander/+merge/68536?
[12:20] <danilos> wgrant, (or disprove, if you are so inclined :)
[12:20] <wgrant> danilos: Approved.
[12:21] <wgrant> Thanks!
[12:21] <danilos> wgrant, thank you!
[12:21] <danilos> wgrant, I'd say "bzr lp-land" should be fairly safe with this, what do you think?
[12:21] <wgrant> Yes, definitely.
[12:23] <wgrant> cjwatson: Your ubuntustudio germinate change should be deployed to cocoplum in the 1600UTC downtime window today.
[12:25] <danilos> wgrant, ok, I'll try to arrange a deployment towards the end of my day (when lpbuildbot run completes), if not, I'll ask some of my fellow yellow Americans
[12:30] <wgrant> danilos: I was about to ask if you could do that. Thanks!
[12:30] <wgrant> danilos: We are QAed up to current stable tip, so it's just your rev left.
[12:30] <danilos> wgrant, cool, thanks
[12:30] <wgrant> So it will be a nice easy thing to deploy in ~5 hours.
[12:32] <wgrant> Thanks for the quick fix.
[12:32]  * wgrant sleeps.
[12:44] <cjwatson> wgrant: cool, that's quicker than I expected, thanks
[12:52] <gary_poster> jml, I had a pre-imp for  (private) https://bugs.launchpad.net/launchpad/+bug/812335 with flacoste yesterday and was hoping I would not need to bother you, but I just ran into some concerns.  Would you have tie for a pre-imp?
[12:52] <gary_poster> or time
[12:53] <bac> hello mrevell
[12:53] <mrevell> hey bac, otp
[12:53] <bac> mrevell: np, ping when you're free
[12:55] <jml> gary_poster: sure
[12:55] <jml> gary_poster: I need to eat first though.
[12:55]  * jml has been putting that off on account of unusually high productivity
[12:55] <gary_poster> thanks jml.  ok, I have a dentist appt I need to leave for in 15 minutes, so maybe a couple of hours later then
[12:56] <jml> gary_poster: perfect.
[12:56] <gary_poster> thanks again
[12:56] <danilos> jml, if you put it off for long enough, productivity will go to zero but so will your (non?) living costs
[13:02] <deryck> Morning, all.
[13:02] <gary_poster> hiya
[13:08] <henninge> Anybody noticed this missalignment before? Is there a bug for it? I don't know what to search for ...
[13:08] <henninge> http://people.canonical.com/~henninge/screenshots/miss-aligned-bugs.png
[13:09] <danilos> henninge, looks like my expander replacements might be the culprit
[13:09] <danilos> henninge, what browser is that?
[13:09] <henninge> danilos: chromium
[13:10] <danilos> henninge, fwiw, the bug priority icons were not even shown in webkit-based browsers before, so maybe the issue was there but spans were zero height
[13:10] <henninge> they weren't? oh
[13:11] <danilos> henninge, yeah, <li>s now probably need more indentation for two sprites (expander icon and the bug icon), at least I think that's the problem; please file a "regression ui" bug and I'll look into it tomorrowish
[13:11] <danilos> henninge, or, if you feel like it, fix it :)
[13:12] <henninge> danilos: I have another one I want to do, I was gonna talk to you about that, too ... ;)
[13:13] <danilos> henninge, shoot before I head out to lunch :)
[13:14] <henninge> danilos: I want to remove TranslationBranchApprover and replace it with TranslationBuildApprover.
[13:14] <danilos> henninge, hum, what's a TranslationBuildApprover? :) and why is it different at all?
[13:15] <henninge> danilos: ;-)
[13:15] <henninge> danilos: TranslationBuildApprover is run after templates were build from a branch.
[13:15] <henninge> danilos: it is much simpler and only determines the template name from the file name.
[13:16] <henninge> danilos: it does not care to check which templates are already in rosetta and which are in the branch.
[13:16] <danilos> henninge, makes sense
[13:16] <henninge> danilos: TBranchA stops if a template is missing in the branch.
[13:17] <henninge> we need to do a lot of manual approval because of that.
[13:17] <henninge> danilos: That "comparing" functionality doesn't really help.
[13:18] <danilos> henninge, right, but what happens when someone renames a template?
[13:18] <danilos> henninge, how do they fix the mess?
[13:18] <henninge> danilos: it *could* be helpful if it could explain that to the uploader and the uploader had a chance to do something about it.
[13:18] <danilos> henninge, well, I've got a window of two weeks to finish the switch of approval to maintainers
[13:18] <danilos> henninge, so, they'll be able to control their templates much more
[13:18] <henninge> danilos: the TBranchA gets stuck and does not approve anything, the TBuildA just creates a new template
[13:19] <danilos> henninge, right, but how would one ever "join" two templates together when one renames the template in the branch then?
[13:19] <henninge> good luck gary-dentist
[13:20] <danilos> henninge, imagine there was a template with lots of translations (history and stuff), and maintainer renames it in a branch: it automatically gets imported as the new template with no history preserved
[13:20] <henninge> danilos: not possible
[13:20] <danilos> henninge, that would suck very much, wouldn't it?
[13:20] <henninge> danilos: correct, we don't have a good renaming story
[13:21] <danilos> henninge, I'd rather just let people approve stuff on their own than mess it up completely (I've seen people rename templates all the time, at least until they get a good setup)
[13:21] <danilos> henninge, fwiw, I think your approver makes more sense for ubuntu uploads
[13:22] <danilos> henninge, "your" == TBuildA
[13:22] <henninge> danilos: Letting maintainers approve themselves is much better of course.
[13:22] <henninge> danilos: I wrote both ...
[13:22] <henninge> ;-)
[13:22] <danilos> henninge, heh, right :)
[13:23] <henninge> danilos: why for Ubuntu uploads?
[13:23] <henninge> danilos: so I guess we need to fix bug 728876 instead
[13:23] <_mup_> Bug #728876: Know when translations branch/build auto-approvers give up <Launchpad itself:Triaged> < https://launchpad.net/bugs/728876 >
[13:23] <danilos> henninge, because they are for trusted packages and are basically the same thing as what we build for TBuildA to approve (i.e. they are result of intltool-update -p for GNOME packages, and whatever else others use)
[13:24] <henninge> right
[13:25] <danilos> henninge, perhaps, but let's first let maintainers manage the import queue themselves
[13:25] <henninge> danilos: that would add valuable information to enable them to manage them correctly.
[13:25] <danilos> henninge, indeed, I agree
[13:25] <danilos> henninge, so, I will be very happy if it gets fixed :)
[13:26] <henninge> danilos: It would be best if it could give a specific reason ...
[13:27] <danilos> henninge, indeed, you can reuse error_output for that
[13:31] <deryck> henninge, ping for standup
[13:33] <henninge> deryck: oh, sorry
[13:37] <jtv> Has anyone ever seen this failure I'm getting in EC2?  ScriptActivitySet.recordSuccess violates scriptactivity_pkey (even though that's just an id that the database assigns normally).  Sign that the database needs to be marked dirty?
[13:38] <jcsackett> sinzui: available to mumble this morning?
[13:38] <sinzui> yes
[13:40] <stub> jtv: not sure how that would happen even if there are test isolation issues
[13:40] <jtv> I can't even reproduce it locally.
[13:40] <stub> jtv: You might need to dump the contents of the table before that point, which is sucky if it is only happening on ec2
[13:41] <jtv> But my branch triggers it consistently in EC2, and it's probably because of something I did.
[13:42] <jtv> I turned a function that gets invoked by scripts into a LaunchpadCronScript itself.  So now we have LaunchpadCronScripts instantiating a LaunchpadCronScript and invoking it.  But I'd like to understand why the id clash.
[13:43] <jtv> The test in question forks off a proper script instance, so maybe that ought to mark the db as dirty.
[13:43] <jtv> It does, actually.
[13:43] <jtv> Oh, but in what looks like the wrong place.
[13:44] <bac> jtv: thanks for the review.  i've updated it showing i took your suggestion.
[13:44] <jtv> It does that in the assertion after the script has completed...  so if one of the invocations failed for a different reason, that would sabotage the "dirty" bookkeeping.
[13:45] <jtv> bac: thanks!  I didn't expect you to have much time for that kind of polish, so nice surprise.
[13:47] <jtv> stub: is there any circumstance under which we'd reset sequences but not the db?
[13:48] <stub> Hmm... I think there might be, and your initial idea could be correct.
[13:48] <jtv> I'm seeing it on LFC as well.
[13:48] <stub> If the db is not dirty, we assume all the data changes roll back. But the sequences don't reset, so we reset em
[13:49] <stub> (although if our tests were good, we wouldn't have to reset the sequences because we would not be depending on tests getting consistent ids)
[13:49] <jtv> Then I'll just start by marking the database when the script runs, instead of after it's completed.
[13:50] <jtv> Yes, I wonder how much would break if we stopped resetting them.
[14:01] <jtv> Oh blast, it's one of the fun ones.
[14:01] <jtv> I can reproduce the problem by running a whole lot more tests at once.
[14:03] <jtv> AAAAAAAAAAAAAhhhhh!  The preceding test invokes a script as part of its test data setup!
[14:03] <jtv> And neglects to mark the database dirty, of course.
[14:03] <jtv> At least I see a way to make that test a lot faster…
[14:07] <bigjools> jtv: we should automate that dirtying somehow
[14:08] <jtv> Yes, that'd be nice as well.  If it's not too expensive.
[14:10] <jml> I wonder if there's a way to ask postgres if the db has had a write since a given time
[14:10] <jml> or, when the last write was
[14:17] <jtv> The problem is, I suspect, that you need to find out what was the last committed write.
[14:17] <jtv> (Assuming we don't need to reset sequences, which we currently do)
[14:17] <henninge> danilos: bug 813540
[14:17] <_mup_> Bug #813540: Bug icons in dupefinder listing get pushed to next line <regression> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/813540 >
[14:17] <henninge> danilos: I'll probably take it, looks shallow.
[14:18] <jtv> jml: technically there could even be a write in progress that hasn't committed yet, though.
[14:18] <jml> jtv: by the time the script has ended?
[14:19] <jtv> I wonder if we know for certain that all transactions have ended at the end of the test.
[14:19] <jtv> Chances are pretty good though.
[14:19] <jml> jtv: if the test is buggy and leaves processes or threads running, then I guess you won't know
[14:20] <jml> jtv: but tests shouldn't be buggy, and we've already got reasonably good catches for those things
[14:20] <jtv> Exactly, that's the hard case.
[14:20] <jtv> Although with daemons this may all get harder.
[14:20] <jtv> What if the Librarian is about to commit on the test's behalf, for instance?
[14:20] <jml> yeah, that'd be a problem
[14:20] <jml> because those could cross boundaries.
[14:20] <jml> hmm
[14:20] <jtv> Well, I don't know if the Librarian ever commits to the db of course.
[14:20] <jml> but that's currently a problem anyway
[14:21] <jml> it just depends which side you want to err on
[14:22] <jml> anyway, it might be worth playing a bit with the idea, since it would ultimately be more reliable than remembering to mark as dirty
[14:23] <jtv> Very true.
[14:24] <jtv> And I'd like to have a ratchet on the number of test failures we get when we don't reset sequences.
[14:25] <jtv> That's probably only worth it when we actually start working on it though: we could see the ratchet close.
[14:26] <jtv> (It could be a driver for getting rid of some more old-style tests)
[14:40] <jtv> Anyone know where this comes from?
[14:40] <jtv> <class 'zope.tales.tales.RegistrationError'>: Multiple registrations for Expression type "cache".
[14:41] <jtv> Multiple zcml-for-scripts initialization maybe?
[14:41] <jtv> ahh yes, must be
[14:43] <jtv> Did I seriously just knock 26 seconds off test time by fixing that?
[14:45] <danilos> henninge, thanks for taking care of it (was lunching)
[15:16] <henninge> danilos: https://code.launchpad.net/~henninge/launchpad/bug-813540-dupefinder/+merge/68557
[15:20] <gary_poster> thanks for the good luck wishes henninge :-)
[15:24] <danilos> henninge, looking
[15:31] <gary_poster> jml, are you available for a call now?
[15:31] <danilos> henninge, r=me, thanks
[15:31] <henninge> danilos: thank *you* ;-)
[15:33] <danilos> henninge, btw, I agree that layout should not be table-based, and would probably need to be reformatted completely to be sane
[15:33] <henninge> yup
[15:36] <jml> gary_poster: hi
[15:36] <jml> gary_poster: a short one, yes.
[15:36] <gary_poster> hey, ok jml thanks.  I'm ready with skype (garyposter) or mumble
[15:37] <jml> gary_poster: ok
[15:42] <rvba> :w
[15:44] <jml> gary_poster: TestGenericBranchCollectionVisibleFilter in lp.code.model.tests.test_branchcollection
[15:47] <jml> gary_poster: lp.code.tests.test_branch.TestAccessBranch
[16:07] <jml> did my reply to "An open invitation to do a no-downtime-deploy" go through?
[16:20] <gary_poster> jml, from almost three hours ago, yes
[16:20] <jml> gary_poster: cool, thank.
[16:20] <jml> thanks.
[16:20] <gary_poster> yw
[17:18] <mtaylor> wow. SSO fail
[17:18] <nigelb> heh, probably should go on /topic in the other channel.
[17:19] <elmo> sorry, it is being worked on
[17:28] <elmo> it's back up
[17:45] <mtaylor> is there any way to get a user's openid deletgate url from launchpadlib/launchpad api?
[17:51] <maxb> I think that info is only revealed to admins and the user themselves by the security policy at all
[17:52] <jml> mtaylor: Can't see anything obvious at https://launchpad.net/+apidoc/devel.html#person
[17:57] <mtaylor> jml: yeah. me neither - I was sort of hoping there was something hidden I didn't know about
[17:57] <mtaylor> maxb: it's visible on the web page
[17:57] <mtaylor> maxb: view-source in the link rel  -- otherwise the calling context wouldn't know what url to visit
[17:57] <maxb> mtaylor: But only for yourself, AFAIK?
[17:58] <mtaylor> maxb: nope. for anybody
[17:58] <mtaylor> for instance: view-source:https://launchpad.net/~jaypipes
[17:58] <maxb> oh, so it is
[17:59] <mtaylor> (I'm working on a script to pre-populate a user database with launchpad information for a system that will use launchpad/ubuntu openid as a point of SSO)
[18:00] <mtaylor> but to match that up, I _believe_ I also need to inject the openid local_id so that the SSO code will know how to associate an sso user with pre-filled in meta info
[18:00]  * mtaylor hopes he isn't about to write a web-scraping script - it's possilbe there's another way to solve this...
[18:00] <maxb> If configured to allow it, SSO can tell you the lp id
[18:01] <maxb> as part of the OpenID exchange
[18:01] <mtaylor> yeah - I'm hoping that will be enough to make the match on the side of the SSO side ... need to chat with the other dev
[18:09] <thedac> I have cocoplum OOPes alerting
[19:43] <cr3> can some celebrities authenticate to the api?
[19:45] <lifeless> no
[19:45] <lifeless> celebrity != service account
[19:46] <cr3> lifeless: that's what I thought, thanks for the confirmation!
[19:47] <nigelb> I wonder what happened about the bot discussion.
[20:02] <dobey> cr3: i haven't had any problems doing so ;)
[20:03] <lifeless> dobey: You aren't a Launchpad celebrity
[20:06] <deryck> lifeless, hey there....
[20:06] <dobey> lifeless: you are no fun
[20:06] <lifeless> deryck: hi :)
[20:06] <deryck> lifeless, are changes to trusted.sql treated like schema changes?  Or is trusted.sql applied on every nodowntime deploy?
[20:06] <lifeless> dobey: I'm plenty fun.... a little later in the day :P
[20:08] <lifeless> deryck: it won't be no.
[20:08] <lifeless> deryck: you need /all/ changes to be in a patch script
[20:09] <lifeless> deryck: you may also need the function in trusted.sql to have 'make schema' work.
[20:09] <lifeless> deryck: this is a (lot) fugly, and deserves a bug.
[20:10] <deryck> lifeless, ah, gotchas.  yeah, that is fugly, but I follow.
[21:12] <bac> lifeless: thanks for your comments on my merge proposal
[21:15] <lifeless> sorry have to run to hospital for an appt
[21:15] <lifeless> I hope lp didn't make me claim it, as I only wanted to add that headsup
[21:29] <deryck> Later on, everyone.
[22:02] <wgrant> danilos: Thanks for that quick fix and deploy.
[23:10] <LPCIBot> Project db-devel build #738: FAILURE in 5 hr 39 min: https://lpci.wedontsleep.org/job/db-devel/738/
[23:28] <poolie> spiv, bmp re-sent
[23:35] <spiv> Thanks