=== Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [08:01] good morning [08:04] Guten morgen developertrons [08:14] it is I, quasimodo === almaisan-away is now known as al-maisan [10:30] question about the lp test runner [10:31] if I have a test that fails in ec2 [10:31] given the test name [10:31] whats the best way to run it locally [10:35] lifeless: bin/test -vvt [10:44] StevenK: thanks [10:44] StevenK: and common causes for it passing locally failing in ec2land ? [10:47] lifeless: ec2 land is hardy running python 2.5 [10:48] hmmm [10:49] at a guess anyway [10:50] lifeless: I'd need to see the traceback [10:51] easy done [10:51] lifeless: There isn't really a bunch of common causes for stuff like this [10:52] http://pastebin.org/383643 [10:52] I've merged devel to my branch locally, made no diff [10:53] running: ./bin/test --subunit -t test_runJobHandleErrors_oops_generated| testr load [10:53] id: 46 tests: 19 skips: 2 [10:54] oh [10:54] well, at least partly what's going on here is a glorious lack of test isolation [10:55] aroo ? [10:55] I'd like to make oops' generated by tests not hit disk at all [10:55] but I don't want to make the patch bigger still [10:55] as my focus is profiling, not oopses [10:56] otherwise it looks like a parenthesising bug? [10:56] if logid.isdigit() and (lastid is None or int(logid) > lastid): [11:00] hmm, worth trying for [11:00] I guess different fs characteristics in ec2 [11:00] thanks! [11:01] does ec2land land tip or 'approved revision' === henninge_ is now known as henninge [11:07] tip i think [11:07] (sadly) [11:07] \o/ I don't need to play silly-things [11:07] mwhudson: oh, I got ec2land running outside [11:08] 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] lifeless: congrats :) [11:09] how much of that is mergable, do you think? [11:16] hello everyone [11:18] jml: Rabble rabble not open enough rabble rabble. [11:18] *ahem*. Morning. [11:18] wgrant: ? [11:19] lifeless: Referencing a recent Facebook update. [11:19] oh right [11:19] clearly true [11:30] lifeless: No fair complaining about a WIP MP [11:33] StevenK: sorry - saw it come in, replied. [12:06] bigjools: btw, not stalking, just subscribed :) [12:07] lifeless: heh - prepare for email deluge [12:07] bigjools: I have been for 6 years [12:07] bigjools: I doubt you'll shock me today [12:07] ok, continue delige [12:07] deluge, even [12:10] Speaking of being subscribed to merge proposals... [12:11] Why do I get a rejection email from some lists.c.c address for every piece of merge proposal email I send? [12:11] because we're muppets [12:11] For LP, that is. [12:11] yes [12:11] matsubara is fixing that I thought - it's an artefect of the various ownerships [12:11] there is a list representing reviewers [12:11] artefact, evem [12:11] oh fuck I can't type today [12:11] 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] Ah. [12:12] and that list, has a not-c.c policy on it [12:12] so it goes barf [12:12] just deleting the contact address on the list should fix it. [12:13] But won't that then spam all the members? [12:13] Actually, I guess it would fix it. [12:13] Since the people affected by the spam would be the people most empowered to fix it :P [12:13] they can manage their influx by setting a personal subscription [12:13] do no-mail, AIUI === Ursinha-afk is now known as Ursinha [12:53] see you guys tomorrow === Ursinha-afk is now known as Ursinha [13:46] 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 [13:48] jtv: indeed, thanks for bringing it to my attention. I'll get that back on track. [13:49] 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] jtv, agreed. [13:58] 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] A service might need to be kicked. [14:01] edge seems to be fairly borked [15:05] jml: Regarding that email, is there not a work item missing for adding a new security level? [15:05] Simply sending an email post-hoc is surely insufficient. [15:06] wgrant, if you think so, please say so on the thread, since others seem to disagree with you. [15:06] wgrant: why? [15:06] (lets talk briefly now, and either save a round trip, or generate a more targeted mail) [15:07] lifeless: Because I don't want most of my applications to be able to change my authentication tokens. [15:07] Even if it tells me about it later. [15:07] Allowing most apps to do that is *utterly stupid*. [15:08] Even if I immediately revert it, there is a window there. [15:08] A significant risk that can be avoided by simply adding a new privilege level. [15:09] 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] like [15:09] read[/write] public [15:09] read[/write] public+private [15:09] read[/write] public+private+security-details [15:09] read[/write] public [15:09] read[/write] public+private [15:09] allowed to steal my identity [15:10] Yes, it's pretty bad even if a read/write token gets compromised. But it's not permanent-account-hijackingly bad. [15:11] That level of risk should be minimised, surely. [15:12] so I think you have a valid concern [15:12] there are usability tradeoffs here. [15:12] There is no question of this, surely. [15:12] Yes, there are tradeoffs. [15:13] ftr I don't think we *must* or *must not* do this. [15:13] But I might point out what lots of Launchpad accounts have access to. [15:13] I'd like to explain why [15:13] lets say we add this new privilege level for oauth. [15:13] quickly will *ask for it always* [15:14] (because quickly wants to be able to do this if the user selects a menu item) [15:15] 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] sure, no question of that. [15:15] what might be ideal is a trusted dialog saying 'you sure?' [15:16] the email is a way to ensure that no matter what, the user is told. [15:16] 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] Personally, given the choices of: [15:17] - quickly screen scraping in the users web context [15:17] - quickly using an API with an email audit notification [15:17] - quickly... with extra privilege level [15:18] I really want to avoid the first at all costs. [15:19] 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] 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] 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] so I'd really like to see a creative solution [15:26] 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] sleep, take #2. === Ursinha is now known as Ursinha-fud [17:05] Does anyone know how I fix these problems starting the Librarian layer? http://paste.ubuntu.com/459509/ I got them after an unexpected shutdown. === abentley is now known as abentley-lunch === matsubara is now known as matsubara-lunch [17:26] henninge: I just pushed the fix for test_helpers. [17:26] jtv: cool, thanks === salgado is now known as salgado-lunch === Ursinha-fud is now known as Ursinha [18:23] jtv, make sure all the librarian processes are dead and pid files are deleted. [18:23] jml: again? [18:23] After all the reboots, shutdowns, kills, make schema runs etc? [18:23] jtv, well, that's what I'd do to try to fix the problem. [18:23] Well past that, I'm afraid. :-( [18:24] ok. [18:24] jtv, what happens when you try to start the librarian manually? [18:24] It depends. With the twistd commandline mars gave me, it ran without complaints. [18:25] jtv: what happens if you run ./bin/start_librarian ? [18:25] I tried "make start_librarian" which exits with: [18:25] Daemons cannot log to stdout, exiting! [18:25] Now trying bin/start_librarian [18:25] Gives me the same line. [18:26] Either way, it takes pretty long to reach that stage for some reason. === salgado-lunch is now known as salgado === matsubara-lunch is now known as matsubara [18:27] jml: remarkably, none of all this shows up in /var/tmp/librarian.log [18:28] That just stops where my system shut down unexpectedly Friday. [18:28] hm [18:28] jtv, maybe that's a config=TESTRUNNER vs config=DEVELOPMENT confusion [18:28] (except I think I got the case inverted) [18:28] :) [18:29] so basically start_librarian runs the same thing as the twistd line i gave you [18:29] oh well [18:29] it daemonizes i guess [18:30] But the twistd line worked. [18:30] isn't the daemonizing thing important wrt tacrunner interactions? [18:31] jtv: ./bin/twistd --python daemons/librarian.tac --pidfile /var/tmp/librarian.pid --prefix Librarian --logfile /var/tmp/librarian.log [18:31] jml: but i think the librarian started by the test runner doesn't daemonize [18:31] may be wrong there [18:31] mwhudson: that returns quietly [18:32] mwhudson, I don't know. [18:32] 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] mwhudson: yay! that starts up the daemon. [18:32] This time, output appears in the log. [18:32] 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] mwhudson: and what's more, tests still break [18:36] jtv: maybe it is a development/testrunner thing like jml said [18:37] 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] jtv, take a working command and do LPCONFIG=testrunner working-command [18:37] jtv, alternatively, if it's make, then "make working-command LPCONFIG=testrunner" [18:38] for reasons that elude my poor little mind. [18:38] Trying the same tests [18:38] 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] Hmm... the tests still break with LPCONFIG=testrunner [18:39] oh, that's why I said "working command" [18:39] if it's "breaking command", then do LPCONFIG=development :) [18:40] The absence of a "working command" was thwarting me :) [18:40] "make run" and tests both break. [18:40] I thought you had two things to compare [18:40] mwhudson: yay! that starts up the daemon. [18:40] oh now I see [18:40] never mind [18:40] anyway, if the tests break with both configs in the same way, then it's not a config issue :) [18:40] Well frankly I don't... I thought the daemon might keep running. [18:41] or not a config selection issue, rather. [18:41] 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] 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] jml: no, though the same problems occur in both. [18:46] jtv, which subset of the tests are you running? [18:46] jml: I've been running various subsets of Translations tests. [18:47] 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] From trunk, and now from db-stable. [18:47] I'm fairly sure it is, given that it started happening across an unexpected system shutdown. === abentley-lunch is now known as abentley- === abentley- is now known as abentley [18:48] I'm currently setting up a test branch based on db-stable. [18:50] jml: this produces it on a devel-based branch: ./bin/test -vv -m lp.registry -t test_milestone [18:50] now trying db-stable as well [18:50] Oh blast, that wants another "make schema" [18:54] jml: same result on db-stable. [19:09] jml: what's really strange is that now my librarian seems to be running, but I'm still getting the same error. [19:09] And still nothing from lsof -i TCP:111... is it on the wrong port perhaps? [19:12] Ah... the librarian I have running now listens on the ports set up in the development config, not the ones in the testrunner config. === jtv is now known as jtv-afk === al-maisan is now known as almaisan-away === flacoste_afk is now known as flacoste [20:15] Hrm :-/ [20:15] sinzui's pocket-lint throws errors on apt-installation [20:19] We didn't officially de-support hardy as a LP dev platform yet, did we? === matsubara is now known as matsubara-afk [20:29] maxb: we're still deployed on hardy, so I sure hope not. [20:30] maxb: OTOH All the canonical staff should be on Lucid anyhow; so they'd need hardy vms... [20:30] sinzui's new linter only runs on python 2.6 [20:30] heh [20:30] I hope thats not in the deployment code path. [20:33] Only in lp-dev-deps on lucid for now, but it breaks the ability to sync lp-deps versions across all distroseries [20:33] yeah [20:33] is it an external package [20:34] (you imply that, I'm checking for clarity) [20:34] Built in sinzui's personal PPA, copied into the launchpad PPA [20:35] is it a new custom package or a maverick backport? [I'm wondering where to file a bug on it] [20:36] Fully custom so far [20:45] maxb, the lp-dev-deps don't get deployed to production. IS has their own packaging (AFAIK) [20:46] maxb, I was running a hardy chroot for a long time, until those packages brokedededed [20:46] 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 === lifeless changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 4 of 10.06 | PQM is RC; devel is open | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews | Use http://paste.ubuntu.com/ for pastes === mars changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 4 of 10.06 | PQM is RC; devel is open | | Release Manager and R-C wrangler: mars | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews | Use http://paste.ubuntu.com/ for pastes [22:03] 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] abentley: ok [22:03] abentley, does that also mean no mumbling? [22:03] abentley: can you mumble? [22:04] rockstar, thumper: Haven't tried yet. I do have fring on my phone if that doesn't work. [22:04] abentley: I'm in mumble now if you want to try === salgado is now known as salgado-afk === Ursinha is now known as Ursinha-dinner