[00:15] <StevenK> Bleh, it doesn't OOPS
[00:15] <StevenK> It gives a traceback directly
[00:28] <StevenK> 2012-11-20 02:54:33 INFO    Error updating http://bugzilla.libav.org/: Failed to parse XML description for http://bugzilla.libav.org bugs [u'221', u'222', u'298']: mismatched tag: line 101, column 4
[00:28] <StevenK> RAGH
[00:50] <StevenK> wgrant: So I'd expect a cronscript that tosses an exception to print out the OOPS number and exit, which doesn't happen. :-(
[00:51] <wgrant> StevenK: Well, have you changed the code to make it do that?
[00:51] <StevenK> I don't know how :-(
[00:52] <StevenK> I thought I had to add the OopsHandler in scripts.logger, but LaunchpadCronScript adds it anyway
[00:52] <StevenK> There is a log_unhandled_exceptions_func function, but I'm not sure if that interacts with the handler, or what goes on
[00:54] <wgrant> Well, find out how the current handler works
[00:54] <wgrant> That should tell you why the OOPS handler doesn't
[01:09] <StevenK> wgrant: I'm not sure if OopsHandler is even used by anything that isn't a test
[01:30] <StevenK> Hmm
[01:31] <StevenK> logger.exception adds an ERROR, which should get tripped by the OopsHandler to give an oops
[01:32] <StevenK> wgrant: I've been staring at this too long. Can you glance at http://pastebin.ubuntu.com/1373869/ and see if you can find something I'm missing?
[01:39] <wgrant> What doesn't work?
[01:40] <StevenK> The raise Exception in the midst of expire-bugtasks prints out a full traceback
[01:42] <wgrant> StevenK: OopsHandler in its current state is designed to log an OOPS for any message greater than a warning
[01:42] <wgrant> You might want a separate one for exceptions
[01:42] <wgrant> Hm, though it looks like it's meant to handle it
[01:44] <StevenK> Exactly
[01:44] <StevenK> Like I say, been staring at it too long
[01:46] <wgrant> StevenK: Hm, it works fine for me
[01:46] <wgrant> I get OOPSes out of it properly
[01:46] <StevenK> wgrant: Oh?
[01:46] <StevenK> Can I see the output?
[01:47] <wgrant> There's no special output, because you need a custom formatter for that
[01:47] <wgrant> But an OOPS is logged
[01:47] <StevenK> Ah
[01:48] <StevenK> So I need to grow a OopsFormatter
[01:48] <wgrant> Probably, yes
[01:48] <cjwatson> wgrant: Hmm, if bug 817358 is specifically about lots of bugs, shouldn't it have been fixed by the introduction of ProcessAcceptedBugsJob?
[01:48] <_mup_> Bug #817358: Copying packages with lots of associated bugs can cause timeout <bugs> <package-copies> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/817358 >
[01:48] <StevenK> wgrant: Maybe we just make LaunchpadFormatter do it
[01:49] <wgrant> cjwatson: Copies
[01:49] <wgrant> cjwatson: Not accepts
[01:49] <cjwatson> (I realise syncSource is always going to be somewhat terrible, but in this specific instance ...)
[01:49] <cjwatson> wgrant: Yes, so?
[01:49] <cjwatson> wgrant: The implementation goes through the same bits
[01:49] <wgrant> Oh, I guess an in-app sync would use the same code...
[01:49] <wgrant> hmm.
[01:49] <cjwatson> zactly
[01:49] <wgrant> Fair point
[01:50] <wgrant> Fixed
[01:50] <cjwatson> Ta.  Not that it affects the critical count
[01:50] <wgrant> Indeed
[01:55] <StevenK> Hmmmm, now if the handler has created an oops, how the heck do I get my hands on it
[03:02] <StevenK> ... Why does the formatter get called first :-(
[03:07] <wgrant> StevenK: You may have to turn it all into a formatter rather than a handler, possibly
[03:08] <StevenK> Looking into a filter
[03:08] <StevenK> Might help
[03:08] <StevenK> I hope
[04:14] <StevenK>  5102 steven    21   1 1569m 1.5g 3312 R  89.1 19.3  11:43.05 bzr
[04:14] <StevenK> Fun
[04:33] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/destroy-librarianformatter/+merge/135311
[04:33] <wgrant> StevenK: Why do you hate freedom^Wtracebacks?
[04:34] <wgrant> It would seem prudent to show both the traceback and the OOPS ID
[04:34] <StevenK> I can remove that bit of LaunchpadFormatter if you wish
[04:34] <wgrant> That would be nice
[04:34] <wgrant> Otherwise if the OOPS goes nowhere then we have no idea what went wrong
[04:35] <StevenK> -LDAP!
[04:35] <wgrant> ?
[04:35] <StevenK> Healing: 389 lines of code
[04:37] <StevenK> wgrant: http://pastebin.ubuntu.com/1374074/
[04:37] <wgrant> And corresponding test changes, presumably
[04:37] <wgrant> But yeah, that sounds good
[04:37] <StevenK> I've tossed it at ec2 test, so we'll see what the fallout is.
[04:38] <wgrant> I mean you added two tests for the OOPS ID
[04:38] <wgrant> They are presumably now broken
[04:39] <StevenK> I did?
[04:39] <wgrant> Oh
[04:39] <wgrant> Those were just in the description
[04:39] <wgrant> Right
[04:39] <StevenK> Yes, that was a demo
[04:48] <StevenK> wgrant: Hmm, does my change kill your milliseconds logging?
[04:49] <wgrant> Remarkable timing
[04:49] <wgrant> That logging is not mine, but stub's
[04:49] <wgrant> But you still use LaunchpadFormatter, don't you?
[04:49] <wgrant> Which should preserve it
[04:50] <StevenK> wgrant: But it was created differently based on the milliseconds argument
[04:50] <StevenK> LibrarianFormatter was a subclass of LaunchpadFormatter
[04:50] <wgrant> Ah
[04:50] <wgrant> You're right, yeah
[04:50] <wgrant> You'll need to revert that bit
[05:35] <stub> LibrarianFormatter should die
[05:35] <StevenK> stub: I killed it
[05:35] <stub> Yay. I would have but was scared of dealing with the test fallout
[05:36] <StevenK> So far only one failing test
[05:37] <stub> Bug #641103
[05:37] <_mup_> Bug #641103: LibrarianFormatter should die <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/641103 >
[05:37] <StevenK> stub: You'll note there is an MP attached ...
[05:58] <stub> I could have sworn we supported multiple --log-file arguments
[05:58]  * stub wonders why he didn't
[05:59] <wgrant> Huh, don't we?
[05:59] <wgrant> I'd always assumed that just worked
[05:59] <wgrant> But I guess I've only ever used the default stdout -q/-v options plus a --log-file
[06:02] <stub> no, just noticed in the MP and had to double check. It would be trivial to support it
[07:04] <nigelb> bigjools: hahaha, gavinator
[07:06] <bigjools> :)
[07:07] <bigjools> the meme commences
[07:18] <lifeless> oh no
[07:18] <lifeless> you didn't
[08:21] <adeuring> good morning
[10:04] <czajkowski> bigjools: you're a tad evil!
[10:04] <bigjools> guffaw
[10:05] <czajkowski> at least this memme isn't filling up planet ubuntu ..yet!
[11:46] <rick_h> morning party people
[11:47] <mgz> morning rick_h
[11:48] <czajkowski> howdy
[13:53] <jcsackett> morning all.
[13:53] <czajkowski> ello jcsackett
[14:37] <adeuring> abentley: https://code.launchpad.net/~adeuring/launchpad/bug-1056881/+merge/135374
[14:37] <abentley> adeuring: ack
[15:25] <abentley> adeuring: If a spec is made PROPRIETARY, the AccessArtifactGrant.grantor will be the person who made it proprietary, and so they will be able to unsubscribe anyone.
[15:26] <adeuring> abentley: yes
[15:27] <adeuring> abentley: well, provided that they had to grant an AAG
[15:27] <abentley> adeuring: Right.  They won't be able to unsubscribe anyone who had an APG.
[15:28] <adeuring> abentley: is anything wrong with this logic?
[15:31] <abentley> Well, it's not a great rationale for granting the ability to unsubscribe people.  Though of course I understand the limitation in the schema that makes this hard.
[15:33] <adeuring> abentley: right, but there also this logic: Basically, people with lp.Edit permission can also grant access to other people, and the same permission is needed to change the information type. And revoking grnats need again the same permission
[15:40] <abentley> adeuring: I'm in the check-in hangout, so I'll get back to this after.
[15:40] <adeuring> abentley: gah, forgot that completely..
[16:00] <jcsackett> abentley: are you reviewing today? if so, can you look at https://code.launchpad.net/~jcsackett/launchpad/filter-in-getRequestTargets/+merge/135457
[16:01] <jcsackett> abentley: well, that answers my first question. :-P
[16:01] <abentley> jcsackett: Yes, I'll look at it after I'm done with abel's.
[16:01] <jcsackett> abentley: awesome, thanks.
[16:02] <jcsackett> deryck: i was just looking over our cards, and i think there are some comments on bug 1043902 that make a strong case for dropping it. has there already been discussion incorporating that info?
[16:02] <_mup_> Bug #1043902: magic InformationType numbers in access grant related DB procedures <information-type> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1043902 >
[16:04] <abentley> adeuring: This solution is an improvement, but ensure a bug is filed about the lack of a subscribed_by field in SpecificationSubscription, and reference it in the security adapter and bug comments.
[16:05] <abentley> s/bug comments/test comments/
[16:05] <adeuring> abentley: ok
[16:07] <abentley> adeuring: You can address the too-long enum names by assigning the enum to a local variable.  That is what I do.
[16:08] <adeuring> abentley: I know...
[16:11] <abentley> adeuring: Other than that, r=me.
[16:11] <adeuring> abentley: thanks
[16:12] <deryck> jcsackett, yes, I think that can be dropped, but would love to hear for sure from adeuring. Just in case there's some bit of what he's worried about that I don't understand.
[16:12] <jcsackett> deryck: fair.
[16:12] <deryck> adeuring, can we drop bug 1043902?
[16:12] <_mup_> Bug #1043902: magic InformationType numbers in access grant related DB procedures <information-type> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1043902 >
[16:14] <adeuring> jcsackett, deryck: Its not that important for me. My main reason for writing this bug was that I like to have a kind of additional check for things secuirty related.. FOr xample, if the meaning of an integer value is changed in Python code but not in stored procedures, this can have security implications. OTOH, LP devs tend not to be insane enough to this ;)
[16:15] <adeuring> so, its fine for me to drop this card
[16:16] <abentley> jcsackett: in  getRequestTargets, having the user default to none means that calling code can accidentall omit it.  I think it should be a non-optional parameter, even though this means changing parameter order.
[16:17] <jcsackett> abentley: there's a small number of call sites, so that works for me. same comlaint for list_product_request_filters?
[16:18] <abentley> jcsackett: Same complaint for list_product_request_targets
[16:18] <jcsackett> right, that's the one.
[16:19] <jcsackett> small set of sites there, so no worries.
[16:19] <abentley> Aside from that, this looks good.  r=me.
[16:28] <jcsackett> thanks. i'll make those changes.
[16:38] <deryck> adeuring, ok, thanks.  sorry was on call.
[16:38] <deryck> jcsackett, do you mind dropping both the bug and the card then?
[16:38] <jcsackett> deryck: on it.
[16:40] <deryck> thanks!
[18:20] <rick_h> abentley: review if you have the time. https://code.launchpad.net/~rharding/launchpad/translatables/+merge/135492 after talking with deryck went with the less impact approach
[18:45] <abentley> rick_h: Hmm.  Perhaps we don't need to do this, since AIUI products cannot be proprietary if they have translation enabled.
[18:46] <abentley> rick_h: That's not actually implemented yet, but https://bugs.launchpad.net/launchpad/+bug/1079785/comments/3
[18:46] <_mup_> Bug #1079785: public artifacts are permitted on confidential projects <private-projects> <Launchpad itself:In Progress by abentley> < https://launchpad.net/bugs/1079785 >
[18:51] <rick_h> abentley: ah, gotcha
[18:51] <rick_h> completely didn't think of that part
[18:58] <rick_h> abentley: so I read that as we'd like to get to deleting things that would fall into here, but we don't currently so I'm going to go with let's make sure we don't leak for the moment?
[19:04] <abentley> rick_h: I'm not thrilled with that approach, because we're not guaranteeing privacy now, and it makes more work for later when we have to disable the test and remove the code.
[19:05] <rick_h> abentley: I guess if we have cards for handling the delete/clean up and the whole transitino process I'd be ok with burying this under that work.
[19:06] <rick_h> but I don't want to leave a hole out there without something on the board that says it won't be a hole
[19:06] <abentley> rick_h: Sure, let's do that.
[19:06] <rick_h> abentley: so will yuor current branch then do all that is mentioned in that comment?
[19:08] <abentley> rick_h: Probably.  I can certainly commit to doing the translation bit.
[19:08] <rick_h> Ok, will put the branch in WIP and move the card back into the final with a note on it that it can be wiped once that's true
[19:08] <rick_h> and I suppose the other branch I landed yesterday can probably backed as well then
[19:09] <abentley> rick_h: Right.  Sorry I didn't catch it then.
[19:10] <rick_h> oh well, I'll move that card back into final and alter it to a back-out work then.
[19:12] <abentley> rick_h: I've added a misc card for fixing any existing data.
[19:12] <rick_h> ok
[19:51] <jcsackett> abentley: can you review https://code.launchpad.net/~jcsackett/launchpad/blueprints-in-ui-not-specification/+merge/135503
[19:51] <abentley> jcsackett: Sure, but give me a few minutes.
[19:51] <jcsackett> abentley: no rush.
[20:02] <abentley> jcsackett: r=me
[20:06] <jcsackett> abentley: thanks!
[22:01] <sinzui> StevenK, wgrant, I am in a meeting. I may be 30 minutes late.