[00:12] <StevenK> wgrant: http://sourceforge.net/apps/trac/sourceforge/wiki/API => no bugs
[00:13] <wgrant> Ah
[00:13] <wgrant> There's a bug RSS feed, but that's it
[00:14] <StevenK> Which doesn't help
[03:28] <StevenK> wgrant: So I just created two bugwatches pointing to libav, bug 16 had a invalid bug number, and bug 17 had a valid one. After running checkwatches, bug 16 is still Unknown/Unknown but bug 17 is Fix Released/Medium
[03:28] <_mup_> Bug #16: "Swedish" and "Swedish (Sweden)" should be the same language <lp-translations> <Launchpad itself:Fix Released by daf> < https://launchpad.net/bugs/16 >
[03:28] <_mup_> Bug #17: System error <lp-translations> <Launchpad itself:Fix Released by carlos> < https://launchpad.net/bugs/17 >
[03:28] <_mup_> Bug #16: "Swedish" and "Swedish (Sweden)" should be the same language <lp-translations> <Launchpad itself:Fix Released by daf> < https://launchpad.net/bugs/16 >
[03:28] <_mup_> Bug #17: System error <lp-translations> <Launchpad itself:Fix Released by carlos> < https://launchpad.net/bugs/17 >
[03:28] <StevenK> _mup_: Go away
[03:28] <StevenK> wgrant: So I guess bug 634906 is fixed
[03:28] <_mup_> Bug #634906: An invalid remote bug ID can cause a checkwatches run to break completely <bugwatch> <lp-bugs> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/634906 >
[03:33] <wgrant> StevenK: Excellent.
[03:33] <StevenK> So that's two nailed shut today
[03:33] <StevenK> Three if we deploy
[03:41] <StevenK> wgrant: Turns out urlopen that initializeRemoteBugDB calls uses the default timeout value. Perhaps we should set it to 180 and move on?
[03:42] <StevenK> It might be more sinister
[03:42] <wgrant> StevenK: Perhaps block the connection locally and see if you can reproduce the behaviour?
[03:43] <StevenK> The urlopen call has a ensure_no_transaction decorator
[03:46] <wgrant> Sure, we know it has no transaction open
[03:46] <wgrant> Since it doesn't get idle-killed
[03:46] <StevenK> Right
[03:47] <StevenK> I was wondering if that was what was causing the spining
[03:52] <StevenK> wgrant: Right, I have forbidden my computer to talk to libav's bugzilla
[03:53] <wgrant> -j DROP, I hope?
[03:53] <StevenK>  Well, duh
[03:53] <StevenK> I don't want checkwatches getting port unreachable or wind of it
[03:58] <StevenK> It's still trying
[03:58] <StevenK> 36 dropped packets
[03:58] <wgrant> Hmm hmm
[03:58] <wgrant> Leave it for half an hour and see what happens :)
[03:58] <StevenK> It hasn't logged anything about libav
[03:58] <StevenK> Which is naughty
[03:59] <wgrant> It usually does
[03:59] <wgrant> Oh, unless it's hung on some preprobe
[03:59] <StevenK> Which is likely, it's trying to get the version
[03:59] <StevenK> 2012-11-20 03:59:01 INFO    Updating 1 watches for 1 bugs on http://bugzilla.libav.org
[03:59] <StevenK> It seems it gave up
[04:00] <StevenK> Now it's probably POSTing
[04:03] <StevenK> 2012-11-20 04:01:08 INFO    Error updating http://bugzilla.libav.org/: http://bugzilla.libav.org: <urlopen error [Errno 110] Connection timed out>
[04:03] <StevenK> That's disappointing
[04:19] <StevenK> urlopen uses socket._GLOBAL_DEFAULT_TIMEOUT if it isn't set, which is defined as object()
[04:19] <StevenK> socket.create_connection will only call socket.settimeout if the timout isn't that
[04:23] <StevenK> It could be a proxy thing
[04:24] <StevenK> squid just keeps a open connection
[04:24] <StevenK> But I'm grasping at straws
[04:28] <wgrant> Possibly
[04:30] <StevenK> wgrant: It may explain why neither of us can reproduce it locally
[04:38] <StevenK> And the squid I just installed gives a 504
[04:38] <StevenK> But that's default config
[04:40] <wgrant> IIRC I even tried it from behind squid.internal
[04:40] <wgrant> And it worked
[04:42] <StevenK> Strange
[04:42] <wgrant> Have you checked the last couple of hangs?
[04:42] <StevenK> I have not
[04:43] <StevenK> But I'll stop scratching my head over this and move onto glaring at Redhat XMLRPC
[05:58] <StevenK> wgrant: Ah ha. We send Bugzilla.time as a XMLRPC to redhat's tracker and get back Fault -32000
[06:00] <wgrant> StevenK: So the method to get the remote tracker's current time fails?
[06:01] <StevenK> Yeah
[06:01] <StevenK> <?xml version='1.0'?>\n<methodCall>\n<methodName>Bugzilla.time</methodName>\n<params>\n</params>\n</methodCall>\n'
[06:01] <wgrant> Oh, not even any params? Nice
[06:01] <StevenK> Is what we send
[06:01] <wgrant> I guess we'll need to file a bug with them :)
[06:02] <StevenK> I can't find any docs about Bugzilla.time
[06:02] <wgrant> What's the full traceback we get from them?
[06:02] <wgrant> I assume it works on other bugzillae
[06:02] <wgrant> but theirs is broken
[06:03] <StevenK> wgrant: Yeah, it seems fine with others
[06:03] <StevenK> Let me hack xmlrpclib
[06:04] <StevenK> ({'faultCode': -32000, 'faultString': 'Cannot compare a datetime to a regular scalar at /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/DateTime.pm line 1385.\n'},)
[06:05] <StevenK> That's the full stack in xmlrpclib.close
[06:07] <wgrant> https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&version=4.2 might be your friend
[06:07] <wgrant> I suspect
[06:07]  * StevenK stabs bugzilla
[06:09] <StevenK> wgrant: http://pastebin.ubuntu.com/1371847/
[06:09] <StevenK> The first run is with the ooo proxy commented out, the second with the redhat one
[06:09] <wgrant> yep
[06:10] <StevenK> Bleh
[06:10] <StevenK> Create an account? :-(
[06:10] <wgrant> Yeah
[06:10] <wgrant> If only all bugtrackers supported arbitrary third-party OpenID providers :)
[06:12] <StevenK> bugzilla-owner@redhat.com is the registered owner, we could just mail them ...
[06:12] <wgrant> Well
[06:12] <wgrant> You know we always ask for bugs to be filed
[06:12] <wgrant> Let's extend the same courtesy to them!
[06:24] <StevenK> wgrant: Bugzilla bug filed, LP bug updated, card created and marked as blocked
[06:24] <wgrant> Did you create a bugwatch so we can check its status? :P
[06:25] <StevenK> I can't!
[06:26] <StevenK> And noted that in the LP bug, so bugger off
[06:26] <wgrant> Hm, why can't you?
[06:28] <StevenK> The watch will never get updated
[06:28] <StevenK> The RedHat bugtracker is disabled
[06:28] <StevenK> So there is little point
[06:28] <wgrant> Ah, right, I was thinking that if they'd fix it then we'd know
[06:28] <wgrant> But not if it's disabled
[06:31] <StevenK> Not turning it back on, either. We can do without an extra 2500 OOPSes a day
[08:50] <adeuring> good morning
[09:56] <stub> Trying to bludgeon buildout into running in offline mode is a real pain in the arse
[09:58] <stub> Something is seriously broken when you get download errors when running in offline mode. WTF were you looking there in the first place stupid?
[09:59] <czajkowski> stub: you're being a bit harsh on yourself today
[10:26] <stub> Umm... don't we stop bugs being duplicates of each other?
[10:27] <stub> oh, nm
[13:17] <smartboyhw> Hmm yesterday I asked about the release date of CoC not correct on Launchpad QAstaging. Now CoC 2.0 is official, but then the date is still not changed....
[13:21] <czajkowski> smartboyhw: date doesnt need to change
[13:21] <czajkowski> it's up to date.
[13:22] <smartboyhw> czajkowski, you can't say that the CoC 2.0 is released in 2005 (or can you?)
[13:22] <czajkowski> I can and I did :) it needs to be done that way for reasons  like making sure anyone who has signed previous versions are still valid.
[13:24] <rick_h> czajkowski: ah ok. Yea missed the date thing when I pushed
[13:24] <czajkowski> rick_h: no tis fine
[13:24] <czajkowski> checked with wgrant and co that it needs to be that way
[13:24] <czajkowski> so tis grand
[13:24] <czajkowski> thanks rick_h
[13:24] <rick_h> does look strange. been many moons since I did CoC stuff (e.g. signed it)
[13:24] <czajkowski> rick_h: like the blog post :)
[13:25] <rick_h> ok, well I'll stop looking at what to fix then.
[13:25] <czajkowski> rick_h: :)
[13:25] <czajkowski> dont fix what's not broken :)
[13:26] <czajkowski> I can find lots of bugs if you want to fix stuff :p
[13:26] <rick_h> heh, I'll just go back to fixing the bug I've been working on
[13:34] <rick_h> adeuring: ping, have time to help me out with something?
[13:34] <adeuring> rick_h: sure
[13:34] <rick_h> hangout ok?
[13:35] <adeuring> rick_h: sure
[14:38] <czajkowski> rick_h: you see errors like this before https://bugs.launchpad.net/launchpad/+bug/1081131
[14:39] <_mup_> Bug #1081131: Specifications privacy: error when trying to change sharing settings <Launchpad itself:New> < https://launchpad.net/bugs/1081131 >
[14:39] <rick_h> czajkowski: stand up, but will peek in a few
[14:39] <czajkowski> np
[14:57] <rick_h> czajkowski: I've not seen that exactly and the bug wanders a bit so not 100% sure. Most things consider owner.
[14:58] <rick_h> I've not looked at the sharing ui itself which is seems he got access to bug couldn't change. Maybe deryck or abentley can speak more to that specifically
[14:58] <czajkowski> nods
[14:58] <czajkowski> sorry for pinging you just saw you online :) wasnt picking on you :p
[14:59] <rick_h> that's ok, I'm more than happy to play flight directing guy and wave you over away :P
[14:59] <czajkowski> lol
[14:59] <czajkowski> deryck: how is the little one post op ?
[14:59] <czajkowski> all good I hope
[15:00] <abentley> I haven't worked on the sharing UI.  It does sound like it should only be shown as editable to folks with Launchpad.Edit on the appropriate members.
[15:09] <deryck> czajkowski, hi.  she's good, thanks! A little sore this morning as you'd expect but she's getting better with each moment.
[15:09] <czajkowski> great to hear
[15:10] <czajkowski> I had mine out as an adult and was back to eating as normal 3 days later.
[15:10] <czajkowski> but bf had his out there last year, took him 2 weeks to recover
[15:10] <czajkowski> everyone recovers differently
[15:10] <deryck> she's eating pretty good now herself, albeit soft stuff like mac-n-cheese and mashed potatoes.
[15:11] <czajkowski> good going
[15:11] <deryck> she was starving.  but my little would consume the doors of the kitchen if we'd let her.
[15:11] <czajkowski> deryck: while you're here you might be able to shed some light on https://bugs.launchpad.net/launchpad/+bug/1081131
[15:11] <_mup_> Bug #1081131: Specifications privacy: error when trying to change sharing settings <Launchpad itself:New> < https://launchpad.net/bugs/1081131 >
[15:12] <deryck> czajkowski, yes, was just looking at that.  I agree with abentley's assessment above.  we need to ensure we don't show the edit icons to the wrong folks.
[15:12] <deryck> czajkowski, but it does sound like we already block the action, per the bug's description/
[15:13] <deryck> czajkowski, I've traiged it now.
[15:13] <deryck> triaged it even
[15:14] <czajkowski> grand job thanks folks
[15:15] <deryck> new title to make it clearer, too.  bug 1081131
[15:15] <_mup_> Bug #1081131: +sharing should not show edit icons if you don't have launchpad.Edit <private-projects> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1081131 >
[15:40] <rick_h> deryck: or abentley either of you have a sec to review since I'm OCR? I'm particularly want to make sure I'm saying that the ProjectGroup part is correct. https://code.launchpad.net/~rharding/launchpad/filter_more_products/+merge/135164
[15:40] <abentley> rick_h: I can have a look.
[15:40] <rick_h> abentley: thanks
[15:48] <abentley> rick_h: You are right about ProjectGroups.
[15:49] <rick_h> abentley: ok cool. The use in top_projects had me thinking I was missing a connection that I would allow leakage through
[15:49] <abentley> rick_h: Where possible, I've been updating APIs to accept a user parameter, rather than using ILaunchBag.user.  Have you looked at that option?
[15:50] <rick_h> abentley: no, I didn't look. I'll chase it up to browser and see if I can add the user
[15:50] <rick_h> cargo culting usage fml heh
[15:50] <abentley> rick_h: If you could, that would be great.
[15:51] <rick_h> abentley: rgr, makes sense now that you say it
[16:13] <abentley> rick_h: Could you please review https://code.launchpad.net/~abentley/launchpad/proprietary-karma/+merge/135188 ?
[16:14] <deryck> sinzui, I'm about to head out to lunch, but would love to catch some voice time with you after that if you have time.
[16:14] <rick_h> abentley: sure thing
[16:14] <abentley> rick_h: Thanks.
[16:31] <rick_h> abentley: r=me, I bow before your storm-fu turning the manual sql into storm
[16:31] <rick_h> though ugh at reading it
[16:31] <abentley> rick_h: was a multi-step process, and I had to check with curtis about the meaning of the original.  Do you think I should try to clean up the storm version more?
[16:33] <rick_h> abentley: I think it's just more I can read sql ok. So no, I think it's ok
[16:33] <rick_h> as is
[16:34] <abentley> rick_h: Okay.  Thanks for the review.
[17:40] <rick_h> abentley: I'm looking at trying to update the usage to include the user in the call but hitting a TAL wall: https://pastebin.canonical.com/78762/
[17:40] <rick_h> any idea or example where the method in the TAL gets a parameter passed in?
[17:40] <rick_h> I'm bzr grep'ing through but not coming up with an example I can see
[17:44] <sinzui> rick_h, We don't want python in tal. It is difficult to test
[17:44] <sinzui> rick_h, add a helper to the view to call the context with the user
[17:44] <rick_h> sinzui: yea, I'm thinking of punting on the suggest for my branch tbh. It's just going to be a giant pita to make user a param to the changes
[17:44] <sinzui> rick_h, or ...
[17:45]  * sinzui looks for cheat code
[17:45] <rick_h> sinzui: because doing that I hook the portlet to the view
[17:46] <rick_h> which I guess is ok since it's the one use but that seems dirty as well
[17:47] <jcsackett> rick_h: is this so you can get user in that method to do the privacy filter?
[17:47] <sinzui> rick_h, we have several cases where the mode must have a user, but the callsite will not pass it. The code will get the current request to find the user. maybe
[17:48] <sinzui> request = get_current_browser_request()
[17:48] <sinzui> user = request.user
[17:48] <jcsackett> you can also get the user from the launchbag, can't you?
[17:48] <sinzui> oh, it is person = IPerson(request.principal)
[17:48] <rick_h> jcsackett: yea, that's what I did but the suggestion was to avoid it
[17:48] <jcsackett> rick_h: ah.
[17:48] <rick_h> so trying to figure out the best way to replace the launchbag with direct calls because hte usage is in a portlet .pt
[17:49] <sinzui> yeah, the launchbag is used too much
[17:49] <rick_h> I think sinzui is right. The best thing is to add a helper on the view, but then it's ugly because the portlet is making the view api change
[18:29] <rick_h> abentley: ok, comment added. Updated one of the 3 change points.
[21:55] <jcsackett> deryck: are you around, and can you review https://code.launchpad.net/~jcsackett/launchpad/404-project-milestones-privacy/+merge/135252
[21:55] <deryck> jcsackett, yes and yes :)
[21:55] <jcsackett> deryck: awesome. thanks!
[21:55] <deryck> jcsackett, on call now but will look shortly
[22:01] <jcsackett> deryck: works for me.
[22:31] <sinzui> wgrant, StevenK: https://pastebin.canonical.com/78751/
[22:34] <wgrant> http://launchpadlibrarian.net/122750088/qxTB0SY4SJMb6haWptIok9Gyind.txt
[22:41] <sinzui> StevenK, https://bugs.launchpad.net/launchpad/+bug/665307
[22:41] <_mup_> Bug #665307: cronscripts/expire-bugtasks.py fails trying to put backtrace in librarian <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/665307 >
[22:45] <StevenK> webops: The NDT r16286 deployment is done, can you move it to Past Deployments?
[22:45] <sinzui> wgrant, StevenK: https://bugs.launchpad.net/launchpad/+bug/687446
[22:45] <_mup_> Bug #687446: process-mail dies on malformed email addresses <email> <lp-foundations> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/687446 >
[22:47] <deryck> jcsackett, r=me
[22:52] <jcsackett> deryck: Awesome, thanks.
[22:52] <deryck> jcsackett, np.  sorry it took me so long.  had back to back calls.
[22:55] <deryck> good night, everyone.
[22:57] <slank> StevenK: I had trouble finding your ping again ... that NDT is moved in productionstatus
[22:58] <StevenK> BAH, wrong window after all, too.
[22:58] <StevenK> slank: Thanks