[00:00] actually, mawson has a sufficient python-apt version [00:00] it'll have trouble with the multiarch-translations branch until we get it upgraded, but it'll be good enough for dpkg-xz-support [00:01] so it can be QAed on dogfood [00:01] cjwatson: If this branch lands, it should be fine to test on mawson on Monday -- prod myself or wgrant before you start so we can update its code. [00:02] in that case, can I get https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations/+merge/67640 landed too? we can test it on mawson then too [00:02] (I don't know what the procedure for QAing db-devel branches is) [00:03] I think you might need to change the DB patch number. lifeless: ^ [00:03] cjwatson: that needs to be split [00:03] its got both code and schema [00:03] and we only deploy schema from db-devel [00:04] hm? I already split out a schema branch for that [00:04] https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess [00:04] https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations/+merge/67640 ? i see changes to lib/lp/archivepublisher/model/ftparchive.py, to === modified file 'lib/lp/archivepublisher/tests/apt-data/apt.conf' [00:04] https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations-schema which has landed [00:04] etc [00:05] multiarch-translations was supposed to be just the code bit [00:05] https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations/+merge/67640 has a db patch in it - = added file 'database/schema/patch-2208-79-0.sql' [00:05] so this need to go to devel [00:05] and it can't land until we've deployed the schema change [00:06] thats blocked on the losas finishing pgbouncer migration [00:06] I'm confused about why LP is showing that, if you look at https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations-schema/+merge/67992 then it has the same schema patch [00:06] and it's merged [00:06] which is blocked on them sprinting [00:06] its certainly not deployed [00:06] I was told a couple of weeks ago that multiarch-translations needed to go to db-devel :-( [00:06] the schema did [00:06] I would appreciate a consistent story here [00:06] the other part, *if* you land on db-devel, will sit there until you cherrypick it across to devel post deploy of the schema change. [00:07] I can't cherrypick anything to devel personally, no access [00:07] 79-0 is already on db-devel [00:07] well, you would do it by preparing another branch which we can land via ec2 at the right time [00:08] cjwatson: if you want to flush your queue, you can land this on db-devel yes. But we can't deploy it from there, [00:08] cjwatson: I'm sorry that this feels inconsistent to you [00:08] cjwatson: particularly if its my fault :) [00:08] 2011-07-14.log:12:54 cjwatson: for your branch, you'll need to land both components on db-devel (because we're not live on the incremental deploy steps yet) [00:09] cjwatson: ah yes, so thats up to me to be more clear [00:09] so right now I am completely confused as to what I need to do. I don't care about flushing my queue, I care about getting things deployed [00:09] ok [00:10] I can see the schema is already on db-devel [00:10] so right now, this is blocked on losa work: we have no way to deploy schema changes until the pgbouncer migration is completed. [00:10] thats stubs and the losas top priority ticket [00:10] as soon as thats done we'll start doing fastdowntimes, one per day, with one db patch per day [00:10] that's fine. what I'd like to know is (a) how I know when to proceed (b) what I should do next [00:11] oh and (c) what if anythng I should do to the multiarch-translations branch [00:11] so - nothing. [00:11] merge it from db-devel maybe? [00:11] the bug for the schema change should be sitting in fix committed now [00:12] when we have the patch deployed that will toggle to fix released [00:12] and we can continue with the rest of the work [00:15] bug for the schema change> is that https://bugs.launchpad.net/launchpad/+bug/809123 ? [00:15] <_mup_> Bug #809123: we cannot deploy DB schema changes live

