| mars | lifeless, I'm signing off for now, will push the branch once the upgrade finishes | 00:01 |
|---|---|---|
| mars | (which would be now) | 00:02 |
| lifeless | mars: cool | 00:09 |
| wgrant | lifeless: I think basic auth is still enabled, just using the old passwords. | 00:23 |
| wgrant | Which is probably useless and a security risk. | 00:23 |
| lifeless | oh, hahaha. | 00:27 |
| lifeless | I just realised another interaction/issue with lowering hard timeouts | 00:27 |
| * lifeless sighs | 00:27 | |
| wgrant | Oh? | 00:27 |
| thumper | lifeless: ? | 00:27 |
| lifeless | a single rogue page that renders slowly can cause 3 other requests to timeout | 00:27 |
| lifeless | because python + threads is epic fail. | 00:28 |
| lifeless | so the lower the hard timeout, the more boundary-case slow pages will cause *other* pages to have inexplicable timeouts like - https://lp-oops.canonical.com/oops.py/?oopsid=1681EB3871 | 00:29 |
| lifeless | OTOH this may just be a genuinely slow template | 00:30 |
| wgrant | lifeless: Maybe you should use that as an excuse to spawn a push to minimise Python time throughout the application. | 00:33 |
| lifeless | wgrant: we're doing that by lowering the timeout :P | 00:33 |
| wgrant | Is the performance report public again yet? | 00:33 |
| lifeless | any losa around that can't sleep? I need a kcachegrind profile from staging please. | 00:34 |
| lifeless | wgrant: no, it needs log filtering applied to strip private urls. | 00:34 |
| lifeless | wgrant: technically even staff can't look at it atm. | 00:34 |
| wgrant | Ahh. | 00:34 |
| lifeless | well, thats a slight exaggeration, but you know what I mean: there *can* be stuff turn up that normally you'd need DB access to see | 00:35 |
| lifeless | which is undesirable at best | 00:36 |
| ajmitch | OOPS reports don't expose quite as much? | 00:38 |
| lifeless | they are also staff only | 00:38 |
| lifeless | and also need to have this issue addressed | 00:38 |
| lifeless | with the issue addressed we could start publicising them, which I would dearly love to do | 00:38 |
| * thumper is frustrated | 00:40 | |
| thumper | damn code didn't work as I expected | 00:40 |
| lifeless | which one? | 00:40 |
| thumper | QAing the fix I did for processing merge directives | 00:41 |
| lifeless | wgrant: publishedpackage is what you nuked yes? | 00:41 |
| lifeless | wgrant: what revision did it land in? has it landed? | 00:41 |
| thumper | I fixed one bug, but now it isn't actually pulling in the directive (it seems) | 00:41 |
| thumper | how often are the staging logs synced to devpad? | 00:42 |
| lifeless | 7 minutes I think | 00:43 |
| lifeless | perhaps 6 | 00:43 |
| thumper | :( known 2a and MD bug check failed: Cannot add revision(s) to repository: missing text keys: | 00:45 |
| * thumper thinks | 00:45 | |
| thumper | only way to confirm fix is not to use 2a | 00:45 |
| wgrant | lifeless: db-devel r9628 | 00:45 |
| lifeless | damn | 00:46 |
| wgrant | Not on staging yet? | 00:46 |
| lifeless | wgrant: I wish you had done that as two separate patches, db + other | 00:46 |
| lifeless | wgrant: no, 10 timeouts from it in sundays edge report | 00:47 |
| wgrant | :( | 00:47 |
| wgrant | Which views? | 00:48 |
| wgrant | +distrotask? | 00:48 |
| lifeless | +filebug | 00:48 |
| wgrant | Ah. | 00:49 |
| lifeless | tell me about SPPPH | 00:59 |
| lifeless | sorry, SPPH | 00:59 |
| lifeless | also, ugh, pagination *hate* | 01:00 |
| thumper | lifeless: got a stutter there? | 01:00 |
| thumper | can anyone push to staging right now? | 01:01 |
| wgrant | lifeless: What about SPPH? | 01:09 |
| wgrant | SSPPH died a few months ago. | 01:10 |
| lifeless | wgrant: timeouts | 01:12 |
| wgrant | lifeless: Ah, the getBuildRecords timeout? | 01:14 |
| james_w | wgrant: yeah, it's a separate class so we can port a bit at a time. It has a different API as I think this is better than the old one. | 01:15 |
| wgrant | james_w: It looks like it, yes. | 01:15 |
| wgrant | STP is pretty old and was put together over a long time. | 01:16 |
| james_w | yeah, it's understandable. IMO it needs to mature now that it is a central part of Soyuz's testing | 01:16 |
| wgrant | Definitely. | 01:16 |
| wgrant | And bonus points for eliminating sample data while we're at it. | 01:16 |
| james_w | yeah, that's my main aim, but as I started working with it I wanted to clean up the API | 01:17 |
| wgrant | 0*$ bash Menu:<F9> | 01:17 |
| james_w | some changes are gratuitous, but others will help stop being the tests so tightly bound to the implementation, which is one of the problems that we have with sampledata, so I wouldn't want to replicate it at a different level | 01:17 |
| wgrant | Indeed. | 01:18 |
| wgrant | We have model code working around bad sampledata :( | 01:18 |
| wgrant | So it will be good to eliminate it. | 01:18 |
| lifeless | grah | 01:18 |
| lifeless | hmm | 01:26 |
| lifeless | this is nonoptimal | 01:26 |
| lifeless | lpmain_staging=> SELECT Bug.heat FROM Bug, Bugtask, DistroSeries WHERE Bugtask.bug = Bug.id AND Bugtask.distroseries = DistroSeries.id AND DistroSeries.distribution = 3 ORDER BY Bug.heat DESC LIMIT 1; | 01:26 |
| lifeless | heat | 01:26 |
| lifeless | ------ | 01:27 |
| lifeless | (0 rows) | 01:27 |
| lifeless | Time: 235347.492 ms | 01:27 |
| ajmitch | ... | 01:27 |
| ajmitch | that's awfully long | 01:27 |
| lifeless | you think? | 01:27 |
| wgrant | It is staging, though. | 01:27 |
| wgrant | But yeah, just slightly slow. | 01:27 |
| lifeless | 14 seconds 'hot' | 01:27 |
| lifeless | which matches production timing | 01:27 |
| lifeless | http://pastebin.com/G8sctDVF | 01:29 |
| wgrant | Hmm. | 01:30 |
| lifeless | If I read it correctly its scanning every bug ever in descending heat and one by one comparing their distroseries distribution | 01:31 |
| lifeless | what we'd really rather it do is expand the set of distroseries ids to be 'IN select distroseries.id from distroseries where distroseries.distribution = 3' | 01:32 |
| mwhudson | i don't suppose it matters here, but can there really not be an index on distroseries.distribution? | 01:32 |
| lifeless | of course, also to do that magically. | 01:32 |
| mwhudson | maybe it's just such a small table that seqscan is quicker | 01:32 |
| lifeless | mwhudson: it may be that that is needed. | 01:32 |
| wgrant | It's a tiny table at the moment. | 01:32 |
| lifeless | yes, but query analyser magic. | 01:32 |
| * wgrant wishes for an import fixer. | 01:34 | |
| wgrant | sed's handy for moving stuff, but then you have to reorder and merge lines :( | 01:35 |
| lifeless | edwin has a vim script for it | 01:35 |
| wgrant | I have his set of vim scripts. | 01:36 |
| wgrant | Maybe I have it but just don't know about it. | 01:36 |
| * wgrant looks. | 01:36 | |
| mwhudson | i want to write something that does all my import statement editing for me | 01:37 |
| mwhudson | (based on tags or something) | 01:37 |
| mwhudson | rope apparently has something to do this, but i never got ropemacs to work | 01:37 |
| wgrant | Hm, so, yes, it has Ctrl+L which uses tags and adds the magical import. | 01:37 |
| wgrant | And Ctrl+P supposedly reformats all the imports. | 01:37 |
| lifeless | wgrant: if you're interested in performance stuff | 02:02 |
| lifeless | DistroSeries:EntryResource:getBuildRecords | 02:02 |
| lifeless | https://bugs.launchpad.net/soyuz/+bug/590708 | 02:03 |
| _mup_ | Bug #590708: DistroSeries.getBuildRecords often timing out <api> <oops> <soyuz-build> <timeout> <Launchpad Foundations:Triaged by benji> <Soyuz:Triaged by michael.nelson> <https://launchpad.net/bugs/590708> | 02:03 |
| lifeless | wgrant: ^ the soyuz task on it needs to change to a better query in the short term | 02:03 |
| lifeless | wgrant: danilo has crafted one, but its not been transcribed; should be very low hanging fruit, and its the top timeout from mondahy | 02:04 |
| lifeless | poolie: shall we continue with that bug ? | 02:05 |
| lifeless | hmm, when do we toggle from 'fix committed' to 'fix released' ? | 02:24 |
| lifeless | sinzui: hi, btw Ursinha requested that we use oops and timeout tags as mutually exclusive things | 02:31 |
| Ursinha | lifeless, after the rollout? | 02:32 |
| lifeless | Ursinha: no, a couple of weeks ago | 02:32 |
| lifeless | Ursinha: you pinged me about filing bugs with oops & timeout tags, as said 'one or other' | 02:32 |
| Ursinha | lifeless, I answered your first question | 02:32 |
| Ursinha | <lifeless> hmm, when do we toggle from 'fix committed' to 'fix released' ? | 02:32 |
| lifeless | Ursinha: ah, cool, ECONFUSED :) | 02:33 |
| Ursinha | hehe :) | 02:33 |
| sinzui | lifeless, akc | 02:33 |
| sinzui | or ack | 02:33 |
| sinzui | Ursinha, When I see the release announcement, and I see the registry change is indeed on lpnet, I run the close_developer_bugs for the registry team. When I was RM, I ran it for all launchpad-project | 02:35 |
| Ursinha | sinzui, that's cool | 02:36 |
| Ursinha | lifeless, ^ | 02:36 |
| lifeless | cool | 02:36 |
| lifeless | I was asking because I wanted to fit in ;) | 02:36 |
| sinzui | I know I sent it to the list a few months back. you can pass a list of launchpad ids to update, or ALL to DTRT | 02:37 |
| lifeless | sinzui: the portlet thing | 02:38 |
| sinzui | yes that thing | 02:38 |
| lifeless | when I looked at an oops for the timeout | 02:38 |
| lifeless | it shows a very long non-sql gap taking place | 02:38 |
| lifeless | do you think that that is just the parsing and construction of the objects returned by the earlier query ? | 02:39 |
| sinzui | lifeless, yes. EdwinGrubbs can to that conclusion | 02:40 |
| sinzui | we only want a number too | 02:40 |
| lifeless | right | 02:40 |
| lifeless | I'm with you on that, just wanting to be sure we fix the core issue :) | 02:40 |
| lifeless | sinzui: the thing is, that there are 2155 rows | 02:41 |
| lifeless | sinzui: I find it hard to believe that creating 2155 objects takes 18 seconds of python time | 02:41 |
| lifeless | sorry, 16 seconds | 02:41 |
| lifeless | sinzui: I'm looking at https://lp-oops.canonical.com/oops.py/?oopsid=1681EB2995 | 02:42 |
| lifeless | the last query that completed is at 960ms into the request, and has no limit - its the one you want to convert to get a count. | 02:42 |
| lifeless | the distroseries is 103 based on another place in that page that has the literal | 02:43 |
| sinzui | That is the one I was looking at | 02:43 |
| sinzui | I think it is getting packaging, spn, product_series, product) because in most cases, you want to see all the items...but most cases also make the request with a batch navigatot | 02:46 |
| sinzui | lifeless, ^ | 02:46 |
| lifeless | so, that makes sense to me | 02:47 |
| sinzui | lifeless, The property must use a decorated resultset too. It is iterating over *all* the items | 02:47 |
| lifeless | it does, or it should ? | 02:48 |
| sinzui | It should I think | 02:48 |
| lifeless | makes sense to me | 02:48 |
| lifeless | whats the property called ? | 02:48 |
| sinzui | distroseries.packaging | 02:48 |
| sinzui | lifeless, last year this property only had to content with a few hundred packages. It is time to review all the callsites and decide wha the model really needs to provide | 02:50 |
| sinzui | s/content/contend/ | 02:50 |
| lifeless | thanks | 02:50 |
| lifeless | yes, I agree | 02:50 |
| lifeless | scaling - this is part of my design guidelines, and its past time I wrote them up on the wiki | 02:50 |
| sinzui | I almost got rid of distroseries.packaging 6 months ago too :( | 02:51 |
| lifeless | I wanted to get some actual concrete fingers-dirty things done before making real suggestions | 02:51 |
| lifeless | sinzui: :) | 02:51 |
| sinzui | lifeless, we are down to 4 callsite, 3 of which is the distroseries model itself | 02:53 |
| lifeless | so is the attribute the issue | 02:54 |
| lifeless | or the table joins etc? | 02:54 |
| lifeless | I guess I mean, whichi thing are yo uworking to reduce-the-use-of-and-delete? | 02:54 |
| Ursinha | lifeless, email sent | 02:54 |
| sinzui | I am wrong, one callsite, just the one getting the count! we can replace it without packaging_count | 02:54 |
| Ursinha | (about oops/bug change) | 02:54 |
| lifeless | Ursinha: sweet, thanks. | 02:55 |
| * sinzui sees EdwinGrubbs move the other callsites to use _all_packagings via specialised menthods | 02:56 | |
| cody-somerville | is '++profile++' the name of soom tool? | 02:56 |
| cody-somerville | *some | 02:56 |
| spiv | It's a magic URL path segment you'll be able to add to Launchpad URLs to make it generate profiling data. | 02:57 |
| spiv | (once the relevant work lands, if it hasn't already) | 02:57 |
| poolie | lifeless: hi, yes, let's | 03:00 |
| poolie | scutwork of expenses and sysadmin is done | 03:00 |
| poolie | i wonder if paused kvms survive reboots? | 03:00 |
| poolie | probably not | 03:00 |
| lifeless | The defn does | 03:01 |
| lifeless | the instance doesn't | 03:01 |
| lifeless | spiv: everything but the glue has landed | 03:01 |
| cody-somerville | Are there any examples in Launchpad where the privacy of an object is determined by an 'owning' object? | 03:02 |
| poolie | lifeless, as of last night, i put that null object into the testrequest and that had a trivial failure | 03:02 |
| poolie | so let's try again | 03:02 |
| lifeless | cody-somerville: not polished ones, no. | 03:03 |
| lifeless | cody-somerville: but private bug attachments will be kindof this soon | 03:04 |
| lifeless | cody-somerville: and branches already are via the 'branch policy' stuff | 03:04 |
| lifeless | poolie: cool; I has caffeine and I has toast cooking | 03:04 |
| cody-somerville | Thats not really what I meant | 03:04 |
| cody-somerville | although branch policy describes the default privacy for a new branch, privacy checks aren't actually delegated to it | 03:04 |
| * poolie tries again | 03:04 | |
| poolie | have you seen any deprecation warning failures in bzr builder to do with 'debian' vs 'debian_bundle'? | 03:05 |
| lifeless | cody-somerville: sinzui's team will be working on something very much like this soon | 03:05 |
| wgrant | cody-somerville: P3As do that sort of thing. | 03:05 |
| poolie | or is that just out of date sourcecode or something? | 03:05 |
| wgrant | All the publications and builds within the P3A inherit their privacy from it. | 03:05 |
| lifeless | poolie: jelmer did something related to that recently | 03:05 |
| cody-somerville | wgrant, Is this a feature inherent to zope or something the soyuz folks bolted on? | 03:05 |
| wgrant | The security adapters just delegate to the archive. | 03:06 |
| wgrant | You could write a security adapter which just by default delegates to the parent, but that's not the default. | 03:06 |
| wgrant | In a normal Zope app that would work fine, since everything has a parent. | 03:06 |
| wgrant | Not so much in LP. | 03:06 |
| cody-somerville | wgrant, Do you actually write a security adapter or is it all done via zcml? | 03:06 |
| lifeless | god no | 03:06 |
| wgrant | cody-somerville: One just needs to throw an adapter in lib/canonical/launchpad/security.py. No ZCML required. | 03:07 |
| * ajmitch is reminded too much of acquisition at the moment | 03:07 | |
| wgrant | ajmitch: Hm? | 03:07 |
| lifeless | cody-somerville: its a four letter word around here :P | 03:07 |
| ajmitch | though that's more the containing object | 03:07 |
| lifeless | ajmitch: its more uncles | 03:08 |
| poolie | how do you typically run tests? | 03:08 |
| poolie | make check? | 03:08 |
| poolie | or bin/test? | 03:08 |
| wgrant | poolie: The former runs everything, so you can't use it. | 03:08 |
| poolie | ? | 03:09 |
| wgrant | You want to use bin/test, unless you want to run the whole test suite locally, in which case you might be crazy. | 03:09 |
| lifeless | poolie: testr run -- -t PATTERN | 03:09 |
| poolie | cos.. it'll take a long time? | 03:10 |
| wgrant | poolie: ~4 hours on a fast machine. | 03:10 |
| poolie | that's ok | 03:10 |
| wgrant | I just 'bin/test -1cvvt [sometestspec]' | 03:10 |
| wgrant | Ah. | 03:10 |
| poolie | i have a decently fast machine | 03:10 |
| poolie | i don't see a good reason to run it on ec2 and leave this idle | 03:11 |
| poolie | but also, i want to run specific tests too | 03:11 |
| wgrant | If you want to run the whole thing, do use 'make check'. It wraps things in xvfb-run so you don't get Firefox windows popping up everywhere. | 03:11 |
| poolie | on a separate vm | 03:11 |
| lifeless | wgrant: so does testr run :) | 03:12 |
| wgrant | lifeless: Hm, so it does. | 03:12 |
| wgrant | Handy. | 03:12 |
| jtv | The good thing about waking up at decent times for my timezone is the first thing I see online is my antipodean friends. The bad thing is: there is a risk that they may be talking windmill. | 03:13 |
| lifeless | wgrant: so what do you think about doing that query change? | 03:13 |
| wgrant | lifeless: I was hoping that stub could come up with something better. | 03:13 |
| wgrant | But apparently not. | 03:13 |
| lifeless | poolie: ok, so where does that leave us - are you making headway, or fighting friction? | 03:14 |
| lifeless | wgrant: I'm about to start hacking on another branch; you're better equiped to do that one, but I don't want to ignore the high-oopser | 03:15 |
| lifeless | wgrant: which is why I'm looking for either 'I'm on it' or 'not me' from you :) | 03:16 |
| poolie | still moving forward | 03:16 |
| wgrant | lifeless: I'm on it. | 03:16 |
| lifeless | wgrant: \o/ | 03:16 |
| poolie | hm apparently 2GB is not enough to run the tests | 03:18 |
| wgrant | lifeless: Can you please explain analyze these two queries a few times on staging? http://paste.ubuntu.com/475721/ | 03:22 |
| lifeless | http://pastebin.com/AT04PS1P | 03:26 |
| wgrant | WTF | 03:27 |
| sinzui | poolie, I run the whole suite in 2G on a dual core 1.8Gh | 03:28 |
| lifeless | sinzui: so this is the problem line ? | 03:29 |
| wgrant | lifeless: http://paste.ubuntu.com/475724/ | 03:29 |
| lifeless | <dt id="recently-linked" tal:condition="view/recently_linked"> | 03:29 |
| lifeless | ? | 03:29 |
| sinzui | before that | 03:29 |
| lifeless | sinzui: its my first time (in many years) debugging from the pt down, so please excuse my fail :) | 03:30 |
| sinzui | lifeless, count view/num_linked_packages >> len(self.context.packagings) | 03:30 |
| lifeless | ok | 03:31 |
| lifeless | and that would be found by looking at the view class | 03:31 |
| lifeless | yes? | 03:31 |
| lifeless | (just so I know how the dots are joined) | 03:31 |
| sinzui | lifeless, the line you were looking at is intended to return the 5 latest packagings...I noted that we may need an index on datecreated too | 03:32 |
| sinzui | lifeless, yes, I see the view class doing len() | 03:32 |
| lifeless | wgrant: http://pastebin.com/1mdW53Yv | 03:32 |
| lifeless | sinzui: ok, cool. | 03:32 |
| lifeless | sinzui: I'll have a poke | 03:33 |
| wgrant | lifeless: Aha, thanks. | 03:33 |
| wgrant | The query planner is stupid. | 03:33 |
| lifeless | wgrant: remember that staging stats can be different to prod too, but yes - thats what that bug seemed to say, to me. | 03:33 |
| lifeless | wgrant: do you think you've got a better offering than danilos? | 03:33 |
| wgrant | lifeless: I'm trimming a couple of other bits out of the query that don't make sense. | 03:34 |
| lifeless | ah, ye old holistic approach | 03:34 |
| lifeless | sinzui: this looks odd to me | 03:35 |
| poolie | sinzui: my mistake, the vm only had 1gb | 03:35 |
| poolie | and no swap | 03:35 |
| lifeless | results = results.order_by(Desc(Packaging.datecreated), SourcePackageName.name)[:5] | 03:35 |
| lifeless | oh foo, ignore me. | 03:36 |
| lifeless | ECAFFEINE> | 03:36 |
| poolie | would it make any sense to share ~/launchpad across VMs over nfs? | 03:37 |
| lifeless | no | 03:37 |
| lifeless | test isolation is - and I use the word advisedly - terrible in Launchpad | 03:37 |
| mwhudson | bzr doesn't work across nfs, remember! | 03:37 |
| * mwhudson hides | 03:37 | |
| lifeless | mwhudson: :P | 03:37 |
| poolie | :-P | 03:37 |
| lifeless | might make sense to share your repo and use a checkout over nfs | 03:38 |
| lifeless | the sourcedeps caches are pretty small and I wouldn't stress about them | 03:38 |
| mwhudson | well | 03:39 |
| mwhudson | my download-cache is twice the size of my launchpad repo | 03:39 |
| lifeless | lightweight checkout time ;) | 03:40 |
| mwhudson | and the eggs dir about 1.5x the size | 03:40 |
| lifeless | its actually a case where that works well | 03:40 |
| mwhudson | i guess that would save about 50% yar | 03:40 |
| lifeless | the eggs dir I have to nuke regularly | 03:40 |
| poolie | i have a 1.5GB download cache | 03:40 |
| poolie | how do you clean it up? just randomly delete stuff? | 03:40 |
| mwhudson | that seems very large | 03:40 |
| mwhudson | mine is 415 megs and is a full branch i think | 03:41 |
| lifeless | rm -rf eggs/*; make build (but of course be sure to delete a couple of things I never remember because the Makefile + buildout combo is ... traumatic | 03:41 |
| mwhudson | oh eggs can get huge | 03:41 |
| poolie | 611MB eggs; 470MB sourcecode; 416MB download-cache (of which 217MB .bzr) | 03:42 |
| === Ursinha is now known as Ursinha-afk | ||
| lifeless | sinzui: whats a good test case to run to be sure I haven't broken this ? | 03:44 |
| * sinzui thinks | 03:44 | |
| sinzui | lifeless, I do not see a single test for num_linked_packages | 03:47 |
| lifeless | sinzui: well, anything that uses 'packagings' will be fine. | 03:47 |
| sinzui | lifeless, lp/registry/doc/distroseries.txt has 3 tests | 03:49 |
| lifeless | thanks | 03:49 |
| lifeless | http://pastebin.com/xUwxKGC1 | 03:49 |
| lifeless | hah, forbidden attribute len() | 03:50 |
| poolie | ok, so with all eggs deleted, i get 'no module ZConfig' | 03:53 |
| poolie | i guess it depends on actually having some eggs present? | 03:53 |
| lifeless | yes | 03:53 |
| poolie | :/ | 03:53 |
| lifeless | as I said - traumatic | 03:53 |
| lifeless | you need to delete the generated files from bin/ | 03:53 |
| lifeless | (bzr can tell you those) | 03:53 |
| lifeless | and then do python ./bootstrap | 03:54 |
| lifeless | and then 'make build | 03:54 |
| poolie | bin in my branch, or elsewhere? | 03:54 |
| lifeless | in your working tree | 03:54 |
| sinzui | lifeless, I do not think we need .packagings any more. No callsite wants the data returned. The only callsite wants count | 03:54 |
| lifeless | sinzui: \o/ tests pass | 03:54 |
| lifeless | sinzui: whats the page that shows it ? | 03:54 |
| lifeless | just any distroseries ? | 03:55 |
| lifeless | Upstream packaging | 03:56 |
| lifeless | 3 source packages are linked to registered upstream projects. 1 need linking. | 03:56 |
| lifeless | \o/ | 03:56 |
| sinzui | any ubuntu or debian series | 03:56 |
| lifeless | sinzui: well, this was very shallow, so I'll push it up and we can see ;) | 03:57 |
| sinzui | fab | 03:58 |
| lifeless | sinzui: I don't know enough to know what the right/wrong fix is here | 03:58 |
| lifeless | other than that this should help | 03:58 |
| poolie | ok, re-bootstrapping | 03:58 |
| lifeless | sinzui: https://code.edge.launchpad.net/~lifeless/launchpad/registry-packagings/+merge/32164 | 04:01 |
| sinzui | lifeless, r=me | 04:10 |
| poolie | lifeless: so if 'testr run' mentions no failures, there were no failures? | 04:12 |
| lifeless | sinzui: cool | 04:13 |
| lifeless | poolie: thats right | 04:13 |
| lifeless | sinzui: do you think this is rc ? | 04:13 |
| poolie | what's the invocation to re-run failures? | 04:14 |
| lifeless | testr run --faling | 04:14 |
| lifeless | bah | 04:14 |
| lifeless | testr run --failing | 04:14 |
| sinzui | lifeless, yes.I think it is RC. I expect it is also a CP candidate since we really want users seeing the distroseries page | 04:17 |
| lifeless | well as rc I can shoot it off now and it should be in the rollout ? | 04:18 |
| poolie | ok now http://pastebin.ubuntu.com/475731/ is strange | 04:19 |
| lifeless | poolie: how so ? the fact its failing? | 04:19 |
| poolie | yes | 04:20 |
| poolie | maybe it's not my fault | 04:20 |
| poolie | how would i re-run just a doctest? -t views_txt doesn't seem to work | 04:22 |
| poolie | maybe with a dot? | 04:22 |
| lifeless | teset | 04:22 |
| lifeless | yes | 04:23 |
| lifeless | e.g. -t doc/views.txt | 04:23 |
| lifeless | or whatever | 04:23 |
| poolie | do you have any guesses about the memcached test failure? | 04:24 |
| lifeless | none sorry | 04:25 |
| lifeless | it looks like it uses a subclassed test or something ? | 04:25 |
| lifeless | sinzui: throwing it at ec2 | 04:25 |
| lifeless | subclassed view I mean | 04:25 |
| sinzui | woot! | 04:25 |
| poolie | maybe memcached is sad? i'm also getting "WARNING:root:Memcache set failed"... | 04:26 |
| poolie | just thinking aloud here | 04:26 |
| sinzui | poolie, I think that means the test needs to run on the LaunchpadFunctionalLayer | 04:27 |
| sinzui | Oh, it is on the correct layer | 04:28 |
| sinzui | poolie, Did you change something on the distroseries-needs-packaging.pt page? | 04:30 |
| lifeless | sinzui: he changed base-layout | 04:32 |
| sinzui | I do not think that should have any impact on the test. The test does not care about layout/markup. | 04:33 |
| sinzui | poolie, when you saw ""WARNING:root:Memcache" did you see the the memcache layer was brought up before the test? | 04:35 |
| lifeless | poolie: you can do 'subunit-ls<.testrepository/$testid' to answer that question | 04:35 |
| jtv | lifeless: would it be easy to implement the fake librarian as a test resource? I could install it from setUp/tearDown but it'd be such a chore. | 04:36 |
| lifeless | jtv: we don't have testresources glued in with layers yet | 04:36 |
| lifeless | jtv: so, setUp/tearDown will be easier, for now. | 04:36 |
| lifeless | afk for a bit | 04:37 |
| jtv | bummer | 04:37 |
| poolie | sinzui: it did say the layer had been started up | 04:37 |
| sinzui | poolie, I see the test requires LaunchpadFunctionalLayer. I have see the warning reported when authoring a test on the wrong layer | 04:38 |
| sinzui | poolie, memcache layer is brought up just before the LaunchpadFunctionalLayer... | 04:38 |
| mwhudson | do we need another scummy loop to make sure memcache has started accepting connections? | 04:39 |
| sinzui | poolie, I think (speculate) that I have seen memcached startup/shutdown contentions between tests. I think I saw memcached not come up because it was not fully torn down in a previous test | 04:40 |
| sinzui | I saw it only once, and the issue was only on my machine when I was refactoring | 04:40 |
| poolie | so maybe it's something about the specific tests i was asking for | 04:42 |
| sinzui | :( | 04:42 |
| sinzui | poolie, you may want to try --layer=LaunchpadFunctional to restrict tests to a certain layer | 04:44 |
| poolie | that runs only the tests in that layer? | 04:44 |
| sinzui | correct | 04:44 |
| poolie | ok | 04:44 |
| poolie | i'm now trying to just run everything | 04:44 |
| poolie | everything seems to be passing | 04:51 |
| sinzui | :) | 04:52 |
| poolie | though who knows what will fail later | 04:53 |
| poolie | and i found another tribunal bug :) | 04:53 |
| poolie | it should set stdin into nonblocking mode to cope better with slowly-fed pipes | 04:53 |
| lifeless | jtv: did you get the mail 'Translation template import - typewriter in pidgin-typewriter trunk' just now ? | 04:53 |
| jtv | lifeless: I don't think I did. | 04:54 |
| lifeless | forwarded | 04:54 |
| lifeless | its a little worrying that it exposes all the email addresses | 04:54 |
| lifeless | and | 04:54 |
| lifeless | that we're getting it at all :) | 04:54 |
| jtv | That was a little side job I didn't quite get around to doing at Epic. | 04:55 |
| jtv | We want to disable these success notices for Ubuntu imports at the least. | 04:55 |
| poolie | i get a lot of these | 04:55 |
| poolie | i don't know about yours in particular | 04:55 |
| jtv | lifeless: I believe the exposure of co-recipients happens in simple_sendmail | 04:56 |
| poolie | jtv: i just happened to notice that there's what seems to be translations exported metadata inside 'virsh help domname' | 04:57 |
| poolie | actually i'll just file, or look for, a bug | 04:57 |
| jtv | poolie: sorry what is "virsh help domname"? | 04:57 |
| lifeless | virsh is a tool for managing kvm stuff | 04:57 |
| lifeless | domname is a help topic in the tool | 04:58 |
| jtv | and who is domname? | 04:58 |
| poolie | i think it's a bug in either their use of gettext or our packaging | 04:58 |
| jtv | Then that would probably be a bug in libvirt-bin | 04:58 |
| lifeless | we're down to 52 timeout bugs | 04:58 |
| lifeless | < 2 per developer! | 04:58 |
| jtv | (or rather, whatever source package it came from) | 04:59 |
| cody-somerville | lifeless, you rock! :) | 04:59 |
| lifeless | cody-somerville: not I | 04:59 |
| lifeless | cody-somerville: I've done 2 I think | 05:00 |
| cody-somerville | lifeless, I was just commenting on how you rock :P | 05:01 |
| lifeless | cody-somerville: aw shucks, well thanks! | 05:01 |
| poolie | or 52 per lifeless | 05:10 |
| poolie | so with all of the tests running, i don't seem to see that memcached failure | 05:11 |
| lifeless | poolie: cool | 05:13 |
| poolie | lifeless: with that null object added, 0 failures out of 2280 so far | 05:34 |
| lifeless | awesome | 05:35 |
| poolie | want to give me an incremental review? | 05:41 |
| lifeless | yes | 05:42 |
| lifeless | r=lifeless | 05:42 |
| lifeless | except as its not release-critical, it can't be landed for the moment >< | 05:42 |
| poolie | ok | 05:42 |
| poolie | i might take a break and let this keep grinding | 05:42 |
| lifeless | kk | 05:45 |
| lifeless | wgrant: around/ | 05:45 |
| wgrant | lifeless: Just wandered into uni. | 05:45 |
| wgrant | So, yes. | 05:45 |
| lifeless | hey | 05:45 |
| lifeless | so | 05:45 |
| lifeless | I mailed you an oops-extract | 05:46 |
| lifeless | I was wondering if you could quickly eyeball me and tell me if its still relevant, or if something done in soyuz recently has 'made it all better' | 05:46 |
| wgrant | My eyes are bleeding. | 05:47 |
| wgrant | That... that query. | 05:47 |
| wgrant | So, I'd say that's still problematic. | 05:49 |
| wgrant | And probably related to the model changes a couple of months ago. | 05:49 |
| wgrant | Nothing there has changed recently. | 05:49 |
| lifeless | the query at the top isn't particularly bad | 05:50 |
| lifeless | its death by a thousand cuts territory | 05:50 |
| wgrant | It's always been a problematic page. | 05:50 |
| lifeless | do you remember the template name ? | 05:50 |
| lifeless | nvm I see it | 05:50 |
| lifeless | more relevantly, are their unit tests of it ? | 05:51 |
| wgrant | Of the view? | 05:51 |
| wgrant | Very unlikely. | 05:51 |
| wgrant | Only Code tends to do those, AFAIK. | 05:51 |
| lifeless | s/their/there/ | 05:51 |
| lifeless | wgrant: many places do fwiw | 05:51 |
| lifeless | not directly, but via publication, using unit test frameork though | 05:51 |
| wgrant | Hm, so they do. | 05:52 |
| lifeless | in fact, test_archive_packages == soyuz one | 05:52 |
| wgrant | Indeed, there are a few. | 05:52 |
| wgrant | But it's tiny. | 05:53 |
| lifeless | also, if they drive the view without publication its an invalid test | 05:57 |
| lifeless | which is higher up the stack | 05:59 |
| lifeless | LPFunctionalLayer | 05:59 |
| lifeless | or DBFunctionalLayer ? | 05:59 |
| wgrant | lifeless: So, the whole getBuildRecords stack makes me somewhat sad. Code duplication, manual SQL construction, etc. I've a quick and ugly fix for the slow query now, but I'll rewrite it all next cycle. | 05:59 |
| lifeless | wgrant: \o/ | 06:00 |
| wgrant | lifeless: LP == DB + librarian + memcached | 06:00 |
| wgrant | functional = Zope | 06:00 |
| wgrant | zopeless = Zopeless Zope | 06:00 |
| wgrant | I think those are the main ones. | 06:00 |
| spiv | I should have called "zopeless" "zope on a rope". It would still be inaccurate, but at least it would make me laugh. | 06:01 |
| wgrant | spiv: Was it ever actually Zopeless? | 06:01 |
| lifeless | wgrant: it is zope-- | 06:01 |
| spiv | Kinda. | 06:01 |
| spiv | Once upon a time it avoided loading all the config and zcml and whatnot. | 06:02 |
| wgrant | Right. That's what I thought it would do, when I first came upon the name. | 06:02 |
| lifeless | whats the thing to get a test browser again ? | 06:02 |
| spiv | I think that was back when the paint in cave paintings was still wet. | 06:03 |
| wgrant | lifeless: self.getUserBrowser | 06:03 |
| lifeless | spiv: so, yesterday then ? | 06:03 |
| lifeless | spiv: :P | 06:03 |
| lifeless | wgrant: any tips on test helpers to populate a ppa? | 06:05 |
| lifeless | wgrant: I want to trigger the repeated queries seen in https://edge.launchpad.net/~kalon33/+archive/experimental-stuff/+packages | 06:05 |
| wgrant | lifeless: See SoyuzTestPublisher. james_w is in the middle of an API change, but the old one will be around for a while. | 06:05 |
| wgrant | Although there might be enough stuff directly in the factory now. | 06:05 |
| wgrant | Let's see. | 06:05 |
| wgrant | lifeless: STP.getPubBinaries will be more useful if you want sources, binaries and builds (which is probably the case). If you just want sources, LOF.makeSourcePackagePublishingHistory would work. | 06:07 |
| lifeless | thanks, I'll see if I can get a failing test up with those hints | 06:07 |
| lifeless | object.canonical_url is the way to get a canonical url, right ? | 06:08 |
| wgrant | canonical_url(object) | 06:08 |
| lifeless | blah | 06:08 |
| * mtaylor decides to just be annoying and complain about zcml for no reason | 06:08 | |
| lifeless | mtaylor: I think you need to actually make a complaint for that to make any sense at all | 06:09 |
| mtaylor | lifeless: oh - I was just complaining about the existence of zcml in the first place | 06:10 |
| lifeless | mtaylor: it solves a problem | 06:10 |
| mtaylor | lifeless: yes. it does. | 06:11 |
| lifeless | mtaylor: you didn't have enough things to complain about! | 06:11 |
| mtaylor | lifeless: this is a strong, but potentially correct assertion :) | 06:12 |
| mtaylor | gah! python-software-properties should have been in base | 06:16 |
| wgrant | mtaylor: Yes :( | 06:17 |
| wgrant | add-apt-repository is handy. | 06:17 |
| mtaylor | it's fantastic | 06:17 |
| mtaylor | of course ... don't even get me started that to install add-apt-repository one has to install python-software-properties... | 06:17 |
| lifeless | wgrant: self.getPubBinaries ? | 06:18 |
| wgrant | lifeless: You need a SoyuzTestPublisher. | 06:18 |
| wgrant | Which is in lp.soyuz.tests.test_publishing | 06:19 |
| lifeless | ay | 06:19 |
| lifeless | is making a new series feasible | 06:19 |
| lifeless | or should I just use hoary? | 06:19 |
| wgrant | lifeless: http://bazaar.launchpad.net/~wgrant/launchpad/bug-590708-getBuildsByArchIds-timeout/revision/11317 is my quick fix. It does the same thing we do in most of the rest of the Soyuz queries -- precalculate the archive IDs (making use of the distribution/purpose index), and stick them into the query, preventing the planner from fucking us over. | 06:20 |
| lifeless | I'm cloning from the top of xx-archive.txt which only makes me slightly dirty | 06:20 |
| wgrant | lifeless: Use hoary for now. | 06:20 |
| wgrant | james_w is fixing everything to let us not use sampledata, but it's not quite there yet. | 06:20 |
| StevenK | My problem with that is that almost all of the Soyuz tests use sampledata :-( | 06:21 |
| wgrant | Yes :( | 06:21 |
| lifeless | wgrant: +1 | 06:21 |
| lifeless | wgrant: is the fakeChroots thing etc needed? | 06:22 |
| lifeless | wgrant: I see 5 lines of boilerplate in xx-archive.txt and and don't want to copy unneeded boilerplate | 06:23 |
| wgrant | lifeless: I wonder if you might not get any builds if you don't add them. | 06:23 |
| wgrant | But try without. | 06:23 |
| lifeless | so, just construct and use ? | 06:23 |
| wgrant | In order to get the right binaries, you may have to prepareBreezyAutotest and use breezy-autotest instead. | 06:24 |
| wgrant | Different tests do different things for different reasons :( | 06:24 |
| lifeless | wgrant: I'm totally list | 06:24 |
| lifeless | lost | 06:24 |
| wgrant | lifeless: STP.prepareBreezyAutotest does 'stuff'. | 06:25 |
| wgrant | The 'stuff' may be necessary to get the right binaries. | 06:25 |
| wgrant | I'm not quite sure. | 06:25 |
| lifeless | ok, I'll just copy cprovs stuff :) | 06:25 |
| wgrant | lifeless: So, I'd like to confirm that the query still performs sanely. For that I need the archive IDs. | 06:25 |
| lifeless | shoot | 06:26 |
| wgrant | SELECT archive.id, archive.name FROM archive JOIN distribution ON archive.distribution = distribution.id WHERE distribution.name = 'ubuntu' AND archive.purpose IN (1, 4); | 06:26 |
| lifeless | 1 | primary | 06:27 |
| lifeless | 534 | partner | 06:27 |
| wgrant | Thanks. | 06:27 |
| lifeless | you could do this with a subselect and an IN clause, just saying. | 06:27 |
| wgrant | The query planner disagrees. | 06:28 |
| lifeless | oh! | 06:28 |
| lifeless | thats fail | 06:28 |
| lifeless | though I'm a natural born sceptic here | 06:28 |
| lifeless | I would suspect a correlated subquery-by-mistake or something like that | 06:28 |
| wgrant | That's the whole problem with the query. | 06:28 |
| wgrant | lifeless: http://paste.ubuntu.com/475767/ | 06:29 |
| wgrant | analyze plz. | 06:29 |
| lifeless | wgrant: cold cache this one is a bitch | 06:31 |
| wgrant | Of course. | 06:31 |
| lifeless | suggests we have more work to do is all | 06:31 |
| lifeless | Index Scan Backward using buildfarmjob__date_finished__idx on buildfarmjob (cost=0.00..71787.87 rows=103051 width=12) (actual time=0.118..246.771 rows=778 loops=1) | 06:33 |
| lifeless | is the one that seems to be painful | 06:33 |
| wgrant | Still, timing-wise it's 30 times better than the current one. | 06:34 |
| wgrant | And I may be able to remove the date_finished thing later. | 06:34 |
| wgrant | Its purpose is limited. | 06:34 |
| cody-somerville | how do you interpret the cost= bit? | 06:35 |
| lifeless | cody-somerville: its a scale-less estimate | 06:35 |
| lifeless | all the costs are on the same scale, but the scale can't be compared outside the explain | 06:36 |
| StevenK | It looked at over 103k rows? | 06:36 |
| wgrant | That's the expected. | 06:36 |
| lifeless | StevenK: well, the stats made it thought it would | 06:36 |
| poolie | one more failure, a very specific test about base-layout | 06:36 |
| poolie | should be shallow | 06:36 |
| lifeless | poolie: \o/ | 06:36 |
| wgrant | First parenthesised section is what the planner thinks, second is what actually happened. | 06:36 |
| poolie | with 6168 run | 06:37 |
| lifeless | wgrant: | 06:40 |
| lifeless | ERROR: lp.soyuz.browser.tests.test_archive_packages.TestPPAPackages.test_ppa_packages_query_limit | 06:40 |
| lifeless | File "/home/robertc/launchpad/lp-branches/working/lib/lp/soyuz/browser/tests/test_archive_packages.py", line 111, in test_ppa_packages_query_limit | 06:40 |
| lifeless | test_publisher.getPubBinaries('binary1', distroseries=hoary, archive=ppa) | 06:40 |
| lifeless | File "/home/robertc/launchpad/lp-branches/working/lib/lp/soyuz/tests/test_publishing.py", line 303, in getPubBinaries | 06:40 |
| lifeless | build.builder = builder | 06:40 |
| lifeless | Unauthorized: (<BinaryPackageBuild at 0xda2c250>, 'builder', 'launchpad.Edit') | 06:40 |
| lifeless | ------------ | 06:40 |
| lifeless | should I login as the owner of the ppa first ? | 06:41 |
| wgrant | I hope not. | 06:41 |
| lifeless | http://pastebin.com/ciEsMcd6 | 06:42 |
| lifeless | the with_person_logged_in bit was not there when it errored | 06:42 |
| StevenK | I didn't think .builder was settable except by celebrity? | 06:43 |
| lifeless | so how are you meant to use this test 'helper' | 06:44 |
| wgrant | lifeless: See how others use it, I guess. | 06:44 |
| wgrant | I suspect the other users might mostly run Zopeless :/ | 06:45 |
| lifeless | deathrow doesn't even login | 06:45 |
| wgrant | Zopeless doesn't need login. | 06:45 |
| lifeless | ok, so -who- should be logged in to use this ? | 06:45 |
| wgrant | I guess you could just use an admin. | 06:45 |
| wgrant | That's what lots of tests seem to use. | 06:45 |
| lifeless | how is that spelt ? | 06:46 |
| wgrant | login('admin@canonical.com') | 06:46 |
| wgrant | There may be a constant for that now. | 06:46 |
| lifeless | adding one | 06:47 |
| StevenK | I thought one had been added | 06:50 |
| mwhudson | there is one | 06:50 |
| mwhudson | of course i can't find it now | 06:50 |
| mwhudson | login_team('admins') also works i guess | 06:50 |
| lifeless | elif person_or_team.is_team: | 06:51 |
| lifeless | AttributeError: 'str' object has no attribute 'is_team' | 06:51 |
| lifeless | sadness, person_logged_in -> fail on str | 06:51 |
| StevenK | Then obviously it isn't an IPersonRole | 06:51 |
| StevenK | I think I'm misremembering that | 06:52 |
| poolie | jtv, lifeless, bug 615708 is the one i mentioned before | 06:54 |
| _mup_ | Bug #615708: help for domname contains Launchpad translations metadata? <amd64> <apport-bug> <maverick> <Launchpad itself:New> <libvirt (Ubuntu):New> <https://launchpad.net/bugs/615708> | 06:54 |
| poolie | StevenK: do you have any idea how that^^ could happen in soyuz | 06:55 |
| wgrant | Sounds like Rosetta's langpack stuff to me. | 06:56 |
| StevenK | Indeed | 06:56 |
| wgrant | Soyuz has just about nothing to do with that. | 06:56 |
| jtv | No, that's the po file header (which would typically be present anyway, Launchpad involvement or not) being allowed to sneak into somewhere where it's not supposed to be. | 06:56 |
| wgrant | Rosetta just sends the files through it. | 06:56 |
| jtv | As I said yesterday, looks more like a bug in the source package—something in how it's built. | 06:57 |
| jtv | Maybe upstream uses gettext files without headers, and came to rely on that. Maybe they run the empty string through gettext somewhere and so get the header as a translation. | 07:00 |
| lifeless | in short, its a software bug in virsh ? :) | 07:00 |
| jtv | lifeless: that was my impression yesterday, and I stick by it. | 07:01 |
| jtv | stand by it, rather. | 07:01 |
| * StevenK grumbles at initialise-from-parent.txt | 07:01 | |
| wgrant | StevenK: bzr rm | 07:02 |
| StevenK | I did | 07:02 |
| StevenK | wgrant: Code from it in a unittest fails | 07:02 |
| wgrant | StevenK: Functional vs Zopeless, I bet. | 07:02 |
| lifeless | wgrant: thanks, I have enough now to try hooking in HasQueryCount | 07:03 |
| wgrant | Or possibly just being logged in as a different user. | 07:03 |
| StevenK | wgrant: The line that is failing is hoary['i386'].getPublishedReleases(). But IDistroArchSeries doesn't have a .getPublishedReleases()? WTF? | 07:04 |
| wgrant | StevenK: i-f-p.txt doesn't have ['i386']. | 07:04 |
| wgrant | Also, that method name is broken. | 07:05 |
| wgrant | Kill it. | 07:05 |
| StevenK | - >>> hoary_i386_pmount_pubs = hoary['i386'].getReleasedPackages('pmount') | 07:05 |
| lifeless | haha | 07:05 |
| lifeless | hahaha | 07:05 |
| lifeless | hahahahahahaha | 07:05 |
| wgrant | lib/lp/soyuz/doc/initialise-from-parent.txt: >>> hoary_pmount_pubs = hoary.getPublishedReleases('pmount') | 07:05 |
| lifeless | Difference: queries do not match: 12 is >= 51 | 07:05 |
| wgrant | lib/lp/soyuz/doc/initialise-from-parent.txt: >>> foobuntu_pmount_pubs = foobuntu.getPublishedReleases('pmount') | 07:05 |
| lifeless | to show a PPA with 2 binary publications. | 07:05 |
| wgrant | StevenK: getPublishedReleases != getReleasedPackages | 07:05 |
| StevenK | wgrant: A few lines under that | 07:05 |
| wgrant | StevenK: You initially spoke of getPublishedReleases. But the line you quote mentions getReleasedPackages. | 07:06 |
| StevenK | Right. wgrant correctly tells me that I need to learn to read. | 07:06 |
| wgrant | I stand by my assertion that the method names are fucked. | 07:06 |
| wgrant | This may mean that I need to go on a rampage next week and destroy them all. | 07:06 |
| lifeless | and 55 for 3 packages | 07:09 |
| lifeless | this is going to end badly:) | 07:09 |
| wgrant | Indeed it will. | 07:09 |
| poolie | omg doctests | 07:13 |
| poolie | failing on whitespace differences | 07:13 |
| lifeless | actually | 07:14 |
| lifeless | what it probably means is that there is -one- key diff | 07:14 |
| lifeless | and the whitespace stuff just telling you about all differences | 07:14 |
| lifeless | perhaps not, but I found this behaviour very confusion | 07:14 |
| lifeless | s/ion/ing/ | 07:14 |
| poolie | right, that is it | 07:14 |
| StevenK | poolie: "Feature" | 07:14 |
| lifeless | wgrant: if you're still around ? | 07:21 |
| wgrant | lifeless: Of course. | 07:21 |
| wgrant | In a shitty tute. | 07:21 |
| wgrant | So please, distract me :) | 07:21 |
| lifeless | I'd like to do roughly what I did with _all_members for +packaging | 07:22 |
| lifeless | which is to make the request count constant for 2 and 3 build pages by populating related data | 07:22 |
| lifeless | If you could point me at a couple of entry points in soyuz, that would be great. | 07:22 |
| wgrant | +packaging is more Registry. | 07:23 |
| lifeless | I don't believe in those lines | 07:24 |
| wgrant | So there probably aren't really any Soyuz entrypoints, as such. | 07:24 |
| lifeless | the data is generated by soyuz | 07:24 |
| wgrant | So I'm not quite sure what you're asking. | 07:24 |
| lifeless | hmm | 07:24 |
| lifeless | so | 07:25 |
| lifeless | I'll follow my noise | 07:26 |
| lifeless | *nose*, from the template | 07:26 |
| * StevenK wonders if he can get the exception text with self.assertRaises() | 07:30 | |
| lifeless | it should do that by default | 07:34 |
| lifeless | or you could grab my matchesException , mmm, I wonder if thats in testtools yet | 07:34 |
| poolie | lifeless: i wonder if we should convert doctests one by one to just use matchers or something | 07:41 |
| poolie | just in line, to make it easier | 07:41 |
| poolie | it would have made this one easier | 07:41 |
| poolie | however | 07:41 |
| poolie | my test run failed i guess due to the lack of a $display to run windmill things | 07:41 |
| poolie | i'm going to retry with make check and then i think that's it | 07:41 |
| lifeless | testr run should have done the display thing for you | 07:45 |
| lifeless | be sure to log in with X forwarding in your ssh | 07:45 |
| lifeless | it lets it work regardless | 07:45 |
| poolie | i didn't use it because i wanted to pipe it out to tribunal | 07:46 |
| lifeless | ah right - to get incremental ? | 07:46 |
| poolie | incremental progress and errors yes | 07:47 |
| lifeless | stub: btw, I've tagged a couple of things dba | 07:50 |
| stub | k | 07:52 |
| lifeless | /launchpad-project/+bugs?field.tag=dba or something like that | 07:53 |
| lifeless | stub: I need to chat with you to make sure your life won't become a living hell with the RFWTAD LEP | 07:53 |
| lifeless | francis pointed out that db patching is a bit labour intensive at the moment, or something | 07:54 |
| StevenK | ubuntu['breezy-autotest'] | 07:54 |
| StevenK | And ubuntutest['breezy-autotest'] | 07:54 |
| StevenK | Sampledata, YOU (&(^ING SUCK | 07:54 |
| lifeless | how does this hang together | 08:06 |
| lifeless | archive-packages.pt does | 08:07 |
| lifeless | <metal:package-list use-macro="context/@@+macros/source-package-list" /> | 08:07 |
| lifeless | oh, I see, non_selectable is a bit magic | 08:08 |
| lifeless | and -fun- it has a template per row | 08:10 |
| StevenK | O hai, I can haz review? | 08:11 |
| StevenK | O hai, I can haz review? | 08:19 |
| StevenK | Whoops. | 08:20 |
| StevenK | And obviously not | 08:20 |
| lifeless | heh | 08:21 |
| lifeless | whats up? | 08:21 |
| StevenK | lifeless: Tis simple-ish: https://code.edge.launchpad.net/~stevenk/launchpad/switch-ifp-to-unittests/+merge/32073 | 08:21 |
| lifeless | Its a bit late for me to be confident in checking that | 08:23 |
| lifeless | sorry | 08:23 |
| lifeless | at a first glance though | 08:23 |
| lifeless | you have lots of literal sample data there | 08:23 |
| StevenK | So the original doctest :-( | 08:23 |
| lifeless | might want to add constants to sampledata.py | 08:23 |
| StevenK | Er, so did | 08:23 |
| lifeless | remind me | 08:26 |
| lifeless | how does storm and __init__ interact | 08:26 |
| jtv | danilos: another nice effect of your big variants cleanup is that we're one step closer to not passing pofiles around in the new "recife" methods. | 08:27 |
| lifeless | \o/ registry-packagings passed ec2 | 08:28 |
| lifeless | stub: ping | 08:31 |
| * lifeless wtfs class SourcePackagePublishingHistory(SQLBase, ArchivePublisherBase): | 08:35 | |
| StevenK | Yes, SPPH is ... special | 08:35 |
| lifeless | StevenK: btw I really really wish you wouldn't propose things that you're only just working on | 08:36 |
| StevenK | lifeless: Why not? | 08:36 |
| lifeless | terrible diff gets mailed out | 08:36 |
| lifeless | by which I mean useless | 08:36 |
| StevenK | lifeless: The last MP I did as WIP? | 08:36 |
| lifeless | yes | 08:36 |
| StevenK | Does that still mail out a diff? | 08:36 |
| lifeless | its not how the system is meant to be used | 08:36 |
| StevenK | lifeless: If I want Julian to look at a branch, I need a WIP MP :-( | 08:37 |
| lifeless | why? | 08:37 |
| lifeless | (obvious answer, don't worry about Julian looking at the branch :P) | 08:37 |
| StevenK | Because he wants to view a nice diff in a web page, I guess | 08:37 |
| jtv | danilos, henninge_: setCurrentTranslation doesn't really need a TranslationSide argument, so I'm removing that. Also, IPOTemplate now exposes its TranslationSide but not the traits that go with it. | 08:37 |
| StevenK | I'm doing it because Julian asks me, not to annoy you | 08:38 |
| jtv | danilos, henninge_: at least, when I get this branch reviewed & landed. :) | 08:38 |
| lifeless | StevenK: you're the only person doing it, its pretty weird. I know you're not trying to annoy; What do we need to change to fix this? | 08:38 |
| === henninge_ is now known as henninge | ||
| StevenK | lifeless: Have Julian be less lazy? | 08:38 |
| StevenK | I guess? :-) | 08:39 |
| henninge | jtv: yeah, try finding a reviewer willing to approve *that*! | 08:39 |
| jtv | uh-oh | 08:39 |
| henninge | ;) | 08:39 |
| jtv | henninge: well no worries, guess who's ocr tomorrow :) | 08:39 |
| henninge | no jtv, you can *not* approve your own branches! | 08:39 |
| jtv | «damn—how did he guess!?» | 08:40 |
| lifeless | is there a utility to do what cachedproperty does, but in a function ? | 08:41 |
| adeuring | good morninig | 08:43 |
| poolie | https://bugs.edge.launchpad.net/launchpad/+bug/615740 sigh | 08:45 |
| _mup_ | Bug #615740: test_on_merge.py doesn't handle eintry <Launchpad itself:New> <https://launchpad.net/bugs/615740> | 08:45 |
| lifeless | are there ppas in the sample data? | 08:47 |
| StevenK | yes | 08:48 |
| StevenK | cprov has one, for example | 08:48 |
| lifeless | ok, cool, I've found code that runs when the packages list is shown :) | 08:49 |
| lifeless | except, not on +packages, only on the ppa page itself. wtf | 08:50 |
| stub | lifeless: pong | 08:50 |
| lifeless | stub: hey | 08:50 |
| lifeless | stub: can you do a brief skype call, or is irc more convenient? topic: agile db patches | 08:51 |
| lifeless | oh man, thats so annoying; my timeout fix for sinzui missed edge by 1 hour | 08:51 |
| stub | I can do either. Typing is generally better for me. | 08:52 |
| lifeless | ok, lets go with typing | 08:52 |
| lifeless | so, in the new workflow that should start in ~ a week | 08:52 |
| lifeless | we'll get rid of edge | 08:52 |
| lifeless | and have nondb patches flowing straight through with in-line qa | 08:52 |
| lifeless | you know all this ;) | 08:52 |
| lifeless | to start doing db patches in a similar manner, I've been assuming it was primarily a matter of figuring out a series of non-downtime db patches and background scripts interspersed with code changes to match | 08:53 |
| lifeless | e.g. db, code, db, code etc until the transition is done | 08:53 |
| lifeless | not all db patches can be done like this, and so far I've been figuring that its up to the developer to choose between their development time vs doing a single patch in the monthly downtime | 08:54 |
| stub | Unless we plan to be cowboying all our DB changes, the main issue is reworking our processes and tools to support that. | 08:54 |
| lifeless | so - what things are likely to cause friction or failure | 08:55 |
| stub | With replication, non-downtime means data migration and adding/dropping indexes. | 08:55 |
| lifeless | could you expand a little, so I think I understand :) | 08:55 |
| poolie | how do i fix this: | 08:55 |
| poolie | Getting distribution for 'testtools==0.9.6dev91'. | 08:55 |
| poolie | Error: Couldn't find a distribution for 'testtools==0.9.6dev91'. | 08:55 |
| lifeless | poolie: update your download-cache and run make build | 08:56 |
| stub | Data migration are just python or sql scripts that get run on the master - just data changes like any other script. No real problem, except we need to ensure they get run and tested on staging automatically. | 08:56 |
| poolie | lifeless: with update-sourcecode? | 08:58 |
| stub | Adding and dropping indexes may well have to be a manual process. We need to run CREATE INDEX CONCURRENTLY on each node, outside of a transaction, and be around to cleanup if things messup. Also need to manage long running transactions as the index build will block on long running transactions. | 08:58 |
| lifeless | poolie: I use 'bzr update' in the download-cache directory | 08:58 |
| stub | For pretty much all other DB patches, we need to go via the slony tools. Slony locks all the tables, removes all the replication triggers, applies the patches to the nodes one at a time, rebuilds all the replication triggers (which might be different now there might be new columns etc.), and unlocks. | 08:59 |
| lifeless | stub: does that involve perceived downtime ? | 09:00 |
| poolie | oh for deb dependencies :) | 09:00 |
| stub | lifeless: Yes. The lock will never be granted while the appservers are active. | 09:01 |
| stub | locks I should say (exclusive lock on every replicated table in the replication set) | 09:01 |
| lifeless | stub: ok, so that I understand - we can't e.g. add a column live | 09:01 |
| lifeless | stub: but we could create a whole new table, migrate data to it, then start it replicating ? | 09:02 |
| stub | Yup. So goal is to minimize that time. There are at least two improvements we can make to our existing tools to lower times, and that is the first step I think. | 09:02 |
| stub | Not invoking comments.sql on production (no real need so it is waste), and making security.py more intelligent. | 09:03 |
| stub | Yes, we can create a new table live and add it to replication. | 09:03 |
| lifeless | ok | 09:03 |
| lifeless | so a long term theme will be increasing the refactorings we can do live | 09:04 |
| poolie | spiv i was going to try something like https://bugs.edge.launchpad.net/launchpad-foundations/+bug/615740/comments/1 | 09:04 |
| _mup_ | Bug #615740: test_on_merge.py doesn't handle eintr <Launchpad Foundations:In Progress by mbp> <https://launchpad.net/bugs/615740> | 09:04 |
| stub | Although it usually would be create table, add to replication, populate rather than create table, populate, replicate | 09:04 |
| poolie | oh ffs launchpad | 09:04 |
| lifeless | poolie: ? | 09:04 |
| poolie | whitespace folding in bug comments is not the kindest thing for python programmers | 09:04 |
| lifeless | heh | 09:04 |
| lifeless | masochists all | 09:05 |
| poolie | anyhow spiv http://pastebin.ubuntu.com/475807/ | 09:05 |
| lifeless | stub: thanks; so - in summary - its doable for a small set of cases now, and we can start building them out as we go | 09:05 |
| * spiv moves to this channel | 09:05 | |
| lifeless | stub: there is expected to be a high risk of pear-shapedness, so it won't be part of the fast-qa path | 09:05 |
| lifeless | stub: and thus we also need some reporting for folk that are doing staged-refactorings so they know when w particular db change has gone live and they can move to their next stage. | 09:06 |
| spiv | poolie: looks reasonable to me | 09:06 |
| lifeless | stub: is that about the size of it ? [glossing over the details about what we can/can't do today] | 09:06 |
| poolie | i'll clarify that comment and interactively test it | 09:07 |
| spiv | poolie: although I wonder why make check needs a SIGWINCH handler? | 09:07 |
| lifeless | spiv: make check runs the pqm merge check | 09:07 |
| lifeless | spiv: which ~ 0 devs run - it has a supervisor process etc | 09:07 |
| stub | lifeless: Pretty much. We already do indexes live as necessary, normally without too much grief. The biggest fallout from live changes is occasionally timeout OOPSES when I underestimate how long a lock will need to be held, and breaking staging (eg. creating new DB users and forgetting to replicate that work there). | 09:07 |
| spiv | lifeless: this only makes me more perplexed | 09:07 |
| lifeless | stub: thanks heaps; I'll write this up somewhere. How would you feel if I encourage people to start exercising this ? | 09:08 |
| stub | lifeless: New tables we can do with the existing infrastructure for process and staging. And if the patch is suitable to be applied live, I can do so. I'll need to do it manually, but I don't see any risk on the db side. | 09:08 |
| poolie | spiv i can't see where it gets one from | 09:09 |
| lifeless | stub: do you think the additional work will be a burden ? | 09:09 |
| lifeless | stub: (work for you I mean) | 09:09 |
| stub | We can start now, sure. I'm not sure how popular it will be - suck it and see I guess. | 09:09 |
| poolie | maybe as a side effect of psycopg2 or something? | 09:09 |
| lifeless | stub: cool, thanks! | 09:09 |
| spiv | poolie: possibly something like that :/ | 09:10 |
| lifeless | poolie: +1 | 09:12 |
| poolie | lifeless: to which bit? the patch? | 09:13 |
| lifeless | yes | 09:13 |
| * poolie is glad he bought a new desktop cpu/mb :) | 09:13 | |
| mrevell | Good morning | 09:15 |
| stub | lifeless: So do we want a short term 'I'm busy' system? If the appserver is in read-only mode, all requests pop up a 'I'm busy. This page will automatically reload in 60 seconds' screen. This could give us some agility for, say, <5 min db outages without annoying users too much (for some values of 'too much'). | 09:15 |
| lifeless | stub: that sounds like an improvement on the current read-only thing regardless | 09:16 |
| poolie | why auto reload? | 09:16 |
| stub | So people can walk away, have a coffee, and their posts have been completed when they get back with no need for retyping. | 09:17 |
| lifeless | except for POSTs | 09:17 |
| lifeless | :) | 09:17 |
| stub | It would need to cope with POSTs. I'm not sure of the JS magic required. | 09:18 |
| lifeless | coping with POSTs will run into browser issues | 09:19 |
| lifeless | an interaction between the HTTP spec for POST, and browser security - I | 09:20 |
| wgrant | stub: Hi. | 09:20 |
| lifeless | 'm fairly sure it would be a path to pain | 09:20 |
| stub | yo | 09:22 |
| stub | If it doesn't cope with posts, then there is no improvement. GET requests already work just fine in read-only mode. | 09:23 |
| wgrant | stub: Could you please EXPLAIN ANALYZE http://paste.ubuntu.com/475767/ on a production slave? | 09:24 |
| lifeless | gotcha | 09:24 |
| stub | I think we already do something similar for OpenID - not sure. | 09:24 |
| stub | wgrant: http://paste.ubuntu.com/475813/ | 09:25 |
| wgrant | stub: Eeexcellent. Thanks. | 09:25 |
| bigjools | lifeless: helleau | 09:25 |
| lifeless | bigjools: hiya | 09:25 |
| bigjools | lifeless: a new storm seems to be in our sourcecode, which is nice, coz it's got some improvements we should be using. Thought you might like to be aware :) | 09:26 |
| lifeless | bigjools: I'm trying to find the code that runs to generate the table of packages on ppa/+packages | 09:26 |
| lifeless | bigjools: any tips? | 09:26 |
| bigjools | I'm going to go on a rampage to remove unnecessary .count() with .any() | 09:26 |
| bigjools | s/remove/replace/ | 09:27 |
| bigjools | since the latter now strips ordering | 09:27 |
| * noodles775 looks | 09:27 | |
| lifeless | bigjools: thanks for highlighting that; as it happens I knew because I let deryck know he needed it to land his branch - his branch was how we found the bug with the storm cache that is fixed in 0.17 | 09:27 |
| bigjools | and bool() on SQLObjResultSet now works | 09:27 |
| bigjools | \o/ | 09:27 |
| stub | wgrant: That might start performing bad when there are a large number of unfinished jobs | 09:27 |
| stub | wgrant: I think we can make an index to cope if that happens | 09:27 |
| wgrant | stub: There are already lots with date_finished NULL. | 09:27 |
| bigjools | lifeless: yeah +packages can get slow. | 09:28 |
| lifeless | bigjools: right, I'm pulling on it - it goes up by 4 queries per package, more or less | 09:28 |
| lifeless | bigjools: but having trouble figuring out what damn methods run :) | 09:28 |
| noodles775 | lifeless: is it the source-package-list macro that you're looking for (in archive-macros.pt), which uses the view's batched_sources property? | 09:30 |
| lifeless | noodles775: no, its down at the model layer | 09:30 |
| lifeless | I navigated the templates ok with a little elbow grease | 09:30 |
| stub | wgrant: (((status <> 1) OR (date_finished IS NOT NULL)) AND (status = 2)) | 09:30 |
| stub | wgrant: Doesn't that just simplify to 'status=2' ? | 09:31 |
| stub | Or am I lacking coffee again? | 09:31 |
| wgrant | stub: It does, yes. | 09:34 |
| wgrant | But fixing that requires a bit more of a rework. | 09:34 |
| poolie | lifeless (if any): i think flags-webapp is good now, can you try it again? | 09:34 |
| noodles775 | lifeless: so you've been through the ArchiveSourcePublications iterator that's used by the batched_sources property then? Hrm. ok. | 09:34 |
| wgrant | There's duplicated code and string-based query construction everywhere. I plan to rewrite it. | 09:34 |
| stub | Cool. If we can simplify that sort of thing, we can improve things with more specialized indexes if needed. | 09:35 |
| lifeless | poolie: try again ? If you mean land it - no, I can't - we're frozen for non-rc till, I think, friday | 09:35 |
| lifeless | noodles775: I'm currently looking for getBuildSummaryStatus | 09:35 |
| lifeless | poolie: I can do a test-only run, but that should be precisely equivalent to what you just did | 09:36 |
| lifeless | noodles775: I found what I needed - ArchiveSourcePublication in the adapters | 09:36 |
| noodles775 | Great. | 09:36 |
| lifeless | ok, so it causes 2 of those per-row queries itself | 09:41 |
| lifeless | and man is it indirect, how many getUtility things? | 09:42 |
| lifeless | I'll unravel it a bit tomorrow. Objects are great. | 09:42 |
| bigjools | lifeless: dude, you can't RC approve your own branches! | 09:45 |
| StevenK | Teehee | 09:45 |
| StevenK | That's cheating | 09:45 |
| thumper | heh | 09:47 |
| bigjools | thumper: did you see my comment on the bug you marked qa-untestable? | 09:49 |
| thumper | yes | 09:49 |
| thumper | but I didn't see how that tested it | 09:49 |
| thumper | it didn't start | 09:49 |
| thumper | and staging was down | 09:49 |
| bigjools | the problem was in the creation - as soon as you hit the button it oopsed | 09:49 |
| bigjools | it didn't need to start building | 09:49 |
| thumper | I didn't think so | 09:50 |
| thumper | I thought it was the fact that it could have a date finished, but not a date started | 09:51 |
| thumper | that is what the branch fixed | 09:51 |
| bigjools | hmmm actually, I might be mistaken | 09:51 |
| lifeless | bigjools: can't rc-review, can rc-approve ;) | 09:51 |
| bigjools | lifeless: dude, no! | 09:52 |
| bigjools | not if it's your own branch | 09:52 |
| lifeless | no? my bad then; where are the docs, I'll get the policy straight for future | 09:52 |
| lifeless | rc analysis seems to be totally separate from code review to me | 09:53 |
| bigjools | in this case it's fine I would have said it was ok, but generally it's frowned on | 09:53 |
| thumper | lifeless: but you can't rc analyse your own | 09:53 |
| lifeless | thumper: *why not* | 09:53 |
| lifeless | its not like code review | 09:53 |
| thumper | why can't you review your own code? | 09:53 |
| thumper | yeah, it is | 09:53 |
| lifeless | no, its not | 09:53 |
| thumper | in this regard it is | 09:53 |
| lifeless | *why* | 09:53 |
| thumper | judgement is skewed when looking at your own stuff | 09:54 |
| bigjools | conflict of interest | 09:54 |
| thumper | that is why we have other people look at things | 09:54 |
| lifeless | thats a very adversarial way of thinking about both code review and release-critical assessement | 09:55 |
| bigjools | if it's a genuine RC you won't have any problems getting it in | 09:55 |
| bigjools | there is no rush at this stage | 09:55 |
| lifeless | huh? I think you've just segued to a different concern | 09:56 |
| bigjools | I would not think of doing a branch, getting someone to review it, and then landing it with my own RC | 09:56 |
| bigjools | not really, I'm pointing out that you had plenty of time to get approval from someone else | 09:56 |
| lifeless | I didn't think about time-till-release at all in doing this | 09:57 |
| bigjools | the new approval process says that TLs must get approval from Francis or other TLs | 09:57 |
| lifeless | what new approval process? Only one that I recall was db-query approvals wasn't it? | 09:58 |
| bigjools | all out of band prod changes | 09:58 |
| lifeless | which was (francis, stub, me: can approve anything, TL's can approve each other) | 09:58 |
| bigjools | and you can't approve your own stuff | 09:59 |
| lifeless | taking a step back, I can see you feel I didn't something totally wrong | 09:59 |
| lifeless | and I don't want to be doing that | 09:59 |
| lifeless | however I don't *understand* the assertion you are making | 10:00 |
| lifeless | so I want to drill into that | 10:00 |
| bigjools | it boils down to the fact that we don't like unilateral changes and rc analysing your own code is a potential recipe for problems. | 10:01 |
| lifeless | so there are two things there that concern | 10:02 |
| bigjools | you're the first person I know who's RCed his own branch :) | 10:02 |
| lifeless | what risks do you see in assessing a branch for rc status at this stage, and how are they affected by who wrote the branch vs who assesses it. | 10:03 |
| bigjools | it's the same principle as reviewing your own code, you *will* miss problems that other people see | 10:04 |
| lifeless | I object to it being the same principle | 10:04 |
| lifeless | I don't think its even vaguely similar | 10:04 |
| bigjools | 2 of us disagree with you so far | 10:04 |
| bigjools | anyway I don't want to argue with you about this, perhaps you'd like to raise it in tomorrow's TL call | 10:05 |
| lifeless | You've both asserted a cultural norm, not made any attempt to expand other than to say 'judgment is in question' | 10:05 |
| lifeless | I'm going to read up the process etc | 10:06 |
| lifeless | and get well across that | 10:06 |
| lifeless | I'll probably send it to the list, I think the more intellects assessing this the better | 10:06 |
| thumper | I think it is a matter of culture and policy rather than us saying "in this particular respect" | 10:06 |
| bigjools | I am not asserting a cultural norm, I am telling you that it's the same as reviewing your own code | 10:06 |
| lifeless | bigjools: And I'm disagreeing with the assertion that it is the same. | 10:06 |
| thumper | but I agree with bigjools and the "same as reviewing your own code" | 10:06 |
| thumper | two to one, we win | 10:07 |
| * thumper leaves | 10:07 | |
| bigjools | lol | 10:07 |
| lifeless | rc analysis is about risk assessment: chance of throwing out the release vs delaying the fix for a separate QA round | 10:07 |
| lifeless | code review is about making the code better, understanding if its clear enough for another person to understand it and maintain it | 10:07 |
| bigjools | lifeless: in that case, why don't we let all developers RC their own branches? | 10:09 |
| bigjools | what makes you special? | 10:10 |
| lifeless | because RC assessment is delegated to the rotating RM, plus jml me & flacoste, AIUI | 10:10 |
| bigjools | ah, so it's by convention | 10:10 |
| lifeless | yes | 10:10 |
| bigjools | or should I say "culture and policy" | 10:10 |
| bigjools | which is what you were arguing against earlier | 10:11 |
| lifeless | I didn't argue against it, I said I seem to have violated a cultural norm | 10:11 |
| lifeless | that in itself doesn't mean its good or bad | 10:11 |
| lifeless | just different | 10:11 |
| lifeless | and | 10:11 |
| lifeless | Would I be happy with every developer being able to make an RC assessment? Actually, I think I would. | 10:12 |
| lifeless | however, entirely separately, I must apologise for doing *any* RC approvals | 10:13 |
| lifeless | according to https://dev.launchpad.net/PolicyAndProcess/ReleaseManagerRotation its not delegated to *anyone* except the RM | 10:13 |
| lifeless | I'd like to understand why | 10:13 |
| lifeless | (because it doesn't fit what I've observed happening here in the not-very-distant-before-I-became-TA-past | 10:13 |
| lifeless | bigjools: I shall however follow it now that I've reread it and raise it for reevaluation | 10:14 |
| bigjools | lifeless: usually the RM and Francis dole out RCs, because they are best placed to see the bigger picture | 10:15 |
| lifeless | bigjools: and this makes sense to me, and was why I felt comfortable both handing out one the other day (though I put a caveat saying 'If I can' - which you and the other people on the MP seemed to think was appropiate) | 10:16 |
| lifeless | - and handing out one today, because I have been doing little but watching the bigger picture | 10:16 |
| bigjools | lifeless: as long as it's not your own branch I don't mind, but the RM should know about it regardless | 10:16 |
| lifeless | bigjools: of course - note that the one I did of mine I had you as an explicit rc-review requested | 10:17 |
| lifeless | so that you would | 10:17 |
| bigjools | which was good :) | 10:17 |
| lifeless | so concretely, you're happy that that particular branch was rc worthy, you're happy that you were in the loop, you're unhappy that I made that assessment *and* wrote the code. | 10:18 |
| bigjools | I think it would be safe to say that most if not all of us would be uncomfortable with people giving RCs on their own code. | 10:25 |
| lifeless | why? Given what RC /means/ | 10:26 |
| thumper | lifeless: the whole point is to have more than one set of eyes on the problem | 10:27 |
| lifeless | thumper: not all problems are equal. Perhaps a definition of RC would help. | 10:27 |
| lifeless | 'worth adding to the QA queue while the trunk is frozen' | 10:27 |
| lifeless | thats it. Thats /all/ that rc means. | 10:27 |
| bigjools | no, that's completely incorrect | 10:29 |
| lifeless | ok. | 10:29 |
| lifeless | please help me understand, because thats what the process documentation says it is | 10:29 |
| bigjools | RC means we need to land something that is either fixing a critical breakage if we release with it, or adding something that is business critical | 10:30 |
| lifeless | I think you have conflated two concepts: why we rc-approve, and what rc-approve *implies* | 10:30 |
| lifeless | we rc-approve to fix critical breakage or address a business critical concern | 10:30 |
| lifeless | rc approval *implies* that we'll have more QA coming in rather than just reducing the QA so that the release can happen | 10:31 |
| lifeless | reasons *why* we do something are motivation. The impact and effect of doing it are risk and rewards. | 10:32 |
| lifeless | assessing whether something should be rc approved is balancing the why - the desired reward - against the risk and the expected actual reward | 10:32 |
| bigjools | yes, but the motivations to do it are as I stated. The person giving RC needs to assess how risky the change is. | 10:33 |
| bigjools | and now, I am done talking about this. | 10:33 |
| lifeless | ok | 10:34 |
| lifeless | its annoying how chromiums search box is on top of the moin search box on the wiki | 10:34 |
| lifeless | gnight y'all | 10:56 |
| * thumper throws in the towel | 10:56 | |
| bigjools | see y'all | 10:58 |
| deryck | Morning, all. | 11:58 |
| jtv1 | Yay! staging is back. Let's Q/A, people! | 12:57 |
| === jtv1 is now known as jtv | ||
| wgrant | Finally! | 12:58 |
| wgrant | Of course that doesn't mean the code isn't ancient. | 13:00 |
| === matsubara-afk is now known as matsubara | ||
| === Ursinha-afk is now known as Ursinha | ||
| wgrant | OOPS-1683S339 | 13:14 |
| wgrant | Can I have a statement log for that? | 13:14 |
| wgrant | It's really quick now. I guess I could just blame a cold cache. | 13:16 |
| jelmer | wgrant: Did somebody get the statement log for you for that OOPS yet? | 13:33 |
| wgrant | jelmer: Not as yet. | 13:34 |
| wgrant | OOPS-1683S348 also concerns me, and is still happening. | 13:35 |
| wgrant | (I'm trying to QA one of my revs) | 13:36 |
| jelmer | wgrant: I'll get them to you in a sec. | 13:38 |
| wgrant | jelmer: Thanks. | 13:38 |
| bigjools | stub: still around? I have problems with the PG 8.4 upgrade | 13:40 |
| stub | wazzup? | 13:40 |
| bigjools | stub: I installed the 8.4 packages, did the config changes then ran utilites/launchpad-database-setup | 13:41 |
| bigjools | and I get: | 13:41 |
| bigjools | createuser: could not connect to database postgres: | 13:41 |
| bigjools | after it's done the config change | 13:41 |
| bigjools | the server is running AFAICS | 13:41 |
| stub | There is another error message after the one you quoted (the reason it couldn't connect) | 13:41 |
| bigjools | could not connect to server: No such file or directory | 13:42 |
| stub | That makes it sound like it isn't running. You shut it down, edited the configs, restarted yes? | 13:42 |
| bigjools | /var/run/postgresql/.s.PGSQL.5432 is not there, but /var/run/postgresql/.s.PGSQL.5433 is | 13:42 |
| bigjools | yep | 13:42 |
| bigjools | your port instructions on the wiki page conflict with the ones in that email BTW | 13:43 |
| stub | So look in /var/log/postgresql/postgresql-8.4-main.log - should be an error message in there saying why it isn't running. | 13:43 |
| bigjools | it's running ok | 13:44 |
| bigjools | just using port 5433 from the looks of it | 13:44 |
| bigjools | but the client expects 5422 | 13:44 |
| stub | Yes, which is why we edited the config files to make 8.4 listen on 5432 | 13:44 |
| bigjools | gar | 13:45 |
| bigjools | missed that bit :( | 13:45 |
| stub | ;) | 13:45 |
| bigjools | https://dev.launchpad.net/DatabaseSetup needs updating then | 13:46 |
| bigjools | it says to change 5432 into 5433 | 13:46 |
| bigjools | stub: aha, I see what's going on | 13:47 |
| bigjools | launchpad-database-setup is changing the port to 5433 | 13:47 |
| stub | bigjools: Look closer - that section is about upgrading, so matches my email (edit pg8.3's config to use a different port, so 8.4 can use 5432) | 13:48 |
| bigjools | so I hadn't missed it :) | 13:48 |
| bigjools | ah ok | 13:48 |
| bigjools | launchpad-database-setup is buggering things up though | 13:49 |
| stub | So the wiki page documents reconfiguring the old version before the installing the new packages, and my email documents reconfiguring after installing the new packages. | 13:49 |
| stub | Dunno why launchpad-database-setup would be doing that :-P | 13:49 |
| jelmer | maxb, ping | 13:50 |
| maxb | jelmer: pong, but about to disappear for lunch | 13:50 |
| stub | bigjools: Did you edit your 8.3 postgresql.conf too? | 13:50 |
| maxb | oh, was just replying to bigjools email | 13:50 |
| jelmer | maxb: ah, ok | 13:50 |
| stub | bigjools: And bounce 8.3 per the email? | 13:50 |
| jelmer | maxb: I was just wondering if you might be able to have a look at my open meta-lp-deps reviews | 13:50 |
| bigjools | stub: yes, I took it down | 13:50 |
| bigjools | entirely | 13:51 |
| stub | And the config has been edited to say port=5433 ? | 13:51 |
| jelmer | maxb: in preparation of uploading a new version of meta-lp-deps, but from what I read now that process already seems to be in motion.. | 13:51 |
| stub | bigjools: The 8.3 config I mean | 13:51 |
| bigjools | stub: no, I left it alone since I didn't intend to start it up (I wanted to purge the configs but the package dependencies foiled me) | 13:51 |
| stub | Because it looks like launchpad-database-setup rebuilds the 8.4 cluster, and if the postgresql tools see another database configured to use a port it will choose another. | 13:52 |
| bigjools | yay :/ | 13:52 |
| maxb | jelmer: I'll look. AFAIK the current blocker is unresolved questions about what to do w.r.t. pocket-lint and rabbitmq on hardy | 13:52 |
| * maxb gone | 13:52 | |
| jelmer | maxb: pocket-lint should no longer be an issue (we've uploaded a package for hardy), not sure about rabbitmq | 13:52 |
| maxb | bigjools: Are you all settled on pg8.4 now? | 14:09 |
| bigjools | maxb: I am :) | 14:10 |
| bigjools | 8.3 and configs is history | 14:10 |
| wgrant | When's production moving to Lucid? | 14:10 |
| bigjools | RSN | 14:10 |
| maxb | What's the ordering here? => pg 8.4, then later => Lucid? | 14:10 |
| maxb | jelmer: you saw my needsinfo review of https://code.edge.launchpad.net/~jelmer/meta-lp-deps/chardet-dep/+merge/31260, right? | 14:11 |
| jelmer | maxb: Yep, thanks | 14:11 |
| maxb | Also, in the spirit of Robert's email, I should point out that no one has said I can review meta-lp-deps merges. Though in this case I _know_ that the process is that there is no defined process. | 14:12 |
| jelmer | maxb: That's a good point. You had been doing reviews (and are the registrant of lp:meta-lp-deps) so I assumed that was the proper procedure. | 14:14 |
| maxb | https://dev.launchpad.net/LaunchpadPpa says "Exercise personal judgment on whether your change merits a merge proposal, or is sufficiently trivial to just be committed directly." -- and I wrote that | 14:15 |
| jelmer | maxb: That doesn't say anything about who should do the review :-) | 14:17 |
| maxb | That seemed in keeping with the fact that I wasn't given any requirements to seek review of any kind when I was issued with ~launchpad/+archive/ppa upload permissions | 14:17 |
| wgrant | It doesn't even say there should be a review, just an MP :P | 14:17 |
| jelmer | maxb: Anyway, these changes are quite simple but I would prefer if somebody else could give them a quick glance regardless. There are two MPs left. | 14:18 |
| jelmer | wgrant: Well, a proposal implies that there is going to be acceptance or a declination somehow. | 14:19 |
| henninge | danilos, jtv: POTMsgSet.submitSuggestion does not sanitize translations. Is that intended? | 14:22 |
| * henninge vaguely remembers something like that. | 14:22 | |
| danilos | henninge, what does "sanitize" translations mean? calling old "sanitizeTranslations"? :) | 14:23 |
| jtv | henninge: for setCurrentTranslation it was a documented assumption, but I don't think we discussed it for this one. | 14:23 |
| henninge | danilos: No, calling the new code. | 14:23 |
| danilos | henninge, oh, right, we've split that out already, right? | 14:23 |
| danilos | henninge, jtv: I don't think it should sanitize input | 14:24 |
| henninge | danilos: yes, I did that in a hotel room in Recife ;-) | 14:24 |
| danilos | henninge, jtv: it's something that callsites should do | 14:24 |
| danilos | henninge, when it was four of us squeezing together? oh yes, I remember | 14:24 |
| henninge | danilos: ok, so in tests I should make sure to pass sanitized input. | 14:24 |
| danilos | henninge, put that into a factory method ;) | 14:24 |
| jtv | The problem IIRC was that "sanitized" was actually relative to the input medium—different de-indentation requirements for browser and import, etc. | 14:25 |
| danilos | henninge, or simply into translations test helpers | 14:25 |
| danilos | jtv, exactly | 14:25 |
| jtv | Then, there's validation. | 14:25 |
| danilos | jtv, also, we store invalid translations as suggestions as well | 14:25 |
| danilos | :) | 14:25 |
| jtv | But we don't make them current, right? | 14:25 |
| jtv | Although that can still happen if a template update adds a flag, I guess. | 14:26 |
| danilos | jtv, yeah, that's an old bug | 14:28 |
| danilos | jtv, but unrelated to this :) | 14:28 |
| jtv | just saying :) | 14:28 |
| * bigjools -> lunch | 14:28 | |
| abentley | bigjools, jelmer: Does soyuz.browser.build.CompleteBuild serve any purpose nowadays? AFAICT, we don't use its self._buildqueue_record attribute at all. | 14:39 |
| jelmer | abentley: I'm not sure, I | 14:41 |
| jelmer | 'm not very familiar with that class. | 14:41 |
| jelmer | noodles775: Do you happen to know perhaps? | 14:41 |
| maxb | https://code.edge.launchpad.net/~maxb/meta-lp-deps/pg8.4/+merge/32200 <-- if someone has a moment | 14:46 |
| noodles775 | abentley, jelmer: It's caching the buildqueue_record with the batched builds, and seems to be used in soyuz/templates/builds-list.pt:96? | 14:47 |
| jelmer | maxb: Reviewing | 14:48 |
| abentley | noodles775, ah. I missed that buildqueue_record method. (Which surely ought to be a property?) | 14:48 |
| noodles775 | Looks like it certainly should, but zope templates apparently don't care. | 14:49 |
| abentley | noodles775, it was causing me grief because it delegates to IBinaryPackageBuild, but setupCompleteBuilds was wrapping it onto SourcePackageRecipeBuilds. | 14:51 |
| maxb | Who is the best person to ask to push for getting the launchpad ppa / hardy / rabbitmq situation resolved? Basically it needs packages copying from the internal "cat" archive | 14:52 |
| abentley | maxb, copied *to* the cat archive? | 14:52 |
| maxb | *from* | 14:52 |
| abentley | maxb, to what? | 14:52 |
| maxb | to the public launchpad PPA - the problem is that launchpad-dependencies depends on rabbitmq, which is satisfied via the cat archive, but makes launchpad-dependencies uninstallable unless you have access to cat | 14:53 |
| abentley | maxb, I assume you mean on older distros, because I don't use the cat archive and I have launchpad-dependencies installed. | 14:55 |
| maxb | Correct, this is only an issue on hardy | 14:55 |
| abentley | maxb, elmo is the usual guardian of that archive. mars might also be interested. | 14:55 |
| mars | maxb, I can file an RT for you. It is rabbitmq for hardy, right? Do we still support hardy in the PPA? I thought we skipped to the next LTS? | 14:58 |
| maxb | I believe there's an email from flacoste stating that we ought to support what production is running in the PPA | 14:59 |
| jelmer | maxb: FWIW the landscape folks have a backport of rabbitmq to hardy in their PPA. | 14:59 |
| maxb | lifeless asked mthaddon about this on launchpad-dev@, but the thread died | 14:59 |
| mthaddon | maxb: the request has been filed, we're just working on other stuff (based on priorities that we've agreed with the LP devs) | 15:00 |
| mars | mthaddon is usually swamped, and rarely checks mail unless it is an RT | 15:00 |
| mthaddon | iow, it should get done at some magical time in the future when we have time to do it :) | 15:00 |
| maxb | mthaddon: ok. That bit of info didn't make it into the public dev list :-) | 15:00 |
| maxb | Meanwhile, we can't/shouldn't update the launchpad-dependencies version in hardy in the PPA, unless we make a hardy branch that omits rabbit | 15:02 |
| salgado | sinzui, do you know what external services/scripts use xmlrpc.launchpad.net? | 15:23 |
| sinzui | salgado, I do not | 15:24 |
| salgado | flacoste, do you? (^) | 15:24 |
| james_w | salgado: bazaar at least | 15:24 |
| salgado | yeah, I thought bazaar would be one of its users. I'm trying to find all of its users to see if we'd need it for vostok, in order to make sure https://code.edge.launchpad.net/~salgado/launchpad/layer-specific-navigation/+merge/32124 is not going to be a problem for us | 15:27 |
| salgado | james_w, btw, it'd be great if you could have a look at the cover letter there and tell me what you think | 15:27 |
| jml | salgado, maybe your best bet is to ask a losa for the logs? | 15:28 |
| salgado | indeed, that should work. thanks jml | 15:28 |
| james_w | salgado: I think that if we do want xmlrpc to support any existing clients then we likely won't need to change the navigation | 15:30 |
| james_w | salgado: would it be feasible to have a vostokxmlrpc layer if we needed?# | 15:31 |
| salgado | I think so | 15:32 |
| === deryck is now known as deryck[lunch] | ||
| jml | salgado, how do I look at the apidocs? | 16:18 |
| salgado | jml, apidocs.launchpad.dev | 16:18 |
| jml | salgado, and that starts from "make run"? | 16:18 |
| salgado | yep | 16:19 |
| jml | is there a way to do a static build of them? | 16:19 |
| salgado | jml, yes, gary has one at https://devpad.canonical.com/~gary/apidoc.launchpad.dev/++apidoc++/static.html | 16:19 |
| jml | salgado, do you know how to make one of those? | 16:20 |
| jml | hmm. it looks much better from the live site. | 16:22 |
| salgado | jml, I think gary pointed something like wget at apidocs.lp.dev/static.html to generate that | 16:22 |
| jml | heh, although clicking "Book" makes an oops. | 16:22 |
| jml | salgado, ok, thanks. | 16:23 |
| james_w | do I need to do anything special to do LFA.read() in the testsuite? | 16:25 |
| jml | james_w, maybe be in the librarian layer? | 16:25 |
| jml | (I honestly have no clue) | 16:25 |
| james_w | It appears to be a problem with something about http_proxy, which is then masked in to an error "raise LookupError, aliasID" | 16:25 |
| james_w | jml: yep, already hit that one | 16:25 |
| jml | james_w, perhaps you could find out what PGPSignatureNotPreserved in test_uploadprocessor does and copy that | 16:26 |
| james_w | jml: doesn't seem to do anything special. I suspect an environment issue. | 16:28 |
| jml | james_w, good luck with that. sorry I couldn't help more. | 16:29 |
| * jml goes to purchase some consolation chocolate | 16:29 | |
| === salgado is now known as salgado-lunch | ||
| maxb | jelmer: Don't forget to 'bzr mark-uploaded' and push | 16:40 |
| leonardr | up-to-date launchpad branch is getting deprecation warning from bzrplugins/builder ("please use 'debian' instead of 'debian_bundle'). anyone know what's up? | 16:42 |
| === Ursinha is now known as Ursinha-afk | ||
| maxb | leonardr: I'll guess that that's been triggered by upgrading to the newer python-debian in the launchpad ppa | 16:50 |
| james_w | hmm, no it's nothing to do with http_proxy it seems. It seems like the librarian just doesn't have the file. Maybe there is a commit missing somewhere or something | 16:51 |
| bigjools | james_w: you need to commit | 16:51 |
| bigjools | or it doesn't write the file | 16:51 |
| * bigjools thinks commits are evil in tests :( | 16:52 | |
| james_w | thanks bigjools | 16:55 |
| === deryck[lunch] is now known as deryck | ||
| === Ursinha-afk is now known as Ursinha | ||
| leonardr | salgado, when i integrate the version of lazr.restful with your change into launchpad i get some test failures. can you take al ook? | 17:09 |
| === beuno is now known as beuno-lunch | ||
| === salgado-lunch is now known as salgado | ||
| salgado | leonardr, sure, send them my way | 17:21 |
| === bigjools changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 4 of 10.08, Release Manager: bigjools | PQM is release-critical | firefighting: - | buildbot/pqm has been switched to watching the *lucid* builders | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | ||
| leonardr | salgado, http://paste.ubuntu.com/476022/ | 17:24 |
| leonardr | any clues? | 17:24 |
| * salgado checks | 17:26 | |
| salgado | leonardr, is that the only failure you got? | 17:27 |
| leonardr | salgado: there were a bunch of failures afterward but they were all caused by spec not being defined | 17:27 |
| salgado | leonardr, right, so only this test failed, then? | 17:28 |
| leonardr | salgado: there was also a failure in cache.txt but i don't think that was your fault | 17:28 |
| salgado | leonardr, apparently that's a bug which is only exposed when we export an entry with no fields/operations. I should be able to get it fixed quickly | 17:32 |
| leonardr | salgado: lazr.restful bug? ok | 17:32 |
| salgado | yes | 17:32 |
| salgado | leonardr, got http://paste.ubuntu.com/476025/ when running buildout on a new lazr.restful branch. any idea why? | 17:37 |
| leonardr | salgado: yeah, benji changed buildout to disallow 'picked' versions of the dependencies. they have to be explicitly named in versions.cfg | 17:38 |
| leonardr | i must have had that one installed globally or something, so i missed it | 17:39 |
| leonardr | add distributed = 0.6.14 to versions.cfg in the appropriate place and rerun | 17:39 |
| === beuno-lunch is now known as beuno | ||
| salgado | leonardr, I'm seeing a failure on webservice-declarations.txt on trunk. is that known? | 18:26 |
| salgado | leonardr, and http://paste.ubuntu.com/476043/ has a fix for the problem you encountered when running LP's test suite | 18:28 |
| === matsubara is now known as matsubara-lunch | ||
| mars | rockstar, ping, Tarmac question for you | 18:40 |
| rockstar | mars, pong. Also, #tarmac if I'm not around. | 18:41 |
| mars | oh, cool | 18:41 |
| rockstar | Er, if I'm ever not around. | 18:41 |
| leonardr | salgado: give me the test failure? | 18:43 |
| salgado | leonardr, http://paste.ubuntu.com/476065/ | 19:19 |
| salgado | leonardr, does the fix look ok to you? would you like me to create a merge-proposal for it? | 19:20 |
| jml | o/` Mammal, mammal. Their names are called, they raise a paw, the bat, the cat, dolphin and dog, koala bear and hog! o/` | 19:21 |
| leonardr | salgado, i think start should really be 0, so i don't know what's up | 19:22 |
| salgado | leonardr, doesn't it fail for you on a trunk branch? | 19:23 |
| leonardr | i don't think so, let me try | 19:23 |
| leonardr | salgado: no, i get no failures | 19:24 |
| leonardr | you are at revno 137? | 19:25 |
| salgado | yes, 137. using python2.6 | 19:26 |
| leonardr | weird | 19:29 |
| === matsubara-lunch is now known as matsubara | ||
| * salgado starts a new trunk branch from scratch, just in case | 19:32 | |
| jml | someone might be interested in reviewing https://code.launchpad.net/~jml/launchpad/readme/+merge/32238 | 19:32 |
| jml | (not that I can land it) | 19:32 |
| salgado | leonardr, it doesn't fail on this branch I started from scratch | 19:33 |
| salgado | s/branch/tree | 19:34 |
| jml | flacoste, you might actually be interested ^^ | 19:34 |
| flacoste | jml: reviewed | 19:39 |
| flacoste | jml: not that i have any comments apart awesome! | 19:39 |
| jml | flacoste, thanks. I'll land that first thing Tuesday :) | 19:39 |
| flacoste | jml: that's today or next week? | 19:39 |
| jml | whenever PQM opens. | 19:39 |
| * rockstar heads to lunch | 19:40 | |
| james_w | thanks jml | 20:43 |
| lifeless | matsubara: I'm here | 20:55 |
| === Ursinha is now known as Ursinha-lunch | ||
| === Ursinha-lunch is now known as Ursinha-afk | ||
| rockstar | Is there a way to tell what user I'm logged in as in the tests? I'm pretty sure I have the right permissions to get to these attributes, but for some reason the test is saying no. | 22:12 |
| lifeless | getCurrentInteraction or something | 22:13 |
| lifeless | its the 'interaction' that defines 'who is logged in' | 22:13 |
| lifeless | look in lp.testing._login | 22:14 |
| rockstar | lifeless, great, thanks. | 22:14 |
| mwhudson | there's get_current_principal somewhere in canonical.launchpad.webapp | 22:15 |
| mwhudson | rockstar: there's also getUtility(ILaunchBag).user | 22:16 |
| mwhudson | if the two disagree, confusion can certainly result | 22:16 |
| === matsubara is now known as matsubara-afk | ||
| rockstar | mwhudson, yeah, I had your suggestion, and it seems to not be working. | 22:16 |
| * mwhudson afk | 22:17 | |
| lifeless | grah I remember what I wanted leonardr for | 22:17 |
| lifeless | nope, forgotten again | 22:18 |
| jml | james_w, any time | 22:23 |
| === salgado is now known as salgado-afk | ||
| lifeless | when is the next staging update due ? | 23:05 |
| === Ursinha-afk is now known as Ursinha | ||
| wgrant | lifeless: It looks like one might be in progress now. | 23:13 |
| wgrant | Although it hasn't been trying to update regularly since it returned last night... | 23:13 |
| wgrant | So the break in logging may not be indicative of an in-progress update, but just that someone hasn't switched the cron job on properly. | 23:14 |
| lifeless | losa ping ^ | 23:20 |
| lifeless | nice, edge is looking way better than prod now | 23:22 |
| lifeless | mean 0.37 stddev 0.62 | 23:22 |
| lifeless | mean 0.36 stddev 0.94 | 23:22 |
| lifeless | wow, Public XML-RPC is terrible | 23:23 |
| wgrant | Is that over all requests? | 23:23 |
| lifeless | 8.36 4.48 | 23:23 |
| lifeless | mwhudson ^ | 23:24 |
| wgrant | What's public XML-RPC, except for lp: lookups? | 23:24 |
| lifeless | wgrant: I'm not sure | 23:24 |
| lifeless | but 8 seconds of db time ain't brilliant | 23:24 |
| lifeless | db avg stddev | 23:24 |
| lifeless | 7.49 2.61 | 23:24 |
| wgrant | Ew. | 23:24 |
| lifeless | for that group | 23:24 |
| lifeless | translations are also up there | 23:26 |
| lifeless | 1.42 1.89 | 23:26 |
| lifeless | compared to the overall app | 23:26 |
| lifeless | problem pages | 23:26 |
| lifeless | Archive:+copy-packages | 23:26 |
| lifeless | Archive:+delete-packages | 23:26 |
| lifeless | Archive:+index | 23:26 |
| lifeless | Archive:+packages | 23:26 |
| wgrant | I knew +delete-packages would be up there, but i didn't think it was that bad. | 23:26 |
| wgrant | Also, is there a reason that the OOPS summaries are private? | 23:26 |
| lifeless | BazaarApplication:+index | 23:26 |
| wgrant | Don't they just contain page IDs, not URLs? | 23:26 |
| lifeless | wgrant: they contain urls | 23:26 |
| lifeless | but we can fix | 23:26 |
| wgrant | :( | 23:26 |
| lifeless | please file a bug | 23:26 |
| wgrant | Against what? | 23:26 |
| wgrant | oops-tools? | 23:26 |
| lifeless | yeah | 23:28 |
| lifeless | BranchMergeProposal:+index | 23:29 |
| lifeless | BranchSet:CollectionResource | 23:29 |
| lifeless | BugTask:+create-question is -terrible- | 23:29 |
| lifeless | 11.03 8.97 | 23:29 |
| lifeless | only two hits, but *boy* where they doozies | 23:30 |
| wgrant | I don't know how it's so bad, given that it's normally used on new bugs. | 23:30 |
| lifeless | no, its not | 23:30 |
| lifeless | can't be given the hit count | 23:30 |
| wgrant | Hm. | 23:30 |
| lifeless | BugTask:+distrotask | 23:30 |
| lifeless | BugTask:+editstatus-page | 23:30 |
| wgrant | I've hopefully fixed those. | 23:30 |
| wgrant | Well, that and the heat fix. | 23:30 |
| lifeless | BugTrackerSet:+index wow | 23:31 |
| lifeless | 14.63 5.58 | 23:31 |
| wgrant | It's unbatched and going to be selecting lots of tasks, I guess. | 23:31 |
| lifeless | Builder:+history | 23:31 |
| lifeless | 8.59 2.42 | 23:31 |
| wgrant | It probably needs some prejoining for the new schema. | 23:31 |
| lifeless | Distribution:+addquestion | 23:32 |
| lifeless | thats probably search performance, which is fixed | 23:32 |
| lifeless | Distribution:+archivemirrors | 23:32 |
| lifeless | 7.76 4.18 | 23:32 |
| lifeless | 99% in 19 seconds | 23:32 |
| lifeless | bet you its on the lpnet timeout summary | 23:32 |
| lifeless | Distribution:+assignments | 23:32 |
| lifeless | 15.98 7.77 | 23:33 |
| lifeless | Distribution:+branches 5.44 2.76 | 23:33 |
| lifeless | Distribution:+bugs 3.24 2.98 | 23:33 |
| lifeless | Distribution:+bugtarget-portlet-bugfilters-stats 6.79 1.64 | 23:34 |
| lifeless | Distribution:+bugtarget-portlet-tags-content 6.35 2.00 | 23:34 |
| lifeless | Distribution:+cdmirrors | 23:34 |
| lifeless | Distribution:+filebug - again likely search and thus fixed. | 23:35 |
| lifeless | Distribution:+filebug-show-similar ditto | 23:35 |
| lifeless | Distribution:+patches | 23:35 |
| lifeless | Distribution:+ppas | 23:35 |
| lifeless | Distribution:+questions | 23:36 |
| lifeless | Distribution:+search | 23:36 |
| lifeless | DistributionSourcePackage:+addquestion - again, hopefully fixed | 23:36 |
| lifeless | DistributionSourcePackage:+filebug-show-similar ditto | 23:36 |
| lifeless | DistributionSourcePackage:+questions ditto | 23:37 |
| lifeless | DistroArchSeries:+builds 3.50 4.04 | 23:37 |
| lifeless | DistroArchSeries:+index 2.39 3.10 | 23:37 |
| lifeless | mwhudson: hi | 23:38 |
| lifeless | 10:22 < lifeless> mean 0.36 stddev 0.94 | 23:38 |
| lifeless | 10:23 < lifeless> wow, Public XML-RPC is terrible | 23:38 |
| lifeless | 10:23 < wgrant> Is that over all requests? | 23:38 |
| lifeless | 10:23 < lifeless> 8.36 4.48 | 23:38 |
| lifeless | mwhudson: ^ page performance stats | 23:38 |
| lifeless | DistroSeries:+builds 6.47 4.50 | 23:39 |
| lifeless | DistroSeries:+cve 19.64 0.00 | 23:39 |
| mwhudson | lifeless: got a link? | 23:39 |
| lifeless | https://devpad.canonical.com/~stub/ppr/lpnet/latest-daily-combined.html | 23:39 |
| mwhudson | lifeless: i suspect that's actually private xml-rpc stuff | 23:39 |
| mwhudson | getJobForMachine does a good job of contending with itslef | 23:40 |
| lifeless | DistroSeries:+needs-packaging 12.93 7.63 | 23:40 |
| lifeless | DistroSeries:+templates 18.53 0.73 | 23:40 |
| lifeless | LibraryFileAlias:StreamOrRedirectLibraryFileAliasView 12.45 9.55 | 23:40 |
| mwhudson | yeah, regex for private xml-rpc looks wrong | 23:41 |
| lifeless | MaloneApplication:+bugs 7.09 3.19 | 23:41 |
| lifeless | Person:+editproposedmembers 12.22 6.93 | 23:41 |
| lifeless | its a little worrying how fast I'm getting at eyeballing 99% on this thing | 23:42 |
| lifeless | Person:+patches 17.61 0.00 | 23:42 |
| lifeless | Product:+filebug-show-similar search again | 23:43 |
| lifeless | ProductSet:+project-cloud 6.22 4.31 | 23:43 |
| lifeless | ProjectGroup:+milestones 4.87 5.94 | 23:43 |
| mwhudson | project-cloud _really_ should be in memcache | 23:43 |
| mwhudson | or something | 23:43 |
| lifeless | Question:+confirm 4.87 6.75 | 23:43 |
| lifeless | Question:+edit 6.66 6.87 | 23:44 |
| lifeless | mwhudson: we need the _miss_ time to be subsecond | 23:44 |
| lifeless | mwhudson: after that we can talk caching | 23:44 |
| lifeless | if we need to memoise it to make it subsecond we should do that, but it should be persistent, no ? | 23:44 |
| mwhudson | lifeless: maybe generated daily and stuffed somewhere that the website can access then? | 23:44 |
| mwhudson | doing it 'in-line' in the appserver is fairly bonkers | 23:45 |
| lifeless | mwhudson: agreed | 23:45 |
| lifeless | Question:+makebug 4.61 7.73 - probably search | 23:45 |
| _mup_ | Bug #4: Importing finished po doesn't change progressbar <Launchpad Translations:Fix Released by carlos> <Ubuntu:Invalid> <https://launchpad.net/bugs/4> | 23:45 |
| lifeless | RootObject:+recently-changed-branches 6.68 3.05 | 23:45 |
| lifeless | RootObject:+recently-registered-branches 5.08 2.30 | 23:45 |
| lifeless | TranslationGroup:+index 6.82 5.10 | 23:46 |
| lifeless | -fin- | 23:46 |
| lifeless | we fix those to lower their 99% point, we can lower the timeout some more | 23:46 |
| thumper | lifeless: the branch ones shouldn't be too hard | 23:51 |
| thumper | lifeless: I've not looked at them | 23:51 |
| lifeless | thumper: sure, I'm looking forward now that we've got edge OOPS really under control | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!