[00:19] <maxb> It would appear that Google Maps is rejecting Launchpad's requests
[00:19] <maxb> e.g. https://launchpad.net/people/+me
[00:23] <wgrant> Bug 624981
[00:23] <_mup_> Bug #624981: The Google Maps API server rejected your request <maps> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/624981>
[00:23] <lifeless> spm: when you are around, I want a profile please
[00:23] <spm> lifeless: your name is Rob, Your Y yrs old; live in Z ??
[00:31] <lifeless> spm: funny man :P
[00:31] <lifeless> spm: on staging
[00:31] <lifeless> as soon as it finishes updating
[00:31] <lifeless> I want to hit up https://api.staging.launchpad.net/1.0/bugs/414746/attachments
[00:31] <_mup_> Bug #414746: speakers cannot be muted when using headphones regression (karmic) <apport-bug> <apport-collected> <i386> <regression-release> <pulseaudio (Ubuntu):Confirmed> <https://launchpad.net/bugs/414746>
[00:33] <lifeless> also
[00:33] <lifeless> https://api.launchpad.net/1.0/1.0/bugs/414746/attachments/+login har!
[00:33] <_mup_> Bug #414746: speakers cannot be muted when using headphones regression (karmic) <apport-bug> <apport-collected> <i386> <regression-release> <pulseaudio (Ubuntu):Confirmed> <https://launchpad.net/bugs/414746>
[00:33] <lifeless> when an API times out
[00:34] <lifeless> it gives the usual OOPS
[00:34] <lifeless> with a link to login
[00:34] <lifeless> which then blows up
[00:39]  * spm is running out of tabs that aren't doing 'useful stuff' I may have to open a 2nd konsole of 16+ terminal tabs....
[00:41] <lifeless> did you say konsole?
[00:42] <spm> aye. best terminal around, I've found.
[00:43] <spm> tabs at the *bottom* <== biggest positive feature over any other I've found
[00:43] <lifeless> <- xterm
[00:43]  * wgrant quickly emails Ng.
[00:43] <lifeless> well, technically, uxterm.
[00:44] <spm> heh
[00:44] <spm> wgrant: i don't think he cares too much. and well, if it makes him cry? I see that as a plus.
[00:45] <spm> lifeless: so the restore is gtetting there; just doing the importds atm. maybe 5-15 mins eta?
[00:47] <lifeless> spm: cool cool
[01:06] <wgrant> The linter doesn't run henninge's thing, does it?
[01:06] <wgrant> Would be handy, to stop imports from going bad.
[01:07] <spm> lifeless: revised eta, another 5-15 mins. sigh. still going. looks to be doing stuff on the staging buildmaster...
[01:22] <lifeless> spm: hows it looking ?
[01:22] <spm> [10:22:28] <spm> staging codebrowse just went down, so must be getting closer...
[01:23] <spm> make build LPCONFIG=staging <== on multiple builds/machines. painfully slow. we should probably look into parallelising that. but /me worries about KISS and debugging obscure staging update woes.
[01:29] <lifeless> oh yay, db-devel merge failures
[01:29] <lifeless> and so it begins
[02:01] <thumper> lifeless: want to catch up?
[02:17] <mwhudson> spm: we really really shouldn't be running make build from scratch on every machine
[02:17] <mwhudson> that's just bong
[02:18] <spm> and wrong
[02:18] <lifeless> thumper: sure
[02:19] <lifeless> spm: I can haz profile ?
[02:19] <spm> one sec, working iwth u1 atm
[02:20] <spm> lifeless: asuka is doing the nightly.sh run, so be ware it will be slower than usual; if you consider that actually possible
[02:21]  * spm is still trying to unstack/pop about 4 levels of yesterdays interrupts... sigh/woe is me/ etc etc etc
[02:22] <lifeless> spm: yes I still want a profile
[02:25] <wgrant> LP needs a GitHub-like commercial offering.
[02:27] <lifeless> define that please
[02:31] <wgrant> At the moment, you need to get a private project set up manually and poke sysadmins and blah blah.
[02:31] <wgrant> And it's far more expensive than GitHub's cheaper offerings.
[02:33] <mwhudson> lp would also need to start supporting commercial customers better & it's not clear that this is a useful use of resources
[02:35] <wgrant> Well, there are no other bzr hosting solutions around.
[02:35] <wgrant> And GitHub is a really compelling reason to use Git.
[02:36] <persia> So the social benefit of causing more engineers to use bzr for their closed-source efforts is expected to outweigh the social benefit of making it easier to host open-source stuff?
[02:38] <wgrant> Well, the former would probably cause more wide-spread use of bzr.
[02:38] <wgrant> At the moment, if your company wants to use a DVCS, they are probably going to choose Git. Because GitHub is there. That's what I've heard so many people say.
[02:39] <maxb> Personally, I think bzr needs self-hostable hosting solution to properly enable corporate use of bzr
[02:39] <wgrant> For many cases, yes.
[02:42] <wgrant> win 41
[02:42] <wgrant> Gah.
[02:52] <lifeless> so, self hosted via self deployed LP is possible, but traumatic
[02:52] <lifeless> it would be nice if that was easier
[02:52] <lifeless> wgrant: that story does need to be easier; for sure.
[02:52] <wgrant> I guess we need Vostok, but ripping out everything but Codehosting instead.
[02:53] <lifeless> there was talk at one point of developing a self-hosted solution for bzr completely separate to LP
[02:54] <lifeless> spm: ping me when you're ready
[02:55] <thumper> lifeless: there was but it was shot down with a BIG gun
[02:56] <thumper> I didn't agree with the argument
[02:56] <thumper> I think there should be a simple deployable codehosting solution for corporates
[02:56] <thumper> based on bazaar
[02:57] <lifeless> spm: ping me when you're ready
[02:57] <spm> lifeless: timing is everything.was just loggng into asuka to set that up :-)
[02:59] <lifeless> thumper: I think there should be too. I would love it if it had common code with codehosting
[02:59]  * thumper nods
[03:03] <spm> lifeless: just about to restart app server
[03:04] <lifeless> duh da
[03:04] <lifeless> duh da
[03:04] <lifeless> duh da duh da duh da
[03:04] <spm> .... waiting.....
[03:04] <spm> yay. down.
[03:05] <spm> starting....
[03:05] <lifeless> I'm glad it starts up quickly
[03:06] <spm> it lives!
[03:06] <lifeless> ok, you can turn that off, thanks.
[03:06] <thumper> anyone fixing the merge conflict?
[03:06] <thumper> anyone?
[03:06] <spm> lifeless: you may wish to try again; it's only just started working, ish.
[03:06] <lifeless> if you can expedite the rsyncing of the trace and oops (OOPS-1700S32) that would be great.
[03:06] <thumper> beuler?
[03:06] <lifeless> thumper: its his day off
[03:06] <thumper> haha
[03:07] <lifeless> no, I'm not currently fixing it
[03:07] <spm> lifeless: all done? I'll restart
[03:07] <lifeless> spm: yes
[03:07] <spm> oki
[03:07] <lifeless> spm: though I won't know the quality till I get the files ;)
[03:07] <spm> nmp
[03:08] <spm> sorry. forgot the 'I wear evil horns' smily there... oh well, it was implied.
[03:08] <thumper> wallyworld: feel like trying out fixing the merge conflicts?
[03:08] <thumper> wallyworld: you can say no if otherwise engaged
[03:08] <spm> lifeless: they should be synced
[03:09] <thumper> lifeless: is "from datetime import datetime, timedelta" ok with our new import style?
[03:09] <thumper> lifeless: or do I have to put them on multiple lines?
[03:09] <lifeless> its fine
[03:09] <wallyworld> you mean some issues caused by my branch?
[03:10] <thumper> wallyworld: no
[03:10] <thumper> wallyworld: I mean the current merge failure between stable and db-devel
[03:10] <thumper> wallyworld: are you getting those failure emails?
[03:11] <lifeless> spm: hmm, i'm not seeing my oops :(
[03:11] <spm> lifeless: ahh. pebkac. one sec.
[03:11] <wallyworld> thumper: i've subscribed to canonical-launchpad digest but hadn't been looking in too much detail
[03:13] <thumper> wallyworld: ok, I'll fix it
[03:14] <wgrant> lifeless: I was under the impression that the exception was only in place for single-symbol imports.
[03:14] <lifeless> wgrant: < 78 chars or whatever
[03:14] <wallyworld> thumper: i don't mind doing it but if it's time critical then you will be faster than me. but i can look at it np
[03:14] <spm> lifeless: hrm. not pebkac; looks like a script buglet somewhere. but there now: /srv/launchpad.net-logs/staging/asuka/profiling/
[03:15] <thumper> wallyworld: I'm sure we'll get some practise next week
[03:15] <lifeless> wgrant: frankly I think any time spent talking about it is too much :)
[03:15] <thumper> I'll take this one
[03:15] <wgrant> lifeless: https://dev.launchpad.net/PythonStyleGuide?action=diff
[03:15] <lifeless> wgrant: sorted one per line when there are many gets better merge conflicts; when there aren't many, anyway its done is ok
[03:15] <lifeless> meh
[03:16] <lifeless> ok-by-me then
[03:16] <lifeless> spm: its thinking rather more now ;)
[03:17] <lifeless> spm: its almost like it hasn't been rsyncing since the 3rd
[03:17] <spm> lifeless: mmmm. possibly.
[03:17] <lifeless> -rw-r--r-- 1 robertc robertc 239303 2010-08-27 14:11 2010-08-03_02:04:49.560-MailingListApplication:MailingListAPIView-OOPS-1676S234-Dummy-3.prof
[03:17] <spm> I dod suspect a script buglet - we have a new shiny ponies script; so...
[03:17] <lifeless> was the newest file I had
[03:17] <lifeless> note - 27th was when I got it, 08-03 when it was made
[03:18] <spm> nod
[03:22] <lifeless> spm: I has it, thanks
[03:40] <lifeless> anyone familiar with bugs code around ?
[03:40] <wgrant> I know parts of it.
[03:40] <wgrant> What's the issue?
[03:40] <lifeless> https://bugs.edge.launchpad.net/malone/+bug/618849
[03:40] <_mup_> Bug #618849: Timeout accessing bugs' attachments using the API <timeout> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/618849>
[03:41] <lifeless> have a look at that to get the context where I'm looking
[03:41] <wgrant> Wow those are fat comments.
[03:41] <lifeless> mine?
[03:42] <wgrant> All comment fonts are huge. The CSS must be broken.
[03:42] <lifeless> you have the beta installed don't you ?
[03:42] <wgrant> Yeah.
[03:44] <wgrant> Is anybody working on the broken profile page thing?
[03:44] <lifeless> ?
[03:47] <wgrant> lifeless: All profile pages are broken due to the Google Maps thing.
[03:47] <wgrant> They pop up an alert().
[03:47] <lifeless> so, its a maps problem
[03:47] <lifeless> for now we're waiting to see if they resolve it
[03:47] <wgrant> Is it? The Google thing that Curtis mentioned looks irrelevant to me.
[03:47] <lifeless> AIUI
[03:48] <lifeless> why? didn't fit the symptoms ?
[03:49] <wgrant> Well, it seems specific to another Google service. But perhaps it is more general.
[03:49] <lifeless> omg
[03:49] <lifeless> omg omg omg omg omg
[03:49] <lifeless> lib/lp/bugs/browser/bug.py line 522
[03:50] <lifeless> *this is not safe*
[03:50] <wgrant> .....
[03:50] <wgrant> Haha.
[03:50] <lifeless> lets go and pull 140+ objects from the database
[03:50] <thumper> the font size issue is known
[03:50] <mwhudson> lifeless: oof
[03:50] <thumper> and being worked on I believe
[03:51] <mwhudson> lifeless: makes me think of some of this spec code
[03:51] <mwhudson> "find all specs named $x then filter out the ones that aren't targeted at $foo"
[03:51] <mwhudson> (fortunately given how specs are used this probably isn't so bad, but...)
[03:51] <wgrant> mwhudson: In Python, not SQL?
[03:52] <mwhudson> wgrant: yes
[03:53] <wgrant> Yay.
[03:55] <persia> mwhudson, specs get used (or not) the way they do because of the limitations of the impementation, rather than the intent of the users.
[03:55] <mwhudson> persia: well, maybe, but also it's actually unlikely that there are many specs in the system with the same name
[03:58] <persia> There are social conventions in place to avoid that, leading to exceedingly frustrating names for Ubuntu specs (${release-target}-${responsible-team}-${relevant-area}-${real-spec-name})
[03:58] <mwhudson> persia: well yeah, but even if you just used ${real-spec-name} i conjecture that there would be <10 duplicates for any given name
[03:59] <mwhudson> it's not like lifeless's code that could be getting 100s of objects for no good reason
[04:00] <persia> Potentially.  I was involved in the nomenclature discussion, but most example cases were 2-3 with the same name, rather than >10.  I agree it's good optimisation, I just think it's dangerous to base "how to design blueprints" based on current blueprints usage (as opposed to theory, which is safe)
[04:01] <spm> persia: you're not suggestion that stakeholders are consulted are you? that's: 1. crazy talk and 2. heresy!
[04:01] <mwhudson> persia: sure
[04:02]  * mwhudson has one of these "how does this code work at all" moments
[04:03] <persia> spm, No.  I'm just asking for blueprints design based on blue-sky theory, rather than partial analysis of current usage in an attempt to divine the potential desires of conceptual stakeholders.
[04:03] <mwhudson> awesome!
[04:03] <mwhudson> it doesn't
[04:04] <wgrant> mwhudson: What's broken?
[04:04] <wgrant> Apart from the entirety of Blueprint?
[04:05] <mwhudson> wgrant: go to add a dependency to a blueprint, click choose, type some text and search
[04:05] <mwhudson> though it's timing out for me actually, not exploding quite like i expected
[04:05] <persia> That's blueprints.  Expected behaviour
[04:06] <mwhudson> ok, it's not completely broken
[04:06] <mwhudson> just stupid
[04:10] <lifeless> mwhudson: can I encourage you to do one thing.
[04:10] <mwhudson> lifeless: sure
[04:10] <lifeless> mwhudson: add query-capped tests to the views you touch.
[04:10] <mwhudson> lifeless: um
[04:10] <lifeless> mwhudson: doesn't matter what the count is, just put a ratchet there ;)
[04:10] <mwhudson> heh
[04:10] <mwhudson> actually probably not touching any views really
[04:10] <mwhudson> but ok
[04:19] <lifeless> mwhudson: we currently have no insurance for query blowouts
[04:20] <lifeless> mwhudson: its all 'someone analysed this once and made it good', then something changes, and because our code has the property that what looks like good python performs terribly, *boom*
[04:21] <thumper> if I have a method that yields and is used as a generator
[04:21] <thumper> and I have an edge case where I don't want to yield anything
[04:21] <thumper> what do you do?
[04:21] <thumper> raise StopIteration?
[04:21] <lifeless> return
[04:21] <mwhudson> thumper: 'return'
[04:21] <lifeless> it will be a generator because of the yield statements
[04:21] <thumper> ok
[04:22] <lifeless> mwhudson: so anyhow, I think its sensible to put *an* insurance policy in place.
[04:23] <mwhudson> lifeless: ok
[05:09] <lifeless> what is salgado used for in tests ?
[05:11] <mwhudson> too much
[05:11] <mwhudson> the default webservice caller uses him i think
[05:11] <mwhudson> which is crazy, because he's an admin in sample data :(
[05:38] <thumper> how do we ask that we are running in a test environment?
[05:38] <thumper> I have a view that uses the slave store
[05:38] <thumper> but for my test I need to use the master
[05:38] <thumper> to see the new data
[05:39] <thumper> stub: any magic I can use?
[05:39] <wgrant> In Soyuz we just commit. It's ugly, but I think it's better than a special case that might break.
[05:40] <stub> thumper: Sounds like you need a database policy that returns the master store even when the slave is requested. I think there is one in dbpolicy.py already.
[05:41] <thumper> stub: where is that?
[05:41] <stub> thumper: nah.... need to add MasterOnlyDatabasePolicy - SlaveOnlyDatabasePolicy can be cargo culted for that.
[05:41] <stub> thumper: lib/canonical/launchpad/webapp/dbpolicy.py
[05:42] <stub> with MasterOnlyDatabasePolicy(): [...]
[05:42] <thumper> stub: this is for a pagetest, is your solution still sane?
[05:42] <stub> I don't know
[05:42] <thumper> I think the answer is no
[05:42] <thumper> can I ask the config which environment we are in?
[05:42] <thumper> is that sane?
[05:42] <thumper> or just insane?
[05:43] <stub> I've done it before, but then the code your testing isn't the code that will run on production
[05:43] <stub> How come you can't just commit the changes you made to the master so they are available to the slave?
[05:52] <thumper> I'll just commit
[06:23] <lifeless> hmm, exported_as doesn't work if there is an attribute with the same name that isn't exported.
[06:23] <lifeless> what project should I put the bug on? lazr.restful ?
[06:23] <mwhudson> yes
[06:30] <lifeless> https://bugs.edge.launchpad.net/lazr.restful/+bug/625102 \o/
[06:30] <_mup_> Bug #625102: exported_as does not handle overriding an unexported attribute <lazr.restful:New> <https://launchpad.net/bugs/625102>
[07:02] <noodles775> Morning
[07:33] <noodles775> thumper: When I want to split a pipe into two, i add a new pipe before the last one, then how did you interactively include only certain changes? It was something similar to shelve?
[07:34] <noodles775> thumper: sorry, just realised you've probably EOD. nm, enjoy your evening!
[07:35] <noodles775> Ah, merge -i... wonderful.
[07:35] <wgrant> Yep, merge -i is pretty awesome.
[08:14] <lifeless> wow
[08:14] <lifeless> adding one attachment adds 10 queries ><
[08:37] <adeuring> good morning
[11:37] <bigjools> stub: do you know if it's possible to use the result from store.execute() like a ResultSet?
[11:38] <stub> The interface is a little different
[11:38] <bigjools> I need it to work in the batch navigator
[11:38] <bigjools> so count and slicing is all that's needed I think
[11:38] <stub> It might work
[11:39] <bigjools> I shall give it a go then :)
[11:39] <stub> Otherwise convert it to a store.find   (store.find(Foo, SQL("hairy where clause")))
[11:39] <bigjools> (I'm trying to put the results of findBuildCandidate into a page)
[11:40] <bigjools> I doubt that would work, take a look at findBuildCandidate... :/
[11:48] <jkakar> FYI, am getting a Javascript alert complaining about an invalid Google Maps key when navigating to https://edge.launchpad.net/~nick-moffitt
[11:54] <stub> Are we using Vouchers or is that dead code?
[11:58] <wgrant> They're still used for commercial subscriptions, AFAIK.
[11:58] <jtv> lifeless: any reason why installFixture should not return its argument?
[12:24] <jtv> mrevell: Any comments on the help bubble so far?  I put the branch up for review, since it's a substantial code improvement in any case.  If there's anything you _hate_ about it I can still opt not to land, or if there's something that's not quite the way you want it then we can do that as a separate bug.
[12:36] <jtv> What's wrong with EC2?  I'm getting "remote host identification has changed" errors all the time, meaning I have to delete ~/.ec2/known_hosts again.  Also, startup takes ages.
[12:40] <jtv> Also, does anyone know how I can choose a different EC2 site?  I can think of one that must be at least 4 megameters nearer than the one I'm getting now.
[12:46] <jelmer> jtv: IIRC you can change EC2 sites in the console. IIRC there are only sites in east/west coast of the US and Europe though
[12:46] <jtv> jelmer: and singapore!
[12:46] <jtv> thanks
[12:47] <jtv> Singapore is quite, quite nearby in terms of internet infrastructure…  Some ISPs here will probably take traffic for a US EC2 _through_ Singapore.
[12:48] <jtv> (And then it gets slow due to poor bandwidth allocation, so in principle I could speed things up by running a proxy in the Singapore EC!)
[13:52] <davidstrauss> Where can I find the Bazaar SSH smart server integration into Twisted Conch?
[13:54] <davidstrauss> Is it the Poppy code?
[13:58] <jelmer> davidstrauss: Hi
[13:58] <davidstrauss> jelmer, hi!
[13:59] <jelmer> davidstrauss: No, poppy is the server code that's used for package uploads.
[13:59] <davidstrauss> jelmer, ah
[13:59] <davidstrauss> jelmer, what is the twisted daemon for branches?
[13:59] <jelmer> davidstrauss: My guess is lp.codehosting.sshserver
[14:02] <davidstrauss> jelmer, thanks
[15:44] <bdmurray> I received an error when trying to land a cherry pick on production devel that I could use some help sorting out
[15:45] <bdmurray> All lines of log output:["PQM Cannot merge between different VCSsystems.
[15:45] <bdmurray> 'bzr+ssh://bazaar.launchpad.net/~brian-murray/launchpad/cherry-pick-bug-modifier'(pqm.Baz1_1Handler) and
[15:45] <bdmurray> '/home/pqm/archives/rocketfuel/launchpad/production-devel'(pqm.Bazaar2Handler) are different
[15:45] <jelmer> bdmurray, are you sure 'bzr+ssh://bazaar.launchpad.net/~brian-murray/launchpad/cherry-pick-bug-modifier' exists?
[15:46] <jelmer> bdmurray, pqm seems to think there is a bazaar 1 ("baz") repository at that location
[15:48] <bdmurray> jelmer: yes, I'm sure - would the fact that it is a private branch affect it?
[15:48] <jelmer> bdmurray: probably - is the launchpad pqm able to access that branch?
[15:48] <jelmer> bdmurray: I think it has to be subscribed.
[15:48] <bdmurray> jelmer: no, I'll give that a shot then
[15:49] <bdmurray> that's a rather unhelpful error message
[15:51] <jelmer> bdmurray: It probably defaults to thinking there is a "baz" repository there if it can't find anything else.
[15:58] <bdmurray> jelmer: any idea how I could try resubmitting the branch?  bzr lp-land is failing since it is a private branch
[15:59] <jelmer> bdmurray: You can use "bzr pqm-submit", which is part of the bzr-pqm plugin.
[15:59] <jelmer> Alternatively, you should be able to construct a PQM email manually.
[16:38] <noodles775> bdmurray: you can subscribe launchpad-pqm to the branch and it should then work.
[16:39]  * noodles775 realises that's been tried.
[16:46]  * rockstar physically relocates
[18:54] <lifeless> morning
[19:02] <daker> hello
[19:03] <daker> can anyone explain to me what is this http://is.gd/eH471
[19:03] <daker> ?
[19:13] <lifeless> yes, we believe its a known outage at Google
[19:14] <lifeless> https://bugs.edge.launchpad.net/launchpad-registry/+bug/624981
[19:14] <_mup_> Bug #624981: The Google Maps API server rejected your request <maps> <Launchpad Registry:In Progress by sinzui> <https://launchpad.net/bugs/624981>
[19:14]  * sinzui is experimenting with a brute force use of featureflags to control gmp2
[19:15] <benji> I was thinking along the same lines.  Seems like a perfect use for them.
[19:16] <daker> lifeless, thanks
[19:19] <sinzui> benji, the controller objects are not all in production. I am writing my code to what I see in a production test instead of what is in our development tree
[19:19] <benji> mmm
[19:20] <lifeless> sinzui: \o/
[19:20] <benji> I would suppose your result will be trivially translatable to the real thing once it's deployed.
[19:20] <sinzui> yes
[19:20] <sinzui> this is not the first time google has failed us
[19:21] <sinzui> we talked about a way to toggle maps on/off last year
[19:27] <lifeless> sinzui: a flag ?
[19:28] <lifeless> ah
[19:28] <lifeless> thats what gmp2 is
[19:28] <lifeless> ?
[19:29] <sinzui> lifeless, there are many versions of gmap. we use a specific version. We need to track their version. Having flags for the version we want is ideal
[19:29] <lifeless> cool
[19:29] <lifeless> I think feature flags can return a value
[19:29] <lifeless> if they can't, its a small tweak to make them do so
[19:29] <lifeless> or you can use different flags, one for each version
[19:30] <sinzui> correct. We had some adventures shortly after we added maps and the versions changed.
[20:31] <cr3> if I run testr -t my_application, it seems that 62 tests match, so is there a way to specifically run the tests for my application?
[20:32] <lifeless> testr -- -p packagename
[20:33] <lifeless> it depends on your app structure really
[20:33] <cr3> lifeless: I'll give that a try
[20:34] <lifeless> its runnin bin/test under the hood
[20:40] <cr3> lifeless: ./bin/test --help seems to indicate that -p is for progress (where testr -- -p package gets translated to xvfb-run ./bin/test --subunit  -p package
[20:41] <lifeless> cr3: the -- says 'to the right, pass onto the test process
[20:41] <lifeless> cr3: I was told -p was package
[20:41] <lifeless> perhaps its -m you want
[20:41] <lifeless> anyway, all I'm saying is that its a bin/test problem for defining 'my application'
[20:42] <cr3> lifeless: heh, understood :)
[20:42] <lifeless> I'm no expert on bin/test :P
[20:44] <cr3> what's the difference between lib/lp/<application>/scripts/tests  and lib/lp/<application>/scripts, where both sometimes contain test_*.py files?
[20:45] <cr3> the first path is apparently recommended for containing tests as detailed here: https://dev.launchpad.net/Testing
[20:45] <cr3> actually, my mistake, scripts doesn't contain test_*.py files (not that I've seen anyways), my mistake. nevermind :)
[20:46] <lifeless> :P
[20:46] <cr3> lifeless: I'm obviously writing my first test for launchpad
[20:49] <cr3> lifeless: how can I use testr to show the details about the tests that were run instead of just the number of tests?
[20:50] <lifeless> apply one of jmls patches I haven't merged
[20:50] <lifeless> or
[20:51] <lifeless> subunit-ls < .testrepository/XX
[20:51] <lifeless> testr will show failures always
[20:52] <cr3> lifeless: looking good, thanks!
[20:58] <cr3> is there a document on dev.launchpad.net for modifying the database schema? I see lots of files under the database/schema directory and I could tentatively create a patch with a sequentially numbered filename, but I'm not sure that'll make everyone happy
[20:59] <salgado> cr3, https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess
[20:59] <cr3> nevermind, found the answer in the README file conveniently located under that directory
[20:59] <salgado> (from database/schema/README)
[20:59] <salgado> :)
[22:23] <cr3> I'm running preliminary tests and would like to access the database, so I'm using getUtility(IStoreSelector).get(MAIN_STORE, DEFAULT_FLAVOR). but, when I try to retrieve rows, I get: ProgrammingError: permission denied for relation result
[22:23] <cr3> might there be an obvious reason for this?
[22:31] <cr3> in a test, setting a breakpoint with pdb.set_trace() doesn't seem to show anything when running testr. should this be done otherwise?
[22:33] <lifeless> you haven't granted permission in security.py
[22:33] <lifeless> do that
[22:33] <james_w> cr3: are you running as a special db user do you know?
[22:33] <lifeless> and run make schema again
[22:33] <cr3> aha! nevermind that last question, running ./bin/test directly and not piping to testr load works fine
[22:33] <lifeless> cr3: ?! thats new, and I have no idea how that could be happening
[22:34] <cr3> james_w: I looked around for special db privileges and didn't find anything, but it certainly feels that way since I'm getting an error from storm execute
[22:35] <james_w> cr3: take a look at database/schema/security.cfg
[22:35] <james_w> there is where the permissions for various tables are granted to various users
[22:35] <james_w> if you aren't running a script in your test then it is likely that you are just running as the "launchpad" user
[22:36] <cr3> james_w: crap, I didn't get to step 13 yet in the database policy. my bad, thanks!
[22:36] <james_w> add public.result = SELECT, INSERT to [launchpad_main] and you should be good to go
[22:37] <cr3> james_w: awesome, I was just wondering how to prevent UPDATE and DELETE on the table so that solves another problem :)
[22:38] <cr3> james_w: while I have your attention, is there a special user with autocommit isolation level?
[22:38] <james_w> don't know
[22:38] <cr3> I'll grep around, that should be easy to find if such a user at least exists
[22:38] <james_w> you probably don't want that if you are running the webapp context are you?
[22:39] <cr3> in some cases, it is desirable to run some statements that way
[22:39] <james_w> well, you have transaction.commit()
[22:39] <james_w> you may want to defer some of your processing in to a script outside the webapp context
[22:39]  * james_w -> dinner
[22:40] <cr3> maybe I'll have a function that checks for the conflict exception, whatever that might be. lots of exploration to do, we'll see
[22:44] <cr3> security.cfg did the trick, thanks folks!