< https://launchpad.net/bugs/809123 > [00:15] that too; no I meant the one linked to your schema patch [00:16] (there is one, isn't there? it may be the main one for your translations support) [00:16] there isn't onoe [00:16] ah [00:16] ok [00:16] hm [00:16] so i suggest picking this up when 809123 is fix released [00:16] I'm getting an oops when searching for someone (trying to add a new ubuntu member) [00:16] at that point we'll be a few days out from your thing being live [00:16] OOPS-2057DX [00:16] ok, subscribing to that [00:18] I basically just want to make sure that any delays in the process are not down to me - it's felt very much like there've been serial multiple-day delays so far [00:19] and I appreciate the assistance in deployment but the feature in general is important enough that I need to report on t [00:19] cjwatson: welcome to LP dev :) [00:19] *it [00:19] heh [00:20] cjwatson: this is one of the things that we're working on reducing - dev friction is insanely high atm [00:20] right, understood [00:20] and FWIW non-db stuff has clearly been getting better from my POV [00:20] thanks! [00:32] I've merged db-devel into multiarch-translations so that it now clearly only contains code. Do I need to resubmit that against devel (presumably after 809123 is fix released)? Can I do that without losing approvals or will it need re-rubber-stamped? [00:35] yes, an dyes, and probably needs a rubber stamp at that point. Use the 'resubmit' button. [00:35] (at the right time) [00:36] ok [02:19] Hi wallyworld__ [02:19] jtv: yellow [02:20] ? [02:20] jtv: hello [02:20] Ah. [02:20] one review just popped up recently [02:20] doing it soon [02:20] OK [02:20] just finishing off a ^@%%@!& yui test [02:21] * jtv shudders in sympathy [03:35] StevenK, are you hammering dogfood? [03:38] Not any more [03:40] Ah. I just updated the code/schema as well. [03:42] And now it's failed to come up. [03:42] Ah. Not that again. [03:43] Fixing it. === almaisan-away is now known as al-maisan [04:07] wallyworld__: I thought my feelings to yui was isolated. apparently not ;-) [04:08] nigelb: it's not that bad actually. just a bit tedious sometimes [04:08] I know! [04:08] to mock everything needed to allow the tests to run in isolation [04:08] that's one of the things I'm stuck at because I lack time. [04:08] how is your branch? [04:08] yeah, i can understand that [04:08] needs tests [04:09] well you are not alone there [04:09] hehe [04:09] and work's been busy, so I get very little time [04:09] what do yiu do for work? [04:10] er, what? :) [04:10] what's your day job? [04:10] ah, I work as a systems engineer at a local startup :) [04:11] sounds cool. i worked for a startup once, about 11 years ago [04:11] but they went bust [04:11] is everything working apart from the tests? [04:11] heh [04:11] yeah, the code's working for anon as well as non-anon user [04:11] and I tested with private bug too [04:12] so I want to catch alll that i my tests [04:12] I put some ground work in there [04:12] sounds good. [04:14] the javascript bits doesn't have a test right now [04:14] booyah [04:14] I have oopses from gpgverify. [04:14] So, I'll probably write a test for the entire code. Also, because I want to learn how to do it [04:19] nigelb: well, yes it will be educational to do it for sure [04:20] s/educational/brain-damaging/ [04:21] lifeless: congrats! [04:21] wallyworld__: yeah, that was my thinking :) [04:21] StevenK: bwahaha [04:25] lifeless: Paste? [04:29] web.py [04:30] doing $anything on thursday is daft. [04:30] rule 1. [04:30] I thought you'd discounted it. [04:30] Hah. [04:30] Right. [04:30] http://bazaar.launchpad.net/~lifeless/+junk/gpgverify/revision/11?start_revid=11 === jtv is now known as jtv-eat [04:32] text/html... ew. [04:32] meh [04:32] that was cargo cloned; I should change. [04:33] It must not be used frivolously. [04:33] Like Twisted Web. [04:33] (it defaults to text/html... what could possibly go wrong) [04:33] or $all $web $frameworks [04:33] so does flask [04:33] and paste IIRC [04:33] Kill it. [04:33] for their errors [04:33] so does django [04:33] Kill them all. [04:33] +1 wgrant [04:34] Yes, let's just default to the most dangerous content type in the world. [04:34] Nothing bad could come of that. [04:37] fixed in 12 [04:40] Thanks. [04:40] Although 'OOPS-ID' is not a standard HTTP header, AFAIK :P [04:41] picky :P [04:46] lifeless: We can't have some generic WSGI container launcher thing that does OOPS stuff, rather than having all this stuff in the core code of every service? [04:46] Like our scripts, it seems silly to have all these boilerplate wrapper scripts rather than a parameterised launcher. [04:49] I guess twistd is already a similar sort of thing. [04:49] But I think we should do it for more than just daemons :) [04:59] wgrant: well, if we have two * web.py services, we can have python-oops-webpy [04:59] wgrant: it should be! [05:00] wgrant: the problem is, as I said yesterday, web.py isn't actually wsgi === al-maisan is now known as almaisan-away [05:00] its kindof wsgo [05:01] same goes for flask.weurkzeug [05:01] s/\.//// [05:01] :( [05:01] they both want to stop exceptions bubbling out [05:01] so they error handle themselves rather than as layers [05:01] Yay [05:02] by the time you're sniffing start_response for 500's and trying to reconstruct a long-gong sys.exc_info you've lost. [05:02] I think hooking in in the preferred for for any given framework is best. [05:02] thats the point of having a simple, flexible core, after all. [05:02] its just a shame that wsgi is so micro that few things use it. [05:03] It would be nice if there was a standard. [05:03] e.g. werkzeug uses request and response objects, which wsgi has no knowledge off (and response puns as a wsgi app... which is actually quite good) [05:03] but its request objects are thread local meta things [05:05] anyhow [05:05] I'm going to setup a project for gpgverify [05:05] shove the current code in there [05:05] teach it to handle detached sigs and use a regular form object at the same time [05:05] and then next week, deploy the biatch. [05:06] jamesh is playing with python-oops-wsgi, which django manages to have a sane way to integrate in [05:06] Excellent. [05:06] which is - huge - brownie points for django IMO [05:07] (are you keeping a reasonably small backlog of in-progress work now, given your impending incapacitation?) [05:07] we have two very modest features identified there to make it have parity with the used features of wsgi-oops [05:07] wgrant: as much as I can yeah [05:07] Great. [05:07] I wanted to unblock SOA before my life changes forever [05:07] Yes. [05:08] the one key thing for oops remaining is to teach oops-tools to use a repo interface rather than parsing itself [05:08] then we could switch it over to a different backend [05:08] That interface gives back a dict? [05:08] yes [05:08] The current repo implementation is just a directory containing date dirs? [05:09] So oops-tools would need lots? [05:09] we'd want to shuffle a bunch of stuff like getOopReport(id) from lp into python-oops-datedir-repo [05:10] we could model oops-tools needs as either a collection of repos [05:10] or as a repo with knowledge of many root dirs. [05:10] Right. [05:10] the main thing is to lift the conceptual stuff out of rfc822 parsing and up to useful types [05:10] with that done, we can switch to bson and iterate on things like messages and extra keys easily enough [05:11] which is a totally separate project. [05:11] relatedly, moving to cassandra might be unblocked if we take a map-reduce search approach rather than a pre-indexed one (for finding oopses by non-id) [05:12] Why can't we pre-index? [05:12] we can, with e.g. solandra [05:12] but if we want anything more sophisticated map-reduce is probably a good idea anyway [05:12] Yeah. [05:12] Killall solr [05:12] so starting with map-reduce would deliver the necessary conditions [05:13] whereas starting with solandra doesn't really. [05:13] þ [05:16] anyhow [05:16] thats for tomorrow^Wmonday [06:40] lifeless, hi, could we have a short supplementary chat? [06:41] g31 [06:41] argh [06:42] :) === wallyworld__ changed the topic of #launchpad-dev to: https:dev.launchpad.net/ | On call reviewer: - | Critical bugs: 238 - 0:[#######=]:256 === jtv-eat is now known as jtv [08:07] Anybody merging stable into db-devel currently? [08:14] No, that's not trivial for me. [08:14] ^ Looks like something jelmer_ and bigjools could do. [08:17] seriously? [08:17] rvba: I will request a deploy. If your QA is quick it can still be included. ;-) [08:18] bigjools: I looked at bzr annotate and found your name and jelmer's for safe_open [08:18] henninge: if you're talking about 820452 then I'm afraid the QA won't be quick. :( [08:18] rvba: ok, np [08:19] one more reason to request the deploy asap ;) [08:19] Right :) [08:22] henninge, I'll have a look [08:23] bigjools, jelmer_ : I have a branch ready, so if you want to tell me how to fix it, I can do the mechanics. [08:23] henninge: have you fixed the conflicts? [08:23] no ;) [08:23] just done the merge and looked at them [08:24] it's just one in each file, so it might be easy [08:24] ok [08:29] henninge: I'm a little concerned about deploying now, TBH. [08:29] StevenK: why is that? [08:29] StevenK: because it's Friday? [08:29] henninge: Because most of IS are going to be on a plane over the weekend [08:30] oic [08:30] It's Friday and everyone will be in the air for the weekend. [08:30] And we don't have APAC LOSAs on Monday. [08:30] The first LOSA will appear in 72 hours. [08:30] do not deploy today, please [08:30] The earliest we can deal with problems is Monday UK [08:30] good reasons ;-) [08:30] we never deply on Fridays [08:30] I thought mornings are ok [08:31] but the "in the air" issue is a neck breaker. [08:31] I will re-visit this on Monday [08:31] mornings are not ok [08:31] some problems will only occurr overnight [08:31] so I learn ;-) [08:32] henninge: Friday morning *in Australia* can be okay, since then we have LOSA coverage for another long while [08:32] (we will occasionally deploy up to early afternoon my time, but I normally try to stick to mornings) [08:34] henninge: for the test_notification conflict, take the second, larger chunk [08:34] bigjools: I will [08:34] I dunno about the other [08:36] jelmer_: any insight on the merge? [08:36] for safe_open.py [08:37] henninge: I just emailed the list that I would sort out the stable -> db-devel conflicts, but bigjools says you're on it, and so I shall leave you to it :) Thank you. [08:38] allenap: you're welcome [08:47] henninge: what's the conflict like? [08:47] jelmer_: let me paste it [08:48] jelmer_: http://paste.ubuntu.com/669867/ [08:51] henninge: you'd want the second chunk in that case [08:51] (bzr resolve --take-other) [08:58] is there a wiki page that describes what branch gets deployed where, when, how often, etc? [09:01] jelmer_: thanks [09:06] poolie: sure [10:22] argh, why does launchpad-dependencies hate me [10:23] cjwatson: It isn't just you, sadly. [10:23] turns out that the upload target isn't a reliable way to test which version it's being built for either [10:24] cjwatson: I think I've just figured why your branch failed in ec2, too. [10:24] so it's broken in lucid right now [10:24] I suspect it might be related? [10:24] I mean, I noticed while trying to upgrade my LP dev VM, but ... [10:24] cjwatson: The ec2 images are not updated for newer dependencies, they need to be done manually. [10:25] I could have sworn I saw an apt-get dist-upgrade in the test setup [10:25] ./lib/devscripts/ec2test/instance.py:134:aptitude -y full-upgrade [10:25] launchpad-dependencies (0.97~lucid1) natty; urgency=low [10:25] Hmm [10:25] anyway, that's why it's going wrong [10:25] bloody recipes [10:26] Hah [10:27] while the IS builds are more like "launchpad-dependencies (0.97~0.IS.10.04) lucid-cat; urgency=low" [10:54] Could somebody review/merge https://code.launchpad.net/~cjwatson/meta-lp-deps/fix-target-detection-harder/+merge/72166 ? Reasonably urgent since launchpad-dependencies is currently broken in the LP PPA for lucid [10:54] StevenK: maybe you could? [11:02] cjwatson: You mean distroseries, not distribution [11:03] But perhaps we should fix that [11:03] Either way, r=me [11:08] StevenK: well - it's called Distribution in dpkg-parsechangelog output [11:08] so I was mirroring that [11:08] I can rename if you feel it necessary [11:09] StevenK: can you land it for me? === henninge is now known as henninge-lunch [11:29] gary_poster: hi! Say, do you know how I can enumerate all of Launchpad's registered utilities? getGlobalSiteManager().registeredUtilities() gives me nothing. [11:30] hi jtv. Thanks for looking at that. Lemme look, one sec. [11:32] ... maybe somebody else can land https://code.launchpad.net/~cjwatson/meta-lp-deps/fix-target-detection-harder/+merge/72166 for me? I've made the distribution -> distroseries substitution as suggested by StevenK [11:33] jtv, I'm surprised that registeredUtilities is giving you nothing. It looks like it does all the right things. Could it be that you called it before zcml was processed? [11:34] gary_poster: unlikely—I'm calling it from a LaunchpadScript and one of the reasons was that zcml would be processed for me. :) [11:34] jtv, could you verify by trying to look up a utility? [11:34] You mean using zope.component.getUtility? [11:35] Or using getGlobalSiteManager().getUtility or something? [11:35] jtv, both, either. [11:37] gary_poster: Hmm... componentlookuperror [11:37] jtv, that's what I would expect. registeredUtilities really does look in some integral data structures. :-) [11:38] Arrh… I think I needed to script.run() instead of script.main() [11:38] Now it takes the requisite 20 minutes to start up. [11:38] :-/ [11:38] cjwatson, that needs ec2 land I assume? [11:38] gary_poster: it fails later now, so that gets us past the first hurdle. Thanks. [11:39] cool jtv, np [11:39] gary_poster: no, AFAICS it's just direct-commit [11:39] cjwatson, you mean, you can verify that all tests pass, and if buildbot fails you will be shocked, awed, and at least mildly embarrassed? :-) [11:39] lp:meta-lp-deps is owned by ~launchpad-committers and the commits are all just direct [11:40] of duh [11:40] meta-lp-deps has no tests ... [11:40] s/of/oh/ [11:40] * gary_poster was not looking closely enough [11:40] * gary_poster goes to look at mp [11:40] I wasn't suggesting direct commit to launchpad :-) [11:40] * cjwatson is nowhere near that brave [11:41] heh :-) [11:42] cjwatson, ok, I'm giving it a whirl [11:43] great, thanks [11:46] cjwatson, please approve/adjust commit message: "[r=StevenK] fix target detection so that it works for both recipe builds and the CAT repository" [11:46] gary_poster: next of my hurdles. The docs I saw "on the internet somewhere" said UtilityRegistration had members "provides" and "provided." But no. [11:47] Maybe it's just a typo. [11:48] jtv, according to code, it has "self.registry, self.provided, self.name, self.component, self.info, self.factory" [11:48] gary_poster: ack, that's fine [11:48] cool cjwatson [11:48] gary_poster: yup, the provides was a typo. I'm getting further now. [11:49] Funny. Some of them have empty names. [11:50] cjwatson, done [11:50] jtv, sure, those are utilities you just look up with an interface [11:50] ILaunchBag, for instance [11:50] gary_poster: thanks! [11:50] Well lots of them give an interface name as the utility registration's name. [11:50] welcome [11:52] jtv, yes, that's something you will probably want to filter out. IIRC, something or other registers all interfaces that it encounters as a utility. So that it can do something else. Later. [11:52] s/all interfaces/each interface/ [11:53] gary_poster: it looks as if the ones _with_ names are the ones I'm supposed to skip. [11:54] jtv, that's what I would expect to be the common case, yes. I'd instead say that if the utility provides IInterface, skip it. That might be equivalent, but it is more careful. [11:55] Oh, OK [12:01] gary_poster: checked 347 interfaces, 238 failed. :/ [12:01] jtv, ow. :-( [12:01] Probably a bug in my code. [12:01] * gary_poster hopes so, practically speaking :-) [12:02] jtv, are you using the zope.interface-provided interface checker, or rolling your own [12:02] ? [12:03] gary_poster: I was lazy and grabbed our own test matchers' Provides. [12:05] jtv, ah ok. I think I looked at that once but I forgot how that works. I meant zope.interface.verify.verifyObject FWIW [12:06] Well, I'll just give it a whirl. [12:07] cjwatson, we've got a problem. Don't know if it is related... https://launchpadlibrarian.net/77594282/buildlog.txt.gz [12:08] I just asked #is about that [12:08] it's not related to my change [12:08] ok thanks cjwatson [12:08] I suspect badness due to puppet deployment but that's just a guess ... [12:09] heh, puppet is getting a lot of bad press lately [12:09] I may be blaming it unfairly, it's just that I think I heard of a previous instance of this problem and I only started hearing about it this wewek [12:09] *week [12:10] gary_poster: getting better — 109 failures (out of 347) [12:11] I just wonder why so many raise DoesNotImplement. [12:11] jtv, I suggest you change the checker to lambda *args: True [12:12] What checker? [12:12] jtv, sorry, trying to make a joke. verify your interface with an "everything passes". Hee. Hee. [12:13] Ah. You are… American, right? Might I suggest you check with a European first? It may prevent misunderstandings. :-P [12:13] jtv :-P [12:13] But the lambda idea is good too. :) [12:15] gary_poster: I wonder if I need to do this differently for classProvides than for implements. [12:15] jtv, ah, quite possibly. [12:16] jtv, so you mean that we are registering some classes as utilities, yes? [12:16] And I'm pretty sure the component isn't supposed to be "security proxied __builtin__.type instance" [12:16] Yes, we use both in LP. [12:16] jtv, as a separate issue, you may need to rip off security procxies, if you have not already. [12:17] With disturbing pleasure. [12:17] lol === adeuring changed the topic of #launchpad-dev to: On call reviewer: adeuring | Critical bugs: 238 - 0:[#######=]:256 [12:18] jtv, FWIW, I suspect you are right that neither verifyObject nor verifyClass will do what you want for class utilities. You may need to make your own verification for that. === adeuring changed the topic of #launchpad-dev to: https:dev.launchpad.net/ | On call reviewer: adeuring | Critical bugs: 238 - 0:[#######=]:256 [12:19] Seriously? === bac changed the topic of #launchpad-dev to: https:dev.launchpad.net/ | On call reviewer: adeuring,bac | Critical bugs: 238 - 0:[#######=]:256 [12:19] But I've verified them in the past as verifyObject(II, getUtility(II)) === henninge-lunch is now known as henninge [12:22] jtv, ah, then...I thought you implied it was not working? ("I wonder if I need to do this differently for classProvides than for implements.") If it is working, then, uh, I suggest you keep using it. I was just not confident that verifyObject would do what you need without digging into it. [12:23] why would you remove security proxies? [12:24] gary_poster: I'm not sure if it's working or not. I'm getting a bunch of DoesNotImplement exceptions (besides some other exceptions that I did expect) [12:30] jml, primarily because security proxies will only let someone with the proper authority look at the value. I suppose another approach would be to log in as a Launchpad admin (if I remember correctly that they have all permissions in all contexts). Secondarily because the verification machinery might not expect them generally, and it's a good first pass to ignore them. [12:32] jtv, ok. In your shoes, I'd simply investigate some seemingly representative reports and see if the complaints seem to have merit. [12:32] gary_poster: oh, of course. I was thinking only of the security proxies other duty as JIT interface validators (e.g. raising ForbiddenAttribute because you spelled 'displayname' incorrectly) [12:33] gary_poster: I guess I could try to verify the result of getUtility instead of the component. [12:33] maybe some of those utilities don't have correct implements() lines. [12:33] Since 93 of the 124 failures I have now are DoesNotImplement, I think I'm verifying the wrong object. [12:34] jml: wouldn't that be noticed immediately? [12:40] gary_poster, jml: checked out a first case of DoesNotImplement… the implements() is in a base class. [12:40] I suppose that would also apply for all these vocabularies that are giving me the same error. [12:42] If I check getUtility(interface) instead of utility_registration.component, I only get 11 instances of DoesNotImplement. [12:42] huh [12:43] I have not worked with utility registrations enough to know how unexpected that might be [12:43] I'd say stick with whatever spelling seems to reflect reality and move on, myself. That might be stating the obvious. [12:53] is is just me or launchpad has performance issues today? [12:53] scripts are timing out [13:05] Ursinha, I haven't experienced any problems myself, but graphs seem to suggest that we had increased db load and an increased number of errors starting about six hours ago. I have no idea what that might be: we have not had a rollout since the 16th. [13:06] * gary_poster tries to find page performance report, and tries to remember other tools for this. [13:06] gary_poster: I'm not able to generate ubuntu reports for a while; in general it takes about 6 minutes and now it's timing out [13:07] cjwatson: Sorry about that, I was picking up my wife and having dinner. Did you find someone? [13:07] StevenK, hey, I did it for him [13:07] gary_poster: Excellent, thanks. [13:08] StevenK, do you happen to have an idea of something that might have changed six hours ago to make our db load and errors increase? It is not an increased number of requests, according to the graphs. [13:09] And the recipe fails due to chroot problem? Awesomeness [13:09]