[00:00] <lifeless> you want to file the bug, or shall I ?
[00:00] <lifeless> the lower our latency the more often this will happen
[00:04] <james_w> wgrant: all in ec2
[00:05] <lifeless> does anyone else see  lp.registry.windmill.tests.test_person_picker.TesPersonPickerWidget.test_person_picker_widget failing ?
[00:05] <lifeless> WindmillTestClientException: {u'suite_name': u'PersonPickerWidget', u'result': False, u'starttime': u'2010-7-4T10:26:38.547Z', u'params': {u'xpath': u'//div[contains(@class, "yui-picker ") and not(contains(@class, "yui-picker-hidden"))]', u'timeout': u'20000'}, u'output': None, u'endtime': u'2010-7-4T10:26:59.337Z', u'method': u'waits.forElement'}
[00:05] <lifeless> branch is a few days old
[00:24] <thumper> lifeless: running locally or through ec2?
[00:26] <lifeless> local
[00:26] <thumper> I'll try it here
[00:26] <thumper> is it really TesPersonPickerWidget, not Test... ?
[00:27] <lifeless> lp.registry.windmill.tests.test_person_picker.TesPersonPickerWidget.test_person_picker_widget
[00:27] <lifeless> I have a few other failures
[00:28] <lifeless> lp.registry.browser.tests.test_person_view.TestPersonRelatedSoftwareView.test_latest_uploaded_ppa_packages_with_stats
[00:28] <lifeless> lp.registry.browser.tests.test_person_view.TestPersonEditView.test_can_rename_with_deleted_PPA
[00:28] <lifeless> and similar
[00:28] <thumper> lifeless: works for me
[00:29] <lifeless> thanks
[01:14] <wgrant> james_w: Thanks.
[01:14] <wgrant> lifeless: Looks like we can destroy PublishedPackage easily.
[01:15] <lifeless> wgrant: \o/
[01:15] <lifeless> wgrant: Nuke It, Nuke It, Nuke It
[01:15] <wgrant> Particularly if we don't care about create-debwatches.py, which probably doesn't work anyway.
[01:15] <lifeless> what doth that do ?
[01:15] <wgrant> It imports Debian's bugs into LP.
[01:15] <wgrant> But it might be easy enough to port.
[01:16] <wgrant> It's never been used, and is several years old.
[01:16] <lifeless> harh
[01:16] <lifeless> so, does it have tests ?
[01:16] <lifeless> actually let me rephrase.
[01:16] <lifeless> does it have any reason to be in the LP core rather than an API client ?
[01:16] <wgrant> It probably impersonates.
[01:17] <lifeless> ok, so we need impersonation in the API eventually
[01:17] <lifeless> but not now
[01:17] <wgrant> There are no tests that I can see. So I'll just port it and pretend that it works.
[01:17] <lifeless> \o/
[01:17] <lifeless> thank you _very_ much for doing this
[01:18] <wgrant> The other PublishedPackage callsite only needs ~6 of the 13 tables.
[01:18] <lifeless> mars: still up ?
[01:18] <wgrant> So I'll replace it with another method, and drop the view.
[01:18] <wgrant> And hopefully get it landed tonight.
[01:18]  * mwhudson gets ready to run some windmill tests
[01:18] <lifeless> awesome!
[01:18] <mwhudson> i wonder if i can get to the shop and back before they're done
[01:19] <lifeless> mwhudson: 'yes'
[01:21] <mwhudson> i guess everything will time out
[01:26] <lifeless> spm: hey, so, where on your queue is the +icing rollout tweak ?
[01:28] <spm> lifeless: it's not on mine tbh; still working on the next phase of the slony1 roll; getting some LS stuff done; and some 'fit in the cracks' U1 more trivialish scripting stuff. and packing at some point.
[01:28] <lifeless> spm: ok; you're sprinting or something ?
[01:29] <spm> yup all next week
[01:29] <lifeless> cool
[01:29] <lifeless> do you guys deliberately do these on release weeks ?
[01:29] <lifeless> A;)
[01:29] <spm> ha!
[01:30] <spm> the release we did for LP in barcelona last year was ... instructive for the rather large collection of observers and sympathisers I felt.
[01:30] <spm> probably freaked the hotel staff out a tad I'll bet :-)
[01:30] <spm> 15 folks all hanging aournd 2-3 laptops....
[01:31] <lifeless> spm: if you have the opportunity to do the icing thing, and wanted a bribe... well, just let me know :)
[01:33] <mwhudson> yes, my machine is too slow to run the windmill tests
[01:34] <mwhudson> can i get someone to run some tests for me?
[01:34] <lifeless> mwhudson: yes; you could use ec2 though, FWIW
[01:34] <mwhudson> yes, that's true
[01:34] <mwhudson> lifeless: could you get
[01:34] <mwhudson> bzr+ssh://bazaar.launchpad.net/~mwhudson/launchpad/vostok-main-template
[01:34] <mwhudson> and run
[01:34] <mwhudson> lp.code.windmill.tests.test_branchmergeproposal_commitmessage.TestCommitMessage.test_set_commit_message
[01:34] <mwhudson> lp.code.windmill.tests.test_branchmergeproposal_review.TestReviewCommenting.test_merge_proposal_replying
[01:34] <mwhudson> ?
[01:35] <spm> lifeless: we had a brief discussion some weeks back in losa land around some topics we could present at various other team sprints; i'll give you the brief synopsis of each one? it may help with your previous question?
[01:35] <spm> * "Why Cake is Good For Keeping LOSAs Onside" - Well. Dur.
[01:35] <spm> * "Let Them Eat Cake" - a discussion around various types of Cakes enjoyed by the losas, accounting for cultural variations across the team. Mudcakes, Cheesecakes, Pavlova, Poutine Cake etc
[01:35] <spm> * "Haz Cakez, Willz Patchz Youz Servicez" - we are open to bribery to apportion RT priorities more ... appropriately. A look at proposed cake:priority bribe ratios.
[01:35] <spm> * "Not Cake" - a free flowing discussion around other non cake foods - eg brownies, fudge; and how they may be treated as an acceptable substitute when Cake is not as easily forthcoming.
[01:35] <spm> lifeless: ^^
[01:36] <lifeless> rotfl
[01:36] <mwhudson> poutine cake?
[01:36] <lifeless> spm: so, courier, or pickup from the bakery?
[01:36] <spm> we just come back from Montréal, poutine cake seemed appropriate at the time.
[01:36] <lifeless> mwhudson: does it need a make schema ?
[01:36] <mwhudson> lifeless: no
[01:37] <lifeless> :!testr run -- --load-list mwhudson.list
[01:37] <lifeless> please wait ;)
[01:38] <mwhudson> hm, it seems i didn't have the wadl built locally, does that affect using the api over js?
[01:38] <lifeless> ni idea
[01:38] <poolie> speaking of speed, is it really recessary to spend 15s rebuilding js at the start of 'make run'?
[01:39] <lifeless> windmill.server.proxy: INFO     Could not fullfill proxy request to http://www.google.co.nz/+icing/rev10721/MochiKit.js
[01:39] <lifeless>  ?
[01:39] <lifeless> mwhudson: test_results: ERROR    Test Failure in test {'version': '0.1', 'suite_name': u'Commit message editing.', 'result': False, 'starttime': u'2010-7-5T6:8:14.422Z', 'output': None, u'params': {u'xpath': u'//div[@id="edit-commit_message"]//textarea[@class="yui-ieditor-input"][1]', 'uuid': 'b99e4c88-a029-11df-8e6c-5254002410b3'}, 'endtime': u'2010-7-5T6:8:27.487Z', u'method': u'waits.forElement'}
[01:39] <wgrant> mwhudson: It doesn't, AFAIK.
[01:40] <lifeless> id: 197 tests: 22 failures: 1 skips: 1
[01:41] <mwhudson> lifeless: ok thanks
[01:41] <lifeless> mwhudson: that google.co.nz error worries me :)
[01:41] <mwhudson> yes, does look pretty dodgy
[01:42] <mwhudson> lifeless: can you run it in trunk too?
[01:42] <lifeless> mwhudson: what do you mean?
[01:42] <mwhudson> lifeless: does the test fail in trunk for you too?
[01:42] <lifeless> devel or db-devel
[01:43] <mwhudson> lifeless: devel
[01:43] <lifeless> trying
[01:43] <mwhudson> thanks
[01:45] <lifeless> no
[01:45] <lifeless> erm
[01:45] <lifeless> yes
[01:45] <lifeless> yes it fails
[01:45] <mwhudson> :(
[01:51] <mwhudson> well i did what the test does by hand in a real browser and it worked, so...
[01:53] <wgrant> lifeless: Since those two are the same bug (Distribution.guessPackageNames is slow), should I dupe them and move to launchpad-registry?
[01:54] <lifeless> wgrant: sure
[01:54] <lifeless> wgrant: though I would have said it was a soyuz problem :P
[01:54] <wgrant> Although both bugs seem to cover other issues too..
[01:54] <lifeless> wgrant: do what you think makes the most sense.
[01:54] <lifeless> make a third bug even.
[01:54]  * wgrant does so.
[01:57] <wgrant> Oh look, PublishedPackage is now unused.
[01:57]  * wgrant drops.
[01:59] <lifeless> \o/
[02:03] <wgrant> It looks like the view's main user was removed for 3.0.
[02:03] <wgrant> The distribution package listing was eliminated.
[02:03] <lifeless> seeking feedback on https://help.launchpad.net/Oops
[02:05] <mwhudson> lifeless: looks pretty good to me
[02:07] <lifeless> mwhudson: care do to a small review for me? see #lp-r
[02:09] <james_w> mwhudson: if you are having trouble running problematic tests then feel free to drop me an email and I can take a look tomorrow
[02:10] <mwhudson> james_w: i might do that thanks
[02:15] <wgrant> I have a slave query returning an object that gets passed around and eventually dies when some code tries to link it to a master object.
[02:15] <wgrant> Where's the right place to do the IMasterObject adaption?
[02:16] <mwhudson> i think it's basically impossible to say on this much information :-)
[02:17] <mwhudson> i guess in the linking place, maybe?
[02:17] <wgrant> Yeah, but it's a reasonably complex stack, so I decided to omit the messy description.
[02:18] <wgrant> Some Bugs views use Distribution.guessPackageNames to retrieve a sourcepackagename and binarypackagename.
[02:19] <wgrant> I've just moved that query to a slave.
[02:19] <wgrant> Eventually the view calls Bug.addTask with one of those two slave objects.
[02:20] <wgrant> This then tries to create a DistributionSourcePackageInDatabase, which crashes with a WrongStoreError.
[02:21] <mwhudson> wgrant: i guess addTask would be a reasonable place?
[02:23] <wgrant> Ah, hm. The problem is actually when it generates the DistributionSourcePackage (not the DistributionSourcePackageInDatabase). I guess Distribution.getSourcePackage should make sure that its sourcepackagename is from the right store.
[02:24] <wgrant> I wonder if there's an easy way to do that (get an object from the store of another object).
[02:27] <wgrant> Nyeh. i guess I'll just IMasterObject it before I call getSourcePackage.
[02:36] <lifeless> whats an IMO ?
[02:36] <mwhudson> lifeless: it's a thing that lets you ensure that a database object is from the master store
[02:37] <mwhudson> master_object = IMasterObject(master_or_slave_object)
[02:37]  * mwhudson afk briefly
[02:42] <wgrant> Argh
[02:42]  * wgrant stabs canonical.widgets.
[02:43] <wgrant> Nasty code, evading my grep.
[02:53] <spm> wgrant: that sounds suspiciously like the Bad Workman Blaming The Tools???
[02:53] <lifeless> this from a sysadmin?
[02:53] <lifeless> :P
[02:54] <spm> point, veritable good point. 1/0
[03:04] <wgrant> spm: Well, I expect stuff to live in lp.*, or canonical.launchpad.* at worst...
[03:04] <spm> :-)
[03:06] <lifeless> wgrant: bzr-grep ?
[03:06] <wgrant> lifeless: grepping the whole LP tree on a cold cache is slow.
[03:06] <lifeless> wgrant: :<
[03:11] <wgrant> lifeless: Can I have a patch number for the PublishedPackage drop?
[03:13] <mwhudson> wgrant: grepping everything can't be much slower than grepping lib/lp and lib/canonical/launchpad surely?
[03:13] <mwhudson> at least if you use bzr-grep or bzr ls | xargs
[03:13] <mwhudson> grepping all the eggs and sourcecode does take a while
[03:13] <wgrant> mwhudson: Right, eggs and sourcecode takes a while.
[03:13] <wgrant> I should probably install bzr-grep.
[03:15] <lifeless> wgrant: except when stubs on leave, he should be the one handing them out
[03:16] <lifeless> wgrant: it is a little more latency, but I think its better to have no confusion in this area ;)
[03:16] <wgrant> Ah, so a longer-term definition of 'not available' than I thought.
[03:16] <wgrant> OK.
[03:16] <lifeless> well, thats my understanding
[03:16] <wgrant> yeah, you're probably right.
[03:17] <lifeless> I'll check with him that that is our shared understanding, and tweak the wiki page to be clearer one way or another
[03:17] <wgrant> I was just remembering the email from a couple of days ago.
[03:17] <mwhudson> someone could write a webservice to hand out patch numbers!
[03:17]  * mwhudson runs away
[03:17] <lifeless> mwhudson: slap!
[03:18] <lifeless> the lp login pages to the list is really quite entertaining
[03:18] <lifeless> s/lp/sso/
[03:18] <mwhudson> or stub and lifeless could use some kind of distributed voting algorithm
[03:18] <lifeless> we do
[03:18] <lifeless> he votes
[03:18] <lifeless> I don't.
[03:18] <lifeless> see, distributed.
[03:19] <wgrant> lifeless: Which login pages?
[03:19] <mwhudson> wgrant: i typed "bzr ls --versioned --recursive --null --kind file | xargs -0 grep" once and have a super huge bash_history file :-)
[03:19] <wgrant> mwhudson: Heh.
[03:19] <mwhudson> lifeless: :-)
[03:19] <lifeless> wgrant: the thingy ones
[03:19] <lifeless> wgrant: team oops summaries
[03:19] <wgrant> lifeless: Ah.
[03:19] <mwhudson> wgrant: we get oops summaries to the internal mailing list
[03:19] <wgrant> Right.
[03:19] <lifeless> and they are baaaagggered
[03:19] <mwhudson> except for the last couple of days, the bodies of the mails have been openid login pages
[03:19] <wgrant> hahaha.
[03:19] <wgrant> Nice.
[03:20] <mwhudson> i don't even really understand how this is possible
[03:20] <wgrant> It certainly leaves me concerned as to how they are generated...
[03:23] <lifeless> mwhudson: cron. Datacentre. \o/
[03:26] <lifeless> wgrant: the main oops reports work ok, its the team summaries that are being pulled from a web service that are booming
[03:27] <wgrant> mwhudson: I'm guessing you have a PQM rejection for my branch?
[03:27] <wgrant> It probably conflicted with james_w.
[03:27] <wgrant> Yes :(
[03:28] <mwhudson> wgrant: mail.canonical.com is being administered, so i don't have any mail at the moment
[03:28] <wgrant> 'administered'. Nice euphemism.
[03:29] <wgrant> Hm.
[03:29] <wgrant> I wonder if lack of MTA means the three other branches that have just succeeded will fail to submit...
[03:30] <mwhudson> well
[03:30] <mwhudson> at worst they'll just get queued
[03:31] <wgrant> Hopefully.
[03:31] <wgrant> I doubt it, though.
[03:31] <mwhudson> wgrant: it's planned maintenence
[03:31] <wgrant> mwhudson: But doesn't pqm-submit use mail.canonical.com:25, which is currently timing out?
[03:32] <wgrant> Oh, maybe smtp.canonical.com, which works.
[03:32] <mwhudson> yeah
[03:33] <mwhudson> mail.canonical.com:25 gets eaten by the firewall i imagine :-)
[03:45] <lifeless> anyone got a few minutes to point me at a good example of a pyunit browser test ?
[03:55] <spiv> mwhudson: thanks for landing the codebrowse-oops branch!
[03:55] <mwhudson> spiv: np, have you looked at lp-production-configs yet?
[03:55] <spiv> no, I was about to ask about the production config stuff
[03:56] <spiv> I'd be happiest if it was just SEP ;)
[03:56] <lifeless> spiv: mail losas@c.c asking for the config details to use
[03:56] <lifeless> then edit the lp-production-configs branch to make the change, and propose a merge
[03:57] <spiv> lifeless: well, more specifically, I was asking if mwhudson had taken care of that already, as he'd landed the branch
[03:57] <lifeless> spiv: I know that that would make you happiest :)
[03:58] <mwhudson> spiv: i haven't done anything in that regard
[03:59] <lifeless> wgrant: hi
[04:05] <spiv> mwhudson: ok.  I might look into that tomorrow then.
[04:16] <thumper> wasn't there going to be an email outage?
[04:16] <mwhudson> thumper: only if you're an imap user maybe?
[04:18] <wgrant> lifeless: Fail. I forgot to add the DB patch.
[04:18] <lifeless> wgrant: so does my suggestion make sense
[04:18] <lifeless> wgrant: recommit your branch against devel
[04:18] <lifeless> do *just* the db-patch against db-devel
[04:19] <lifeless> and do that after the other branch has landed
[04:19] <wgrant> lifeless: Hm, I suppose, but we freeze in 24 hours so there's no point.
[04:19] <lifeless> wgrant: oh, fair point.
[04:19] <lifeless> anywhich way is good for me
[04:20] <wgrant> lifeless: DB patch pushed.
[04:27] <thumper> StevenK: ping
[04:28] <lifeless> wgrant: url ?
[04:29] <wgrant> lifeless: https://code.edge.launchpad.net/~wgrant/launchpad/destroy-publishedpackage/+merge/31813
[04:38] <lifeless> spm: An updated diff will be available in a few minutes. Reload to see the changes.
[04:38] <lifeless> spm: after 10 minutes...
[04:39] <mwhudson> uhm
[04:39] <mwhudson> is merge-proposal-jobs stuck again?
[04:39] <thumper> I hope not
[04:40] <thumper> it is possible it is a big job...
[04:40] <thumper> maybe
[04:40] <thumper> spm: sync logz plz?
[04:41] <lifeless> thumper: mwhudson: does code have pyunit based browser using tests ?
[04:41] <lifeless> not windmill, the zope mechanise thingy
[04:41] <mwhudson> lifeless: yes
[04:41] <wgrant> zope.testbrowser?
[04:41] <mwhudson> lifeless: grep for getUserBrowser iirc
[04:42] <lifeless> mwhudson: please point me at some as per my plea for help above ;P
[04:42] <wgrant> lp.code.browser.tests looks relevant.
[04:42] <lifeless> mwhudson: thanks
[04:43] <thumper> BrowserTestCase in lp.testing I believe
[04:43]  * thumper is smacking his head against inmemory xmlrpc implementation
[04:44] <spm> thumper: syncing in progress
[04:44] <thumper> spm: ta
[04:49] <thumper> spm: merge proposal jobs is stuck again
[04:49] <thumper> spm: plz kill
[04:49] <spm> killed
[04:50] <spm> logs resynced
[04:51] <thumper> ta
[04:52] <spm> thumper: looks like a couple of bodgy branches from that shyster wgrant again. any chance of you and me flying down to his place and ... trying some attitude adjustment? :-P
[04:52] <wgrant> Heh.
[04:52] <thumper> spm: you book the flights, I'll approve them ;-)
[04:52] <spm> oki, brb. one sec.
[04:53] <spm> wgrant: so that destroy-publisher one was first off - should be good now
[04:53] <wgrant> spm: destroy-publishedpackage? Sounds good.
[04:53] <wgrant> I hope I'm not destroying the publisher itself!
[04:55] <spm> wgrant: destroy-publishedpackage yup. too lazy to select and paste :-)
[04:56] <wgrant> lifeless: diff's there now.
[04:57] <spm> lifeless: fwiw, that's bug https://bugs.launchpad.net/bugs/605772 (tongue firmly in cheek) you may be able to get the priority on a fix raised?
[04:57] <_mup_> Bug #605772: merge-proposal-jobs is "hanging", apparently with nothing to do <canonical-losa-lp> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/605772>
[04:59] <j24> did someone known whereis the admin interface of launchpad?
[04:59] <mwhudson> if that's the same bug as was hanging the branch mirror script once upon a time, it's a complete mystery
[05:00] <spm> j24: it doesn't really have one. some pages have extra features if you have admin access is about it
[05:01] <j24> how can I remove projects?
[05:01] <j24> how can I manage user right?
[05:01] <thumper> j24: set them inactive
[05:02] <thumper> j24: what type of user rights?
[05:02] <j24> thumper: read write acces to projects
[05:02] <spm> create a team; give that team project ownership; add them to the team
[05:02] <thumper> j24: the owner needs to be set to a team that the users are members of
[05:03] <wgrant> j24: Have you used Launchpad before?
[05:03] <j24> never
[05:03] <wgrant> You probably shouldn't be trying to run your own if you haven't.
[05:03] <j24> I'm looking for a solutoin to manage bazar and hear that launchpad will the good one
[05:03] <j24> for now we use redmine
[05:04] <j24> I'm evalluating bazar as a replacement
[05:06] <j24> I'm evalluating launchpad as a replacement
[05:12] <lifeless> spm: asking for a backtrace
[05:12] <j24> patch-2207-51-0.sql has not been applied to the database. You probably want to run 'make schema'.
[05:12] <lifeless> spm: it may help shed light, though the unhandled error is a pretty good hint
[05:12] <spm> lifeless: some more context?
[05:13] <j24> but when I did sudo -u postgres make create
[05:13] <j24> the patch is reported apply
[05:13] <lifeless> spm: 15:57 < spm> lifeless: fwiw, that's bug https://bugs.launchpad.net/bugs/605772 (tongue firmly in cheek) you may be able to get the priority on a fix raised?
[05:13] <_mup_> Bug #605772: merge-proposal-jobs is "hanging", apparently with nothing to do <canonical-losa-lp> <Launchpad Bazaar Integration:Incomplete> <https://launchpad.net/bugs/605772>
[05:13] <j24> any idea?
[05:13] <spm> lifeless: Oh right.
[05:15] <lifeless> j24: well, launchpad is *intended* to be a hosted solution, so the easiest thing you can do use use launchpad.net. However I realise that isn't answer your question, so let me have a guess
[05:16] <lifeless> j24: you appear to be running make create, not make schema.
[05:16] <lifeless> j24: the 'make' targets are meant for developers, not for production rollouts / upgrades
[05:16] <lifeless> j24: so, probably, you need to run 'make schema'
[05:16] <j24> lifeless: I did first
[05:17] <j24> lifeless: but I nned to run the create as postgres
[05:17] <j24> use
[05:17] <j24> r
[05:20] <wgrant> mwhudson: Could you resubmit https://code.edge.launchpad.net/~wgrant/launchpad/per-archive-build-debug-symbols/+merge/29671, please? The conflict is fixed.
[05:21] <j24> lifeless: is ther any easy way to create your own host of launchpad?
[05:22] <wgrant> No.
[05:22] <mwhudson> wgrant: ok
[05:22] <wgrant> mwhudson: Thanks.
[05:24] <lifeless> j24: so, If you have run 'make schema' (*not* make create), as postgres, and you are now running the appserver as a different user, I suspect postgres permissions will be stopping it reading the db properly
[05:27] <lifeless> hmmm, byebye wave
[05:28] <wgrant> lifeless: Well, they don't say it's being shut down.
[05:29] <wgrant> Just that they're ceasing development...
[05:29] <lifeless> they say end of year shutdown
[05:29] <wgrant> Oh?
[05:29] <wgrant> Didn't see that.
[05:29] <j24> lifeless: I've to run make schema as potgress to fix it
[05:29] <j24> lifeless: how can I've a empty database ?
[05:30] <j24> lifeless: no projects
[05:30] <wgrant> lifeless: Ah, there it is.
[05:30] <lifeless> wgrant: its not quite 'turn off', but the option is well implied
[05:30] <wgrant> lifeless: And thanks for the review.
[05:30] <lifeless> wgrant: de nada
[05:45] <wgrant> [A2
[05:46] <lifeless> +1
[05:49] <wgrant> lifeless: Serious WTFery at that link in #launchpad.
[05:50] <wgrant> Looks like the TAL caching being strange...
[05:50] <wgrant> He sees three of one milestone, while I see two of each.
[05:50]  * ajmitch sees nothing wrong
[05:50] <wgrant> ajmitch: Refresh a couple of times.
[05:50] <wgrant> Or it may require the addition of some more.
[05:50] <wgrant> Aha, yes.
[05:51] <wgrant> I initially viewed it when there were only three.
[05:51] <wgrant> Now there are six, and I see the first three repeated twice.
[05:51] <wgrant> He initially viewed it when there was one.
[05:51] <wgrant> Then added two more, and saw three of the first one.
[05:53] <thumper> wgrant: what is the A reference?
[05:54] <wgrant> thumper: Hm?
 [A2
[05:54] <lifeless> so, thats the milestone caching I would like to disable
[05:55] <lifeless> as one of the examples of we're-not-ready-yet memcached use
[05:55] <wgrant> thumper: That was some network lag converting my up arrow (which would normally revive the previous irssi command) into some garbage.
[05:55] <wgrant> Not sure why it does that.
[05:55] <wgrant> lifeless: No, this is a bug.
[05:55] <thumper> ah
[05:56] <wgrant> lifeless: Something's wrong in the caching infrastructure.
[05:56] <lifeless> wgrant: tell me more
[05:58] <wgrant> lifeless: It's using the cache for the wrong object, somehow.
[05:59] <wgrant> Hmm, interesting.
[05:59] <wgrant> Ah, got it.
[06:02] <lifeless> ?
[06:02] <wgrant> Well, not entirely, actually, as it turns out.
[06:03] <wgrant> But the way it handles tal:cache in loops seems a bit odd.
[06:04] <thumper> :(
[06:04] <thumper> grr
[06:04] <wgrant> Hm?
[06:04] <lifeless> I need a another test hint
[06:05] <lifeless> I want to exercise an API
[06:05] <lifeless> is doing a single browser request to the relative URL the OOPS shows sufficient ?
[06:05] <lifeless> e.g. https://api.launchpad.net/beta/~ubuntu-dev/participants
[06:09] <lifeless> or is there a better way ?
[06:09] <lifeless> my goal is:
[06:09] <lifeless>  - exercise the web request that is blowing up
[06:09] <lifeless>  - measure its query count
[06:09] <lifeless>  - fix it
[06:10] <mwhudson> lifeless: there's something called a WebserviceCaller somewhere i think
[06:13] <lifeless> thanks
[06:13] <lifeless> LaunchpadWebServiceCaller
[06:14] <wgrant> lifeless: So, the TAL memcached stuff adds the loop index to the key.
[06:14] <wgrant> lifeless: What goes wrong is that the indexes change...
[06:15] <wgrant> I'm not sure whether this is a Registry or Foundations bug.
[06:17] <lifeless> so the key is host/object/template/loopN (or something)
[06:17] <lifeless> uhm
[06:17] <wgrant> Pretty much, yes.
[06:17] <lifeless> yes, clearly thats a problem
[06:17] <lifeless> cache at canonical url only basically
[06:36] <lifeless> mwhudson: newInteraction called while another interaction is active.
[06:36] <lifeless> mwhudson: I have a feeling you know about this
[06:37] <lifeless> mwhudson: http://pastebin.com/pkBkT68i
[06:37]  * mwhudson clicks, waits
[06:38] <mwhudson> lifeless: has pastebin.com fallen over?
[06:38] <wgrant> lifeless: Log out before you log in again.
[06:39] <mwhudson> ah there it is
[06:39] <StevenK> http://downforeveryoneorjustme.com/pastebin.comhttp://downforeveryoneorjustme.com/pastebin.com
[06:39] <StevenK> :-P
[06:39] <mwhudson> lifeless: yes, you need to logout before doing web requesty type stuff
[06:40] <mwhudson> TestCaseWithFactory.setUp() logs in as anonymous
[06:40] <mwhudson> lifeless: all of this is fairly horrible
[06:40] <lifeless> oh, it _fail_
[06:41] <lifeless> how unexpected
[06:41] <lifeless> how much would die if that got fixed?
[06:41] <mwhudson> i'm not even sure what a fix would be like
[06:41] <lifeless> don't log in as anonymous
[06:42] <mwhudson> oh right
[06:42] <mwhudson> well, dunno
[06:42] <mwhudson> probably plenty
[06:42] <lifeless>   File "/home/robertc/launchpad/lp-branches/working/lib/lp/testing/factory.py", line 434, in makePerson
[06:42] <lifeless>     person, email = getUtility(IPersonSet).createPersonAndEmail(
[06:42] <lifeless> like that :P
[06:42] <lifeless> its odd that anonymous can createPersonAndEmail, or is that just me ?
[06:43] <mwhudson> lifeless: there's a special case somewhere
[06:43] <lifeless> *blink*
[06:43] <mwhudson> you have to be able to create person records without being logged in ...
[06:46] <stub> Is anyone landing https://code.edge.launchpad.net/~wgrant/launchpad/per-archive-build-debug-symbols/+merge/29671 ?
[06:46] <mwhudson> i think i'm trying to
[06:46] <stub> k
[06:46] <mwhudson> yes
[06:46] <mwhudson> it's in ec2
[06:47] <wgrant> stub: It was rejected by PQM a few hours ago due to a conflict, but should land in a couple of hours.
[06:48] <lifeless> man
[06:49] <lifeless> its very surprising to have 'url = "/~%s/participants" % team.name' fail if you don't have something logged in.
[06:49] <lifeless> _not python anymore_
[06:50] <lifeless> garh
[06:50] <lifeless> and now
[06:50] <lifeless> response 'Anonymous requests must provide a User-Agent.
[06:50] <lifeless> '401' ><
[06:51] <wgrant> lifeless: You know there are a couple of webservice wrapper utilities, right?
[06:51] <wgrant> There's the old one, and then there's launchpadlib.
[06:52] <mwhudson> haha, after 5 or so days, my recipe build fails with a stupid typo
[06:53] <lifeless> wgrant: I'm using LaunchpadWebServiceCaller
[06:53] <lifeless> wgrant: I want to do exactly one http request, and launchpadlib is very not-geared-to-control-that.
[06:54] <wgrant> lifeless: Shh.
[06:55] <lifeless> wgrant: its peanut butter jelly time
[07:02] <wgrant> stub: Thanks.
[07:40]  * mwhudson creates a mercurial import, optimistically
[07:43] <lifeless> bbiab
[07:43] <mwhudson> wow, it completed in 60 secs
[07:44] <wgrant> mwhudson: Successfully?
[07:44] <mwhudson> wgrant: yeah
[07:44] <wgrant> Hm.
[07:44] <wgrant> Did it have any revisions?
[07:44] <mwhudson> 662 apparently
[08:00] <adeuring> good morning
[08:18] <lifeless> I am in a maze of unfinished toolchains
[08:19] <wgrant> Oh?
[08:21] <lifeless> wgrant: just building up my normal test flexability
[08:21] <wgrant> Ah.
[08:22] <lifeless> the next thing will be make_query_checker(LessThan(20))
[08:22] <wgrant> Excellent idea.
[08:24] <lifeless> part 1 is up for testtools review already
[08:37] <lifeless> jml: hi
[08:38] <lifeless> testtools trunk has UTF8_TEXT in news and PLAIN_TEXT in content_type
[09:01] <mrevell> Hello
[09:04] <lifeless> mrevell: hello
[09:24] <thumper> does loggerhead stay running for anyone else using `make run_codehosting`?
[09:26] <lifeless> james_w: btw, have you seen testtools.matchers.Annotate ?
[09:47] <poolie> lifeless: what does that do?
[09:47] <lifeless> adds : LITERAL to the mismatch
[09:47] <lifeless> which some of james new code in lp.testing.matchers does as well
[09:48] <poolie> nice
[10:17] <lifeless> jml: hi, awake?
[10:18] <hrw> hi
[10:23] <wgrant> bigjools: Hi. lamont's fine with https://code.edge.launchpad.net/~wgrant/launchpad/multi-arch-builders/+merge/31740 -- how 'bout you?
[10:26] <lifeless> wgrant: http://pastebin.com/B72J7fuA
[10:26] <wgrant> lifeless: Hmm?
[10:27] <lifeless> thats what the test infrastructure I just finished putting together reports
[10:27] <wgrant> lifeless: Oh, right. I just looked at the two tracebacks at the top and wondered what I'd broken :P
[10:28] <lifeless> lp.registry.tests.test_person.TestAPIPartipication.test_participation_query_limit is the only interesting bit
[10:29] <wgrant> Yep.
[10:29] <wgrant> Looks good.
[10:44] <jml> lifeless, am now.
[10:44] <stub> Monster storm coming through. If I'm gone its a power outage.
[10:59] <lifeless> jml: hi
[10:59] <lifeless> jml: i added another matcher
[10:59] <jml> lifeless, approved
[10:59] <lifeless> jml: and found a glitch in testtools trunk - UTF8_TEXT doesn't exist, but NEWS claims it does.
[11:00] <jml> lifeless, oh right. easily fixed.
[11:00] <jml> although a shame that glitch is in a release
[11:00] <lifeless> jml: I haven't uploaded the release to debian
[11:01] <lifeless> cause I've been lazy
[11:01] <jml> http://pastebin.ubuntu.com/473448/
[11:03] <lifeless> jml: +1
[11:07] <lifeless> jml: you might like https://code.edge.launchpad.net/~lifeless/launchpad/registry/+merge/31830
[11:07] <jml> Python's warnings filter doesn't work the way I expected.
[11:08] <jml> lifeless, nice.
[11:09] <jml> oh, this might not be Python
[11:14] <jml> le sigh
[11:16] <lifeless> ?
[11:20] <jml> https://code.edge.launchpad.net/~jml/launchpad/show-warnings-once/+merge/31831
[11:21] <jml> heh. lifeless, I've got five branches that you alone can review.
[11:21] <jml> jelmer, I've got one branch that you can review: https://code.edge.launchpad.net/~jml/subunit/move-ls/+merge/31769
[11:22] <lifeless> jml: testrepository ones?
[11:23] <jml> lifeless, yeah.
[11:24] <lifeless> I'm sorry.
[11:24] <lifeless> I suck
[11:24] <lifeless> I want to review them, honest.
[11:28] <jml> that's ok.
[11:29] <jml> each of them is a usability improvement (imo), so keen to get them landed :)
[11:30] <jml> then all I need to do is add native --load-list support to zope.testing and trial and then that branch of depth-first traversal of my hacking problems will be finished
[11:32] <jelmer> jml: I'll see if I can do a review during an evening this week.
[11:32] <jml> jelmer, thanks. it really is a very simple change.
[11:32] <jelmer> ah, ok - I haven't looked yet
[11:32] <lifeless> jml: cool.
[11:32] <lifeless> jml: I'm still bootstrapping myself to proper effectiveness in lp's code base
[11:33] <jml> lifeless, me too!
[11:34] <lifeless> jml: har har har
[11:34] <lifeless> jml: I'm fairly sure you know where all the skeletons are by now :)
[11:39] <lifeless> later
[11:40] <jelmer> jml: +1 on the user side of your MPs, though I wonder if it's always a good idea to initialize on load if there's no .testrepository directory.
[11:41] <jml> jelmer, what possible harm could there be in doing so?
[11:41] <jelmer> e.g. me running "bzr selftest --subunit | testr load" but in the wrong directory
[11:42] <jml> I guess the harm there is you "lose" a test run to another repo & don't know about it
[11:43] <jml> vs the harm of pissing me off every single time I make a new branch.
[11:46] <lifeless> jml: fwiw testr init returns 0 if there is already a repo
[11:46] <lifeless> jml: to allow testr init; testr run/load/whatever
[11:46] <lifeless> jml: I did this to permit both styles of work
[11:46] <lifeless> I think.
[11:46] <lifeless> ETired. really gone.
[11:46] <jml> lifeless, ok, good night.
[12:01] <deryck> Morning, all.
[12:05] <jml> deryck, good morning.
[12:06] <deryck> hi jml.  Do you have some time tomorrow that you and I could chat?  Just to catch up a bit for one, and then I have some LEP and LEP-like things to chat about.
[12:07] <jml> deryck, sure.
[12:07] <jml> lemme consult my calendar
[12:08] <jml> deryck, how's 1400UTC?
[12:09] <deryck> jml, perfect.  Thanks!
[12:10] <deryck> heh, we double calendared.  I'll accept yours, jml.
[12:10] <jml> deryck, ta.
[12:52] <jml> this wireless card dropping thing is amazingly disruptive. I might as well have my computer spontaneously reboot on me.
[13:08] <mars> wgrant, ping, got a failure running ec2 land last night: lib/lp/archiveuploader/tests/nascentupload-ddebs.tx
[13:09] <wgrant> mars: Yeah, fixed and landed already :)
[13:09] <wgrant> Thanks.
[13:09] <mars> wgrant, ok
[13:10] <mars> np
[13:29] <jtv> danilos, henninge: I filed bug 613821 for the approver failure, and an incidental bug 613823
[13:29] <_mup_> Bug #613821: Approver violates unique constraint <Launchpad Translations:New> <https://launchpad.net/bugs/613821>
[13:29] <_mup_> Bug #613823: Approver should log oopses <Launchpad Translations:New> <https://launchpad.net/bugs/613823>
[13:32] <danilos> jtv, thanks, 613923 is not very useful unless we plan to start working on it, and we don't
[13:32] <jtv> danilos: well I admit fixing it would be bad from the zero-oops perspective…
[13:32] <danilos> jtv, (because the same holds for language-packs, po exports, pofile stats,...)
[13:33] <jtv> OTOH it's basically saying we're accepting oopses as a matter of course.
[13:33] <danilos> jtv, no, it's just that it's a known problem with most of our old scripts
[13:33] <jtv> Definitely.  But in this case, it's hiding oopses.
[13:34] <danilos> jtv, it's not, that's why we have it logging with full detail
[13:34] <jtv> danilos: do you check those logs regularly?
[13:34] <danilos> jtv, OOPSes are hidden for those parts where we have to dig through a million-OOPS count, this is all in easy to look at log files
[13:34] <danilos> jtv, yes
[13:35] <jtv> Okay, then this falls under "time-saver" not under "oopses."
[13:35] <jtv> How long had we been having that approval conflict I posted about?
[13:35] <danilos> jtv, well, not really, since at the moment oops tools could only provide us with *another* email instead of aggregating it into one
[13:36] <danilos> jtv, we've had it appear and go for a few days already
[13:36] <danilos> jtv, you were mostly tracking them though
[13:37] <danilos> jtv, or maybe I am talking about a different approver bug
[13:38] <jtv> I don't see how the approval conflict could go away.  We had a different traceback a few days ago, for which I cleaned up the data.  And now we're having a different kind of traceback.  But as a third problem, there's the KDE approval conflict where it's been logging that there were two templates with the same domain.
[13:38] <jtv> I hope that will stay as unusual as I find it now: we find 3 completely different approval problems in 1 week.
[13:39] <jtv> grrr staging buildfarm hurry up
[13:39] <danilos> jtv, yeah, this one was hitting us for 3 days now
[13:51] <jtv> danilos: 3 days is about the maximum time for this approver problem.  If the older entry is still in the way after that time, chances are it's in Failed state and will stay around for much longer.  :(
[13:51]  * jtv updates bug report with this note
[14:04] <stub> What is our preferred mock logger?
[14:06] <deryck> mrevell, ping
[14:06] <mars> stub, for launchpad?  I've used mocker elsewhere, but not for logging.
[14:06] <mrevell> Hi there deryck
[14:06] <stub> There are three or four mock loggers for tests in the tree I believe, and I can't find any of them (including the one I wrote)
[14:07] <mars> abentley, ping, any idea why this project /still/ insists that there is no default branch, even though the website says I did? https://code.edge.launchpad.net/~launchpad-qa/qa-shepherd/devel
[14:07] <abentley> mars, default for what?
[14:08] <mars> abentley, for this qa-shepherd project
[14:08] <mars> sorry, default for the project
[14:08] <abentley> mars, do you mean "development focus"?
[14:09] <stub> lp.testing.logger defines MockLogger
[14:09] <mars> abentley, no idea.  All I know is that I tried what our website says, "bzr branch lp:qa-shepherd", and bzr returns an error saying "bzr: ERROR: Invalid url supplied to transport: "lp:qa-shepherd": qa-shepherd has no default branch."
[14:09] <mars> abentley, here is the project page: https://edge.launchpad.net/qa-shepherd
[14:09] <mars> abentley, everything looks OK to me on that page
[14:10] <mars> stub, then I would take the fact you can't find the other three instances as a good thing :)
[14:11] <stub> There is a comment from 2007 in there pointing to one of the others (launchpad.scripts.logger.FakeLogger)
[14:11] <stub> Maybe it is a daisy chain - I don't want to look.
[14:11] <mars> hehe
[14:13] <abentley> mars, no, I've never heard of a problem like this before.
[14:14] <mars> abentley, it sounds like a branch policy violation.  I wonder, could the branch policy for the project still be 'private by default' or something?
[14:15] <mars> abentley, hmm: https://code.edge.launchpad.net/qa-shepherd - the development focus is stacked on my branch, and my branch is private
[14:15] <abentley> mars, I would not expect the branch policy to matter.  I would expect only the branch privacy to matter.
[14:15] <mars> could that do it?
[14:15] <abentley> mars, that sounds possible.
[14:16] <mars> abentley, and it works now.  Shall I file a bug?
[14:16] <abentley> mars, please do.
[14:16] <abentley> mars, did you do anything to fix it?
[14:17] <mars> abentley, I changed my branch (the stacking base) to a public branch
[14:17] <mars> from a private one
[14:18] <mars> that allowed the project branch, which was stacked on top of mine, to start working
[14:18] <abentley> mars, so the bug here is that you shouldn't be able to set a branch public without also setting its stacked-on branch public.
[14:18] <mars> right
[14:19] <abentley> Probably some better diagnostics would be good too.
[14:59] <bigjools> jml: I've been trying to break the new buildd-manager in dogfood and it's coped with everything I can throw at it so far.  I'm shocked.  I even saw it resetting one builder at the same time as dispatching to another, which is a first.
[14:59] <bigjools> time to land it I think
[15:04] <mars> abentley, bug filed: 613841
[15:07]  * jelmer wonders why dev.launchpad.net doesn't let him subscribe to pages
[15:07] <abentley> mars, we only use the development focus branch for stacking on.
[15:08] <abentley> mars, so your recipe implies "2.5 make lp:~me/theproject/devel the development focus of the project"
[15:08] <mars> jelmer, our custom Moin theme dropped a few wiki features, like subscribing to pages and smilies.  I have no idea why though.
[15:08] <bigjools> jelmer: you have to url hack
[15:08] <bigjools> jelmer: ?action=subscribe
[15:08] <mars> beat me to it
[15:08] <jelmer> bigjools, mars: thanks!
[15:09] <mars> abentley, you are right, that is what I did, yet
[15:09] <mars> yes even!
[15:10] <mars> Ah, text searching - that feature was dropped too
[15:10] <mars> So you have to do a title search, then click the 'do a text search' button on the title search results page
[15:12] <jml> bigjools, cool :)
[15:13] <bigjools> jml: but given that we have nothing like a production environment to test with, I'm still scared :)
[15:36] <bigjools> so I just did a full test run for the first time in a while, and I'm astonished at the fact that the output is basically doubled in size with all the "warnings" at the end
[16:12] <jml> bigjools, yes. you may have noticed some complaints about this on the list :)
[16:13] <bigjools> jml: complaints? really? :)
[16:16] <mars> gary_poster, ping, I have a buildout question for you when you have a moment
[16:17] <gary_poster> mars, ack, on call.  will ping when off
[16:17] <mars> ok
[16:30] <sinzui> mrevell, ping
[16:30] <mrevell> yo sinzui
[17:11] <bigjools> sinzui: so, where are distroseries.title, displayname, summary and description all used?  I want to fix the crappy descriptions on the addseries page.
[17:31] <sinzui> bigjools, I think they are used on ds+index, ds+series, milestone+index. I think you need to grep for series\.(title|displayname|summary)
[17:32] <bigjools> sinzui: yeah I did, I can't work out why we have a separate summary and description
[17:32] <bigjools> do you know of any hysterical raisins?
[17:33] <sinzui> bigjools, There is also an calculated attr (named_version) That is more often used. I regret creating it. I think the lts/name/version issue could have been solved if I really made displayname calculated
[17:33] <sinzui> bigjools, summary may only be useful on +series
[17:33] <bigjools> sinzui: yes, the difference between Display Name and Title eludes me a bit too
[17:34] <sinzui> bigjools, I also believe that mpt was right in suggesting we abandon title
[17:36] <bigjools> yeah, it seems redundant
[17:37] <bigjools> perhaps now is the time, while I am redesigning the addseries page
[17:37] <sinzui> Yes
[17:37] <sinzui> I think so
[17:37] <bigjools> ok, I'll exclude it from the mockups
[18:56] <mtaylor> sinzui: hey - don't mean to be a pest, but any luck figuring out why that guy isn't getting mailing list mail? he's starting to get frustrated
[18:56] <sinzui> I have no power in that regard. I asked an admin to look at the error and vette log for evidence of problems
[19:12] <mtaylor> sinzui: excellent. thanks!
[19:13] <sinzui> mtaylor, when staging gets a copy of production data in 3 days, I will have some power to see what has happened. So if and Admin has not solved the issue, I can at least look for problems
[19:14] <mtaylor> sinzui: cool. don't you love odd problems like this one? :)
[19:47] <Ursinha> sinzui, hello. do you know what is a ProfilingOops? https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1676S100
[19:48] <sinzui> Ursinha, lp.services.profile. lifeless created it recently
[19:49] <Ursinha> aha, I was suspecting
[19:49] <sinzui> Ursinha, is is manually enable-able on staging to do research into timeouts. This looks like it did not work
[19:49] <Ursinha> it seems
[19:50] <sinzui> oh
[19:50] <Ursinha> I see ~200
[19:50] <Ursinha> I also see a lot of DisconnectionErrors...
[19:51] <sinzui> profiling is one and it is for everything. then you turn it off. you are trying to get exclusive use of staging to do a test. But...this example shows the xmlrpc polling by mailman was running during the test
[19:51] <sinzui> s/one/on/
[19:55] <Ursinha> I see
[19:59] <Ursinha> sinzui, about the accountmerge timeouts... is there a bug for that? I only found one bug, a very old one
[19:59] <Ursinha> and doesn't seem related
[20:00] <sinzui> Account merge (profile merge) is 40 steps. the oopses can mutate. The same code is also used for person and team, for user requested and admin requested. one code, 160 kinds of oopes
[20:01] <sinzui> Ursinha, we agree we cannot fix the timeout by changing the code shown in the oops we need a new process.
[20:01] <sinzui> I created a bug tag to help see the problem
[20:02] <Ursinha> sinzui, right
[20:03] <sinzui> Ursinha, https://bugs.edge.launchpad.net/launchpad-registry/+bugs?field.tag=merge-deactivate, The real problem will be fixed with bug 162510
[20:03] <_mup_> Bug #162510: Person merging needs to be done asynchronously <chr> <feature> <merge-deactivate> <tech-debt> <timeout> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/162510>
[20:03] <Ursinha> looking
[20:15] <deryck> hurrah.  I have a fix for my mysterious storm caching bug.  My duplicate_of changes can now land.
[20:18] <deryck> gary_poster, would you have time for a review of this?  Since I think you chatted with lifeless about this duplicate_of caching issue when it was discovered.
[20:18] <gary_poster> on calls, for afternoon :-/  can tomorrow
[20:19] <deryck> ah, no worries.  Thanks anyway, gary.
[20:29] <lifeless> moin
[20:29] <lifeless> deryck: excellent
[20:30] <deryck> lifeless, hey.  Glad you up.  Let me paste you a diff for now and see if you think I'm sane, or not. :-)
[20:31] <deryck> lifeless, http://pastebin.ubuntu.com/473667/
[20:32] <lifeless> that seems like a decent workaround if storm trunk doesn't have a fix
[20:33] <lifeless> I'd *prefer* a new storm and no cruft, so perhaps you can add a XXX: and a bug reference there ?
[20:33] <lifeless> jkakar: hi
[20:33] <lifeless> jkakar: ^
[20:33] <deryck> lifeless, sure.  I never could connect with anyone yesterday on storm, but the latest release on Launchpad is a few months old.
[20:34] <deryck> So I can XXX until there's a fix in Storm.
[20:34] <lifeless> yeah
[20:34] <lifeless> I know it broken in the latest release as of 2 weeks ago
[20:34] <lifeless> it might be fixed in trunk
[20:35] <deryck> lifeless, I can report a bug if you didn't, but since you worked it out initially, if you have more to explain about it, feel free to report it. :-)
[20:35] <jkakar> lifeless: Hi. :)
[20:35] <deryck> oh
[20:35] <deryck> unless it's fixed
[20:35] <lifeless> deryck: ah rev 361 in trunk
[20:35] <lifeless> jkakar: hiya. Has there been a storm release since rev 361 ?
[20:35] <lifeless> deryck: http://bazaar.launchpad.net/~storm/storm/trunk/changes
[20:35]  * deryck looks
[20:35] <jkakar> deryck: Nope, I'm waiting for a branch to land (for you guys).
[20:36] <jkakar> lifeless: ^^
[20:36] <jkakar> lifeless: Then I'll prepare an 0.17 release.
[20:36] <lifeless> ok, well we can use a snapshot
[20:36] <lifeless> jkakar: whats the branch ?
[20:36] <jkakar> lifeless: https://code.edge.launchpad.net/~jkakar/storm/sqlobject-is-empty/+merge/31565
[20:36] <jkakar> lifeless: If you can take a peek and review that today, I can prepare 0.17 tomorrow.
[20:37] <lifeless> jkakar: I'm with stub, it looks good
[20:37] <deryck> interesting.  hi, jkakar, btw :-)
[20:37] <jkakar> lifeless: Cool.  I'll prepare the release tomorrow.
[20:37] <jkakar> deryck: Hi! :)
[20:37] <deryck> lifeless, so should I hold on my changes here?  Or for now it's ok, until we get on latest storm?
[20:38] <lifeless> deryck: latest storm is < 24 hours away
[20:38] <james_w> hi lifeless, are you landing an updated version of testtools in to launchpad?
[20:38] <lifeless> james_w: yes, if my merge is approved
[20:39] <james_w> lifeless: great, I'll try and remember to make the Annotate change after that then
[20:39] <lifeless> james_w: is my merge approved? Is that my cow?
[20:39] <deryck> lifeless, yeah, but pqm closes tomorrow.  And I want a little time for QA with these changes.  Maybe I'm rushing too much, though.
[20:39] <james_w> lifeless: you know about lp:lp-source-dependencies?
[20:39] <lifeless> deryck: so, I'd be happy about you doing it via a versions.cfg change with a storm snapshot of trunk
[20:40] <lifeless> deryck: because then your malone model code doesn't need to get all ugly at all ;)
[20:40] <deryck> heh
[20:40] <deryck> fair enough.
[20:40] <lifeless> deryck: if you've done that before its very straight forward
[20:40] <lifeless> james_w: lets pretend I don't
[20:40] <deryck> lifeless, I haven't for storm.  But for lazr-js several times.  I assume it's similar.  Roll the egg, update versions.cfg, profit.
[20:41] <lifeless> deryck: yeah
[20:41] <lifeless> shove it in the download cache
[20:41] <deryck> ok, branching now.
[20:41] <lifeless> deryck: you can put the versions.cfg change in your branch for simplicity ;)
[20:41] <lifeless> james_w: https://code.edge.launchpad.net/~lifeless/launchpad/registry/+merge/31830 is my new testtools referencing version
[20:41] <james_w> lifeless: cool, thanks
[20:41] <deryck> lifeless, so off tip, i.e. r365 of storm trunk?
[20:42] <lifeless> deryck: looks like it should be sane to me
[20:42] <deryck> cool, thanks!
[20:43] <lifeless> de nada
[20:43] <lifeless> I'm sorry I lost touch with where the fix was
[20:43] <lifeless> or I could have said this on wed
[20:44] <deryck> no worries.  Lot going on lately.
[20:53] <lifeless> oh, thats steadystate for me :)
[20:54] <deryck> The life of a TA :-)
[20:55] <lifeless> ahha
[20:56] <lifeless> no, *me*
[20:56] <lifeless> this may mean I am a good fit for ta :P
[21:00] <lifeless> jcsackett: so, I have https://code.edge.launchpad.net/~lifeless/launchpad/registry/+merge/31830 landing now
[21:00] <sinzui> high lifeless, jcsackett and I started looking at the pathological cases of +participation
[21:00] <sinzui> The same people keep getting listed, each has more than 150 teams
[21:00] <lifeless> jcsackett: and if you look at that webpage I have the test I've written to show when the bug is fixed
[21:00] <lifeless> sinzui: wheee
[21:01] <lifeless> sinzui: so there may be rather different things for the /participation and +participation cases?
[21:02] <lifeless> sinzui: thanks for your thoughts-on email, I think its a very good question to raise
[21:02] <sinzui> +participation can die iterating over a large number of teams. The timeout can happen getting the icon, mailing list, or the path of the indirect team
[21:03] <jcsackett> sinzui: and you said there's not a whole lot of people who are bringing this problem up, right?
[21:03] <lifeless> sinzui: I'm just looking at one of the oops again now
[21:04] <sinzui> pitti, sabdfl and mdz appear through this month. pitti every day
[21:04] <lifeless> ok, I'm back up to speed
[21:04] <lifeless> the /participation and +participation bugs are different but similar
[21:04] <lifeless> from what I see they both are doing a lot of individual attribute lookups, with single backend sql queries happening as a result
[21:04] <lifeless> the individual queries are fast
[21:05] <sinzui> the mailing list query is death by a 1000 cuts
[21:05] <lifeless> but the overhead of doing those queries is substantial, and when hundreds of queries show up, the page will be in trouble
[21:05] <lifeless> sinzui: yes
[21:06] <lifeless> so, jcsackett - I have not been working directly on +participation; I can offer thoughts about it, but if you're already dived-into it, you probably have more thoughts than me already :)
[21:06] <lifeless> jcsackett: also, first time we've spoken - welcome to the team!
[21:06]  * sinzui really wanted to know who was subscribed to lists.
[21:06] <jcsackett> thanks, lifeless. glad to be on it.
[21:07] <deryck> lifeless, can I get a rubber stamp please?  https://code.edge.launchpad.net/~deryck/launchpad/update-storm-r365/+merge/31881
[21:07] <lifeless> deryck: r=lifeless
[21:07] <deryck> lifeless, thanks!
[21:08] <lifeless> deryck: however, do you want the bad news :)
[21:08] <lifeless> deryck: its may conflict with my versions.cfg change
[21:08] <deryck> ah, that's not so bad then :-)
[21:08] <deryck> you had me scared :-)
[21:08] <lifeless> :)
[21:09] <deryck> I'm running through ec2 test now, so I'll merge trunk later tonight before lp-land'ing it.
[21:09] <deryck> and resolve then
[21:09] <lifeless> sinzui: ok, so do you / jcsackett have a plan, or do you want to talk about strategies to fix it?
[21:09] <jcsackett> lifeless: i think sinzui and i are circling around a plan.
[21:10] <lifeless> jcsackett: cool! I'm interested - I'm new to my role too :) - and trying to get a good feel for how things are fixed and improved
[21:11] <jcsackett> lifeless: cool! yeah, i'm still getting a handle on things myself.
[21:11] <sinzui> lifeless, we are exploring 1 batching for pathological cases, 2 make mailing cheap...possible get everything on one query, 3, consider the cost of building the path of indirect teams...we do extra work to avoid showing private teams
[21:13] <lifeless> sinzui: 2 is what I would reach for first
[21:13] <lifeless> sinzui: getting things down to a constant number of queries will help a great deal across the system
[21:24] <flacoste> sinzui: are the mailman integration tests still off?
[21:24] <sinzui> yes
[21:26] <rockstar> We need to teach mup about testfix mode.
[21:26] <lifeless> flacoste: I will land poolies missing patch today
[21:26] <flacoste> lifeless: thanks
[21:27] <flacoste> sinzui: this might be problematic for the Lucid upgrade
[21:27] <mwhudson> morning
[21:27] <flacoste> sinzui: your team should run the tests manually on Lucid and probably do a smoke test on staging (which is now on Lucid)
[21:27] <sinzui> flacoste, we can enable them, but they never ran reliably. I ran them two months ago successfully, but bac or edwin got failures
[21:28] <rockstar> flacoste, what are the ramifications of testing through ec2 now?
[21:28] <flacoste> sinzui: i think running them once is fine, no need to enable them for all test runs
[21:28] <flacoste> sinzui: if you get one succesful test run, it's likely to be fine
[21:28] <flacoste> rockstar: i don't understand the questions, and how are you feeling btw?
[21:29] <sinzui> flacoste, I will do that in a few hours then on two machines to verify
[21:29] <flacoste> sinzui: it's not urgent, there are still many machiens to update, i've told mthaddon to hold on the mailman box until he gets confirmation from you that it's fine
[21:29] <rockstar> flacoste, still feeling ill, but need to work to maintain my sanity.  Since Lucid failures can put us in testfix, how can I prevent my changes from doing so if the ec2 machine is on hardy?
[21:30] <flacoste> rockstar: run "relevant" tests locally on lucid?
[21:30] <flacoste> rockstar: that's no silver bullet, but i don't have any better suggestion until mars gets to update the ec2 image
[21:30] <flacoste> rockstar: or someone else beats him to it
[21:31] <rockstar> flacoste, ack.  I guess we'll just deal with the pain and embarassment of breaking the build when it happens then.  :)
[21:31] <flacoste> :-)
[21:42] <sinzui> jcsackett, look at https://edge.launchpad.net/~pitti/+participation
[22:10] <thumper> jcsackett: morning
[22:10] <thumper> jcsackett: welcome to the team
[22:10] <jcsackett> thumper: good afternoon. :-) and thanks.
[22:25] <sinzui> jcsackett, https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1678EC1214
[22:40] <wgrant> Can someone please land https://code.edge.launchpad.net/~wgrant/launchpad/multi-arch-builders/+merge/31740?
[22:43] <james_w> wgrant: yep
[22:43] <wgrant> james_w: Thanks.
[22:43] <james_w> wgrant: sbuild really takes the arch twice in its arguments?
[22:44] <wgrant> james_w: sbuild-package is a wrapper. It does some stuff (and needs to know the architecture to do that), then passes the rest of the args through to sbuild.
[22:45] <james_w> ah, ok
[22:45] <wgrant> But it'll be gone once I land my system sbuild branch.
[22:48] <james_w> wgrant: if you could cashttps://code.edge.launchpad.net/~james-w/launchpad/soyuz-factory-improvements/+merge/31890 and https://code.edge.launchpad.net/~james-w/launchpad/no-more-sampledata-2/+merge/31891 that would be greatt an eye over
[22:54] <james_w> wgrant: that branch has detached in to ec2
[22:54] <wgrant> james_w: Thanks. Looking at yoursnow.
[23:13] <wgrant> james_w: https://code.edge.launchpad.net/~wgrant/launchpad/destroy-publishedpackage/+merge/31813 would also like to be landed, if you could.
[23:14] <wgrant> james_w: In no-more-sampledata-2, you seem to prefer rSP over logging in as the right user.
[23:14] <wgrant> I'm not sure if that's right.
[23:15] <james_w> wgrant: in any particular place, or all over?
[23:15] <wgrant> james_w: Setting parent_series is the most obvious so far.
[23:15] <wgrant> You could also probably use BPR.override on line 201 of the diff.
[23:16] <james_w> wgrant: I assumed that wasn't a normally allowed operation
[23:16] <wgrant> james_w: It's exposed on DistroSeries:+admin.
[23:16] <wgrant> So someone's allowed to do it.
[23:16] <james_w> I'm happy to change if it's the right thing to do, I thought that in test setup it didn't really matter, as it's the results rather than the method that you care about
[23:16] <wgrant> True.
[23:19] <wgrant> What do all those .sync() calls do?
[23:19] <wgrant> I wonder if they're irrelevant now that [SB]PPH isn't a view
[23:28] <james_w> wgrant: that's possible
[23:29] <james_w> I'd be tempted to just delete them and run the tests
[23:41] <wgrant> james_w: I think that's probably a good idea.
[23:41] <wgrant> james_w: Did you fire off that second ec2 instance?
[23:41] <james_w> wgrant: second branch in ec2
[23:42] <wgrant> Heh, thanks.
[23:42] <james_w> wgrant: I'll give it a go
[23:42] <james_w> must go and cook now though
[23:42] <wgrant> There's still lots of code around that is redundant now that S[SB]PPH are gone.