[00:01] <jelmer> thumper: Will do. Thanks.
[00:03] <mwhudson> jelmer: man, that mapdbs fix had me seriously head-scratching :-)
[00:03] <mwhudson> i hope it's not necessary any more
[00:04] <jelmer> mwhudson: heh, I bet
[00:04] <jelmer> mwhudson: it's still used actually
[00:04] <jelmer> though we'll hopefully be able to use bzr index files with git pack files for the cache hopefully
[00:04] <mwhudson> ok, maybe more of a fix than deleting the tearDown is required
[00:05] <jelmer> (that should also be the point at which we can have a "bzr serve --git" that works with decent performance)
[00:06] <jelmer> that reminds me.. any news on bzr:// support, or is it all recipes these days in the code team ? :-)
[00:06] <thumper> jelmer: all recipes
[00:07] <lifeless> jelmer: bzr:// support - for anonymous access to branches ?
[00:07] <jelmer> lifeless: yeah
[00:07] <lifeless> jelmer: I'd rather we just did bzr on http
[00:08] <lifeless> jelmer: less setup, better support in firewalled situations
[00:11] <jelmer> lifeless: either would be awesome
[00:16] <lifeless> wgrant: btw
[00:16] <lifeless> wgrant: private PPA log file tailing. That permits an attack on launchpad.net via content insertion, no ?
[00:16] <wgrant> lifeless: Howso? logtail should be escaped by the template.
[00:17] <lifeless> ah
[00:17] <lifeless> I was thinking put js in it and let the streamorview thing do its sniffing
[00:17] <wgrant> And the downloable build log should be text/plain.
[00:17] <wgrant> Ah, no, there's no JS there.
[00:17] <wgrant> Just boring old refreshing.
[00:17] <lifeless> and the build log is the full thing, right ?
[00:17] <wgrant> It is.
[00:18] <wgrant> There's probably a vulnerability there somewhere.
[00:21] <lifeless> wgrant: you were saying that setting cd:attachment will break streaming logs
[00:21] <lifeless> wgrant: but if its being escaped in the appserver, it won't have any immediate impact, will it ?
[00:21] <wgrant> lifeless: Not streaming logs. Viewing of logs in the browser.
[00:21] <wgrant> At the moment I can click on a build log link and not have to download it.
[00:21] <wgrant> This is unrelated to logtail.
[00:21] <lifeless> ok
[00:23] <lifeless> anyhow, I've filed a bug, if you have ideas about how to do things, please dive in.
[00:23] <wgrant> I think the existing build log streaming might be vulnerable in IE, since IE likes to sniff content rather than obeying content types.
[00:26] <lifeless> heh
[00:40] <wgrant> How much SQL time is there on OOPS-1675ED4744?
[00:42] <lifeless> is that oops code correct ?
[00:42] <mwhudson> wgrant: did it just get created?
[00:42] <wgrant> Maybe it just missed the sync.
[00:44] <lifeless> SQL time: 4761 ms
[00:44] <lifeless> Non-sql time: 13888 ms
[00:44] <lifeless> Total time: 18649 ms
[00:44] <lifeless> Statement Count: 59
[00:45] <wgrant> Right, that's about what I thought.
[00:45] <wgrant> WTF is the non-SQL time, I wonder.
[00:46] <thumper> wgrant: python execution time,
[00:46] <thumper> storm object creation time...
[00:46] <lifeless> we can get a profile of it for you
[00:46] <lifeless> if you ask a losa
[00:46] <wgrant> I know, but that's an awfully large amount of time considering the few queries.
[00:47] <lifeless> pasting you some stuff
[01:49] <lifeless> losa ping
[01:50] <spm> yo
[01:50] <lifeless> I'd like to get a profile from staging per favour
[01:50] <spm> sure
[01:51] <lifeless> so, in theory I wait, you say 'go ahead' then I say 'done'.
[01:51] <lifeless> in practice, I'm guessing this is the first time ever and you have no idea whats about to happen :P
[01:51] <spm> that'd be spot on
[01:51] <lifeless> and the difference between theory and practice.. :)
[01:51] <lifeless> so in the config file for staging
[01:51] <lifeless> on staging
[01:51] <lifeless> there is a profiling section
[01:51] <spm> I can infer what you want; but not quite sure exactly what you want to achieve, and the how of.
[01:51] <lifeless> with a key profile_requests (IIRC)
[01:52] <lifeless> you need to turn that on and bounce the app server
[01:52] <spm> huh. I didn't know that!
[01:52] <lifeless> tada
[01:52] <spm> this is the app server? (to confirm) vs code*
[01:52] <lifeless> we're going to make this less manual
[01:52] <lifeless> appserver
[01:52] <lifeless> https://api.staging.launchpad.net/beta/~ubuntu-dev/participants is the URL I want to profile
[01:53] <lifeless> spm: for context, see maris's email to launchpad-dev at the end of the epic
[01:53] <lifeless> spm: so, 2 weeks backish. it describes the process on a developer machine.
[01:54] <spm> hrm. we have no 'profiling section' or 'profile_requests' is the existing configs; can you give me a quick dump of the lines to add?
[01:54] <spm> s/is/in/
[01:54] <lifeless> [profiling]
[01:55] <lifeless> profile_requests: True
[01:55] <spm> hmm. complex.
[01:55] <lifeless> (see configs/schema-lazr.conf for missing things like this)
[01:55] <lifeless> you can also set profile_dir:
[01:55] <lifeless> if you want them to go to a /var dir or some such - the default is '.'
[01:55] <spm> what!?!? srsly!?!? you want me to rtfm!?!?! I'm a *sysadmin*!!!
[01:56] <lifeless> oh, and lastly, we should also set
[01:56] <lifeless> *in that section*
[01:56] <lifeless> error_dir: and oops_prefix:
[01:56] <lifeless> because it will generate an oops to go with, so that we get the DB trace etc
[01:56] <spm> ahh kk
[01:57] <lifeless> https://pastebin.canonical.com/35303/
[01:57] <lifeless> to bring it all together.
[01:57] <spm> not such a big deal here'n'now; but might be worth getting this formally landed into the prod configs - staging section only. ??
[01:57] <lifeless> yeah
[01:58] <lifeless> if you tell me the stuff to put in it :)
[01:58] <spm> staging-lazr.conf ?
[01:58] <spm> oh. right. lala eparse
[01:59] <lifeless> I can wait if you need a coffee :)
[01:59] <spm> [profiling]
[01:59] <spm> profile_requests: True
[01:59] <spm> error_dir: /srv/staging.launchpad.net/staging-logs/profiling
[01:59] <spm> profile_dir: /srv/staging.launchpad.net/staging-logs/profiling
[01:59] <spm> oops_prefix: PROFILE
[01:59] <spm> do I what...
[01:59] <spm> losa_needs_coffee: ZOMGTRUE
[02:00] <spm> restarting the app server...
[02:00] <spm> Kah Boom.
[02:00] <spm> https://pastebin.canonical.com/35304/
[02:00] <lifeless> HAH
[02:01] <lifeless> delete the error_dir key
[02:01] <spm> kk
[02:01] <lifeless> oh
[02:01] <spm> same error.
[02:01] <lifeless> delete the oops prefix too
[02:01] <lifeless> the schema had a confusing bit, it got me good
[02:01] <spm> :-)
[02:02] <spm> that's happy
[02:02] <spm> see that's what rtfm does for you. confuses. much better to just make s**t up
[02:02] <lifeless> is it up and running ?
[02:03] <spm> shouldbe... stopped doing stuff; giove it a few secs to "settle"
[02:03] <spm> and responding to nagios checks; go for it
[02:03] <lifeless> ok, I just got a request through.. turn it off again
[02:04] <lifeless> then we'll grab the profile file and oops and I can nod off and examine it
[02:04] <spm> haha. what a guess. that directory - completely unlooked for; already existed.
[02:04] <spm> [profiling]
[02:04] <spm> profile_requests: False
[02:04] <spm> profile_dir: /srv/staging.launchpad.net/staging-logs/profiling
[02:04] <spm> syncing logs...
[02:05] <lifeless> bzr+ssh://bazaar.launchpad.net/~lifeless/lp-production-configs/timeouts has it in it now, but don't merge it - see special rollout notes
[02:05] <spm> is restarted
[02:07] <lifeless> so in that directory
[02:07] <lifeless> there should be a bunch of files
[02:07] <lifeless> and
[02:07] <lifeless> possibly some oops's there, or otherwise they will be in the regular oops dir
[02:08] <spm> sodium:/srv/launchpad.net-logs/staging/asuka/profiling/
[02:09] <lifeless> spm: you can delete all the 2008 files ;)
[02:10] <lifeless> hmm, but I can't see the participation one I would expect. time to grep em al I think
[02:10] <spm> I was thinking that :-)
[02:12] <lifeless> wgrant: https://bugs.edge.launchpad.net/ubuntu/+bug/602360 is a bug you might find interesting - soyuz query
[02:12] <_mup_> Bug #602360: timeout on source package bug filing page <timeout> <Launchpad Bugs:Triaged> <Ubuntu:Invalid> <https://launchpad.net/bugs/602360>
[02:12] <lifeless> spm: ah, its one of ScopedCollection:CollectionResource
[02:13] <wgrant> lifeless: That plan makes me cringe.
[02:13] <wgrant> It can't possibly need all of those tables.
[02:14] <lifeless> curtis said, in a similar bug
[02:14] <lifeless> https://bugs.edge.launchpad.net/launchpad-answers/+bug/608037
[02:14] <_mup_> Bug #608037: timeouts in Question:+edit <oops> <timeout> <Launchpad Answers:Triaged> <https://launchpad.net/bugs/608037>
[02:21] <lifeless> spm: actually, can you please nuke the 2008* files ;)
[02:21] <spm> sure; done on asuka, will rm from sodium
[02:22] <spm> gone
[02:22] <lifeless> thanks
[02:24] <lifeless> spm: also, can you look for oopses +- 1 minute from when I said 'done'
[02:24] <lifeless> spm: and grep them for the url .../participation
[02:24] <lifeless> there should be 2 I think
[02:24] <lifeless> I just need the OOPS ids.
[02:26] <spm>  /participants ?
[02:26] <lifeless> yes
[02:27] <spm> 03796.S56 03826.S95 are the files. go up one dir on sodium from the logs and into 2010-08-03
[02:27]  * spm regrets cat'ing those out...
[02:28] <lifeless> :P
[02:28] <spm> OOPS-1676S95 OOPS-1676S56
[02:28] <lifeless> thanks!
[02:29] <lifeless> sweet - https://lp-oops.canonical.com/oops.py/?oopsid=1676S95
[02:29] <lifeless> 1.8 seconds sql, 4.6 seconds python
[02:29] <lifeless> 430 sql requests
[02:31] <lifeless> also
[02:32] <lifeless> haha:  WHERE Person.name = %s AND Person.merged IS NULL ORDER BY person_sort_key(Person.displayname, Person.name)
[02:32] <lifeless> thats a little odd
[02:32] <lifeless> exact match, oh but lets order it please.
[02:33] <spm> *430* SQL requests! eek!
[02:33] <lifeless> iz potato programming
[02:34] <lifeless> now, I need to find some folk with detailed knowledge of the storm glue
[02:34] <spm> as in like Mr Potatohead? just more bits stuck together?
[02:35] <lifeless> 2010-08-03_02:03:40.261-ScopedCollection:CollectionResource-OOPS-1676S95-Dummy-2.prof is the profile file if you're interested
[02:36] <spm> I shall have a look
[02:38] <thumper> lifeless: what's up?
[02:38]  * thumper knows glue well
[02:42] <lifeless> thumper: hiya
[02:42] <lifeless> have a look at  https://lp-oops.canonical.com/oops.py/?oopsid=1676S95
[02:42] <lifeless> its a slow API call
[02:42] <thumper> lifeless: we could go to voice if it helps
[02:43] <lifeless> that might be a good bootstrap exercise
[02:52] <lifeless> sodium:/srv/launchpad.net-logs/staging/asuka/profiling/2010-08-03_02:03:40.261-ScopedCollection:CollectionResource-OOPS-1676S95-Dummy-2.prof is the kcachegrind profile
[03:02] <lifeless> thumper: https://api.edge.launchpad.net/beta/~ubuntu-dev/participants - open it in your browser
[03:27] <lifeless> thumper: http://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420/ref=sr_1_1?ie=UTF8&s=books&qid=1280802410&sr=8-1
[03:51] <lifeless> bbiab, chores to run
[04:50] <poolie> happy performance day!
[06:47]  * thumper done for nwo
[06:47] <thumper> now
[07:27] <lifeless> thumper: so, another question - can you point me at an example of testing the API / making a browser request - outside of a doctest ?
[07:56] <bebo_mz> can any one help me in this W: GPG error: http://ppa.launchpad.net lucid Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 449F83829320B41C
[08:09] <lifeless> you might have better luck in #launchpad
[08:31] <adeuring> good morning
[08:41] <lifeless> good morning
[09:02] <didrocks> jml: hey, how are you?
[09:08] <adeuring> lifeless: could you please explain a bit what the security issue is in my MP for lp:~adeuring/launchpad/bug-39674-update-retricted-flag-of-private-bugattachments ?
[09:15] <mrevell> Morning
[09:19] <jkakar> If someone has time to review a trivial Storm branch, please check this out, it adds an is_empty method to SQLObjectResultSet: https://code.edge.launchpad.net/~jkakar/storm/sqlobject-is-empty/+merge/31565
[09:19] <adeuring> what should we for a buildbot failure "xvfb-run: error: Xvfb failed to start"?
[09:31] <lifeless> adeuring: hi
[09:31] <adeuring> hi lifeless
[09:31] <lifeless> adeuring: its the whole arc of work - I filed a dedicated bug about it
[09:32] <adeuring> lifeless: so, do you mean the ProxiedLFA stuff?
[09:32] <lifeless> yes
[09:32] <lifeless> bug attachments are user controlled content
[09:33] <lifeless> if they are served in a domain, they can run scripts to access anything else in the domain - other bugs, private lists, etc, and submit the content to other servers
[09:33] <adeuring> lifeless: right, but I don#t see the issue yet... anyway, can you tell me the bug number?
[09:33] <lifeless> its why the librarian is on launchpadlibrarian.net rather than part of the appservers
[09:34] <lifeless> 612779
[09:35] <lifeless> adeuring: the issue is, that anyone can file a private bug, with an attach script, which will (for instance) steal the users oauth cookie and forward it to a hostile site
[09:36] <adeuring> lifeless: yes, but that applies to attachments of bugs too...
[09:36] <lifeless> no it doesn't
[09:36] <lifeless> because they are on a different domain
[09:36] <adeuring> ah, right, forgot that
[09:36] <bigjools> lifeless: see my comment on your librarian MP
[09:38] <lifeless> bigjools: https://code.edge.launchpad.net/~lifeless/launchpad/private-librarian/+merge/31020 ?
[09:38] <lifeless> bigjools: or the oops one ?
[09:38] <lifeless> I can't see a comment on the private-librarian MP
[09:38] <bigjools> lifeless: 31508
[09:39] <lifeless> full url please ?
[09:40] <lifeless> bigjools: I've already put it on the wiki page a week ago ;)
[09:43] <bigjools> lifeless: teh cool
[09:45]  * thumper fixes the merge conflict
[09:46] <lifeless> \o/ https://bugs.edge.launchpad.net/ubuntu/+filebug is live with my tweaks
[09:47] <adeuring> lifeless: ok, I get it now. So, any estimate when you can land your librarian branch?
[09:48] <lifeless> adeuring: well my branch doesn't really help
[09:48] <lifeless> it has the same concern
[09:48] <lifeless> adeuring: I think what we can sensibly do for now is set cd:attachment on untrusted restricted objects.
[09:49] <lifeless> adeuring: this may require a new field on LFA, *or* a new view for how they are traversed.
[09:49] <adeuring> lifeless: right, that's the other option. I just wondered if this is worth the effort since your work would fix the problem as well
[09:49]  * thumper fixes stable -> db-devel conflicts
[09:50] <lifeless> adeuring: so my work will move the private content off the launchpad main domain
[09:50] <lifeless> adeuring: but it will still let private content attack other private content
[09:50] <adeuring> lifeless: right
[09:50] <lifeless> adeuring: so I think we should *also* take steps to make it less risky
[09:51] <adeuring> lifeless: makes sense. A variant of ProxiedLFA looks reasonable
[09:53] <stub> lifeless: Why doesn't your branch help? I thought with your work, restricted files would be served on the public port on its seperate domain.
[09:53] <stub> oic
[09:53] <lifeless> stub: it helps, but its not the full story
[09:53] <stub> But there is nothing to attack, as no cookies are set.
[09:53] <lifeless> stub: sadly there is
[09:53] <stub> stealing URL history or something?
[09:55] <stub> I guess we could use a wildcard and serve files from https://abctoken.launchpadlibrarian.net/123/foo.txt instead of https://launchpadlibrarian.net/123/foo.txt?token=abctoken
[09:55] <lifeless> stub: window A can access the DOM of window B
[09:56] <lifeless> thus the urls (and tokens) for other private content, and then submit that url encoded to $attckingstite
[09:56] <lifeless> stub: yes, wildcard dns is what I'm thinking will work.
[09:56] <lifeless> (Window A and window B have to be on the same domain for the above attack to work)
[09:57] <lifeless> stub: I was thinking https://contenthash.launchpadlibrarian.net/foo.txt?token=abctoken or something like that
[09:59] <stub> If you use the LFA.id, https://f123.launchpadlibrarian.net/foo.txt instead of the existing https://launchpadlibrarian.net/123/foo.txt, and allows us to rewrite existing URLs.
[09:59] <lifeless> stub: its rather late for me, but I'm totally keen on whatever permutation will work best for us
[10:00] <lifeless> stub: so if you'd like to shove that into the MP discussion on https://code.edge.launchpad.net/~lifeless/launchpad/private-librarian/+merge/31020 with any hints about what glue I'll need to piece it together, that would be cool.
[10:01] <stub> I think you want spiv or jml or someone who has worked with twisted http for the hints. I can add this discussion though.
[10:01] <lifeless> the twisted server internals I am fine on
[10:01] <lifeless> its more things like the dns setup, apache/squid changes etc - just a bookmark of the gotchas
[10:03] <lifeless> also, yay, bug filing searches seem solidly < 10 seconds to me now, on edge.
[10:03] <bigjools> lifeless and stub: can you bless the db patch and give me a number please: https://code.edge.launchpad.net/~julian-edwards/launchpad/buildd-failure-counting/+merge/31556
[10:05] <lifeless> what TZ is deryck in ?
[10:10] <lifeless> ah, us.
[10:14] <jkakar> bigjools: Are you pumped?!  Ready to have a great time!!!  https://code.edge.launchpad.net/~jkakar/storm/sqlobject-is-empty/+merge/31565
[10:20] <bigjools> jkakar: \o/
[10:21] <bigjools> jkakar: I think we should also fix the bug about removing the ordering on .any()
[10:21] <bigjools> lifeless is on a speed war
[10:22] <lifeless> \o/ phwoar
[10:25] <jkakar> bigjools: It's fixed in another branch and al-maisan had agreed to review it!
[10:25] <jkakar> Once that's done it'll land, hopefully today.
[10:25]  * al-maisan just approved that branch
[10:27] <bigjools> \o/
[10:27] <bigjools> jkakar: when will it be released?
[10:29] <lifeless> mpt: hai
[10:29] <mpt> oh hai
[10:29] <jkakar> bigjools: As a package, you mean?
[10:29] <jkakar> al-maisan: Thanks!
[10:29] <lifeless> mpt: I'm all excited - bugs.edge.launchpad.net/ubuntu/+filebug
[10:29] <lifeless> mpt: try it. Marvel at the speed.
[10:29] <lifeless> [actually, it still has lots of room to improve, but I'm easily pleased]
[10:30] <bigjools> jkakar: we use eggs for buildout
[10:31] <jkakar> bigjools: So you need a tarball, right?
[10:31] <bigjools> I guess so, I'm not that familiar with that stuff
[10:31] <jkakar> bigjools: Or I guess an egg, but we don't create those when we make releases as far as I know.
[10:31] <jkakar> bigjools: What would it take to start using the python-storm package?
[10:31] <mpt> lifeless, "lifeless is excited at the speed" returns suggestions in <2 seconds. "Ubuntu sucks" returns suggestions in ~13 seconds.
[10:31] <mpt> Pretty sure that's an improvement. :-)
[10:32] <jkakar> Also, fwiw, we use buildout and have it checkout lp:storm which works quite well, since we're always on trunk.
[10:32] <lifeless> mpt: yes, sadly 2 term searches will still be slow until we get a new search layer.
[10:32] <bigjools> jkakar: no idea!  I don't know the pros/cons of that versus what we do, someone from Foundations would know though.
[10:32] <bigjools> jkakar: interesting, I'll get gary to talk to you
[10:33] <jkakar> bigjools: Get him to talk to sidnei. :)
[10:33] <lifeless> mpt: as in, 2-term searches will be the slowest, if you graph speed vs term count
[10:33] <bigjools> jkakar: o7
[11:40] <bigjools> wgrant: howdy.  I don't suppose you've QA verified any of your fixes this cycle?
[11:41] <lifeless> stub: so, is a 'dba' bug tag ok with you?
[11:42] <stub> Sure, but I need to work out how to get GMail to flag them. I seem to require push methodologies :)
[11:42] <wgrant> bigjools: My stuff is just about impossible for me to QA.
[11:42] <bigjools> I figured :(
[11:43] <wgrant> Sorry.
[11:44] <lifeless> stub: ok, well I'll start marking up :)
[11:45] <lifeless> stub: would an rss feed work ?
[11:46] <stub> I always forget to check my RSS feeds :)
[11:46] <lifeless> hah, ok
[11:46] <lifeless> [me too]
[12:01] <lifeless> deryck: oh hai
[12:01] <deryck> lifeless, hey, man.
[12:06] <wgrant> So, I have a whole lot branches that need to be reviewed, just about no reviewers in my timezone, there's a lack of European OCRs, and American OCRs tend to knock them off the queue if you're not around.
[12:09] <jelmer> wgrant: I'm OCR tomorrow, should have some time to review them then.
[12:09] <wgrant> jelmer: Thanks.
[12:10] <lifeless> wgrant: also, I can review them all tomorrow.
[12:10] <lifeless> wgrant: I wasn't today because performance day!
[12:15] <jelmer> hmm, actually
[12:16] <jelmer> jtv: are you OCR as well tomorrow? Perhaps I should do Thursday this week as noodles is on holidays.
[12:16] <jtv> jelmer: yes, I'm on tomorrow
[12:16] <jtv> jelmer: I'll finish around mid-day for you though
[12:17] <jtv> Who removed installKarmaRecorder from TestCase?
[12:21] <jtv> Oh crap... the entire KarmaRecorder is gone.
[12:22] <jml> jtv, https://code.launchpad.net/~henninge/launchpad/bug-612583-test-errors/+merge/31546 is the only mention of KarmaRecorder in my mailbox
[12:22] <jtv> jml: we must not have been using it for a while.
[12:23] <jtv> jml: hmm... that mp says it was introduced in the recife branch.  I don't remember that; I thought it was older.  Thanks.
[12:23] <jml> jtv, np
[12:30] <wgrant> lifeless: Thanks.
[12:30] <wgrant> They're mostly small.
[12:36]  * lifeless -> sleep
[13:49] <didrocks> jml: hey, how are you?
[13:58] <jml> didrocks, hello, I'm well thanks.
[13:59] <didrocks> jml: I didn't have the time to talk to you before because of GUADEC last week and didn't see you at the sprint apart from the first day, did you have some time to have a look at the gpg/ssh/ppa api?
[14:00] <jml> didrocks, no, sorry. it's on my list though. I think the next step is creating a new permission level
[14:00] <jml> which maybe I can convince someone else to do
[14:01] <didrocks> jml: let's hope so, no hurry for now. I'll ask for a feature freeze exception on the Quickly side. Thanks :)
[15:56] <jelmer> mars: Hi
[15:57] <jelmer> mars: I've build a new EC2 image and would like to bless that as the new official image. As far as I can tell I've done everything mentioned on the wiki, but "ec2 test" locally is still using the old version.
[15:58] <jelmer> mars: I've added myself to the list of valid AMI owners, and made my image public.
[15:59] <jelmer> mars: Is there anything I might have forgotten?
[16:02] <bigjools> jml: thanks for the extra twisted tip BTW, that's sneaky
[16:03] <jml> bigjools: np. as I said, perfectly valid in tests and in some extremely rare real code cases.
[16:05] <mars> jelmer, gary_poster might know if the image is ready to go
[16:05] <mars> I haven't actually built one myself yet, but gary_poster and mwhudson have
[16:06] <mars> jelmer, ack, gary_poster is not around right now, but he should be back before your EOD I would suspect
[16:06] <gary_poster> I am, I am :-)
[16:06] <jelmer> mars: Ok, thanks!
[16:06] <jelmer> ah! Hi Gary
[16:06] <gary_poster> jelmer, hi. public image and valid AMI owner: sounds right to me
[16:07] <gary_poster> do you want me to see if I can see your image on the management console or something?
[16:08] <jelmer> gary_poster: It'd be great if you can check, although it is marked as public here.
[16:08] <gary_poster> k
[16:08] <jelmer> ami-217f9448 is the ID
[16:10] <jelmer> gary_poster: Sorry, unping. I've found the issue.
[16:10] <gary_poster> jelmer: cool.  fwiw, I couldn't find it
[16:10] <gary_poster> I mean, the ami
[16:11] <jelmer> the branch I was submitting didn't have myself added to the list of valid AMI owner IDs yet.
[16:11] <gary_poster> ah :-)
[16:12] <jelmer> gary_poster: sorry for the trouble, thanks for thinking along :-)
[16:12] <gary_poster> np :-)
[16:15] <james_w> could someone tell me what a reasonable check for calling removeSecurityProxy is?
[16:16] <gary_poster> james_w: "reasonable check"?
[16:16] <james_w> exactly
[16:16] <james_w> UnreasonableRemoveSecurityProxyWarning: Called removeSecurityProxy(<PackageUpload at 0xda8906c>) without a check if this is reasonable.
[16:16] <gary_poster> sorry, was intending to convey the idea that I didn't understand that part of the question
[16:16] <gary_poster> oh
[16:16] <james_w> neither do I
[16:17] <gary_poster> abel knows about that
[16:17] <gary_poster> he isn't around
[16:17] <gary_poster> deryck[lunch] knows about that...
[16:17] <gary_poster> of course, I'd grep for the error and see if the code path explained the intent
[16:18] <gary_poster> I'm supposed to be doing several other things so I'll leave that to you, I'm afraid
[16:18] <james_w> it appears to be rather than fixing the fallout caused by returning proxied objects
[16:21]  * james_w replaces it with removeSecurityProxy, I can't see any reason why that would be wrong
[16:24] <jml> james_w, hey
[16:24] <james_w> hi jml
[16:24] <jml> james_w, what that error means is that adeuring changed the code to use rSP but isn't sure whether it was appropriate
[16:25] <jml> james_w, so if it is appropriate to use rSP (which IMO basically it is in all cases in a test except when you're testing security) then change the call to removeSecurityProxy
[16:25] <james_w> right, this is in SoyuzTestPublisher, so if there is application code using it then we have bigger issues
[16:25] <jml> the alternative is to log in as an appropriate user
[16:26] <adeuring> jml, james_w: yes's what I meant: I simply added these calls mecahnically ust to ensure that tests do not fail due to added security proxies
[16:27] <jml> adeuring, thanks.
[16:27] <jml> maybe there's a better way of phrasing the warning...
[17:51] <rockstar> bigjools, is there an open bug about getting new build hardware?  I'd love to mark this bug as a dupe: https://bugs.edge.launchpad.net/launchpad-code/+bug/612177
[17:51] <_mup_> Bug #612177: Built daily? Really? <recipe> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/612177>
[17:52] <bigjools> rockstar: not on soyuz, no.
[17:55] <rockstar> bigjools, should there be?
[17:55] <bigjools> rockstar: it's not really a bug
[17:55] <bigjools> it's an RT
[17:56] <bigjools> however, we are working on some performance improvements but given the number of jobs versus number of builders, we're never going to win
[17:56] <bigjools> rockstar: search for the "buildfarm" and "buildd-manager" tags and see if any fit for a dupe
[18:55]  * rockstar waits forever for dogfood...
[19:24] <jml> abentley, if I wanted to fix bug 608114, would I need to change anything other than Diff.fromTrees in lp.code.model.diff?
[19:24] <_mup_> Bug #608114: Show modified class/method names in the diff of the merge proposals <code-review> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/608114>
[19:25] <abentley> jml, that's a request to stop using bzr to perform diffs and start using /usr/bin/diff.
[19:26] <jml> abentley, does bzr switch to using external diff only when external diff options are provided?
[19:26] <abentley> jml, yes.
[19:27] <jml> abentley, is there any reason we shouldn't be using external diff?
[19:27] <abentley> jml, bzr produces better diffs.
[19:28] <jml> abentley, I see.
[19:29] <abentley> jml, and bzr produces different diffs.  So people will see differences between the bzr output they produces locally and the diffs that Launchpad generates.
[19:29] <jml> abentley, I don't think last one is necessarily bad.
[19:30] <jml> abentley, producing worse diffs is enough to make me not want to go for the easy fix for the bug, though.
[19:30] <abentley> jml, variation breeds confusion.
[19:31] <jml> among other things
[19:31] <jml> I wish more things were easier.
[19:31] <benji> words to live by
[19:36] <jml> abentley, ok, thanks. I've commented on the bug, including a patch that fixes it in the bad way
[19:52] <jml> abentley, I just saw https://bugs.edge.launchpad.net/testrepository/+bug/611706 -- do you think something like the following would be readable?
[19:52] <_mup_> Bug #611706: Confusing output <Testrepository:New> <https://launchpad.net/bugs/611706>
[19:52] <jml> id=0, tests=21, failures=4 skips=1
[19:52] <jml> err... imagine there's a comma after the '4'
[19:53] <abentley> jml, yes, I think that would help me read it properly.
[19:56] <jml> abentley, thanks. I'll submit a patch.
[20:43] <jml> james_w, are you still being bitten bug 597060?
[20:43] <_mup_> Bug #597060: testr run should support limiting ids <testr-run> <Testrepository:New> <https://launchpad.net/bugs/597060>
[20:45] <james_w> jml: yes, in that I've learnt not to do it and so don't use testr as much
[20:45] <jml> hmm :(
[20:46] <jml> james_w: maybe I don't understand it then.
[20:46] <james_w> Rob wants to solve it by working on the bug called something like "$IDOPTION needs some thought"
[20:46] <james_w> jml: I just want to be able to do the parallel of "test run lp.code". With $IDLIST this runs the everything, and then the code tests the second time.
[20:47] <james_w> (not that it does that on LP, as LP uses IDOPTION, so I don't know what happens)
[20:49] <jml> ahh ok
[20:49] <jml> james_w, the source of my confusion is that I was unaware of how flexible .testr.conf files really are
[21:02] <mars> jml, quick silly question: how do I run tribunal from a fresh checkout?  The README doesn't say how.
[21:02] <jml> mars, ./bin/tribunal
[21:03] <jml> mars, ./bin/tribunal-subunit, actually
[21:03] <mars> hmm, no bin/ in the lp:tribunal checkout
[21:03] <jml> mars, my local copy appears to be out of date
[21:04] <mars> usefully out of date :)
[21:04] <jml> mars, ./tribunal-subunit, then
[21:04] <mars> jml, ok, thanks.
[21:05] <jml> (as an aside, Launchpad is a bit weird in that it's the only project I know that has binaries in bin/ that aren't intended for distribution)
[21:06] <mars> I run OpenKomodo mainline, and they have a project-specific bin/ for developers
[21:07] <mars> The project is built from Python and JS wrappers over Mozilla XUL, so it's a fairly large project, too
[21:10] <mars> ok, so "~/src/tribunal/tribunal-subunit ." works
[21:10] <mars> it picks up the .testrepository dir automagically
[21:47] <lifeless> moin
[21:47] <jml> lifeless, hi
[21:47] <lifeless> hi
[21:48] <jml> lifeless, I'd love to talk with you about all the stuff I just did to testrepository, but I also want to escape my computer.
[21:48] <lifeless> well
[21:48] <lifeless> you could ring me from your noncomputer
[21:49] <jml> nah, same thing. thanks though.
[21:49] <jml> lifeless, none of it's urgent, so I think I'll just sign off.
[21:49] <jml> have a good day
[21:49]  * jml off
[21:49] <lifeless> ok, ciao
[21:55] <james_w> I've just found two objects that don't correctly implement their interface, I wonder how many more there are
[21:59] <lifeless> N
[21:59] <lifeless> :P
[21:59] <wgrant> james_w: Lots of classes have verifyObject called on them.
[21:59] <wgrant> But I guess some do not.
[21:59] <wgrant> mars: Thanks for the reviews.
[22:00] <wgrant> mars: yes, lots of those doctests should be unit tests instead, but that basically requires a rewrite of a large portion of the Soyuz test suite.
[22:00] <thumper> morning
[22:00] <wgrant> That's going to take a while.
[22:02] <james_w> a "fun" task is going to be signing an upload during the tests so that an ubuntu series isn't hardcoded in the test data
[22:02] <james_w> though perhaps the best way to do that is to wait until that day that we remove the sampledata and use the factory to create a series with a matching name
[22:02] <wgrant> That was going to be my suggestion.
[22:03] <mars> wgrant, yep, I know.  Julian and I had a discussion about that very problem earlier today.
[22:03] <wgrant> mars: I dissect them where I can, but there's a lot left...
[22:03] <thumper> db-devel branch failing with testMemcachedWorking
[22:03] <thumper> anyone know of recent changes in that area?
[22:03] <mars> thumper, yep
[22:04] <mars> looking
[22:04] <thumper> ta
[22:04] <mars> Hurray for test suite instability!
[22:05] <mars> thumper, losas to fix both, I'll tell them.
[22:06] <thumper> mars: what do you mean?
[22:06] <mars> thumper, both builders are dead on test infrastructure failures
[22:07] <thumper> mars: jelmer is putting in an RT for the devel failure, old ec2 image I'm told
[22:07] <thumper> mars: not sure about the db-devel failure
[22:08] <mars> thumper, ah, that might do it
[22:08] <thumper> mars: jelmer was going to roll-back the last commit (that needs the new package)
[22:09] <mars> yep
[22:09] <mars> might not be that simple
[22:09] <mars> Tom updated that machine to Lucid, which means it's off EC2 now.  If that is true, then a new image won't help
[23:37] <mars> lifeless, ping, did the --load-list option for the zope testrunner get landed or released upstream?
[23:50] <mwhudson>  morning
[23:57] <lifeless> mars: I don't know
[23:58] <mars> ok