[00:06] <wallyworld> sinzui: huwshimi: wgrant: standup?
[00:06] <sinzui> I think my mic is dead. I will restart
[00:12] <huwshimi> sinzui: wallyworld: was just on the phone, back now.
[00:17] <poolie> good morning
[00:22] <huwshimi> poolie: Morning
[00:27] <wallyworld> wgrant: want a review? https://code.launchpad.net/~wallyworld/launchpad/poppy-sftp-gpgconf/+merge/59154
[00:28] <wgrant> Not of that, but OK.
[00:28]  * wgrant looks.
[00:29] <wallyworld> wgrant: you don't have to if you don't want, just asking :-)
[00:30] <wgrant> No, no, I'll do it, it's just a bad problem with no good solution.
[00:30]  * wallyworld nods
[00:39] <wgrant> lifeless: Could you mentor https://code.launchpad.net/~wallyworld/launchpad/poppy-sftp-gpgconf/+merge/59154?
[01:22] <wallyworld> wgrant: with the time.sleep() in the test, we need that because we need to give the job a chance to trigger and execute. simply setting the times in the past won't test that aspect
[01:23] <wgrant> :( OK'
[01:24] <lifeless> wallyworld: while you're looking at it
[01:25] <lifeless> the inner function isn't needed, just make it a normal instance function and call self.touch..
[01:25] <lifeless> secondlyt
[01:25] <lifeless> you appear to do this unconditionally whether its in a twisted environ or not
[01:25] <lifeless> that seems likely to fail hilariously, or perhaps I misunderstand the context
[01:25] <wgrant> Isn't that OK?
[01:25] <lifeless> lastly, should touch the dir as well, just to be fireproof
[01:27] <wallyworld> lifeless: we do touch the dir as well. wrt the inner function, i didn't want to expose the code on the object. is there a reason why you don't like the inner. wrt twisted, yes you are right but i though twisted was part of our deployment and hence could be assumed?
[01:27] <lifeless> wallyworld: in reverse order
[01:27] <lifeless> wallyworld: we use gpghandler in the zope environment too, with no reactor running, and we create them transiently
[01:28] <wallyworld> lifeless: ok. no twisted. will fix
[01:28] <lifeless> wallyworld: you are basically creating a [slow] memory leak of incomplete looping calls per instance with the current code
[01:28] <lifeless> wallyworld: in fact, thinking more about it
[01:28] <lifeless> you need to cancel the looping call
[01:28] <lifeless> at some point as well
[01:28] <lifeless> on the function
[01:29] <lifeless> uhm, style. I prefer not to curry things that don't need currying
[01:29] <wallyworld> lifeless: the looping call is cancelled in the atexit handler or when the job is rescheduled. is that not enough?
[01:29] <lifeless> it makes them more testable
[01:30] <lifeless> oh, and you ar makeing _touch_home_call a mixed attribute
[01:30] <lifeless> set it in __init__
[01:30] <lifeless> -or-
[01:30] <lifeless> assign to it via self.__class__._touch_home_call
[01:30] <wallyworld> lifeless: i guess it's a matter of opinion. i prefer to enforce encapsulation in this case. i don't think the inner hinders testability here but will move it out
[01:31] <lifeless> so in terms of cancellation, the following will leak:
[01:33] <lifeless> ahehm
[01:34] <lifeless> how does the buildmaster use this
[01:34] <lifeless> as a secured utility
[01:34] <wgrant> buildmaster doesn't.
[01:34] <lifeless> or via instances ?
[01:34] <wgrant> poppy does.
[01:34] <lifeless> blah yes that thing
[01:34] <wgrant>             sig = getUtility(IGPGHandler).getVerifiedSignatureResilient(
[01:34] <wgrant> securedutility
[01:34] <lifeless> ok
[01:35] <lifeless> so, we shouldn't be leaking
[01:35] <wgrant> That's what I thought. There's only ever one instance.
[01:35] <lifeless> but the touchiness won't work on zope
[01:35] <lifeless> wgrant: one per thread, no ?
[01:36] <wgrant> Hmm, I guess it probably does use a thread-local site manager, true.
[01:37] <wallyworld> i didn't know that. i though sm was global to a zope instance
[01:37] <wallyworld> but then again my zope foo is not that high
[01:37] <lifeless> wallyworld: it is global
[01:37] <lifeless> but its allowed to follow any old policy for what it hands out
[01:38] <lifeless> I'm pretty sure the default which we use is thread local utilities
[01:38] <wallyworld> ok
[01:38] <lifeless> so that folk don't have to deal with concurrent mutation of instance attributes
[01:38] <lifeless> anyhow
[01:38] <lifeless> we're solving a bug in the twisted environment
[01:38] <lifeless> we should only run the loop in the twisted environment
[01:38] <lifeless> but always in the twisted env
[01:39] <lifeless> I've no idea how to make that true.
[01:39] <wallyworld> lifeless: i could just do it another way without twisted and remove the dependency
[01:40] <wallyworld> but you'd think there would be an api to see if a reactor were running
[01:40] <wallyworld> in the current environment
[01:41] <lifeless> One way would be a different class (e.g. a subclass) for the twisted case and either different zcml or ask for a different utility Iface
[01:42] <lifeless> wallyworld: there is an api to see if there is a running reactor, but do we know that the reactor is running when zcml is parsed during startup of poppy-sftp
[01:45] <wallyworld> lifeless: so if i did getUtility() with  a different interface, i'd only need to do it in the one place - lib/lp/poppy/twistedftp.py  ??
[01:47] <lifeless> yes
[01:47] <wgrant> INotBrokenGPGHandler?
[01:47] <lifeless> and perhaps any tests that are testing lib/lp/poppy/twistedftp.py
[01:48] <wallyworld> cool. i'll do that. keeps all the other pgphandler instances nice and clean. and i hadn't forgotten about any twistedftp tests :-)
[01:48] <lifeless> hmm
[01:49] <lifeless> wonder if a class action against sony is appropriate (for forcing disclosure of birthdate to sign up and then not protecting it properly per UK data protection act rules)
[01:49] <wallyworld> wgrant: perhaps best to just change the known broken use case initially?
[01:49] <wgrant> lifeless: They're already being sued in the US.
[01:49] <wallyworld> i don't think i'll use your suggested iface name :-)
[01:49] <wgrant> Not sure if it's class action, though.
[01:49]  * wallyworld hates sony even more than apple if that's possible
[01:50] <wgrant> wallyworld: Hmm. I think they're pretty similar.
[01:50] <wgrant> Apple has some good aspects, but they are also far more effective at their evil than Sony is.
[01:50] <wgrant> But Sony has no good aspects...
[01:50] <wgrant> So hm..
[01:51] <wallyworld> i don't think apple has any good aspects either. i hate their dumbed down, locked down, retarted pos ipads, iphones and app store
[01:51] <wgrant> They turned KHTML into an awesome WebKit.
[01:51] <wgrant> That's at least one good thing.
[01:52] <wallyworld> and the rapid fanbois whole bend over for steve jobs like he is some sort of deity
[01:52] <wallyworld> i guess so
[01:53] <lifeless> wallyworld: its his massive..innovations they like
[01:53] <wallyworld> lifeless: you say innovations, i say merely refining concepts developed by others
[01:57] <lifeless> wgrant: is it a bug or feature that the upload works after gpg verification fails
[02:00] <lifeless> 760 timeouts
[02:00] <lifeless> reality sets in
[02:01] <wgrant> lifeless: Both.
[02:01] <wgrant> lifeless: It's intentional that they're let through for now, in case it breaks.
[02:01] <wgrant> lifeless: I wonder how many of those timeouts are from edge.
[02:03] <wgrant> This OOPS report is indeed much more plausible.
[02:10] <lifeless>  17 https://bugs.launchpad.net/ubuntu/+bugtarget-portlet-bugfilters-stats (Distribution:+bugtarget-portlet-bugfilters-stats)
[02:10] <lifeless>        OOPS-1943AQ100, OOPS-1943AZ499, OOPS-1943BA451, OOPS-1943CD170, OOPS-1943CK442
[02:10] <lifeless>       6 https://bugs.edge.launchpad.net/ubuntu/+bugtarget-portlet-bugfilters-stats (Distribution:+bugtarget-portlet-bugfilters-stats)
[02:10] <lifeless>        OOPS-1943EDGEA955, OOPS-1943EDGEB1120, OOPS-1943EDGEB1422, OOPS-1943EDGEE1002, OOPS-1943EDGEE897
[02:10] <lifeless>       3 https://launchpad.net/ubuntu/+bugtarget-portlet-bugfilters-stats (Distribution:+bugtarget-portlet-bugfilters-stats)
[02:10] <lifeless>        OOPS-1943AO372, OOPS-1943DT447, OOPS-1943L444
[02:10] <lifeless> so more from edge as a %, less as an absolute count
[02:12] <wgrant>   53 SELECT BugTask.assignee, BugTask.bug, BugTask.bugwatch, BugTask.date_assigned, BugTask.date_close ... e AND BugTask.bug = Bug.id )) ORDER BY BugTask.importance DESC, BugTask.id LIMIT $INT OFFSET $INT:
[02:12] <wgrant>     GET: 53 Robots: 0  Local: 1
[02:12] <wgrant>       23 https://api.edge.launchpad.net/1.0/ubuntu (Distribution:EntryResource:searchTasks)
[02:16] <lifeless> find the user. Point them at prod.
[02:19] <lifeless> ok
[02:19] <lifeless> I'm going to nose down on these triggers
[02:19] <lifeless> unless anyone needs more from me?
[02:44] <wgrant> sinzui: Hi.
[04:23] <wgrant> lifeless: Hmm, 99% under 1.45.
[04:23] <wgrant> lifeless: That's not bad.
[04:38] <lifeless> cool
[05:07] <jtv> lifeless: thanks for that review -- you're a lifesaver.  Our OCR system has basically collapsed.
[05:08] <lifeless> :(
[05:08] <lifeless> I have a killer headache
[05:08] <lifeless> a freaking sore arm
[05:08] <lifeless> and triggers to write
[05:08] <lifeless> I think today will be a writeoff
[05:13] <jtv> lifeless: a sore arm is a warning.  Heed it!
[05:14] <lifeless> jtv: I was injected with 1ml of stuff I'm highly allergic too
[05:14] <lifeless> jtv: not rsi
[05:14] <lifeless> s/too/to/
[05:15] <jtv> Okay... a warning not to let people do that then I guess.  Wow that sucks.
[05:15] <StevenK> lifeless: That sounds like a punishment. What did you say to Lynne? :-P
[05:16] <lifeless> http://en.wikipedia.org/wiki/Allergen_immunotherapy
[05:16] <StevenK> Ugh
[05:17] <StevenK> Just reading that article makes my skin crawl
[05:29] <wgrant> Hi stub.
[05:30] <stub>     UploadFailed: Server said: 200
[05:30] <stub> Yo
[05:31] <stub> Haven't seen that failure before in buildbot, but subsequent builds worked so looks spurious
[05:31] <wgrant> stub: Yeah, known spurious failure.
[05:31] <wgrant> stub: Did SSO fork the emailaddress table?
[05:32] <stub> So occasionally the librarian succeeds, which is considered a failure? :-)
[05:32] <wgrant> Yup.
[05:32] <stub> wgrant: Yes. They have their own email address list.
[05:32] <wgrant> stub: It is full of cruft :(
[05:32] <wgrant> stub: It contains eg. team email addresses.
[05:32] <wgrant> Which don't make sense in SSO.
[05:32] <wgrant> And cause crashes (since it assumes all emailaddresses have an account)
[05:33] <stub> I guess they need to clean it up or ask me too.
[05:34] <wgrant> Their table even still has a person column.
[05:34] <stub> wgrant: Have you opened a bug?
[05:34] <wgrant> No.
[05:34] <wgrant> Should I?
[05:34] <stub> Yes. canonical-identity-provider I think.
[05:35] <wgrant> That's the right project, but I wasn't sure if it was worth a bug.
[05:35] <stub> Crashers are worth bugs :)
[05:35] <wgrant> I guess it means their schema is buggy, true.
[05:37] <stub> Their schema is a pile of cruft because they inherited it from us and only needed 10% of the fields.
[05:37] <stub> They also have a number of Django defined tables which is the stuff  they created.
[05:38] <wgrant> Yeah.
[05:39] <stub> effort/reward for fixing the crufty schema is low (high effort due to high availability requirements), but cleaning out bad data is little trouble.
[05:45] <lifeless> stub: hi
[05:45] <stub> lifeless: Morning
[05:47] <lifeless> stub: I only got a tiny bit done so far - monthly allergy shot messed me up :(
[05:48] <stub> lifeless: Sure. Want me to continue working on my branch or pull in yours again? I wasn't sure if using the BugSummary composite type was a good idea or not.
[05:48] <lifeless> stub: I think it is
[05:48] <lifeless> stub: have your morning coffee, check for dba bugs, reviews etc
[05:48] <lifeless> I have a bit of structure I want to stab at this
[05:48] <stub> cool.
[05:49] <stub> I gotta book me a flight to Dublin.
[05:49] <stub> Not sure exactly why I'm needed at a UI focused sprint, but Ireland should be cool :)
[05:54] <lifeless> cause abstractions leak :)
[05:54] <stub> Who you calling an abstraction???
[05:55] <lifeless> I don't know, do you leak ?:P
[06:14] <lifeless> stub: http://www.slideshare.net/selenamarie/managing-terabytes-when-postgresql-gets-big may interest you
[06:15] <lifeless> stub: 400K tables
[06:37] <jtv> lifeless: selena may want to consider not using WordPress MU then.  :)
[06:38] <wgrant> Anyone want to review https://code.launchpad.net/~wgrant/launchpad/bug-761439/+merge/59317?
[06:40] <stub> pg gets really sucky with huge numbers of tables, but some people do it anyway - just cloning the one set of tables over and over for every customer
[06:40] <jtv> wgrant: loading
[06:40] <StevenK> jtv: I was about to approve it
[06:41] <jtv> StevenK: then don't let me stop you
[06:41] <wgrant> StevenK: You managed to not vomit?
[06:42] <StevenK> Only just.
[06:44] <stub> Geez this current flash player sucks
[06:47] <jtv> lifeless: perhaps you're up for mentoring a review by william?  I need an interretur(*) for https://code.launchpad.net/~jtv/launchpad/db-bug-766807/+merge/59027
[06:48] <jtv> (*) Which I hope is Latin for something like "imprimatur" except for landing instead of printing.  Hope it doesn't mean "let it be buried."
[06:48] <jtv> Does Latin even have terms for landing?  Control towers?  Re-entry shields?
[06:50] <StevenK> jtv: cronscripts/create-distroseries-indexes.py is pointless, run_jobs.py can do it
[06:50] <jtv> StevenK: does run_jobs.py run on the right host?
[06:51] <StevenK> jtv: Note that IDistroSeries.deriveDistroSeries() doesn't use i-f-p, so you'll need to create a job at the end of IDS, not i-f-p
[06:51] <StevenK> jtv: Er, what? How is that even related?
[06:51] <jtv> I don't know.  You started it.
[06:52] <StevenK> jtv: I see the comment in it, but the generic run_jobs.py cronscript can handle it, and it stops our tree getting tons of small mostly-identical cron scripts.
[06:52] <jtv> Okay, how do I use the generic run_jobs.py cronscript?
[06:52] <wgrant> StevenK: Oh, you mean like add it to a new source group and run run_jobs over that group on cocoplum?
[06:53] <StevenK> jtv: You add the interface to schema-lazr.conf and 'run_jobs.py create_distroseries_indexes'
[06:54] <StevenK> As much as I hate perpetuating that antipattern, it's what we have.
[06:54] <jtv> Never mind, I'll look for it in the wiki.
[06:55] <StevenK> jtv: I could create a diff quicker than this argument :-P
[06:55] <jtv> StevenK: I'm not sure what argument we're having, but if a diff is the easiest way to explain what you're trying to tell me, then please do!
[06:56] <jtv> No documentation on the wiki.  :(
[06:57] <StevenK> jtv: There is a generic job running cronscript: cronscripts/run_job.py
[06:57] <jtv> Okay, that part I had figured out by now.
[06:57] <jtv> I'm now looking for documentation.
[06:57] <StevenK> jtv: It is almost identical to the new cronscript you've added in your branch.
[06:58] <StevenK> I'm not sure it is documented.
[06:58] <jtv> It doesn't seem to be.
[07:00] <StevenK> jtv: http://pastebin.ubuntu.com/600158/
[07:01] <jtv> StevenK: so this is part of, but not mentioned in, the job-system documentation?
[07:01] <jtv> Would be worth updating that page.
[07:02] <StevenK> jtv: It's certainly part of the job system, but I doubt it is documented.
[07:02] <jtv> Well there's no mention anywhere on the dev wiki.
[07:02] <jtv> Two places in the test suite mention the script.
[07:02] <StevenK> One of them would be the IDSJ job runner
[07:02] <jtv> Yes.
[07:03] <StevenK> Since I ripped out it's cronscript when I learnt about run_jobs
[07:03] <jtv> And there's 1 mention in the production crontabs.
[07:03] <jtv> What's the point in writing reusable code if there's no way for people to find out about it?
[07:04] <StevenK> Then fix the documentation? :-)
[07:04] <jtv> The documentation is just bad enough that I'm afraid to touch it.
[07:05] <StevenK> Yes.
[07:05] <jtv> By the way I am grateful to you for pointing this out.
[07:37] <lifeless> stub: jtv: cheatsheet - how do you declare a variable to how a set of rows ?
[07:37] <lifeless> s/how a/hold a/
[07:38] <lifeless> jtv: sorry, not just now (review); I can do it later, or any other dev can mentor wgrants review; I'm not picky
[07:38] <stub> 'setof record' or 'setof bugsummary'
[07:38] <stub> oh... you want an array I think
[07:38] <lifeless> declare tags setof bugtag; ?
[07:38] <stub> record[] or bugsummary[]
[07:38] <lifeless> a setof is being returned from a helper function
[07:39] <stub> So returning from a helper, you want RETURNS SETOF bugsummary
[07:39] <stub> Then in the helper, you want to do 'RETURN NEXT a_bugsummary;' which works like yield in python generators
[07:40] <lifeless> yes, I have that
[07:40] <stub> I think I had this in my stub bugsummary_sources()
[07:40] <lifeless> this is in the function that calls that
[07:40] <lifeless> http://pastebin.com/cVajbkq3
[07:40] <lifeless> is the helper
[07:42] <stub> So you can just loop over the result of that doing RETURN NEXT is one way. Or else you should be able to assign the result of that method to a 'bugsummary%ROWTYPE[]' array and iterate over that
[07:42] <lifeless> grwat, thanks
[07:42] <stub> Or we could do this in Python :)
[07:42]  * stub wonders if we care about the speed hit
[07:43] <stub> plpythonu I mean
[07:54] <lifeless> psql:test.sql:157: ERROR:  syntax error at or near "["
[07:54] <lifeless> LINE 6:     tags bugtag%ROWTYPE[];
[08:13] <lifeless> stub: pushing now; got time for a weekly catchup call?
[08:14] <stub> lifeless: sure.
[08:14] <stub> lifeless: you got the syntax working?
[08:14] <lifeless> stub: I did some reading
[08:14] <stub> what is the syntax?
[08:14] <lifeless> looks like an immutable cursor or some such is a better fix
[08:14] <lifeless> *fit*
[08:15] <lifeless> it really wants just 1 row (select into) or a cursor usage.
[08:15] <poolie> i'm getting a proxy timeout on +filebug, ie 'please try again' with no oops
[08:15] <lifeless> stub: however I'm barely a trained monkey here
[08:15] <wgrant> Oh no not again.
[08:15] <wgrant> poolie: How long does it take?
[08:15] <wgrant> And what'
[08:15] <wgrant> s the URL?
[08:15] <lifeless> stub: I've achieved what I wanted which is a structure that is auditable and parallels the loader.
[08:15] <poolie> it was /bzr/+filebug
[08:15] <lifeless> stub: its pushed; skype ?
[08:15] <poolie> it worked on the 3rd attempt
[08:16] <stub> foo integer[]; works fine. bugsummary%ROWTYPE[] should too... but it doesn't.
[08:16] <stub> skype - sure
[08:16] <poolie> uh, it took quite a while
[08:16] <wgrant> lifeless: Do we have visibility into queue depth yet?
[08:16] <poolie> maybe 20s?
[08:16] <lifeless> wgrant: no; losa time
[08:16] <wgrant> spm: Hi.
[08:16] <poolie> the successful run says it completed in 0.64s, and it was probably really a couple of seconds
[08:16] <lifeless> poolie: 30 seconds would be haproxy
[08:16] <spm> ...
[08:16] <wgrant> spm: What's the queue depth like on the haproxies?
[08:17] <poolie> is there anything that distinguishes different types of failure short of an oops?
[08:17] <poolie> ie haproxy vs apache ?
[08:17] <poolie> i mean, anything visible in the page
[08:17] <wgrant> There are slight differences in the HTML. But otherwise not really, AFAIK.
[08:17] <spm> wgrant: currently 0 down the line, but has had a max of 65. banana.
[08:18] <wgrant> Hmm. Not so bad.
[08:18] <poolie> perhaps something subtle would generate better bug reports? i don't know
[08:19] <wgrant> The appserver request graphs are a little empty.
[08:53] <danilos> rvba, r=me on your branch from yesterday
[08:53] <danilos> rvba, not sure about str(enum), so please check with someone else (though this seems right)
[08:54] <rvba> danilos: great, thanks ... the str(enum) works, but I wonder if it's the Right Way to do it. I'll ask around.
[08:56] <lifeless> a'voir (maybe back later)
[08:56] <rvba> danilos: I'll wait a bit to land this branch since StevenK's branch which is depends on is still in the works ...
[08:57] <danilos> rvba, understood :)
[08:58] <StevenK> rvba: I was going to mention that to you. One column, using an enum
[09:07] <adeuring> good morning
[09:23] <mrevell> Morning
[09:32] <jtv> hi mrevell
[09:37] <mrevell> hey jtb
[09:37] <mrevell> er, jtv
[09:40] <jtv> :)
[10:23] <lifeless> poolie: hi
[10:23] <lifeless> poolie: an unthemed 503 is a complete fail in the zope stack (error handler barfing)
[10:23] <lifeless> poolie: a themed oops is a regula fail in the zope stack
[10:24] <lifeless> poolie: a themed 'could not connect' is haproxy/apache (I forget the exact difference, 504/503 I think respectively
[10:24] <lifeless> poolie: and a browser-themed page implies a networking /ssl error
[10:35] <lifeless> still a little excessive 1183  OOPS-1943EC114  POFile:+translate
[10:45] <jtv> StevenK, lifeless: I updated the jobs documentation.  If I got anything horribly wrong then please let me know, that future generations may be entertained and edified.  Look for "run_jobs."  https://dev.launchpad.net/Foundations/JobSystem
[11:12] <jtv> allenap: could I trouble you for a review?  It's large, but wgrant's already gone over it once and StevenK also made suggestions.  The only _really_ new part compared to what they looked at, apart from their suggestions, is some documentation for JobCronScript.
[11:12] <jtv> It's this one: https://code.launchpad.net/~jtv/launchpad/db-bug-766807/+merge/59027
[11:12] <allenap> jtv: Sure :)
[11:12] <jtv> Great, thanks
[11:22] <allenap> jtv: Just revision 10479 then?
[11:23] <allenap> Ah, no revision 10477 too.
[11:23] <jtv> allenap: well william's review also needs mentoring.
[11:23] <allenap> jtv: Okay.
[11:23] <jtv> BTW I updated the job-system docs on the wiki to match what I did here, so you may not want to trust it too much as validation for this branch.
[11:26] <poolie> can you no longer request another review from someone who already commented?
[11:26] <poolie> or was it always thus?
[11:27] <poolie> also, could i get another review on <https://code.launchpad.net/~mbp/launchpad/mail-cleanup/+merge/58867>
[11:28] <rvba> wgrant: Hi! Steven suggested me to request your opinion/suggestions about a task I'm working on ... would you have some time to help me with that?
[11:28] <rvba> I need to change the perm check for syncing packages (from the +localpackagediff pages) from lp.Edit on the series to lp.Append on the archive.
[11:28] <wgrant> rvba: Sure.
[11:28] <rvba> The tricky part is that this check cannot be done in a security adapter because it requires the pocket and component to be available and it's not the case in a security adapter.
[11:28] <rvba> great, thanks
[11:29] <wgrant> lp.Append on the archive does not use the pocket or component, and is not what you want.
[11:29] <rvba> wgrant: here a (very much in the works) mp https://code.launchpad.net/~rvb/launchpad/change-perm-sync/+merge/59341
[11:29] <wgrant> You mean you want it to respect actual upload privileges?
[11:29] <rvba> it's how I understand it yes
[11:30] <rvba> the tickets says 'syncing packages should be lp.append on the archive, not lp.edit on the series'
[11:30] <wgrant> Right. We currently use launchpad.Append in parts of the code as a hack to very roughly approximate that.
[11:30] <wgrant> Ah.
[11:30] <wgrant> So, probably easiest to use lp.Append to start with, if that's all Julian wants for now.
[11:30] <wgrant> That doesn't need the pocket or component.
[11:31] <wgrant> Which bug is this?
[11:31] <rvba> but he also told me that I will need pocket and component ... and this won't be able to use a security adatper.
[11:31] <rvba> there is no but for this yet.
[11:31] <wgrant> He probably didn't mean launchpad.Append, then :/
[11:31] <rvba> that's wht I figured
[11:32] <wgrant> You may want to look at package branches.
[11:32] <rvba> wgrant: perhaps you could have a look at the partial diff on the MP and tell me what you think
[11:33] <rvba> I guess the tricky part is that I not only have to figure out a solution for this ... but also what the problem is :)
[11:33] <wgrant> rvba: Do you have a quote of what Julian said? I saw a bug to use launchpad.Append some time ago, but this sounds like far more than that.
[11:34]  * rvba scans the logs
[11:34] <rvba> avril 27 10:46:55 <bigjools>    rvba: and the permission change
[11:35] <rvba> avril 27 10:47:09 <bigjools>    but that one is hard because of the problem we encountered before
[11:35] <rvba> avril 27 10:47:28 <bigjools>    (we need more info than available in the security adapter)
[11:35] <rvba> avril 27 10:49:04 <bigjools>    I think we can do it, but it will mean not doing it in the security adapter
[11:35] <wgrant> Right, so it sounds like he wants it to go all the way.
[11:35] <rvba> and also (from an email)
[11:35] <wgrant> rvba: You'll want to make use of Archive.canUploadSuiteSourcePackage.
[11:35] <rvba> The security adapters only have the context archive and the user.  Far more is
[11:35] <rvba> needed to ascertain upload privileges. So no, it isn't.  ;)
[11:36] <rvba> It can be worked around by doing the security in the model layer though (not
[11:36] <rvba> the browser layer - so it also works for the API).
[11:36] <wgrant> rvba: That takes a person, suite and source package name, and does the rest for you.
[11:37] <rvba> wgrant: I reckon this is sort of what I did ... but I called directly Archive.checkUpload ... which is what canUploadSuiteSourcePackage seems to do
[11:37] <wgrant> rvba: Also, this probably needs to be flagged. syncSource must not be used to copy into a primary archive yet.
[11:38] <wgrant> rvba: You're using the source component instead of the destination component, but apart from that it looks OK.
[11:41] <rvba> wgrant: how can I get the destination component?
[11:41] <wgrant> rvba: canUploadSuiteSourcePackage has a reasonable example.
[11:42] <rvba> wgrant: (flag) all I do here is add a perm check to existing code ... and this perm check will only be performed if a not None person is passed, which is something that will be done only in flag protected code
[11:42] <rvba> wgrant: so I guess I should be covered don't you think?
[11:42] <rvba> component = sourcepackage.latest_published_component
[11:43] <wgrant> rvba: Ah, you're not also doing this through the API? Sure.
[11:43] <rvba> wgrant: not yet, but I've got another task waiting to expose the sync operation on the api
[11:44] <wgrant> rvba: syncSource is already exposed.
[11:44] <wgrant> (but restricted to launchpad.Append)
[11:44] <rvba> yes, I got confused: I meant doing the same check for the api call
[11:44] <wgrant> That's a long way off.
[11:44] <rvba> and remove the lp.Append protection
[11:45] <wgrant> It needs to do overrides and announcements and respect the queue first.
[11:45] <rvba> I see
[11:46] <rvba> wgrant: I think I'll wait for Julian for the api stuff then. At this stage I just wanted to make sure that my changes will be compatible with this future api refactoring.
[11:48] <rvba> wgrant: I think I'll change the call from checkUpload to canUploadSuiteSourcePackage ... looks like it's more consistent to use most high "level code".
[11:48] <rvba> wgrant: thanks a lot for you help ... I guess I'll have a good time writing tests for this :).
[11:48] <rvba> s/you/your/
[11:49] <wgrant> rvba: It looks reasonable. Although I wonder how it's going to behave for anonymous requests; self.user will be None, so person will be, so it will skip the check.
[11:50] <rvba> wgrant: well spotted ... I'll have to find a way around that ...
[11:51] <rvba> wgrant: in my experience (that is with other systems) the classic work around is for the infrastructure to pass a singleton AnonymousPerson and not None when dealing with anon requests
[11:52] <wgrant> rvba: Yeah :(
[11:53] <rvba> wgrant: I'll find a way ... thanks again for you time ... I might be back tomorrow with more questions ;)
[11:53] <rvba> sigh s/you/your/
[11:53] <wgrant> Heh.
[11:58] <rvba> StevenK: you might want to have a look at the above conversation :)
[13:03] <jtv> allenap: still reviewing?
[13:05] <gary_poster> allenap, hi.  https://code.launchpad.net/~gary/launchpad/bug771232/+merge/59302 could use a review if you have time.  If not, lemme know; I can ask someone on yellow to look at it.
[13:15] <allenap> gary_poster: Sure I'll look at it after I've finished jtv's review.
[13:15] <gary_poster> stub, forgive my paranoia, but buildbot blessed my db branch 15 hours ago and it is on db-stable but not on staging yet.  Should it be there already--is this indicative of a potential problem in the patch?
[13:15] <gary_poster> allenap, thanks!
[13:17]  * stub shrugs
[13:18] <gary_poster> uh, ok :-)
[13:18]  * stub has a look at the staging logs
[13:18] <gary_poster> thank you
[13:19] <gary_poster> I could do that too
[13:20] <stub> Might be faster... my net is the suck.
[13:21] <stub> I think some twats using our data centre have released an operating system or something.
[13:22] <gary_poster> heh
[13:23] <gary_poster> allenap, another favor I could ask you is to go to https://launchpad.net/launchpad/+subscriptions and tell me if you see any subscriptions now that you are in ~yellow (you definitely should see the one from now Launchpad Bug Contacts, and if you don't that is a bug).  You could also take a look at https://launchpad.net/launchpad-project/+subscriptions .
[13:24] <stub> gary_poster: What was the patch number? Looks like the update happened today but there were no patches to apply.
[13:24] <gary_poster> stub, 65 I think.  checking
[13:24] <stub> Not there. Last patch applied was -61 on 24th.
[13:25] <gary_poster> stub, ok, I'll try to hold off on the paranoia some more than.  Thank you!
[13:25] <stub> r10480 of db-stable
[13:44] <jtv> allenap: no questions so far... is that good or bad?  :)
[13:44] <allenap> gary_poster: On launchpad/+subs I see the ~launchpad-bugs subscription, and on launchpad-project/+subs I see my "Triage" subscription, so all seems well. Thanks for following up on that.
[13:45] <allenap> jtv: I have some comments, but no breakage.
[13:45] <jtv> Sweet.
[13:46] <gary_poster> allenap, yay!  thanks for looking
[13:46] <allenap> jtv: I started out doing a full review because I'm not used to mentoring, but I'm just skimming through now.
[13:48] <jtv> allenap: one design worry is that we haven't got the full initialization procedure together yet for derived distros, so we're not sure yet how to slot this in there.
[13:49] <jtv> The actual code should be distro-agnostic though.
[13:49] <jtv> The main concern for the procedure is that there be no concurrent regular publisher runs.  We'll probably develop different ways of solving that anyway.
[13:51] <wgrant> jtv: The great more-extra overrides mystery is solved.
[13:51] <jtv> ?
[13:51] <wgrant> jtv: The symlinks are indeed dangling for the first run, and the dists/ comparison ignores the headers that are missing because of it.
[13:52] <wgrant> So we can just leave them dangling and everything will be fine.
[13:52] <jtv> Good to know.  (I don't think it'd have affected my code because that's only kicked off after the links have been created).  Might be worth noting somewhere if this wasn't previously known.
[13:52] <henninge> allenap: Hi!
[13:52] <allenap> henninge: Hi!
[13:53] <henninge> allenap: Can you please review my branch? ;)
[13:53] <henninge> allenap: https://code.launchpad.net/~henninge/launchpad/devel-766955-fix-forwardCheckAuthenticated/+merge/59364
[13:53] <allenap> henninge: Sure.
[13:53] <allenap> henninge: I've just started a review for Gary, so I'll do yours right after that.
[13:55] <henninge> allenap: thanks!
[14:05] <jtv1> thanks allenap!
[14:05] <allenap> jtv1: No worries.
[14:38]  * henninge relocates
[14:49] <gary_poster> mrevell_ (_?) hi .  You assigned yourself https://bugs.launchpad.net/launchpad/+bug/770315 .  Thank you! Will you have a chance to look at this today or tomorrow?  You are on holiday Monday, right?
[14:49] <_mup_> Bug #770315: Help for bug muting uses unfamiliar terminology <exploratory-testing> <story-better-bug-notification> <Launchpad itself:Triaged by matthew.revell> < https://launchpad.net/bugs/770315 >
[14:49] <mrevell_> gary_poster, Hi! Not sure why I have an underscore. Yeah, I'll deal with that this afternoon.
[14:49] <gary_poster> awesome, thank you mrevell_
[15:00] <jcsackett> henninge: can i bug you for some info on reviewing translation imports?
[15:01] <henninge> jcsackett: sure ;)
[15:02] <jcsackett> henninge: excellent. i am looking at https://translations.launchpad.net/+imports/5469865, and trying to verify the project is set up appropriately.
[15:03] <jcsackett> the page tells me there is no translatable series, but i see that it is targeting a series. i believe i am confused by what that all means.
[15:05] <henninge> jcsackett: "translatable series" refers to a series for which a template has been imported.
[15:05] <jcsackett> ah, so approving this would create a translatable series, henninge?
[15:05] <henninge> jcsackett: so this tells you that this is the first template import ever for this project.
[15:05] <henninge> jcsackett: yes
[15:05] <jcsackett> henninge: okay, that makes sense.
[15:07] <jcsackett> henninge: there is also a thing in the wiki saying that i should look at the product under translations, and check links for release-series to make sure things are setup.
[15:07] <jcsackett> in this case, looking at translations.launchpad.net/libravatar, i see nothing that looks like what the wiki is talking about.
[15:24] <mrevell> danilos, Hey, do you have a moment to talk about bug 770345?
[15:24] <_mup_> Bug #770345: When muting a bug your name disappears from the subscribers list but doesn't re-appear when unmuting <exploratory-testing> <story-better-bug-notification> <Launchpad itself:Triaged by yellow> < https://launchpad.net/bugs/770345 >
[15:24] <danilos> mrevell, sure thing, though note that gary_poster is writing a comment as well :)
[15:24] <danilos> mrevell, want to do voice?
[15:25] <danilos> mrevell, (though, mumble is broken for me, so skype would be better)
[15:25] <mrevell> danilos, I'll wait and see what Gary's comment says :)
[15:25] <danilos> mrevell, I also think you've raised most of the important comments in 770342 as well, fwiw
[15:26] <mrevell> danilos, Did I? Oh, good. /me tries to work out what.
[15:29] <gary_poster> danilos, mrevell, I made my comment.  I don't like the situation at all, but I've said what I thought. :-) https://bugs.launchpad.net/launchpad/+bug/770345
[15:29] <_mup_> Bug #770345: When muting a bug your name disappears from the subscribers list but doesn't re-appear when unmuting <exploratory-testing> <story-better-bug-notification> <Launchpad itself:Invalid by yellow> < https://launchpad.net/bugs/770345 >
[15:30] <gary_poster> mrevell, we can tackle the internal change, but IMO we need approval from Jono and Francis to do so.
[15:31]  * gary_poster needs to run to dr appt.  biab
[15:31] <jcsackett> sinzui: you triaged a bug right out from under me. :-P
[15:31] <snowdream> i want to uninstall launchpad ,what can i do?
[15:32] <danilos> mrevell, if you still want to chat about it, just ping me :)
[15:33] <snowdream> anybody can help me unistall launchpad
[15:38] <henninge> allenap: thanks for the review. How strongly do you feel about assertVectorEqual?
[15:41] <allenap> henninge: I'm not going to fight if you really want to land it :) I agree it's probably useful to get the full state of something when a test breaks, rather than just the first failure, but I don't think assertVectorEqual is a good way to go about it.
[15:41] <mrevell> danilos, Okay, ta
[15:44] <henninge> allenap: So, you are ok with agreeing to disagree on that point?
[15:45] <allenap> henninge: Something like that :)
[15:45] <henninge> allenap: thanks ;-)
[15:56] <henninge> Nooo!
[15:56] <jcsackett> sinzui: have a few to mumble?
[15:56] <jtv1> henninge: what happened?
[15:56] <henninge> I lp-landed my branch but I meant to ec2-land it ...
[15:57] <jtv> henninge: if you "ec2 test" it now, you'll probably still be just ahead of buildbot to patch up any failures.
[15:57] <henninge> jtv: yes, I was thinking about that, too.
[15:57] <henninge> I have 3 hours 38 minutes
[15:57] <jtv> run, henning, run!
[15:58] <jtv> You can also do a local run for the most likely suspects, of course.
[15:58] <jcsackett> henninge: did you already get pqm notification of success? i don't see it in the queue, which implies it's already through, but could mean it hasn't hit it quite yet?
[15:58] <henninge> jcsackett: it's through
[15:58] <jcsackett> blast.
[15:58] <henninge> jtv: problem is I won't be here then.
[15:59] <henninge> I don't expect much to happen.
[15:59] <henninge> I'll start the ec2 test run now
[15:59] <jtv> henninge: I'd also start that local run.  May just catch something before you leave.
[15:59] <henninge> jtv: good point
[16:00] <wgrant> Oh good, it'll fail just in time for my start-of-day :P
[16:01] <jtv> wgrant: while you're still here (and I know you're not), is this accusation I just heard true?
[16:01] <wgrant> Hwhich accusation?
[16:01] <jtv> Do some Australians spread that marmite-clone they have (or however you spell it) right next to nutella?
[16:01] <wgrant> I've never heard of that being done seriously, fortunately.
[16:01] <wgrant> Or I would have to abandon the nation.
[16:02] <jtv> wgrant: thank you, that is an immense relief.  I will pass the news on.
[16:05] <jtv> wgrant: I do have an eyewitness here, but that may have been a freak madman, not representative of the wider gene pool.
[16:05] <jtv> It happened in Hobart, for what it's worth.  Lots of inbreeding there?
[16:06] <wgrant> Indeed.
[16:10] <danilos> allenap, hi, do you think you'll have time to look at https://code.launchpad.net/~danilo/launchpad/subscribers-list-js/+merge/59387? it's mostly JS tests :)
[16:11] <jcsackett> danilos: i can grab it. not sure why my attempt to set topic this morning failed.
[16:11] <danilos> jcsackett, excellent, thanks :)
[16:11] <mrevell> allenap, jcsackett: If either of you have time for https://code.launchpad.net/~matthew.revell/launchpad/bug770315-bug-muting-help/+merge/59388 I'd be most grateful :)
[16:12] <jcsackett> mrevell: if allenap doesn't take it before i finish one for danilos, i'll get it.
[16:13] <adeuring1> allenap: got a few minutes for a pre-imp call? (about duplicate bugs)
[16:13] <allenap> mrevell: Sure, I'll take that.
[16:14] <mrevell> thanks
[16:14] <allenap> adeuring1: Sure. Skype?
[16:15] <adeuring1> allenap: ok, let me just power on a machine where skype is installed.
[16:16] <allenap> adeuring1: Or Mumble is okay.
[16:16] <adeuring1> allenap: then let's mumble ;)
[16:16] <henninge> jtv: I now have a local run for most likely suspects going plus a full ec2 run.
[16:17] <jtv> Very well.
[16:18] <adeuring1> allenap: https://bugs.launchpad.net/launchpad/+bug/769293
[16:18] <_mup_> Bug #769293: Timeout trying to set bunch of dupes <Launchpad itself:In Progress by adeuring> < https://launchpad.net/bugs/769293 >
[16:19] <jcsackett> danilos: this is all my own javascript ignorance, but i see that remove_user_link calls for two params, subscriber and is_dupe. in places you call it with only one argument, and i don't understand if/how is_dupe is set to a default. is there js magic i don't get?
[16:23] <sinzui> jcsackett: I can talk. I was distracted by the flood of water and felt compelled to bail
[16:25] <jcsackett> sinzui: http://people.canonical.com/~jc/images/mark-as-spam-0.png
[16:33] <danilos> jcsackett, yeah, the magic is that it gets set to "undefined"
[16:34] <danilos> jcsackett, thus, I explicitely check for "true" when I want it to be used, I assume everything else means "no"
[16:34] <jcsackett> danilos: ah, ok. that makes sense. thanks!
[16:34] <danilos> jcsackett, np
[16:35] <henninge> Do OOPS ids expire?
[16:35] <henninge> I have an old bug report that refers to an OOPS but the utility cannot find it.
[16:37] <danilos> henninge, they do not expire afaik, but they are sometimes manually purged by LOSAs/QA team I think; worth checking with matsubara/Ursinha
[16:37] <Ursinha> hi
[16:37] <wgrant> oops-prune removes old unreferenced OOPSes.
[16:37] <henninge> Hi Ursinha! ;)
[16:38] <Ursinha> henninge, there's a script, oops-prune, that removes old oopses
[16:38] <Ursinha> hi henninge! :)
[16:38] <henninge> How does it know they are unreferenced?
[16:42] <jcsackett> danilos: r=me.
[16:42] <danilos> jcsackett, thanks
[16:50] <Ursinha> henninge, what do you mean? it doesn't :( it deletes old oopses without any checking
[16:51] <henninge> Ursinha: ah, wgrant mentioned "unreferenced". Thanks for clarifying.
[16:51] <henninge> so, no use putting OOPS urls in bug reports, just paste the oops itself.
[16:52] <henninge> I really have a hard time reproducing the bug now
[16:57] <Ursinha> :/
[17:02] <henninge> jtv, jcsackett, wgrant: My local run did not have any troubles. I am quite confident that it will be fine. ec2 still running, of course. I will check back later.
[17:02] <jtv> Splended
[17:03] <jtv> *did
[17:03] <henninge> bye for now
[17:19] <gary_poster> mrevell, hi, I'm back and available for call if you'd like to have one; OTOH, I don't have much to report that you haven't already experienced first hand :-)
[17:19] <gary_poster> s/much/anything/
[17:19] <mrevell> gary_poster, Hi :) Thanks. I think we've worked pretty closely this week, so I'm happy to skip the call.
[17:19] <gary_poster> cool thanks mrevell.  ttyl
[19:19] <jcsackett> sinzui: can i put you on help contact, or are you still bailing water?
[19:19] <sinzui> yes. I continue to forget
[20:25] <sinzui> jcsackett: can you review https://code.launchpad.net/~sinzui/launchpad/question-email-1/+merge/59414
[20:27] <jcsackett> sinzui: yes. it will give me something to do while my lp-dependencies re-install.
[20:28] <sinzui> thanks
[21:14] <lifeless> moin
[21:19] <jcsackett> sinzui: r=me.
[21:57] <benji> lifeless: if I get the impression that changes to database/schema/security.cfg don't have to go onto the DB branch; is that correct?
[21:57] <benji> (I'm giving the processmail user access to the table where the "I don't want to get messages about things I do" flag is stored.)
[21:57] <benji> s/if//
[22:14] <lifeless> benji: thats correct
[22:14] <lifeless> security.py --no-revoke is run before nodowntime deploys
[22:15] <benji> cool, thanks
[23:30] <wallyworld> lifeless: can you please +1 on https://code.launchpad.net/~wallyworld/launchpad/poppy-sftp-gpgconf/+merge/59154
[23:30] <lifeless> wallyworld: when I get a browser back, sure
[23:31] <lifeless> you'll need to remind me after I disconnect and reconnect
[23:31] <wallyworld> lifeless: np. your system broken?
[23:31] <lifeless> nz ubuntu mirror was horked
[23:31] <lifeless> currently in terminal only while my last -> natty upgrade completes
[23:31] <wallyworld> good luck :-)
[23:58] <lifeless> wallyworld: url me up
[23:59] <wallyworld> lifeless: turns out curtis did the +1 just after i asked you.  thanks anyway