[08:01] <adeuring> good morning
[08:04] <mrevell> Guten morgen developertrons
[08:14] <lifeless> it is I, quasimodo
[10:30] <lifeless> question about the lp test runner
[10:31] <lifeless> if I have a test that fails in ec2
[10:31] <lifeless> given the test name
[10:31] <lifeless> whats the best way to run it locally
[10:35] <StevenK> lifeless: bin/test -vvt <name>
[10:44] <lifeless> StevenK: thanks
[10:44] <lifeless> StevenK: and common causes for it passing locally failing in ec2land ?
[10:47] <mwhudson> lifeless: ec2 land is hardy running python 2.5
[10:48] <lifeless> hmmm
[10:49] <mwhudson> at a guess anyway
[10:50] <StevenK> lifeless: I'd need to see the traceback
[10:51] <lifeless> easy done
[10:51] <StevenK> lifeless: There isn't really a bunch of common causes for stuff like this
[10:52] <lifeless> http://pastebin.org/383643
[10:52] <lifeless> I've merged devel to my branch locally, made no diff
[10:53] <lifeless> running: ./bin/test --subunit  -t test_runJobHandleErrors_oops_generated| testr load
[10:53] <lifeless> id: 46 tests: 19 skips: 2
[10:54] <mwhudson> oh
[10:54] <mwhudson> well, at least partly what's going on here is a glorious lack of test isolation
[10:55] <lifeless> aroo ?
[10:55] <lifeless> I'd like to make oops' generated by tests not hit disk at all
[10:55] <lifeless> but I don't want to make the patch bigger still
[10:55] <lifeless> as my focus is profiling, not oopses
[10:56] <mwhudson> otherwise it looks like a parenthesising bug?
[10:56] <mwhudson> if logid.isdigit() and (lastid is None or int(logid)  > lastid):
[11:00] <lifeless> hmm, worth trying for
[11:00] <lifeless> I guess different fs characteristics in ec2
[11:00] <lifeless> thanks!
[11:01] <lifeless> does ec2land land tip or 'approved revision'
[11:07] <mwhudson> tip i think
[11:07] <mwhudson> (sadly)
[11:07] <lifeless> \o/ I don't need to play silly-things
[11:07] <lifeless> mwhudson: oh, I got ec2land running outside
[11:08] <lifeless> mwhudson: nuked the paramiko check, apt-get installed boto; set pythonpath and manually made an ec2 file because its now glued into buildout and that blew up outside the vm.,
[11:09] <mwhudson> lifeless: congrats :)
[11:09] <lifeless> how much of that is mergable, do you think?
[11:16] <jml> hello everyone
[11:18] <wgrant> jml: Rabble rabble not open enough rabble rabble.
[11:18] <wgrant> *ahem*. Morning.
[11:18] <lifeless> wgrant: ?
[11:19] <wgrant> lifeless: Referencing a recent Facebook update.
[11:19] <lifeless> oh right
[11:19] <lifeless> clearly true
[11:30] <StevenK> lifeless: No fair complaining about a WIP MP
[11:33] <lifeless> StevenK: sorry - saw it come in, replied.
[12:06] <lifeless> bigjools: btw, not stalking, just subscribed :)
[12:07] <bigjools> lifeless: heh - prepare for email deluge
[12:07] <lifeless> bigjools: I have been for 6 years
[12:07] <lifeless> bigjools: I doubt you'll shock me today
[12:07] <bigjools> ok, continue delige
[12:07] <bigjools> deluge, even
[12:10] <wgrant> Speaking of being subscribed to merge proposals...
[12:11] <wgrant> Why do I get a rejection email from some lists.c.c address for every piece of merge proposal email I send?
[12:11] <lifeless> because we're muppets
[12:11] <wgrant> For LP, that is.
[12:11] <lifeless> yes
[12:11] <bigjools> matsubara is fixing that I thought - it's an artefect of the various ownerships
[12:11] <lifeless> there is a list representing reviewers
[12:11] <bigjools> artefact, evem
[12:11] <bigjools> oh fuck I can't type today
[12:11] <lifeless> that list has a contact address - the internal lp reviews list from when lp reviews started to get too much for the dev discussion list.
[12:12] <wgrant> Ah.
[12:12] <lifeless> and that list, has a not-c.c policy on it
[12:12] <lifeless> so it goes barf
[12:12] <lifeless> just deleting the contact address on the list should fix it.
[12:13] <wgrant> But won't that then spam all the members?
[12:13] <wgrant> Actually, I guess it would fix it.
[12:13] <wgrant> Since the people affected by the spam would be the people most empowered to fix it :P
[12:13] <lifeless> they can manage their influx by setting a personal subscription
[12:13] <lifeless> do no-mail, AIUI
[12:53] <lifeless> see you guys tomorrow
[13:46] <jtv> gary_poster: I think bug 534399 has fallen into a bit of a hole.
[13:46] <_mup_> Bug #534399: Windmill breaks branch-rewrite on dev systems <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/534399>
[13:48] <gary_poster> jtv: indeed, thanks for bringing it to my attention.  I'll get that back on track.
[13:49] <jtv> gary_poster: thanks for that!  Anything related to windmill or the build farm is probably a good candidate for smoothing out because the little complications there can be so devastating to our productivity.
[13:49] <gary_poster> jtv, agreed.
[13:58] <jkakar> FYI, just got this: bzr: ERROR: Invalid http response for https://xmlrpc.edge.launchpad.net/bazaar/: Unable to handle http code 502: Bad Gateway
[13:58] <jkakar> A service might need to be kicked.
[14:01] <bigjools> edge seems to be fairly borked
[15:05] <wgrant> jml: Regarding that email, is there not a work item missing for adding a new security level?
[15:05] <wgrant> Simply sending an email post-hoc is surely insufficient.
[15:06] <jml> wgrant, if you think so, please say so on the thread, since others seem to disagree with you.
[15:06] <lifeless> wgrant: why?
[15:06] <lifeless> (lets talk briefly now, and either save a round trip, or generate a more targeted mail)
[15:07] <wgrant> lifeless: Because I don't want most of my applications to be able to change my authentication tokens.
[15:07] <wgrant> Even if it tells me about it later.
[15:07] <wgrant> Allowing most apps to do that is *utterly stupid*.
[15:08] <wgrant> Even if I immediately revert it, there is a window there.
[15:08] <wgrant> A significant risk that can be avoided by simply adding a new privilege level.
[15:09] <lifeless> wgrant: ok, so you mean 'when allocating an oauth key, privileged things *also* require an explicit ACK from the user when allocating permissions'
[15:09] <lifeless> like
[15:09] <lifeless> read[/write] public
[15:09] <lifeless> read[/write] public+private
[15:09] <lifeless> read[/write] public+private+security-details
[15:09] <wgrant> read[/write] public
[15:09] <wgrant> read[/write] public+private
[15:09] <wgrant> allowed to steal my identity
[15:10] <wgrant> Yes, it's pretty bad even if a read/write token gets compromised. But it's not permanent-account-hijackingly bad.
[15:11] <wgrant> That level of risk should be minimised, surely.
[15:12] <lifeless> so I think you have a valid concern
[15:12] <lifeless> there are usability tradeoffs here.
[15:12] <wgrant> There is no question of this, surely.
[15:12] <wgrant> Yes, there are tradeoffs.
[15:13] <lifeless> ftr I don't think we *must* or *must not* do this.
[15:13] <wgrant> But I might point out what lots of Launchpad accounts have access to.
[15:13] <lifeless> I'd like to explain why
[15:13] <lifeless> lets say we add this new privilege level for oauth.
[15:13] <lifeless> quickly will *ask for it always*
[15:14] <lifeless> (because quickly wants to be able to do this if the user selects a menu item)
[15:15] <wgrant> I was hoping it would obtain a privileged token at the start and then drop privileges later. But even if not, it's better than my scripts everywhere being privileged.
[15:15] <lifeless> sure, no question of that.
[15:15] <lifeless> what might be ideal is a trusted dialog saying 'you sure?'
[15:16] <lifeless> the email is a way to ensure that no matter what, the user is told.
[15:16] <lifeless> frankly script privilege is pretty useless in oauth today; noone knows what level to grant, apps can't request a specific level, and its not got any granularity.
[15:17] <lifeless> Personally, given the choices of:
[15:17] <lifeless>  - quickly screen scraping in the users web context
[15:17] <lifeless>  - quickly using an API with an email audit notification
[15:17] <lifeless>  - quickly... with extra privilege level
[15:18] <lifeless> I really want to avoid the first at all costs.
[15:19] <lifeless> I'm not sure that the third is really all that nice a way to tackle credential-and-contact management access control for scripts; *my* inclination would be to do something where silent takeover is impossible as a starting point.
[15:21] <lifeless> wgrant: but your concerns are valid; raise them. I'm too tired to be creative right now :) - but others may not be, and there is always tomorrow. I'm glad that you only see this as 'add a small extra item', it means its mostly right.
[15:26] <lifeless> wgrant: I think what I'm getting at is that privilege escalation shouldn't be unrestricted nor indefinite, but [as currently implemented] this would, and users would invariably grant the wrong access to quickly.
[15:26] <lifeless> so I'd really like to see a creative solution
[15:26] <lifeless> that gave just enough access for just long enough and didn't add room for user error from users that *have never used LP before*
[15:34] <lifeless> sleep, take #2.
[17:05] <jtv> Does anyone know how I fix these problems starting the Librarian layer?  http://paste.ubuntu.com/459509/  I got them after an unexpected shutdown.
[17:26] <jtv> henninge: I just pushed the fix for test_helpers.
[17:26] <henninge> jtv: cool, thanks
[18:23] <jml> jtv, make sure all the librarian processes are dead and pid files are deleted.
[18:23] <jtv> jml: again?
[18:23] <jtv> After all the reboots, shutdowns, kills, make schema runs etc?
[18:23] <jml> jtv, well, that's what I'd do to try to fix the problem.
[18:23] <jtv> Well past that, I'm afraid.  :-(
[18:24] <jml> ok.
[18:24] <jml> jtv, what happens when you try to start the librarian manually?
[18:24] <jtv> It depends.  With the twistd commandline mars gave me, it ran without complaints.
[18:25] <mwhudson> jtv: what happens if you run ./bin/start_librarian ?
[18:25] <jtv> I tried "make start_librarian" which exits with:
[18:25] <jtv> Daemons cannot log to stdout, exiting!
[18:25] <jtv> Now trying bin/start_librarian
[18:25] <jtv> Gives me the same line.
[18:26] <jtv> Either way, it takes pretty long to reach that stage for some reason.
[18:27] <jtv> jml: remarkably, none of all this shows up in /var/tmp/librarian.log
[18:28] <jtv> That just stops where my system shut down unexpectedly Friday.
[18:28] <mwhudson> hm
[18:28] <jml> jtv, maybe that's a config=TESTRUNNER vs config=DEVELOPMENT confusion
[18:28] <jml> (except I think I got the case inverted)
[18:28] <jtv> :)
[18:29] <mwhudson> so basically start_librarian runs the same thing as the twistd line i gave you
[18:29] <mwhudson> oh well
[18:29] <mwhudson> it daemonizes i guess
[18:30] <jtv> But the twistd line worked.
[18:30] <jml> isn't the daemonizing thing important wrt tacrunner interactions?
[18:31] <mwhudson> jtv: ./bin/twistd --python daemons/librarian.tac --pidfile /var/tmp/librarian.pid --prefix Librarian --logfile /var/tmp/librarian.log
[18:31] <mwhudson> jml: but i think the librarian started by the test runner doesn't daemonize
[18:31] <mwhudson> may be wrong there
[18:31] <jtv> mwhudson: that returns quietly
[18:32] <jml> mwhudson, I don't know.
[18:32] <jml> I'm guessing that maybe there's something amiss with the way the tac runner is detecting that the librarian has indeed started.
[18:32] <jtv> mwhudson: yay!  that starts up the daemon.
[18:32] <jtv> This time, output appears in the log.
[18:32] <mwhudson> jtv: then you can have fun exploring the difference between what that does and what start_librarian did because i can't see that there should be any
[18:35] <jtv> mwhudson: and what's more, tests still break
[18:36] <mwhudson> jtv: maybe it is a development/testrunner thing like jml said
[18:37] <jtv> jml, any idea how I would test that?  On "make run" things seem to start normally but references to librarian files still give me an error in the browser.
[18:37] <jml> jtv, take a working command and do LPCONFIG=testrunner working-command
[18:37] <jml> jtv, alternatively, if it's make, then "make working-command LPCONFIG=testrunner"
[18:38] <jml> for reasons that elude my poor little mind.
[18:38] <jtv> Trying the same tests
[18:38] <jtv> jml: I think the former should also work, but make has a feature of allowing the setting of variables in its command line like this.
[18:38] <jtv> Hmm... the tests still break with LPCONFIG=testrunner
[18:39] <jml> oh, that's why I said "working command"
[18:39] <jml> if it's "breaking command", then do LPCONFIG=development :)
[18:40] <jtv> The absence of a "working command" was thwarting me :)
[18:40] <jtv> "make run" and tests both break.
[18:40] <jml> I thought you had two things to compare
 mwhudson: yay!  that starts up the daemon.
