[00:29] <poolie> spm, when you have a spare few minutes could you look over https://dev.launchpad.net/LEP/DKIMAuthenticatedMail from a LOSA's point of view?
[00:33] <spm> poolie: tbh, I don't know a lot about dkim. but the reasonings for, sound fine to me. it's not perfect (what is...), but afaict from the cases there, will assist a large chunk of users. +½, given my ignorance on the full topic.
[00:36] <poolie> thanks
[01:02] <Ursinha-afk> is it just me or it isn't possible to login to staging right now?
[01:03] <lifeless> wgrant: do you mean 'beta is breaking'?
[01:03] <spm> Ursinha-afk: it's not just you. I have the same problem. I believe it's known.
[01:04] <Ursinha-afk> oh...
[01:05] <Ursinha-afk> spm, you're not sure it's known? I'm considering filing a bug for that
[01:05] <Ursinha-afk> what do you think?
[01:05] <spm> Ursinha-afk: :-) file it anyway. worst case LP QA will mark it as a dupe. :-P
[01:05] <spm> tbh, I thought it was just me. but if you're having issues too, perhaps not.
[01:06] <Ursinha-afk> spm, just found out trying to validate a token to use lpapi
[01:06] <spm> nod
[01:07] <Ursinha-afk> and it explodes as a django error, not an oops
[01:47] <ScottK> poolie: In answer to yesterday's question: A dkim signature covers a lot more of the message than a gpg signature.  The one case I've managed to see real success data of a large enterprise trying to do dkim verification on a second tier MTA and not on the border it had a significantly lower verification reliability than cases where I've seen it done on the border MTA.
[01:48] <ScottK> So yes, I think there's an unintended transformation in there, but experience tells me they are hard to avoid entirely.
[02:01] <poolie> ok
[02:01] <poolie> that's useful data
[02:01] <poolie> i saw a post the other day about exchange breaking signatures
[02:02] <poolie> and my first attempt at a test broke because when the message is parsed and unparsed the headers come back re-flowed
[02:04] <poolie> ScottK, i'm kind of hoping we have less of the 'enterprise' software that mangles messages
[02:04] <poolie> imbw
[02:36] <ScottK> poolie: I think it's more to do with verify at the border or internally.  The other issue with internal verification is that not only do you not have to break the signatures now, you have to make sure future changes don't either.  Not an issue if you verify at the border.
[02:36] <ScottK> poolie: Did you add the test messages to the python-dkim bug?  I don't recall seeing the bugmail?
[02:38] <poolie> ScottK, sorry not yet
[02:38] <poolie> haven't worked on it again yet
[02:38] <poolie> it's just itch-scratching/curiousity, not actually my job
[02:38] <ScottK> OK.  As long as it's not forgotten, not a big deal, you just won't get progress on the bug until I get it.
[02:38] <ScottK> OK.
[02:39]  * ScottK looks around to see what's his job.
[02:45] <poolie> k
[04:41] <lifeless> \o/ timeouts
[04:41] <lifeless> spm: can you sync edge oops please?
[04:41] <lifeless> OOPS-1615EC395
[04:42] <spm> done
[04:42] <spm> and not found. wonderful.
[04:42] <lifeless> \o/
[04:42] <lifeless> is it me?
[04:43]  * spm is tempted to say yes, but that'd be the evil talking
[04:50] <lifeless> https://bugs.edge.launchpad.net/oops-tools/+bug/589007
[04:51] <mup> Bug #589007: oops OOPS-1615EC395 not found by lp-oops web ui <OOPS Tools:New> <https://launchpad.net/bugs/589007>
[04:53] <mwhudson> it's there now
[04:53] <lifeless> grr
[04:54] <lifeless> spm rsunc it
[04:54] <lifeless> and it didna work
[04:55] <lifeless> anyhow
[04:55] <lifeless> 10410360ms
[04:55] <lifeless> thats 104  10360ms
[04:55] <lifeless> SELECT COUNT (CASE WHEN BugTask.status = 10 THEN BugTask.id ELSE NULL END), COUNT (CASE WHEN BugTask.status = 15 THEN BugTask.id ELSE NULL END), COUNT (CASE WHEN BugTask.status = 20 THEN BugTask.id ELSE NULL END), COUNT (CASE WHEN BugTask.status = 21 THEN BugTask.id ELSE NULL END), COUNT (CASE WHEN BugTask.status = 22 THEN BugTask.id ELSE NULL END), COUNT (CASE WHEN BugTask.status = 25 THEN BugTask.id ELSE NULL END) FROM BugTask
[04:56] <mwhudson> lotsa ubuntu bugs to count up
[04:58] <thumper> stub: hi
[04:58] <stub> yo
[05:01] <thumper> stub: review poke for abentley's branch
[05:02] <lifeless> another timeout
[05:10] <lifeless> stub: hows the db looking; getting timeouts on edge on fairly routine things
[05:11] <lifeless> like filing a bug on the launchpad project, in the 'related bugs' search
[05:12] <mwhudson> oh
[05:12] <stub> Nothing traumatic. Load of under 10, log lag. Fair bit or replication going on.
[05:12] <mwhudson> well
[05:12] <stub> c/log lag/low lag
[07:53] <stub> Now, on the other hand, we are having load issues...
[07:54] <stub> fiera, karma calculater, garbo-daily, lucille all running at the same time.
[07:54] <lifeless> oops
[07:59] <stub> So OOPS-1615EA901 (trying to view a merge proposal) caused by load I think
[08:00] <lifeless> SELECT %s FROM (SELECT BranchRevision.branch, BranchRevision.id, BranchRevision.revision, BranchRevision.sequence FROM BranchRevision WHERE BranchRevision.branch = 352323 AND BranchRevision.sequence IS NOT NULL AND BranchRevision.revision NOT IN ( SELECT revision FROM BranchRevision WHERE branch = 34755) ORDER BY BranchRevision.sequence DESC LIMIT 1) AS "_tmp" LIMIT 1
[08:00] <lifeless> thats what took 17 seconds
[08:00] <lifeless> I'd guess lock contention rather than sheer load
[08:00]  * lifeless handwaves
[08:11] <adeuring> good morning
[10:18] <krkhan> can anyone point me to the method for manually calculating the ssha hashes used for accounts?
[10:25] <jelmer_> when is PQM going to be opened again?
[10:29] <krkhan> openldap's slappasswd generates ssha hash but it still doesn't login
[10:31] <thumper> jelmer_: did you see the chicken git import failure log?
[10:32] <jelmer_> thumper: hi
[10:33] <lifeless> krkhan: sha hashes? where
[10:34] <jelmer_> thumper: looking
[10:34] <thumper> jelmer_: thanks
[10:34] <krkhan> lifeless: i'm running a local launchpad. i can't login for the default admin@canonical.com account for some reason (invalid email/password). so i thought maybe i changed the passwd and forgot
[10:35] <krkhan> i guess manually editing the accountpassword table would make things work. but i don't know how to correctly calculate the ssha hash used
[10:36] <lifeless> AFAIK launchpad no longer stores any passwords
[10:36] <thumper> krkhan: the local password should be 'test'
[10:36] <thumper> jelmer_: pqm opens when the release manager is happy :)
[10:37] <krkhan> thumper: i used to login with 'test' before. it's not logging in with that any longer
[10:37] <thumper> krkhan: what did you change?
[10:39] <jelmer_> thumper: I can reproduce it locally, but no idea what it's caused by
[10:39] <krkhan> thumper: not the password at least. let me recheck using a previous snapshot of the vm
[10:39] <thumper> jelmer_: some fun debugging then :)
[10:39] <jelmer_> thumper: can you file a bug against bzr-git ?
[10:40] <thumper> sure, but probably tomorrow :)
[10:50] <krkhan> thumper: it refuses to login with admin@canonical.com and test. and i haven't changed anything
[10:50] <thumper> krkhan: I'd run 'make clean schema' and try again
[10:52] <noodles775> krkhan: ^^^ assuming you don't care about any data in the launchpad database.
[10:53] <krkhan> thumper, noodles775: i don't. anything that works will be fine. trying make clean schema
[10:57] <lifeless> thumper: how does local auth work; didn't SSO split it all out ?
[10:58]  * thumper shrugs
[10:58] <thumper> I don't know how it wors
[10:58] <thumper> works
[10:58] <bigjools> o/
[11:05] <thumper> yes bigjools?
[11:05] <bigjools> just saying hi
[11:06] <thumper> oh hi
[11:06] <krkhan> thumper: worked perfectly. thanks :-)
[11:06] <thumper> krkhan: I have no idea why though
[11:06] <thumper> krkhan: make clean schema is my reset button
[11:11] <maxb> ooi, when does the db-devel>devel mergeback happen?
[11:18] <bigjools> maxb: when the release manager decides it can happen, usually when we open PQM after a re-roll, if that happens at all.
[12:52] <wgrant> lifeless: The data is still in the DB -- and LP still has a test OpenID provider which uses that data.
[12:53] <wgrant> Eventually Account will probably die, and testopenid will just have to ask for an email address and no password.
[13:19] <deryck> gmb or adeuring , can one of you help me interpret bad test documentation please?
[13:19] <adeuring> deryck: I can try ;)
[13:19] <deryck> adeuring, see http://pastebin.ubuntu.com/443974/
[13:19] <deryck> adeuring, what "marker" does this test refer to?
[13:20] <adeuring> deryck: I think this means the text "This bug is a duplicate of..." (just concludning from the test output)
[13:21] <deryck> adeuring, ah, ok.
[13:21] <deryck> adeuring, I was thinking so special email foo something or other.  That makes sense.
[13:22] <deryck> printing a ga-jillion emails out in doctest, however, does not. :-)
[13:22] <adeuring> ;)
[13:22] <deryck> adeuring, thanks
[14:07] <svaksha> nigelb: hi
[14:09] <svaksha> bryceh: i was told thatat you have developed a crawler which allows data from LP to be pushed upstream in to a bug tracker. I was looking for a webcrawler which allows data to be entered into forms (ala the kind of crawlers blog spammers use to leave comments)
[14:28] <svaksha> did i miss a reply to my query, /me was disconnected
[14:31] <jml> maxb, thanks for the great bug report
[14:58] <deryck> svaksha, bryceh doesn't really have a crawler.  He has a cgi script that gets bug data from LP and creates an upstream bug report from the data.
[15:02] <svaksha> deryck: thanks. that is probably not what i am looking for
[15:04] <deryck> svaksha, np.  cheers.
[15:09] <svaksha> deryck: i'm trying to test MM lists for errors thatcrop up after some new featureswere implemented. see, http://abiwt.org/mailman/listinfo/dlist-583379
[15:11] <deryck> svaksha, ok, interesting.  How does this relate to Launchpad data?
[15:11] <svaksha> sorry, that is why i didnt mention it earlier
[15:12] <svaksha> umm...i didnt know what bryceh's crawler does. i was told about it so asked to see if it would be useful
[15:22] <deryck> Does any still find make lint output useful?
[15:24] <bigjools> deryck: only if I intend to fix it :)
[15:25] <bigjools> I use a pyflakes vim plugin now, so I tend to pick most lint up immediately.
[15:26] <deryck> bigjools, I used to find make lint useful when I started on lp, but it has become increasingly noisy and always pointing at stuff unrelated to what I'm working on...
[15:26] <deryck> which makes me wonder if anyone actually uses it.
[15:26] <bigjools> deryck: it used to be rigorously enforced
[15:27] <bigjools> doesn't seem like it is any more
[15:27] <deryck> bigjools, by buildbot?  Or just in review?
[15:27] <bigjools> deryck: reviews
[15:27] <bigjools> I'd mention it in the next reviewers' meeting
[15:27] <deryck> yeah, I think I will.
[15:28] <deryck> bac, I can update the wiki, but I'd like to bring up the above ^^ about make lint in the next reviewers meeting.
[15:29] <bac> deryck: i find make lint useful, if noisy
[15:30] <deryck> bac, are you ok with me bringing this up in the reviewers meeting, i.e. to ask if we're enforcing lint checks at review and asking if the output of make lint could be made better?
[15:30] <bac> deryck: for the people that use our supported tools to create MPs, the lint report is always included and is handy for the reviewer.  increasingly i see developers not using 'bzr send' and writing subpar MPs that don't include lint output nor many of the needed sections.
[15:30] <bac> deryck: definitely
[15:31] <deryck> bac, yeah, I'm using bzr lp-propose-merge now, which doesn't include lint output like the bzr send plugin.
[15:34] <deryck> make lint gone bad:  http://pastebin.ubuntu.com/444066/  :-)
[15:49] <mars> deryck, IIRC there was a discussion on the dev list recently where sinzui talked about his improved lint scripts.  They would be nice to land, but his release duties are blocking that.
[15:50] <deryck> mars, yeah, that would be cool to land.
[15:50] <sinzui> My scripts are now gedit plugins. Some work is needed to make them scripts again
[15:51] <deryck> maybe I should just get bigjools pyflakes plugin for vim.
[15:52] <deryck> I tend to watch carefully myself and just like the post-work lint check.
[15:52] <bigjools> the plugin is fabulous
[15:52] <bigjools> it's on vim.org
[15:52] <mars> deryck, yes, you should use that plugin.  I don't use vim anymore, but I still give it a huge +1 :)
[15:52] <mars> I would love to recreate it for Komodo
[15:52] <deryck> ok, I'll grab it here shortly then.
[15:53] <deryck> I still think it's worth having a sane make lint, though.  Just for easy run against a branch we're reviewing.
[15:53] <jelmer> emphasis on "sane" :-)
[18:39] <gary_poster> deryck[lunch]: Are hwdb questions like this appropriate for the bugs team:  https://answers.edge.launchpad.net/launchpad/+question/113350 ?  If not, any ideas on where I should send it?
[19:24] <deryck> gary_poster, yup, completely fine for malone.
[19:26] <gary_poster> thanks deryck
[20:11] <bryceh> whenever I try to load https://dev.launchpad.net in my browser, it redirects me to the last page on that site I viewed, instead of taking me to the homepage.  Anyone else seeing this behavior?
[20:42] <jml> bryceh, no
[21:30] <lifeless> sinzui: ping
[21:30] <sinzui> hi lifeless
[21:30] <lifeless> sinzui: bugs are too low bandwidth, I could feel myself getting into itty-bitty mode
[21:30] <lifeless> the oops thing
[21:30] <lifeless> I'd like to know why you feel/think that its not a coding issue
[21:31] <lifeless> I mean, I can see that we have data to fix *too*, but surely the code should have behaved better given the data we gave it.
[21:31] <sinzui> about Lp identifying reserved names from the db and reserved names in the code and verifying that the object can have the name and that the user can access the object with the name
[21:32] <sinzui> That is a hard problem
[21:32] <lifeless> yeah, and filtering from searches appropriately; blacklisting isn't any harder than privacy, is it ?
[21:32] <lifeless> (he says knowing that privacy isn't all that easy :P)
[21:33] <sinzui> from the db perspective, no, because it is acl/privacy and we do handle it.
[21:33] <sinzui> from the code, we need some way to register the names in traversal and their type to verify they can be used.
[21:33] <sinzui> I think the policy was to ensure the names in the code are added to the db
[21:35] <sinzui> I am pretty sure that did not happen with 'oops' statik had no problems using his project last year. I do not know when we changed the code the break his project
[21:37] <lifeless> so there is a bit of code that lists <names>
[21:37] <lifeless> and a db table that also lists <names> ?
[21:38] <sinzui> yes.
[21:38] <lifeless> I guess what I'm saying is this: how do we fix this so that it doesn't happen again; deleting the project only fixes this instance, not the cause of the confusion behaviour and spurious oops
[21:38] <sinzui> Yes
[21:39] <lifeless> I was assuming we'd need to enforce a blacklist somewhere we weren't, but if I understand you correctly, there's actually 2 lists that are meant to be identical, and aren't.
[21:39] <sinzui> I do not know when or what in the app claims 'oops'
[21:39] <lifeless> there is a ++oops++ handler
[21:39] <lifeless> which triggers an explicit soft oops
[21:39] <lifeless> could that be it ?
[21:40] <lifeless> If so, perhaps the oops project *isn't meant* to be blacklisted
[21:40] <lifeless> its just a victim of thumper's work to let devs trigger oops on demand, to see where db time is going.
[21:40] <sinzui> possibly
[21:41] <lifeless> how do we check the db list of blacklisted names ?
[21:41] <lifeless> if oops isn't in there, and isn't in the app list of blacklisted names, then its not really a blacklist issue
[21:41] <lifeless> its a webapp-overusing-a-name issue
[21:41] <sinzui> that is an open bug. we do a sql query. We want a page to view and edit them.
[21:42] <lifeless> ok
[21:42] <lifeless> losa ping
[21:42] <mbarnett> hello lifeless
[21:42] <lifeless> we're like to get the current list of blacklisted projects from the db please
[21:42] <lifeless> s/we're/we'd/
[21:42] <sinzui> Our fields block admins from renaming a project to a blacklisted name when we know we must do it. They do a sql update to make it happen
[21:45] <lifeless> mbarnett: I don't know the right query to run, if its not in the LOSA pages, sinzui can supply it
[21:46] <sinzui> lifeless, I see the data on staging
[21:46] <lifeless> ok cool
[21:47] <lifeless> mbarnett: sorry, you're not needed :)
[21:47] <lifeless> sinzui: so, is oops in the list of blacklisted projects?
[21:47]  * sinzui still looking for the table
[21:47] <lifeless> :) ok
[21:49] <rockstar> sinzui, do you know how I create a browser for a person that isn't logged in.
[21:49] <sinzui> anon_browser?
[21:49] <lifeless> is that different to logged in anonymously?
[21:50] <sinzui> you can just import it from testing.pages I think
[21:50]  * sinzui reads code to find the table
[21:52]  * sinzui is an idiot
[21:53] <sinzui> lifeless, oops is not in the table
[21:53] <lifeless> ok
[21:54] <lifeless> and its not defined as a blacklist in the app either, its just the ++oops++ trigger?
[21:55] <rockstar> sinzui, I'm not using a pagetest, but a unit test, so it's not available in some evil globals thing.
[21:57] <thumper> rockstar: just call setupBrowser()
[21:57] <thumper> rockstar: with no auth, it is anon
[21:58]  * mbarnett is both glad and sad he is not needed.
[22:01] <sinzui> lifeless,  I lost power just as I was typing that oops is not in the table.
[22:01] <sinzui> rockstar, import setupBrowser() from canonical.launchpad.testing.pages. calling it without arguments return anon_browser
[22:02] <lifeless> 08:53 < lifeless> ok
[22:02] <lifeless> 08:54 < lifeless> and its not defined as a blacklist in the app either, its just the ++oops++ trigger?
[22:02] <rockstar> sinzui, got it, thanks.
[22:02] <sinzui> lifeless, I think so
[22:03] <lifeless> in which case
[22:03] <lifeless> I think a better phrasing of the bug is
[22:04] <lifeless> 'non blacklisted webapp hooks subtly break search'
[22:04] <lifeless> and then we have two related questions
[22:04] <lifeless>  - can we enumerate these hooks (to make an automated cross-check that the db blacklists things that users cant use anyway)
[22:05] <sinzui> But I cannot access "oops" from statik's pages, or from the list commercial project either
[22:05] <lifeless>  - could we change the oops one so that it only triggers as ++oops++ and doesn't cause this broken traversal
[22:05] <lifeless> sinzui: right, somethings clearly going wrong here, but I think is unintentional fallout from the ++oops++ support
[22:06] <sinzui> yes, and we can certainly make the same mistake again
[22:06] <lifeless> right
[22:07] <lifeless> so I'd like to keep one of the bugs open saying 'we should have some code that helps prevent this sort of mistake'
[22:07] <sinzui> yes, I agree that is the bug
[22:07] <lifeless> and if possible, another saying '++oops++ does not need to break the /oops/ project - but perhaps that is hard :- I don't know as I haven't looked into it.
[22:08] <sinzui> It may be knowable if Navigation always uses @stepto and @step, but I am certain there are exceptions
[22:09] <thumper> sinzui: is it really conflicting?
[22:09] <thumper> I'd be surprised
[22:09] <lifeless> thumper: visit launchpad.net
[22:09] <lifeless> thumper: search for oops
[22:09] <lifeless> click on statik's project name there
[22:10] <lifeless> you get a 404 with an oops generated
[22:10] <lifeless> thumper: oops isn't blacklisted in the db, nor in the code from what sinzui could see
[22:11] <thumper> that's the whole reason the namespaces have ++ on each end
[22:11] <thumper> I'm not sure why this is happening
[22:11] <lifeless> indeed
[22:11] <lifeless> I'm going to redraft the bugs to be clearer
[22:11] <mwhudson> lifeless: the oops generation is not mysterious
[22:11] <lifeless> about the generic and specific issues, assuming they are separate
[22:11] <thumper> I'd ask gary_poster, him being a zope master and all :)
[22:11] <mwhudson> lifeless: it's because the referrer is a launchpad url
[22:12] <lifeless> mwhudson: oh right
[22:12] <mwhudson> so we can stop talking about that
[22:12] <lifeless> mwhudson: thanks
[22:12] <lifeless> mwhudson: FWIW I only mentioned it here to address thumpers 'is it really conflicting' question
[22:12] <sinzui> but we are getting about zope person right? there are always two, but which is the master
[22:12] <mwhudson> i thought i said this last night, but maybe my wifi falling over
[22:12] <lifeless> mwhudson: which a simple 404 isn't very convincing about
[22:12] <mwhudson> ok
[22:12] <lifeless> mwhudson: yes, you did, and I know.
[22:13] <mwhudson> sorry for the noise then :)
[22:13]  * gary_poster sees name but nothing to which to respond
[22:13] <lifeless> mwhudson: but I was tired last night :)
[22:13] <lifeless> gary_poster: there is a oops hook in the webapp
[22:13] <gary_poster> for generating oopses you mean?
[22:13] <lifeless> which handles ++oops++ - e.g. lp.net/launchpad/++oops++
[22:13] <lifeless> generates a soft oops
[22:13] <lifeless> yes
[22:13] <lifeless> however
[22:14] <lifeless> it seems that lp.net/oops which is a real project, not blacklisted, is denied access and we think its due to the oops handler existing.
[22:15] <gary_poster> oh!  I suppose "it shouldn't be" is a bit of an obvious reply :-)
[22:15] <gary_poster> perhaps, "why do you think so?" would be better
[22:15] <lifeless> well
[22:15] <gary_poster> that would imply to me that we should be able to dupe on a dev system
[22:15] <gary_poster> lemme try that
[22:15] <lifeless> we know of the following mechanisms to make 404s
[22:15] <lifeless> blacklists
[22:15] <lifeless> deleting things
[22:15] <lifeless> and bugs
[22:15] <lifeless> its not blacklisted
[22:15] <lifeless> its not deleted
[22:16] <lifeless> so must be a bug :)
[22:16] <gary_poster> :-)
[22:20] <lifeless> I haven't setup my dev VM to let me connect to it from the outside host yet, I've just been doing in-place unit testing :( I really should get around to that.
[22:23] <lifeless> gary_poster: does it happen for you locally?
[22:23] <lifeless> we're getting way to many Searching for your bug in Launchpad took too long. Try reducing the number of words in the summary field and click "Check again" to retry your search. Alternatively, you can enter the details of your bug below.
[22:24] <gary_poster> lifeless: I decided to update post-PQM so...things are just ready to start up now post make schema.  Will report back.
[22:24] <gary_poster> post PQM opening I mean
[22:25] <lifeless> I gotcha
[22:26] <gary_poster> lifeless: it is reproducible locally
[22:26] <lifeless> I've updated the bug report
[22:26] <lifeless> sinzui: thanks for teasing this apart with me
[22:26] <sinzui> your welcome
[22:30] <lifeless> gary_poster: so, do you think its the ++oops++ thing, or something different?
[22:31] <gary_poster> lifeless, not sure.  Should be a different code path, of course, but obviously something is wrong, and it's the same string, so....  since we've talked about it, I'm doing a pdb to look around.
[22:31] <lifeless> cool! thanks
[22:33] <gary_poster> yes, most definitely this has something to do with the namespace (Zope considers ++*++ to be a URI namespace mechanism).  The failure is specifically that it can't fine an "index.html" for the OopsNamespace object.
[22:33] <gary_poster> find
[22:37] <lifeless> gary_poster: but lp.dev/oops shouldn't be going into the ++oops++ code, should it ?
[22:37] <gary_poster> nope
[22:37] <gary_poster> possibly a registration error.
[22:56] <gary_poster> oddly, editing one branch and running a branch doesn't accomplish much.
[22:56] <gary_poster> running a different
[22:59] <gary_poster> lifeless: so, the ++oops++ url is registered in an odd way.  It's the problem.  I'll fix it up tomorrow.
[22:59] <gary_poster> night all
[23:33] <bdmurray> Is there some way to run 2 specific tests with bin/test?  something like bin/test -cvvt bugtask-search.txt patches-view.txt ?
[23:35] <lifeless> yes
[23:36] <lifeless> if you've got a failure back from ec2, you can just unzip the subunit log to .testrepository/failing and do testr run --failing
[23:37] <bdmurray> I'm working on this branch and I've modified two tests and just want to run those 2 tests ...
[23:38] <bdmurray> I haven't done anything with ec2 yet
[23:43] <lifeless> try bugtask-search without the .txt
[23:43] <lifeless> if you know the testid you can use --load-list and a file listing ids, one-per line
[23:45] <bdmurray> lifeless: the testid?
[23:45] <lifeless> yes, all tests have a unique test id
[23:45] <lifeless> I don't know what it is for doctests
[23:49] <wgrant> bdmurray: bin/test -cvvt bugtask-search.txt -t patches-view.txt
[23:49] <wgrant> You need the second -t.
[23:50] <lifeless> wgrant: thanks, I'll try to remember that :)
[23:50] <wgrant> (-t's argument is actually a regex, but one normally just uses test names or fragments)
[23:51] <bdmurray> wgrant: great, I couldn't think of a regex that would hit both of those tests.