[00:00] bigjools: "requested to review" [00:00] It's the reviewer [00:00] Not a subscriber [00:00] so that overrides sibscription settings saying not to email? [00:00] sigh [00:00] ok how do I stop this? [00:00] it doesn't override, its direct notification [00:00] remove maas-lander from maas-maintainers [00:00] Set a team email address [00:00] Or remove maas-lander from maas-maintainers, yeah [00:01] put maas-lander and maas-maintainers both in ~canonical-launchpad-branches or a similar branch-only-access team [00:01] then it won't be able to land stuff [00:01] lifeless: that's basically a way for evil js to get at http-only cookies isn't it? [00:01] man this stuff is over complicated [00:01] thats *why* we have that structure in LP, and why I encouraged you to use the same teams, or the same structure, for MAAS :) [00:01] lifeless: I understand - or rather I don't understand why it needs to be so complex :( [00:01] mwhudson: http://en.wikipedia.org/wiki/CRIME_%28security_exploit%29 [00:02] lifeless: "It relies on the attacker being able to observe the size of the ciphertext sent by the browser while at the same time inducing the browser to make multiple carefully crafted web connections to the target site." [00:02] lifeless: if you can do that, you can just carefully craft the results to do evil directly, surely? [00:02] mwhudson: yes, but the demonstration is terrifying [00:03] it's a super cool hack [00:03] mwhudson: no, you can't [00:03] mwhudson: No [00:03] mwhudson: By crafting part of a body I can reveal the headers [00:03] eg. if I control a string embedded deep in JSON somewhere [00:04] !!!!!! I can't set a contact address that is the same as another team's [00:04] bigjools: I wouldn't go the contact address route [00:04] bigjools: it gets super messy. [00:04] ... [00:05] I was going to redirect email to launchpad-reviewers [00:05] This is already super-messy, and the complex team structure doesn't make it any less messy [00:05] exactly wgrant [00:05] MP notifications are fundamentally broken [00:05] It's always going to be messy until they're fixed [00:06] I don't understand the arbitrary refusal to set the contact address to be the same as another team [00:06] that's bizarre [00:06] It's not arbitrary [00:06] It's less than ideal [00:06] But it's certainly not arbitrary [00:06] the error on screen should say why instead of appearing to be arbitrary [00:06] Launchpad doesn't just use it as a contact address [00:06] It's also used to look up the team [00:06] Mostly by Soyuz [00:06] headdesk [00:07] * bigjools sets contact address to devnull@example.com [00:07] Good luck confirming that :) [00:08] bollocks, it ignored it! [00:08] this is fucking infuriating :/ [00:08] wgrant: I agree that things could be better, but given the *current code base* I think the simplest way to manage it is leaf teams for things that do stuff, and organisational teams put into those. [00:08] wgrant: arguing that its broken just aknowledges that it is. [00:08] is this recommended structure documented anywhere on the lp wiki? [00:09] wgrant: the other reason to do it the same way as LP is that it would be the same way as LP [00:09] bigjools: https://dev.launchpad.net/CreatingNewProjects [00:09] thanks [00:09] lifeless: Sure, but that requires renaming branches everywhere [00:09] lifeless: So it's far less destructive to set a contact address [00:09] wgrant: ah, that is a cost to moving, yes. [00:09] which will hurt. [00:10] lifeless: not sure that page helps [00:10] bigjools: I don't think we captured the how-we-got-there anywhere other than the list archives :( - sorry! [00:10] I have to run, shopping trip to do [00:10] lifeless: :( [00:11] back soon, good luck solving your headache. [00:11] my 2c before I go [00:11] - make a new team -reviewers and copy the direct member list from -maintainers to -reviewers [00:11] make it the reviewer [00:12] make it owned by -maintainers [00:12] and refactor to remove duplication post-release. [00:17] * bigjools made launchpad-reviewers the reviewer [00:18] My inbox thanks you [00:19] lp-reviewers was a member of the old team anyway [00:19] Yeah [00:19] But now I'll get less mail :) [00:19] that was the idea :) [00:22] also, when I change the status of an MP to approved it'd be really nice if it either warned about new versions not in the page or just approved them anyway [00:22] :/ [00:45] zomg its a statik [00:53] 2012-09-25 22:55:56 INFO Outage complete. 0:00:01.818455 [00:53] getting there [00:53] (from the latest staging update) [00:54] What, too long? [00:55] No reason for it to take more than a couple of hundred milliseconds [00:56] StevenK: yeah [00:57] security.py is most of the remaining time, I believe [00:59] StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-1056506/+merge/126358 === matsubara is now known as matsubara-afk [01:01] wgrant: r=me [01:01] StevenK: Thanks [01:02] wgrant: I heartily approve of lines 61-69 [01:02] Yeah... [01:06] libreoffice starts -fast- on SSD [01:18] 2012-09-26 01:17:38 INFO Resetting permissions. [01:18] Security took 0.780465126038 [01:18] 2012-09-26 01:17:38 INFO Enabling access to launchpad_dev_master. [01:18] 2012-09-26 01:17:38 INFO Outage complete. 0:00:00.888748 [01:18] So security.py is indeed probably most of it [02:12] 327 / 0 DistroSeries:EntryResource:getBuildRecords [02:12] 321 / 0 Person:+specworkload [02:12] :( [02:22] Why do we get a PQM success mail at 11:59 and then a failure at 12:04? [02:25] StevenK: There are lots of mail delays [02:25] StevenK: So buildbot-poll sends the email [02:25] It gets stuck in a queue [02:26] 5/10 minutes later, buildbot-poll sees there's still stuff to merge [02:26] Sends the email [02:26] Mail queue unclogs, PQM processes both [02:26] I look forward to when we can kill buildbot-poll [02:42] * StevenK stabs lxc [03:35] wgrant: LXC is impenetrable. [03:35] StevenK: Howso? [03:36] I don't understand it at all! [03:36] I know parts of it all too intimately. [03:36] What is it doing to you? [03:36] I destroyed the ec2 instance in disgust before lunch, but the lxc-setup-build script in examples was hanging [03:37] StevenK: Did you have a base container set up properly? [03:37] And where was it hanging? [03:38] lxc-wait -n or so, I think [03:38] And base container? [03:38] See previous statement about impenetrability. [03:38] lp-setup-lxc-build relies on there being a base container already [03:38] It builds LP inside a container [03:39] You can use lpsetup to create this container [03:41] I wonder if we need more 'this is how its all put together' docs for this [03:44] Yeah [03:44] Particularly since the in-DC setup is different [03:44] I suspect we'll be able to pull together docs from me watching StevenK trip over everything :) [03:45] Oh. Yay? [03:46] StevenK: So, do you understand the high-level fundamentals of how parallel testing is implemented for LP today? [03:46] I suspect few outside lifeless, I, Yellow, and some ops, do [03:47] But I'm not sure how much you've picked up on [03:47] As it's all a bit complicated [03:47] wgrant: We create 20 containers run a portion of the tests in them, and testr interleaves it all together into a useful subunit stream [03:47] StevenK: Right [03:48] Now, the 20 containers aren't all created from scratch each time [03:48] They're ephemeral (created by the aptly named lxc-start-ephemeral) as clones of a base container [03:49] This base container has LP code+deps+DB etc in it. [03:49] And it's persistent [03:49] lxc-start-ephemeral uses aufs or overlayfs to create effectively COW snapshots of the base container's tree [03:49] Right [03:49] Then bring up a new throwaway container on that [03:50] You can see the buildbot config in lp:~launchpad/lpbuildbot/public [03:50] With a testr.conf that calls IIRC lp-setup-lxc-test to run bin/test in an ephemeral container [03:51] Yes, it calls /usr/local/bin/lp-setup-lxc-test [03:51] testr just calls the command there to run the tests, so testr doesn't know about LXC at all [03:51] As far as it's concerned it's just running 20 parallel testrunners locally [03:51] I was guessing I needed lp-setup-lxc-build first, but like I said, that wasn't filled with happiness [03:52] Right, lp-setup-lxc-build is run as one of the earlier phases of each full testsuite run [03:52] It basically just runs 'make build schema' [03:52] So that's done in the base container, rather than separately in each cloned one [03:52] But it relies on there being a container already [03:53] lpsetup init-lxc can probably create it for you [03:53] In the DC we do it manually [03:54] Right [03:54] There's nothing really special about the container created by lpsetup [03:55] You can get something roughly equivalent by running rocketfuel-setup in a normal container from lxc-create [03:55] wgrant: I'll bring up an ec2 instance in a bit, working on failing tests from my storm branch. [03:55] There were failures? :( [03:56] Query issues, or just things expecting SQLObjectResultSets? [03:56] Yeah, there was a callsite of handleOptional... hiding in registry/sourcepackage.py [03:56] Oh [03:56] Sinister [03:56] Oh right [03:56] That one [03:56] Yeah [03:56] Which I'd like to destroy [03:56] I tried once upon a time to make the build API sensible [03:56] But didn't quite get all the way [03:57] wgrant: Can I kill _get_ubuntu in that class? [03:58] StevenK: That comment is prehistoric and no longer correct [03:58] So I can kill it? [03:58] You should be able to use an inline ILaunchpadCelebrities lookup instead [03:58] Yeah [03:58] I was going to, yeah [03:58] However [03:58] Hmm [03:59] Check the history on .packaging [03:59] I think the Ubuntu specialcase can probably be removed [03:59] It's the only callsite of priorReleasedSeries [03:59] And seems pretty pointless [04:00] Because Ubuntu should have previous_series set properly everywhere [04:02] Yeah [04:03] Even in sampledata [04:03] So I'd try removing that specialcase and all the priorReleasedSeries definitions and seeing if the test suite complains [04:03] That gets this branch to -60 [04:04] You removed it from DistroSeriesSet and the interfaces too? [04:04] Nope [04:04] Hold on, removed what? [04:04] priorReleasedSeries [04:05] Its sole callsite is the Ubuntu specialcase in SourcePackage.packaging [04:05] And I can't see any value in that special case. [04:05] You might be able to find something [04:05] But I really can't [04:06] Right, it's terrible [04:07] Since Ubuntu releases are serial, the first priorReleasedSeries is always going to be previous_series [04:07] Except when we're on a non-released non-development series [04:07] Like q-series or r-series [04:07] Their first priorReleasedSeries is the current release [04:07] precise [04:07] not quantal [04:08] But that provides no value, since with the special case removed it will fall back to quantal which will fall back to precise [04:08] So yeah [04:08] Delete the special case [04:08] Then probably lp-land and see if buildbot complains [04:08] It probably won't, and if it does then the fix is easy and meh. [04:08] % bzr damage [04:08] Using submit branch /home/steven/launchpad/lp-branches/devel [04:08] Healing: 134 lines of code [04:08] :) [04:08] You got both priorReleasedSeries methods and their respective interfaces? [04:09] And the *enormous* test [04:10] % bzr grep priorReleasedSeries | wc -l [04:10] 0 [04:10] :) [04:10] https://code.launchpad.net/~julian-edwards/launchpad/set-previous-series-bug-805913/+merge/66942 [04:10] is very relevant [04:11] what [04:12] StevenK: The addendum there doesn't make much sense to me [04:12] If there are many unreleased series, then it will just recurse back [04:13] Indeed [04:13] It's not necessary to jump straight to the last released one, AFAICT [04:13] wgrant: Do you want to eyeball a diff before I commit, push and lp-land? [04:13] StevenK: If you push I'll check the MP [04:14] bigjools: I'm guessing that's all a blur and you don't remember the context around that MP any more? [04:15] wgrant: Pushed [04:15] not looked, otp [04:17] bigjools: Not still dealing with broker from hell? [04:17] no thankfully [04:18] StevenK: The amount of red in the incremental diff pleases my eyes. [04:21] StevenK: Can you run -t packaging or so? [04:21] Just in case there's something obvious [04:28] wgrant: Total: 109 tests, 0 failures, 0 errors in 6 minutes 27.422 seconds. [04:28] Total: 109 tests, 0 failures, 0 errors in 6 minutes 27.422 seconds. [04:28] BLEH, this double paste is getting annoying [04:32] StevenK: Sounds good [04:32] Let me lp-land it [04:35] StevenK: Indeed [04:38] cody-somerville: you around? [04:42] * StevenK stabs init-lxc for wanting lots of information [04:43] wallyworld: lazr.restful already has infrastructure for detecting canonical_url changds [04:43] Though I'm not sure why it's not working here [04:43] this is lazr.restfulclient [04:43] and the code path does not detect it [04:44] wallyworld: Sure, but lazr.restful detects a change and sends a 301 with Location [04:44] clearly not :-) [04:44] Blink. It debootstraps? [04:44] this is a fairly old bug too [04:44] Well, yeah, it doesn't work in this case [04:44] But I'd probably investigate why it doesn't work [04:44] I'm going to be unhappy if this requires an LP account [04:45] Rather than adding that somewhat terrible model hack [04:45] StevenK: Why wouldn't it debootstrap? [04:45] It needs to create a fresh installation for the container [04:45] wgrant: Wasn't expecting it is all [04:45] It should be OK with grabbing the branches from LP anonymously, though [04:45] You'd think [04:46] I've fed it nonense, so we'll see [04:47] wallyworld: See lazr.restful._resource.EntryManipulatingResource.applyChanges() for the code which does it on attribute changes [04:47] But I guess not on method calls [04:47] we could run an image rather than debootstrap [04:47] ok, will look. i didn't realise lazr.restful detected url changes [04:47] but LXC isn't [currently] run that way [04:47] Rargh [04:48] lpsetup needs a bug [04:48] It pulls from archive no matter what, it should be configurable [04:48] wallyworld: I'm not quite sure where method calls are done, but I know it automatically calls ObjectModifiedEvent, so there must be something there [04:48] StevenK: Ah yeah [04:49] StevenK: I manually ran lxc-create with MIRROR=whatever beforehand [04:49] wgrant: have you had time to look at the ghosts? [04:49] Sadly, it's going faster than the ec2 mirror [04:49] lxc-create stores a cache keyed on (distroseries, archtag) [04:49] wgrant: by "it", you mean lazr.restful i assume [04:49] So I can't complain much [04:49] wallyworld: Right, sorry [04:49] ok [04:49] lifeless: Not yet, as it doesn't seem overly urgent. If you want me to I'll get onto it nowish, though [04:50] I've been fixing bugs to make bigjools shut up :P [04:50] That fix should be deployed soon [04:50] Indeed :) [04:51] wgrant: Right, so init-lxc just finished [04:51] wgrant: I'd like to know its good this week [04:51] StevenK: Did it branch LP stuff into it and stuff? [04:51] wgrant: as config changes when they are needed, are generally needed now [04:51] lifeless: Yeah, true [04:51] And we have no ops next week [04:51] wgrant: I don't think so [04:51] wgrant: How can I check? [04:51] wgrant: exactly [04:52] StevenK: ls ~ [04:52] wgrant: does the lp-setup-lxc stuff bind-mount ~? [04:52] or does it do a fresh copy of everything ? [04:52] root@ip-10-78-117-158:~# ls -lh ~ [04:52] total 0 [04:52] lifeless: it bind mounts ~ [04:52] StevenK: Ah right [04:53] thats root though :P [04:53] init-lxc Create an LXC container suitable for later installing [04:53] a Launchpad development environment. [04:53] init-repo Get the Launchpad code and dependent source code. [04:53] install-lxc Completely sets up an LXC environment with Launchpad [04:53] using the sandbox development model. [04:53] Oh, bleh [04:53] StevenK: tell me you ran that as root ? [04:53] lifeless: Which as root? [04:53] StevenK: is this on your machine ? [04:53] From install-lxc: [04:53] This is basically the same as running `init-lxc` and then, inside the \ [04:53] newly created container, `lp-setup init-repo`, `lp-setup update`, and [04:53] `make install`. [04:54] lifeless: Note the hostname [04:54] StevenK: doesn't tell me anything [04:54] It's an m2.xlarge ec2 instance [04:54] StevenK: thanks [04:54] m2.2xlarge, rather [04:54] 34GiB of RAM [04:54] StevenK: So I'd start the container, SSH in, and run lp-setup init-repo, lp-setup update, make install [04:55] lxc-start lptests ? [04:55] sudo lxc-start -n lptests -d [04:55] Without -d it'll start in the foreground and give you local console [04:55] Which is usually undesirable [04:56] You can then use lp-lxc-ip (or something close to that) to determine the IP address to give to ssh [04:56] I thought it was ubuntu/ubuntu [04:56] It should be the username and password of whatever account you ran it as, usually [04:56] But otherwise ubuntu/ubuntu [04:56] Or root/ [04:57] root/ doesn't work either [04:57] It's possible that running it as a passwordless root account has confused it [04:57] Check /var/lib/lxc/lptests/rootfs/etc/shadow [04:59] Disabled root, it has an jenkins account [04:59] But the password isn't jenkins or test or ubuntu or test [04:59] Ah, if you ran it as jenkins then it'll have copied your host's jenkins password [04:59] Ahh [04:59] That I know [05:00] I thought you ran it as root, given the PS1 earlier [05:00] It insisted I run it with -u [05:00] Ah [05:00] Right [05:00] lp-setup init-repo: error: No bzr launchpad-login set. [05:00] Bleh [05:01] vim is your friend [05:01] I suspect [05:01] * StevenK adds --use-http [05:01] Or that [05:03] Hm, the amount of progress printed is staggering [05:04] In which direction? [05:04] Do you want to proceed? [y/N] y [05:04] [05:04] Heh [05:05] Right, it is doing something, it just isn't telling me [05:08] * wgrant watches 2500 gpg prompts fly past [05:09] Hm? [05:09] I should probably have disabled signing before running mkghosts [05:10] Heh [05:10] 20 failures [05:10] 6 errors [05:10] So, I love [05:10] lose, even [05:11] wgrant: wheee :P [05:11] StevenK: Hm, what [05:11] You lost [05:11] Terribly [05:11] But how [05:11] Those errors don't make much sense [05:11] It looks like the DSP is ending up None [05:12] BrokenImplementation: An object has failed to implement interface [05:12] Ah, no [05:12] It's just answer_contacts that's broken, it seems [05:13] By "The answer_contacts attribute was not provided" it means "AttributeError: 'NoneType' object has no attribute 'using'" [05:13] How did I manage to screw that up? [05:13] Oh heh [05:13] @property [05:13] - def _store(self): [05:13] - return Store.of(self.sourcepackagename) [05:13] - [05:13] That would do it [05:13] in sourcepackage.py [05:14] Oh, I thought that was unused! [05:14] I even bzr grepped for it [05:14] QuestionTargetMixin uses it [05:15] Anyway, this is why we have 35 minute buildbot :) [05:15] Heh [05:15] Putting together a testfix [05:15] It looks like the only failure, but you would do well to wait until this run finishes and then run all the failures [05:15] It's going to require a branch anyway, but yeah [05:17] It just finished [05:17] * StevenK grabs the stream [05:17] http://lpbuildbot.canonical.com/builders/lucid_lp_lxc/builds/39/steps/shell_9/logs/subunit/text should be what you want, yeah [05:18] Indeed [05:18] I was already wgetting when I said I was grabbing it [05:18] And I'm now waiting on testr run --failing [05:18] (and bzr on said ec2 ...) [05:19] jenkins@lptests:~$ du -sh launchpad/lp-branches/.bzr [05:19] 229M launchpad/lp-branches/.bzr [05:19] :) [05:20] Ran 84 (-22077) tests in 131.750s (-1768.113s) [05:20] PASSED (id=1, skips=6) [05:21] Excellent [05:21] OMG, it finished [05:21] Your ec2 instance? [05:22] Yeah [05:22] lp-setup update depends on CWD? :-( [05:22] Yes [05:22] as do lp-setup-lxc-test and lp-setup-lxc-build [05:22] It makes a fair bit of sense [05:23] jenkins@lptests:~/launchpad/lp-branches/devel$ lp-setup update [05:23] lp-setup update: error: the target dir /home/jenkins/launchpad/lp-branches/devel is not a valid Launchpad tree. [05:24] lp-setup update: error: the target dir /home/jenkins/launchpad/lp-branches/devel is not a valid Launchpad tree. [05:24] Not seen that before [05:24]