[00:06] sinzui: huwshimi: wgrant: standup? [00:06] I think my mic is dead. I will restart [00:12] sinzui: wallyworld: was just on the phone, back now. [00:17] good morning [00:22] poolie: Morning [00:27] wgrant: want a review? https://code.launchpad.net/~wallyworld/launchpad/poppy-sftp-gpgconf/+merge/59154 [00:28] Not of that, but OK. [00:28] * wgrant looks. [00:29] wgrant: you don't have to if you don't want, just asking :-) [00:30] No, no, I'll do it, it's just a bad problem with no good solution. [00:30] * wallyworld nods [00:39] lifeless: Could you mentor https://code.launchpad.net/~wallyworld/launchpad/poppy-sftp-gpgconf/+merge/59154? [01:22] 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] :( OK' [01:24] wallyworld: while you're looking at it [01:25] the inner function isn't needed, just make it a normal instance function and call self.touch.. [01:25] secondlyt [01:25] you appear to do this unconditionally whether its in a twisted environ or not [01:25] that seems likely to fail hilariously, or perhaps I misunderstand the context [01:25] Isn't that OK? [01:25] lastly, should touch the dir as well, just to be fireproof [01:27] 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] wallyworld: in reverse order [01:27] wallyworld: we use gpghandler in the zope environment too, with no reactor running, and we create them transiently [01:28] lifeless: ok. no twisted. will fix [01:28] wallyworld: you are basically creating a [slow] memory leak of incomplete looping calls per instance with the current code [01:28] wallyworld: in fact, thinking more about it [01:28] you need to cancel the looping call [01:28] at some point as well [01:28] on the function [01:29] uhm, style. I prefer not to curry things that don't need currying [01:29] lifeless: the looping call is cancelled in the atexit handler or when the job is rescheduled. is that not enough? [01:29] it makes them more testable [01:30] oh, and you ar makeing _touch_home_call a mixed attribute [01:30] set it in __init__ [01:30] -or- [01:30] assign to it via self.__class__._touch_home_call [01:30] 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] so in terms of cancellation, the following will leak: [01:33] ahehm [01:34] how does the buildmaster use this [01:34] as a secured utility [01:34] buildmaster doesn't. [01:34] or via instances ? [01:34] poppy does. [01:34] blah yes that thing [01:34] sig = getUtility(IGPGHandler).getVerifiedSignatureResilient( [01:34] securedutility [01:34] ok [01:35] so, we shouldn't be leaking [01:35] That's what I thought. There's only ever one instance. [01:35] but the touchiness won't work on zope [01:35] wgrant: one per thread, no ? [01:36] Hmm, I guess it probably does use a thread-local site manager, true. [01:37] i didn't know that. i though sm was global to a zope instance [01:37] but then again my zope foo is not that high [01:37] wallyworld: it is global [01:37] but its allowed to follow any old policy for what it hands out [01:38] I'm pretty sure the default which we use is thread local utilities [01:38] ok [01:38] so that folk don't have to deal with concurrent mutation of instance attributes [01:38] anyhow [01:38] we're solving a bug in the twisted environment [01:38] we should only run the loop in the twisted environment [01:38] but always in the twisted env [01:39] I've no idea how to make that true. [01:39] lifeless: i could just do it another way without twisted and remove the dependency [01:40] but you'd think there would be an api to see if a reactor were running [01:40] in the current environment [01:41] 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] 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] 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] yes [01:47] INotBrokenGPGHandler? [01:47] and perhaps any tests that are testing lib/lp/poppy/twistedftp.py [01:48] 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] hmm [01:49] 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] wgrant: perhaps best to just change the known broken use case initially? [01:49] lifeless: They're already being sued in the US. [01:49] i don't think i'll use your suggested iface name :-) [01:49] Not sure if it's class action, though. [01:49] * wallyworld hates sony even more than apple if that's possible [01:50] wallyworld: Hmm. I think they're pretty similar. [01:50] Apple has some good aspects, but they are also far more effective at their evil than Sony is. [01:50] But Sony has no good aspects... [01:50] So hm.. [01:51] 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] They turned KHTML into an awesome WebKit. [01:51] That's at least one good thing. [01:52] and the rapid fanbois whole bend over for steve jobs like he is some sort of deity [01:52] i guess so [01:53] wallyworld: its his massive..innovations they like [01:53] lifeless: you say innovations, i say merely refining concepts developed by others [01:57] wgrant: is it a bug or feature that the upload works after gpg verification fails [02:00] 760 timeouts [02:00] reality sets in [02:01] lifeless: Both. [02:01] lifeless: It's intentional that they're let through for now, in case it breaks. [02:01] lifeless: I wonder how many of those timeouts are from edge. [02:03] This OOPS report is indeed much more plausible. [02:10] 17 https://bugs.launchpad.net/ubuntu/+bugtarget-portlet-bugfilters-stats (Distribution:+bugtarget-portlet-bugfilters-stats) [02:10] OOPS-1943AQ100, OOPS-1943AZ499, OOPS-1943BA451, OOPS-1943CD170, OOPS-1943CK442 [02:10] 6 https://bugs.edge.launchpad.net/ubuntu/+bugtarget-portlet-bugfilters-stats (Distribution:+bugtarget-portlet-bugfilters-stats) [02:10] OOPS-1943EDGEA955, OOPS-1943EDGEB1120, OOPS-1943EDGEB1422, OOPS-1943EDGEE1002, OOPS-1943EDGEE897 [02:10] 3 https://launchpad.net/ubuntu/+bugtarget-portlet-bugfilters-stats (Distribution:+bugtarget-portlet-bugfilters-stats) [02:10] OOPS-1943AO372, OOPS-1943DT447, OOPS-1943L444 [02:10] so more from edge as a %, less as an absolute count [02:12] 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] GET: 53 Robots: 0 Local: 1 [02:12] 23 https://api.edge.launchpad.net/1.0/ubuntu (Distribution:EntryResource:searchTasks) [02:16] find the user. Point them at prod. [02:19] ok [02:19] I'm going to nose down on these triggers [02:19] unless anyone needs more from me? [02:44] sinzui: Hi. [04:23] lifeless: Hmm, 99% under 1.45. [04:23] lifeless: That's not bad. [04:38] cool [05:07] lifeless: thanks for that review -- you're a lifesaver. Our OCR system has basically collapsed. [05:08] :( [05:08] I have a killer headache [05:08] a freaking sore arm [05:08] and triggers to write [05:08] I think today will be a writeoff [05:13] lifeless: a sore arm is a warning. Heed it! [05:14] jtv: I was injected with 1ml of stuff I'm highly allergic too [05:14] jtv: not rsi [05:14] s/too/to/ [05:15] Okay... a warning not to let people do that then I guess. Wow that sucks. [05:15] lifeless: That sounds like a punishment. What did you say to Lynne? :-P [05:16] http://en.wikipedia.org/wiki/Allergen_immunotherapy [05:16] Ugh [05:17] Just reading that article makes my skin crawl [05:29] Hi stub. [05:30] UploadFailed: Server said: 200 [05:30] Yo [05:31] Haven't seen that failure before in buildbot, but subsequent builds worked so looks spurious [05:31] stub: Yeah, known spurious failure. [05:31] stub: Did SSO fork the emailaddress table? [05:32] So occasionally the librarian succeeds, which is considered a failure? :-) [05:32] Yup. [05:32] wgrant: Yes. They have their own email address list. [05:32] stub: It is full of cruft :( [05:32] stub: It contains eg. team email addresses. [05:32] Which don't make sense in SSO. [05:32] And cause crashes (since it assumes all emailaddresses have an account) [05:33] I guess they need to clean it up or ask me too. [05:34] Their table even still has a person column. [05:34] wgrant: Have you opened a bug? [05:34] No. [05:34] Should I? [05:34] Yes. canonical-identity-provider I think. [05:35] That's the right project, but I wasn't sure if it was worth a bug. [05:35] Crashers are worth bugs :) [05:35] I guess it means their schema is buggy, true. [05:37] Their schema is a pile of cruft because they inherited it from us and only needed 10% of the fields. [05:37] They also have a number of Django defined tables which is the stuff they created. [05:38] Yeah. [05:39] 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] stub: hi [05:45] lifeless: Morning [05:47] stub: I only got a tiny bit done so far - monthly allergy shot messed me up :( [05:48] 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] stub: I think it is [05:48] stub: have your morning coffee, check for dba bugs, reviews etc [05:48] I have a bit of structure I want to stab at this [05:48] cool. [05:49] I gotta book me a flight to Dublin. [05:49] Not sure exactly why I'm needed at a UI focused sprint, but Ireland should be cool :) [05:54] cause abstractions leak :) [05:54] Who you calling an abstraction??? [05:55] I don't know, do you leak ?:P [06:14] stub: http://www.slideshare.net/selenamarie/managing-terabytes-when-postgresql-gets-big may interest you [06:15] stub: 400K tables [06:37] lifeless: selena may want to consider not using WordPress MU then. :) [06:38] Anyone want to review https://code.launchpad.net/~wgrant/launchpad/bug-761439/+merge/59317? [06:40] 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] wgrant: loading [06:40] jtv: I was about to approve it [06:41] StevenK: then don't let me stop you [06:41] StevenK: You managed to not vomit? [06:42] Only just. [06:44] Geez this current flash player sucks [06:47] 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] (*) 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] Does Latin even have terms for landing? Control towers? Re-entry shields? [06:50] jtv: cronscripts/create-distroseries-indexes.py is pointless, run_jobs.py can do it [06:50] StevenK: does run_jobs.py run on the right host? [06:51] 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] jtv: Er, what? How is that even related? [06:51] I don't know. You started it. [06:52] 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] Okay, how do I use the generic run_jobs.py cronscript? [06:52] StevenK: Oh, you mean like add it to a new source group and run run_jobs over that group on cocoplum? [06:53] jtv: You add the interface to schema-lazr.conf and 'run_jobs.py create_distroseries_indexes' [06:54] As much as I hate perpetuating that antipattern, it's what we have. [06:54] Never mind, I'll look for it in the wiki. [06:55] jtv: I could create a diff quicker than this argument :-P [06:55] 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] No documentation on the wiki. :( [06:57] jtv: There is a generic job running cronscript: cronscripts/run_job.py [06:57] Okay, that part I had figured out by now. [06:57] I'm now looking for documentation. [06:57] jtv: It is almost identical to the new cronscript you've added in your branch. [06:58] I'm not sure it is documented. [06:58] It doesn't seem to be. [07:00] jtv: http://pastebin.ubuntu.com/600158/ [07:01] StevenK: so this is part of, but not mentioned in, the job-system documentation? [07:01] Would be worth updating that page. [07:02] jtv: It's certainly part of the job system, but I doubt it is documented. [07:02] Well there's no mention anywhere on the dev wiki. [07:02] Two places in the test suite mention the script. [07:02] One of them would be the IDSJ job runner [07:02] Yes. [07:03] Since I ripped out it's cronscript when I learnt about run_jobs [07:03] And there's 1 mention in the production crontabs. [07:03] What's the point in writing reusable code if there's no way for people to find out about it? [07:04] Then fix the documentation? :-) [07:04] The documentation is just bad enough that I'm afraid to touch it. [07:05] Yes. [07:05] By the way I am grateful to you for pointing this out. [07:37] stub: jtv: cheatsheet - how do you declare a variable to how a set of rows ? [07:37] s/how a/hold a/ [07:38] 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] 'setof record' or 'setof bugsummary' [07:38] oh... you want an array I think [07:38] declare tags setof bugtag; ? [07:38] record[] or bugsummary[] [07:38] a setof is being returned from a helper function [07:39] So returning from a helper, you want RETURNS SETOF bugsummary [07:39] Then in the helper, you want to do 'RETURN NEXT a_bugsummary;' which works like yield in python generators [07:40] yes, I have that [07:40] I think I had this in my stub bugsummary_sources() [07:40] this is in the function that calls that [07:40] http://pastebin.com/cVajbkq3 [07:40] is the helper [07:42] 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] grwat, thanks [07:42] Or we could do this in Python :) [07:42] * stub wonders if we care about the speed hit [07:43] plpythonu I mean [07:54] psql:test.sql:157: ERROR: syntax error at or near "[" [07:54] LINE 6: tags bugtag%ROWTYPE[]; [08:13] stub: pushing now; got time for a weekly catchup call? [08:14] lifeless: sure. [08:14] lifeless: you got the syntax working? [08:14] stub: I did some reading [08:14] what is the syntax? [08:14] looks like an immutable cursor or some such is a better fix [08:14] *fit* [08:15] it really wants just 1 row (select into) or a cursor usage. [08:15] i'm getting a proxy timeout on +filebug, ie 'please try again' with no oops [08:15] stub: however I'm barely a trained monkey here [08:15] Oh no not again. [08:15] poolie: How long does it take? [08:15] And what' [08:15] s the URL? [08:15] stub: I've achieved what I wanted which is a structure that is auditable and parallels the loader. [08:15] it was /bzr/+filebug [08:15] stub: its pushed; skype ? [08:15] it worked on the 3rd attempt [08:16] foo integer[]; works fine. bugsummary%ROWTYPE[] should too... but it doesn't. [08:16] skype - sure [08:16] uh, it took quite a while [08:16] lifeless: Do we have visibility into queue depth yet? [08:16] maybe 20s? [08:16] wgrant: no; losa time [08:16] spm: Hi. [08:16] the successful run says it completed in 0.64s, and it was probably really a couple of seconds [08:16] poolie: 30 seconds would be haproxy [08:16] ... [08:16] spm: What's the queue depth like on the haproxies? [08:17] is there anything that distinguishes different types of failure short of an oops? [08:17] ie haproxy vs apache ? [08:17] i mean, anything visible in the page [08:17] There are slight differences in the HTML. But otherwise not really, AFAIK. [08:17] wgrant: currently 0 down the line, but has had a max of 65. banana. [08:18] Hmm. Not so bad. [08:18] perhaps something subtle would generate better bug reports? i don't know [08:19] The appserver request graphs are a little empty. [08:53] rvba, r=me on your branch from yesterday [08:53] rvba, not sure about str(enum), so please check with someone else (though this seems right) [08:54] 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] a'voir (maybe back later) [08:56] 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] rvba, understood :) [08:58] rvba: I was going to mention that to you. One column, using an enum [09:07] good morning [09:23] Morning [09:32] hi mrevell [09:37] hey jtb [09:37] er, jtv [09:40] :) [10:23] poolie: hi [10:23] poolie: an unthemed 503 is a complete fail in the zope stack (error handler barfing) [10:23] poolie: a themed oops is a regula fail in the zope stack [10:24] poolie: a themed 'could not connect' is haproxy/apache (I forget the exact difference, 504/503 I think respectively [10:24] poolie: and a browser-themed page implies a networking /ssl error [10:35] still a little excessive 1183 OOPS-1943EC114 POFile:+translate [10:45] 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 === allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: allenap | https://code.launchpad.net/launchpad-project/+activereviews [11:12] 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] It's this one: https://code.launchpad.net/~jtv/launchpad/db-bug-766807/+merge/59027 [11:12] jtv: Sure :) [11:12] Great, thanks [11:22] jtv: Just revision 10479 then? [11:23] Ah, no revision 10477 too. [11:23] allenap: well william's review also needs mentoring. [11:23] jtv: Okay. [11:23] 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] can you no longer request another review from someone who already commented? [11:26] or was it always thus? [11:27] also, could i get another review on [11:28] 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] 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] rvba: Sure. [11:28] 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] great, thanks [11:29] lp.Append on the archive does not use the pocket or component, and is not what you want. [11:29] wgrant: here a (very much in the works) mp https://code.launchpad.net/~rvb/launchpad/change-perm-sync/+merge/59341 [11:29] You mean you want it to respect actual upload privileges? [11:29] it's how I understand it yes [11:30] the tickets says 'syncing packages should be lp.append on the archive, not lp.edit on the series' [11:30] Right. We currently use launchpad.Append in parts of the code as a hack to very roughly approximate that. [11:30] Ah. [11:30] So, probably easiest to use lp.Append to start with, if that's all Julian wants for now. [11:30] That doesn't need the pocket or component. [11:31] Which bug is this? [11:31] 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] there is no but for this yet. [11:31] He probably didn't mean launchpad.Append, then :/ [11:31] that's wht I figured [11:32] You may want to look at package branches. [11:32] wgrant: perhaps you could have a look at the partial diff on the MP and tell me what you think [11:33] 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] 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] avril 27 10:46:55 rvba: and the permission change [11:35] avril 27 10:47:09 but that one is hard because of the problem we encountered before [11:35] avril 27 10:47:28 (we need more info than available in the security adapter) [11:35] avril 27 10:49:04 I think we can do it, but it will mean not doing it in the security adapter [11:35] Right, so it sounds like he wants it to go all the way. [11:35] and also (from an email) [11:35] rvba: You'll want to make use of Archive.canUploadSuiteSourcePackage. [11:35] The security adapters only have the context archive and the user. Far more is [11:35] needed to ascertain upload privileges. So no, it isn't. ;) [11:36] It can be worked around by doing the security in the model layer though (not [11:36] the browser layer - so it also works for the API). [11:36] rvba: That takes a person, suite and source package name, and does the rest for you. [11:37] 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] rvba: Also, this probably needs to be flagged. syncSource must not be used to copy into a primary archive yet. [11:38] rvba: You're using the source component instead of the destination component, but apart from that it looks OK. [11:41] wgrant: how can I get the destination component? [11:41] rvba: canUploadSuiteSourcePackage has a reasonable example. [11:42] 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] wgrant: so I guess I should be covered don't you think? [11:42] component = sourcepackage.latest_published_component [11:43] rvba: Ah, you're not also doing this through the API? Sure. [11:43] wgrant: not yet, but I've got another task waiting to expose the sync operation on the api [11:44] rvba: syncSource is already exposed. [11:44] (but restricted to launchpad.Append) [11:44] yes, I got confused: I meant doing the same check for the api call [11:44] That's a long way off. [11:44] and remove the lp.Append protection [11:45] It needs to do overrides and announcements and respect the queue first. [11:45] I see [11:46] 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] 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] wgrant: thanks a lot for you help ... I guess I'll have a good time writing tests for this :). [11:48] s/you/your/ [11:49] 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] wgrant: well spotted ... I'll have to find a way around that ... [11:51] 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] rvba: Yeah :( [11:53] wgrant: I'll find a way ... thanks again for you time ... I might be back tomorrow with more questions ;) [11:53] sigh s/you/your/ [11:53] Heh. [11:58] StevenK: you might want to have a look at the above conversation :) [13:03] allenap: still reviewing? [13:05] 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] gary_poster: Sure I'll look at it after I've finished jtv's review. [13:15] 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] allenap, thanks! [13:17] * stub shrugs [13:18] uh, ok :-) [13:18] * stub has a look at the staging logs [13:18] thank you [13:19] I could do that too [13:20] Might be faster... my net is the suck. [13:21] I think some twats using our data centre have released an operating system or something. [13:22] heh [13:23] 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] gary_poster: What was the patch number? Looks like the update happened today but there were no patches to apply. [13:24] stub, 65 I think. checking [13:24] Not there. Last patch applied was -61 on 24th. [13:25] stub, ok, I'll try to hold off on the paranoia some more than. Thank you! [13:25] r10480 of db-stable [13:44] allenap: no questions so far... is that good or bad? :) [13:44] 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] jtv: I have some comments, but no breakage. [13:45] Sweet. [13:46] allenap, yay! thanks for looking [13:46]