[18:40] <jml> oh now I see
[18:40] <jml> never mind
[18:40] <jml> anyway, if the tests break with both configs in the same way, then it's not a config issue :)
[18:40] <jtv> Well frankly I don't...  I thought the daemon might keep running.
[18:41] <jml> or not a config selection issue, rather.
[18:41] <jml> jtv, you've probably been through this already, but you are doing all of this testing against one of the stable branches, right?
[18:41] <jtv> They fail in _exactly_ the same way, far as I can see.  Shouldn't the tests fail from all other sorts of horrible problems with the wrong config?
[18:42] <jtv> jml: no, though the same problems occur in both.
[18:46] <jml> jtv, which subset of the tests are you running?
[18:46] <jtv> jml: I've been running various subsets of Translations tests.
[18:47] <jml> jtv, the least I can do is try running the same subset locally against db-stable to guarantee that it is indeed a problem with your local configuration
[18:47] <jtv> From trunk, and now from db-stable.
[18:47] <jtv> I'm fairly sure it is, given that it started happening across an unexpected system shutdown.
[18:48] <jtv> I'm currently setting up a test branch based on db-stable.
[18:50] <jtv> jml: this produces it on a devel-based branch: ./bin/test -vv -m lp.registry -t test_milestone
[18:50] <jtv> now trying db-stable as well
[18:50] <jtv> Oh blast, that wants another "make schema"
[18:54] <jtv> jml: same result on db-stable.
[19:09] <jtv> jml: what's really strange is that now my librarian seems to be running, but I'm still getting the same error.
[19:09] <jtv> And still nothing from lsof -i TCP:111...  is it on the wrong port perhaps?
[19:12] <jtv> Ah... the librarian I have running now listens on the ports set up in the development config, not the ones in the testrunner config.
[20:15] <maxb> Hrm :-/
[20:15] <maxb> sinzui's pocket-lint throws errors on apt-installation
[20:19] <maxb> We didn't officially de-support hardy as a LP dev platform yet, did we?
[20:29] <lifeless> maxb: we're still deployed on hardy, so I sure hope not.
[20:30] <lifeless> maxb: OTOH All the canonical staff should be on Lucid anyhow; so they'd need hardy vms...
[20:30] <maxb> sinzui's new linter only runs on python 2.6
[20:30] <lifeless> heh
[20:30] <lifeless> I hope thats not in the deployment code path.
[20:33] <maxb> Only in lp-dev-deps on lucid for now, but it breaks the ability to sync lp-deps versions across all distroseries
[20:33] <lifeless> yeah
[20:33] <lifeless> is it an external package
[20:34] <lifeless> (you imply that, I'm checking for clarity)
[20:34] <maxb> Built in sinzui's personal PPA, copied into the launchpad PPA
[20:35] <lifeless> is it a new custom package or a maverick backport? [I'm wondering where to file a bug on it]
[20:36] <maxb> Fully custom so far
[20:45] <rockstar> maxb, the lp-dev-deps don't get deployed to production. IS has their own packaging (AFAIK)
[20:46] <rockstar> maxb, I was running a hardy chroot for a long time, until those packages brokedededed
[20:46] <maxb> Indeed, but lp-deps and lp-database-deps and lp-soyuz-deps build from the same source ... and AFAIK the LP PPA is still supposed to be workable on hardy
[22:03] <abentley> rockstar, thumper: There's a power outage in my area, which means I'm tethering, which means I can't use irc.canonical.com's unorthodox port number.
[22:03] <thumper> abentley: ok
[22:03] <rockstar> abentley, does that also mean no mumbling?
[22:03] <thumper> abentley: can you mumble?
[22:04] <abentley> rockstar, thumper: Haven't tried yet.  I do have fring on my phone if that doesn't work.
[22:04] <thumper> abentley: I'm in mumble now if you want to try