[00:00] <wgrant> bigjools: "requested to review"
[00:00] <wgrant> It's the reviewer
[00:00] <wgrant> Not a subscriber
[00:00] <bigjools> so that overrides sibscription settings saying not to email?
[00:00] <bigjools> sigh
[00:00] <bigjools> ok how do I stop this?
[00:00] <lifeless> it doesn't override, its direct notification
[00:00] <lifeless> remove maas-lander from maas-maintainers
[00:00] <wgrant> Set a team email address
[00:00] <wgrant> Or remove maas-lander from maas-maintainers, yeah
[00:01] <lifeless> put maas-lander and maas-maintainers both in ~canonical-launchpad-branches or a similar branch-only-access team
[00:01] <bigjools> then it won't be able to land stuff
[00:01] <mwhudson> lifeless: that's basically a way for evil js to get at http-only cookies isn't it?
[00:01] <bigjools> man this stuff is over complicated
[00:01] <lifeless> 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] <bigjools> lifeless: I understand - or rather I don't understand why it needs to be so complex :(
[00:01] <lifeless> mwhudson: http://en.wikipedia.org/wiki/CRIME_%28security_exploit%29
[00:02] <mwhudson> 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] <mwhudson> lifeless: if you can do that, you can just carefully craft the results to do evil directly, surely?
[00:02] <lifeless> mwhudson: yes, but the demonstration is terrifying
[00:03] <mwhudson> it's a super cool hack
[00:03] <lifeless> mwhudson: no, you can't
[00:03] <wgrant> mwhudson: No
[00:03] <wgrant> mwhudson: By crafting part of a body I can reveal the headers
[00:03] <wgrant> eg. if I control a string embedded deep in JSON somewhere
[00:04] <bigjools> !!!!!! I can't set a contact address that is the same as another team's
[00:04] <lifeless> bigjools: I wouldn't go the contact address route
[00:04] <lifeless> bigjools: it gets super messy.
[00:04] <wgrant> ...
[00:05] <bigjools> I was going to redirect email to launchpad-reviewers
[00:05] <wgrant> This is already super-messy, and the complex team structure doesn't make it any less messy
[00:05] <bigjools> exactly wgrant
[00:05] <wgrant> MP notifications are fundamentally broken
[00:05] <wgrant> It's always going to be messy until they're fixed
[00:06] <bigjools> I don't understand the arbitrary refusal to set the contact address to be the same as another team
[00:06] <bigjools> that's bizarre
[00:06] <wgrant> It's not arbitrary
[00:06] <wgrant> It's less than ideal
[00:06] <wgrant> But it's certainly not arbitrary
[00:06] <bigjools> the error on screen should say why instead of appearing to be arbitrary
[00:06] <wgrant> Launchpad doesn't just use it as a contact address
[00:06] <wgrant> It's also used to look up the team
[00:06] <wgrant> Mostly by Soyuz
[00:06] <bigjools> headdesk
[00:07]  * bigjools sets contact address to devnull@example.com
[00:07] <wgrant> Good luck confirming that :)
[00:08] <bigjools> bollocks, it ignored it!
[00:08] <bigjools> this is fucking infuriating :/
[00:08] <lifeless> 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] <lifeless> wgrant: arguing that its broken just aknowledges that it is.
[00:08] <bigjools> is this recommended structure documented anywhere on the lp wiki?
[00:09] <lifeless> wgrant: the other reason to do it the same way as LP is that it would be the same way as LP
[00:09] <lifeless> bigjools: https://dev.launchpad.net/CreatingNewProjects
[00:09] <bigjools> thanks
[00:09] <wgrant> lifeless: Sure, but that requires renaming branches everywhere
[00:09] <wgrant> lifeless: So it's far less destructive to set a contact address
[00:09] <lifeless> wgrant: ah, that is a cost to moving, yes.
[00:09] <lifeless> which will hurt.
[00:10] <bigjools> lifeless: not sure that page helps
[00:10] <lifeless> bigjools: I don't think we captured the how-we-got-there anywhere other than the list archives :( - sorry!
[00:10] <lifeless> I have to run, shopping trip to do
[00:10] <bigjools> lifeless: :(
[00:11] <lifeless> back soon, good luck solving your headache.
[00:11] <lifeless> my 2c before I go
[00:11] <lifeless>  - make a new team -reviewers and copy the direct member list from -maintainers to -reviewers
[00:11] <lifeless> make it the reviewer
[00:12] <lifeless> make it owned by -maintainers
[00:12] <lifeless> and refactor to remove duplication post-release.
[00:17]  * bigjools made launchpad-reviewers the reviewer
[00:18] <wgrant> My inbox thanks you
[00:19] <bigjools> lp-reviewers was a member of the old team anyway
[00:19] <wgrant> Yeah
[00:19] <wgrant> But now I'll get less mail :)
[00:19] <bigjools> that was the idea :)
[00:22] <bigjools> 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] <bigjools> :/
[00:45] <lifeless> zomg its a statik
[00:53] <wgrant> 2012-09-25 22:55:56 INFO    Outage complete. 0:00:01.818455
[00:53] <wgrant> getting there
[00:53] <wgrant> (from the latest staging update)
[00:54] <StevenK> What, too long?
[00:55] <wgrant> No reason for it to take more than a couple of hundred milliseconds
[00:56] <lifeless> StevenK: yeah
[00:57] <wgrant> security.py is most of the remaining time, I believe
[00:59] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-1056506/+merge/126358
[01:01] <StevenK> wgrant: r=me
[01:01] <wgrant> StevenK: Thanks
[01:02] <StevenK> wgrant: I heartily approve of lines 61-69
[01:02] <wgrant> Yeah...
[01:06] <lifeless> libreoffice starts -fast- on SSD
[01:18] <wgrant> 2012-09-26 01:17:38 INFO    Resetting permissions.
[01:18] <wgrant> Security took 0.780465126038
[01:18] <wgrant> 2012-09-26 01:17:38 INFO    Enabling access to launchpad_dev_master.
[01:18] <wgrant> 2012-09-26 01:17:38 INFO    Outage complete. 0:00:00.888748
[01:18] <wgrant> So security.py is indeed probably most of it
[02:12] <lifeless>       327 /    0  DistroSeries:EntryResource:getBuildRecords
[02:12] <lifeless>       321 /    0  Person:+specworkload
[02:12] <lifeless> :(
[02:22] <StevenK> Why do we get a PQM success mail at 11:59 and then a failure at 12:04?
[02:25] <wgrant> StevenK: There are lots of mail delays
[02:25] <wgrant> StevenK: So buildbot-poll sends the email
[02:25] <wgrant> It gets stuck in a queue
[02:26] <wgrant> 5/10 minutes later, buildbot-poll sees there's still stuff to merge
[02:26] <wgrant> Sends the email
[02:26] <wgrant> Mail queue unclogs, PQM processes both
[02:26] <StevenK> I look forward to when we can kill buildbot-poll
[02:42]  * StevenK stabs lxc
[03:35] <StevenK> wgrant: LXC is impenetrable.
[03:35] <wgrant> StevenK: Howso?
[03:36] <StevenK> I don't understand it at all!
[03:36] <wgrant> I know parts of it all too intimately.
[03:36] <wgrant> What is it doing to you?
[03:36] <StevenK> I destroyed the ec2 instance in disgust before lunch, but the lxc-setup-build script in examples was hanging
[03:37] <wgrant> StevenK: Did you have a base container set up properly?
[03:37] <wgrant> And where was it hanging?
[03:38] <StevenK> lxc-wait -n or so, I think
[03:38] <StevenK> And base container?
[03:38] <StevenK> See previous statement about impenetrability.
[03:38] <wgrant> lp-setup-lxc-build relies on there being a base container already
[03:38] <wgrant> It builds LP inside a container
[03:39] <wgrant> You can use lpsetup to create this container
[03:41] <lifeless> I wonder if we need more 'this is how its all put together' docs for this
[03:44] <wgrant> Yeah
[03:44] <wgrant> Particularly since the in-DC setup is different
[03:44] <wgrant> I suspect we'll be able to pull together docs from me watching StevenK trip over everything :)
[03:45] <StevenK> Oh. Yay?
[03:46] <wgrant> StevenK: So, do you understand the high-level fundamentals of how parallel testing is implemented for LP today?
[03:46] <wgrant> I suspect few outside lifeless, I, Yellow, and some ops, do
[03:47] <wgrant> But I'm not sure how much you've picked up on
[03:47] <wgrant> As it's all a bit complicated
[03:47] <StevenK> 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] <wgrant> StevenK: Right
[03:48] <wgrant> Now, the 20 containers aren't all created from scratch each time
[03:48] <wgrant> They're ephemeral (created by the aptly named lxc-start-ephemeral) as clones of a base container
[03:49] <wgrant> This base container has LP code+deps+DB etc in it.
[03:49] <wgrant> And it's persistent
[03:49] <wgrant> lxc-start-ephemeral uses aufs or overlayfs to create effectively COW snapshots of the base container's tree
[03:49] <StevenK> Right
[03:49] <wgrant> Then bring up a new throwaway container on that
[03:50] <wgrant> You can see the buildbot config in lp:~launchpad/lpbuildbot/public
[03:50] <wgrant> With a testr.conf that calls IIRC lp-setup-lxc-test to run bin/test in an ephemeral container
[03:51] <StevenK> Yes, it calls /usr/local/bin/lp-setup-lxc-test
[03:51] <wgrant> testr just calls the command there to run the tests, so testr doesn't know about LXC at all
[03:51] <wgrant> As far as it's concerned it's just running 20 parallel testrunners locally
[03:51] <StevenK> I was guessing I needed lp-setup-lxc-build first, but like I said, that wasn't filled with happiness
[03:52] <wgrant> Right, lp-setup-lxc-build is run as one of the earlier phases of each full testsuite run
[03:52] <wgrant> It basically just runs 'make build schema'
[03:52] <wgrant> So that's done in the base container, rather than separately in each cloned one
[03:52] <wgrant> But it relies on there being a container already
[03:53] <wgrant> lpsetup init-lxc can probably create it for you
[03:53] <wgrant> In the DC we do it manually
[03:54] <StevenK> Right
[03:54] <wgrant> There's nothing really special about the container created by lpsetup
[03:55] <wgrant> You can get something roughly equivalent by running rocketfuel-setup in a normal container from lxc-create
[03:55] <StevenK> wgrant: I'll bring up an ec2 instance in a bit, working on failing tests from my storm branch.
[03:55] <wgrant> There were failures? :(
[03:56] <wgrant> Query issues, or just things expecting SQLObjectResultSets?
[03:56] <StevenK> Yeah, there was a callsite of handleOptional... hiding in registry/sourcepackage.py
[03:56] <wgrant> Oh
[03:56] <wgrant> Sinister
[03:56] <wgrant> Oh right
[03:56] <wgrant> That one
[03:56] <StevenK> Yeah
[03:56] <StevenK> Which I'd like to destroy
[03:56] <wgrant> I tried once upon a time to make the build API sensible
[03:56] <wgrant> But didn't quite get all the way
[03:57] <StevenK> wgrant: Can I kill _get_ubuntu in that class?
[03:58] <wgrant> StevenK: That comment is prehistoric and no longer correct
[03:58] <StevenK> So I can kill it?
[03:58] <wgrant> You should be able to use an inline ILaunchpadCelebrities lookup instead
[03:58] <wgrant> Yeah
[03:58] <StevenK> I was going to, yeah
[03:58] <wgrant> However
[03:58] <wgrant> Hmm
[03:59] <wgrant> Check the history on .packaging
[03:59] <wgrant> I think the Ubuntu specialcase can probably be removed
[03:59] <wgrant> It's the only callsite of priorReleasedSeries
[03:59] <wgrant> And seems pretty pointless
[04:00] <wgrant> Because Ubuntu should have previous_series set properly everywhere
[04:02] <StevenK> Yeah
[04:03] <wgrant> Even in sampledata
[04:03] <wgrant> So I'd try removing that specialcase and all the priorReleasedSeries definitions and seeing if the test suite complains
[04:03] <StevenK> That gets this branch to -60
[04:04] <wgrant> You removed it from DistroSeriesSet and the interfaces too?
[04:04] <StevenK> Nope
[04:04] <StevenK> Hold on, removed what?
[04:04] <wgrant> priorReleasedSeries
[04:05] <wgrant> Its sole callsite is the Ubuntu specialcase in SourcePackage.packaging
[04:05] <wgrant> And I can't see any value in that special case.
[04:05] <wgrant> You might be able to find something
[04:05] <wgrant> But I really can't
[04:06] <StevenK> Right, it's terrible
[04:07] <wgrant> Since Ubuntu releases are serial, the first priorReleasedSeries is always going to be previous_series
[04:07] <wgrant> Except when we're on a non-released non-development series
[04:07] <wgrant> Like q-series or r-series
[04:07] <wgrant> Their first priorReleasedSeries is the current release
[04:07] <wgrant> precise
[04:07] <wgrant> not quantal
[04:08] <wgrant> 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] <wgrant> So yeah
[04:08] <wgrant> Delete the special case
[04:08] <wgrant> Then probably lp-land and see if buildbot complains
[04:08] <wgrant> It probably won't, and if it does then the fix is easy and meh.
[04:08] <StevenK> % bzr damage
[04:08] <StevenK> Using submit branch /home/steven/launchpad/lp-branches/devel
[04:08] <StevenK> Healing: 134 lines of code
[04:08] <wgrant> :)
[04:08] <wgrant> You got both priorReleasedSeries methods and their respective interfaces?
[04:09] <StevenK> And the *enormous* test
[04:10] <StevenK> % bzr grep priorReleasedSeries | wc -l
[04:10] <StevenK> 0
[04:10] <wgrant> :)
[04:10] <wgrant> https://code.launchpad.net/~julian-edwards/launchpad/set-previous-series-bug-805913/+merge/66942
[04:10] <wgrant> is very relevant
[04:11] <bigjools> what
[04:12] <wgrant> StevenK: The addendum there doesn't make much sense to me
[04:12] <wgrant> If there are many unreleased series, then it will just recurse back
[04:13] <StevenK> Indeed
[04:13] <wgrant> It's not necessary to jump straight to the last released one, AFAICT
[04:13] <StevenK> wgrant: Do you want to eyeball a diff before I commit, push and lp-land?
[04:13] <wgrant> StevenK: If you push I'll check the MP
[04:14] <wgrant> bigjools: I'm guessing that's all a blur and you don't remember the context around that MP any more?
[04:15] <StevenK> wgrant: Pushed
[04:15] <bigjools> not looked, otp
[04:17] <StevenK> bigjools: Not still dealing with broker from hell?
[04:17] <bigjools> no thankfully
[04:18] <wgrant> StevenK: The amount of red in the incremental diff pleases my eyes.
[04:21] <wgrant> StevenK: Can you run -t packaging or so?
[04:21] <wgrant> Just in case there's something obvious
[04:28] <StevenK> wgrant: Total: 109 tests, 0 failures, 0 errors in 6 minutes 27.422 seconds.
[04:28] <StevenK> Total: 109 tests, 0 failures, 0 errors in 6 minutes 27.422 seconds.
[04:28] <StevenK> BLEH, this double paste is getting annoying
[04:32] <wgrant> StevenK: Sounds good
[04:32] <StevenK> Let me lp-land it
[04:35] <wgrant> StevenK: Indeed
[04:38] <wallyworld> cody-somerville: you around?
[04:42]  * StevenK stabs init-lxc for wanting lots of information
[04:43] <wgrant> wallyworld: lazr.restful already has infrastructure for detecting canonical_url changds
[04:43] <wgrant> Though I'm not sure why it's not working here
[04:43] <wallyworld> this is lazr.restfulclient
[04:43] <wallyworld> and the code path does not detect it
[04:44] <wgrant> wallyworld: Sure, but lazr.restful detects a change and sends a 301 with Location
[04:44] <wallyworld> clearly not :-)
[04:44] <StevenK> Blink. It debootstraps?
[04:44] <wallyworld> this is a fairly old bug too
[04:44] <wgrant> Well, yeah, it doesn't work in this case
[04:44] <wgrant> But I'd probably investigate why it doesn't work
[04:44] <StevenK> I'm going to be unhappy if this requires an LP account
[04:45] <wgrant> Rather than adding that somewhat terrible model hack
[04:45] <wgrant> StevenK: Why wouldn't it debootstrap?
[04:45] <wgrant> It needs to create a fresh installation for the container
[04:45] <StevenK> wgrant: Wasn't expecting it is all
[04:45] <wgrant> It should be OK with grabbing the branches from LP anonymously, though
[04:45] <StevenK> You'd think
[04:46] <StevenK> I've fed it nonense, so we'll see
[04:47] <wgrant> wallyworld: See lazr.restful._resource.EntryManipulatingResource.applyChanges() for the code which does it on attribute changes
[04:47] <wgrant> But I guess not on method calls
[04:47] <lifeless> we could run an image rather than debootstrap
[04:47] <wallyworld> ok, will look. i didn't realise lazr.restful detected url changes
[04:47] <lifeless> but LXC isn't [currently] run that way
[04:47] <StevenK> Rargh
[04:48] <StevenK> lpsetup needs a bug
[04:48] <StevenK> It pulls from archive no matter what, it should be configurable
[04:48] <wgrant> 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] <wgrant> StevenK: Ah yeah
[04:49] <wgrant> StevenK: I manually ran lxc-create with MIRROR=whatever beforehand
[04:49] <lifeless> wgrant: have you had time to look at the ghosts?
[04:49] <StevenK> Sadly, it's going faster than the ec2 mirror
[04:49] <wgrant> lxc-create stores a cache keyed on (distroseries, archtag)
[04:49] <wallyworld> wgrant: by "it", you mean lazr.restful i assume
[04:49] <StevenK> So I can't complain much
[04:49] <wgrant> wallyworld: Right, sorry
[04:49] <wallyworld> ok
[04:49] <wgrant> lifeless: Not yet, as it doesn't seem overly urgent. If you want me to I'll get onto it nowish, though
[04:50] <wgrant> I've been fixing bugs to make bigjools shut up :P
[04:50] <StevenK> That fix should be deployed soon
[04:50] <wgrant> Indeed :)
[04:51] <StevenK> wgrant: Right, so init-lxc just finished
[04:51] <lifeless> wgrant: I'd like to know its good this week
[04:51] <wgrant> StevenK: Did it branch LP stuff into it and stuff?
[04:51] <lifeless> wgrant: as config changes when they are needed, are generally needed now
[04:51] <wgrant> lifeless: Yeah, true
[04:51] <wgrant> And we have no ops next week
[04:51] <StevenK> wgrant: I don't think so
[04:51] <StevenK> wgrant: How can I check?
[04:51] <lifeless> wgrant: exactly
[04:52] <wgrant> StevenK: ls ~
[04:52] <lifeless> wgrant: does the lp-setup-lxc stuff bind-mount ~?
[04:52] <lifeless> or does it do a fresh copy of everything ?
[04:52] <StevenK> root@ip-10-78-117-158:~# ls -lh ~
[04:52] <StevenK> total 0
[04:52] <wgrant> lifeless: it bind mounts ~
[04:52] <wgrant> StevenK: Ah right
[04:53] <lifeless> thats root though :P
[04:53] <wgrant>     init-lxc            Create an LXC container suitable for later installing
[04:53] <wgrant>                         a Launchpad development environment.
[04:53] <wgrant>     init-repo           Get the Launchpad code and dependent source code.
[04:53] <wgrant>     install-lxc         Completely sets up an LXC environment with Launchpad
[04:53] <wgrant>                         using the sandbox development model.
[04:53] <StevenK> Oh, bleh
[04:53] <lifeless> StevenK: tell me you ran that as root ?
[04:53] <StevenK> lifeless: Which as root?
[04:53] <lifeless> StevenK: is this on your machine ?
[04:53] <wgrant> From install-lxc:
[04:53] <wgrant>     This is basically the same as running `init-lxc` and then, inside the \
[04:53] <wgrant>     newly created container, `lp-setup init-repo`, `lp-setup update`, and
[04:53] <wgrant>     `make install`.
[04:54] <StevenK> lifeless: Note the hostname
[04:54] <lifeless> StevenK: doesn't tell me anything
[04:54] <StevenK> It's an m2.xlarge ec2 instance
[04:54] <lifeless> StevenK: thanks
[04:54] <StevenK> m2.2xlarge, rather
[04:54] <StevenK> 34GiB of RAM
[04:54] <wgrant> StevenK: So I'd start the container, SSH in, and run lp-setup init-repo, lp-setup update, make install
[04:55] <StevenK> lxc-start lptests ?
[04:55] <wgrant> sudo lxc-start -n lptests -d
[04:55] <wgrant> Without -d it'll start in the foreground and give you local console
[04:55] <wgrant> Which is usually undesirable
[04:56] <wgrant> You can then use lp-lxc-ip (or something close to that) to determine the IP address to give to ssh
[04:56] <StevenK> I thought it was ubuntu/ubuntu
[04:56] <wgrant> It should be the username and password of whatever account you ran it as, usually
[04:56] <wgrant> But otherwise ubuntu/ubuntu
[04:56] <wgrant> Or root/
[04:57] <StevenK> root/ doesn't work either
[04:57] <wgrant> It's possible that running it as a passwordless root account has confused it
[04:57] <wgrant> Check /var/lib/lxc/lptests/rootfs/etc/shadow
[04:59] <StevenK> Disabled root, it has an jenkins account
[04:59] <StevenK> But the password isn't jenkins or test or ubuntu or test
[04:59] <wgrant> Ah, if you ran it as jenkins then it'll have copied your host's jenkins password
[04:59] <StevenK> Ahh
[04:59] <StevenK> That I know
[05:00] <wgrant> I thought you ran it as root, given the PS1 earlier
[05:00] <StevenK> It insisted I run it with -u
[05:00] <wgrant> Ah
[05:00] <wgrant> Right
[05:00] <StevenK> lp-setup init-repo: error: No bzr launchpad-login set.
[05:00] <StevenK> Bleh
[05:01] <wgrant> vim is your friend
[05:01] <wgrant> I suspect
[05:01]  * StevenK adds --use-http
[05:01] <wgrant> Or that
[05:03] <StevenK> Hm, the amount of progress printed is staggering
[05:04] <wgrant> In which direction?
[05:04] <StevenK> Do you want to proceed? [y/N] y
[05:04] <StevenK>   
[05:04] <wgrant> Heh
[05:05] <StevenK> Right, it is doing something, it just isn't telling me
[05:08]  * wgrant watches 2500 gpg prompts fly past
[05:09] <StevenK> Hm?
[05:09] <wgrant> I should probably have disabled signing before running mkghosts
[05:10] <StevenK> Heh
[05:10] <StevenK> 20 failures
[05:10] <StevenK> 6 errors
[05:10] <StevenK> So, I love
[05:10] <StevenK> lose, even
[05:11] <lifeless> wgrant: wheee :P
[05:11] <wgrant> StevenK: Hm, what
[05:11] <wgrant> You lost
[05:11] <wgrant> Terribly
[05:11] <wgrant> But how
[05:11] <wgrant> Those errors don't make much sense
[05:11] <wgrant> It looks like the DSP is ending up None
[05:12] <StevenK> BrokenImplementation: An object has failed to implement interface <InterfaceClass lp.answers.interfaces.questiontarget.IQuestionTarget>
[05:12] <wgrant> Ah, no
[05:12] <wgrant> It's just answer_contacts that's broken, it seems
[05:13] <wgrant> By "The answer_contacts attribute was not provided" it means "AttributeError: 'NoneType' object has no attribute 'using'"
[05:13] <StevenK> How did I manage to screw that up?
[05:13] <wgrant> Oh heh
[05:13] <wgrant>      @property
[05:13] <wgrant> -    def _store(self):
[05:13] <wgrant> -        return Store.of(self.sourcepackagename)
[05:13] <wgrant> -
[05:13] <wgrant> That would do it
[05:13] <wgrant> in sourcepackage.py
[05:14] <StevenK> Oh, I thought that was unused!
[05:14] <StevenK> I even bzr grepped for it
[05:14] <wgrant> QuestionTargetMixin uses it
[05:15] <wgrant> Anyway, this is why we have 35 minute buildbot :)
[05:15] <StevenK> Heh
[05:15] <StevenK> Putting together a testfix
[05:15] <wgrant> 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] <StevenK> It's going to require a branch anyway, but yeah
[05:17] <StevenK> It just finished
[05:17]  * StevenK grabs the stream 
[05:17] <wgrant> http://lpbuildbot.canonical.com/builders/lucid_lp_lxc/builds/39/steps/shell_9/logs/subunit/text should be what you want, yeah
[05:18] <StevenK> Indeed
[05:18] <StevenK> I was already wgetting when I said I was grabbing it
[05:18] <StevenK> And I'm now waiting on testr run --failing
[05:18] <StevenK> (and bzr on said ec2 ...)
[05:19] <StevenK> jenkins@lptests:~$ du -sh launchpad/lp-branches/.bzr
[05:19] <StevenK> 229M	launchpad/lp-branches/.bzr
[05:19] <wgrant> :)
[05:20] <StevenK> Ran 84 (-22077) tests in 131.750s (-1768.113s)
[05:20] <StevenK> PASSED (id=1, skips=6)
[05:21] <wgrant> Excellent
[05:21] <StevenK> OMG, it finished
[05:21] <wgrant> Your ec2 instance?
[05:22] <StevenK> Yeah
[05:22] <StevenK> lp-setup update depends on CWD? :-(
[05:22] <wgrant> Yes
[05:22] <wgrant> as do lp-setup-lxc-test and lp-setup-lxc-build
[05:22] <wgrant> It makes a fair bit of sense
[05:23] <StevenK> jenkins@lptests:~/launchpad/lp-branches/devel$ lp-setup update
[05:23] <StevenK> lp-setup update: error: the target dir /home/jenkins/launchpad/lp-branches/devel is not a valid Launchpad tree.
[05:24] <StevenK> lp-setup update: error: the target dir /home/jenkins/launchpad/lp-branches/devel is not a valid Launchpad tree.
[05:24] <wgrant> Not seen that before
[05:24] <wgrant> Luckily the code is quite sensible
[05:24] <StevenK> Oh, it's in sandbox, for ... some reason
[05:25] <StevenK> Testfix landed
[05:27] <wgrant> Thanks
[05:27] <wgrant> StevenK: Right, it uses lightweight checkouts
[05:27] <wgrant> devel is a treeless branch
[05:27] <wgrant> sandbox is a lightweight checkout
[05:27] <StevenK> And devel is empty
[05:27] <wgrant> It has a .bzr
[05:27] <wgrant> But that's it
[05:36] <lifeless> wgrant: StevenK: more low hanging fruit: https://bugs.launchpad.net/loggerhead/+bug/869309
[05:36] <_mup_> Bug #869309: If folders in repository have unicode names, sometimes I get KeyError <navigation> <oops> <trivial> <unicode> <loggerhead:Triaged> < https://launchpad.net/bugs/869309 >
[05:36] <lifeless> brought to my attendion by the new user that just assigned it to themselves ><
[05:37] <wgrant> lifeless: But there's no low-hanging fruit :)
[05:37] <lifeless> wgrant: it has a patch attached.
[05:37] <lifeless> wgrant: doesn't get much lower :)
[05:37] <wgrant> Indeed
[05:42] <StevenK> wgrant: Right, that's all done on my ec2 slave
[05:45] <wallyworld> is it just me or does anyone else's screen dimming fail to turn the screen back when the mouse is moved? the pointer shows up but the screen stays black :-(
[05:47] <lifeless> wallyworld: that could be a dropped vsync for unity
[05:47] <lifeless> wallyworld: it looks like a dimming problem, but it isn't
[05:48] <wallyworld> it doesn't happen if i turn off "screen dimming after 10 minutes"
[05:48] <wallyworld> so i just got back from making a coffee and boom :-(
[05:48] <wallyworld> cause i forgot to turn it off again
[05:49] <lifeless> chat to RAOF
[05:49] <lifeless> in #ubuntu-dekstop
[05:49] <lifeless> desktop
[05:49] <lifeless> once they finish figuring out where to put the privacy setting
[05:50] <wallyworld> ok, i'll search bugs first
[05:51] <StevenK> wgrant: So, next step?
[05:53] <wgrant> StevenK: Do stuff
[05:53] <wgrant> Um
[05:53] <wgrant> StevenK: In sandbox on the host, run lp-setup-lxc-build
[05:53] <wgrant> See if it works
[05:57]  * StevenK stabs it for prompting for a sudo password every 2 seconds
[06:04] <StevenK> wgrant: In a word, no
[06:04] <wgrant> Heh
[06:04] <wgrant> buildbot loves you, though
[06:05] <wgrant> StevenK: What broke?
[06:05] <wgrant> "Everything" is an acceptable answer.
[06:06] <StevenK> The script
[06:07] <StevenK> wgrant: http://pastebin.ubuntu.com/1227964/
[06:07] <wgrant> This command has to be run as root
[06:07] <wgrant> sudo it?
[06:07] <wgrant> Ah
[06:07] <wgrant> You did
[06:08] <wgrant> StevenK: Why ~/lp-setup-lxc-build rather than the one installed in PATH?
[06:08] <wgrant> Did you hack it
[06:08] <wgrant> ?
[06:08] <StevenK> There is none in PATH
[06:08] <wgrant> lp-setup should have come with one
[06:08] <wgrant> I thought
[06:09] <StevenK> It's in /usr/share/pyshared/lpsetup/templates/lp-setup-lxc-build
[06:09] <wgrant> Ah
[06:09] <wgrant> Right
[06:09] <StevenK> And I got sick of that long path so I copied it and +x'd it
[06:09] <wgrant> Container {lxc_name} does not exist
[06:09] <wgrant> Sounds like you didn't replace the bits of the template?
[06:09] <StevenK> Oh, I need to sed over it?
[06:10] <wgrant> It takes {lxcip}, {lxc_name} and {ssh_key_path} variables
[06:10] <wgrant> The last is just a local SSH key to use to connect to the containers
[06:11] <StevenK> So I need to fix it, it certainly doesn't use $1 and so on?
[06:11] <wgrant> Right
[06:11] <wgrant> lxcip shouldn't be an arg, but the other two arguably should be
[06:27] <StevenK> wgrant: So the name is lptests or something that will based off it, like current-test-0 or something?
[06:28] <wgrant> StevenK: lptests is the base, the ephemerals will be something like lptests-temp-wefwhjefuwehfuiweghfuiw
[06:29] <StevenK> wgrant: Sorry, I mean what should {lxc_name} be?
[06:29] <wgrant> StevenK: lptests
[06:35] <StevenK> wgrant: So lxc-stop on lptests failed with Operation not permitted, but it seemed to work
[06:36] <lifeless> lp:~lifeless/python-oops-datedir-repo/bug-971255 <- another critical for you, MP coming up
[06:36] <wgrant> StevenK: You need to sudo lxc-* operations, usually
[06:37] <StevenK> Except the whole script is running as root
[06:38] <wgrant> That's a little odd
[06:39] <StevenK> Hm, I think I should done this as an EBS backed instance
[06:40] <StevenK> wgrant: https://qastaging.launchpad.net/builders/palmer/+history?build_text=libc&build_state=all consistenly times out :-(
[06:40] <lifeless> https://code.launchpad.net/~lifeless/python-oops-datedir-repo/bug-971255/+merge/126386
[06:40] <lifeless> wgrant: StevenK: or wallyworld: ^
[06:41] <StevenK> No diff
[06:41] <StevenK> No review
[06:41] <lifeless> StevenK: there is a diff
[06:41] <lifeless> StevenK: thanks to the magic of ajax
[06:42] <StevenK> Looks good
[06:42] <wgrant> StevenK: Indeed, but we're OK as long as the stuff that worked before hasn't regressed.
[06:43] <wgrant> We should probably just drop name filtering from that page eventually
[06:44]  * StevenK destroys this instance
[06:45] <wgrant> StevenK: I'd recommend against using EBS, as that would let you work around setup awkwardness rather than fixing it properly
[06:45] <StevenK> wgrant: I'm trying to avoid the two hour wait lp-setup install-lxc brings
[06:46] <wgrant> AH
[06:46] <wgrant> H
[06:46] <wgrant> Ah
[06:46] <lifeless> aH
[06:59] <lifeless> wgrant: StevenK: wallyworld: https://code.launchpad.net/~lifeless/python-oops-datedir-repo/bug-1003627/+merge/126392 - with this I'll do a release, and we'll have that critical fix-released.
[07:00] <StevenK> Is the prune bug already solved?
[07:00] <lifeless> no
[07:00] <lifeless> the pruning too fast one is
[07:01] <lifeless> this is pruning-the-right-stuff-is-impossible.
[07:01] <lifeless> we have to physically partition the datedir repo for things in different project groups
[07:01] <lifeless> this will fix it
[07:01] <StevenK> Didn't wgrant write a patch for the prune reference bug?
[07:02] <lifeless> he did: 19:00 < lifeless> the pruning too fast one is
[07:02] <lifeless> this is a different prune bug
[07:03] <StevenK> lifeless: r=me
[07:04] <lifeless> thanks
[07:17] <lifeless> wgrant: isn't bug 1050722 FR ?
[07:17] <_mup_> Bug #1050722: prune only searches for OOPS references up to prune_until <Python OOPS Date-dir repository:Fix Released by wgrant> <python-oops-tools:In Progress by wgrant> < https://launchpad.net/bugs/1050722 >
[07:18] <wgrant> lifeless: Ah, indeed
[07:18] <wgrant> Closed, thanks.
[07:33] <lifeless> StevenK: https://code.launchpad.net/~lifeless/python-oops-tools/bug-1003627/+merge/126401 if you would
[07:34] <lifeless> StevenK: I've set a commit message, so if you can toggle the MP to approved (if you do approve) that would rock. Thanks!
[07:34]  * lifeless waves bye-for-a-bit
[07:35] <StevenK> Do not understand why prune is duplicated
[07:48] <adeuring> good morning
[07:56] <lifeless> StevenK: the CLI is the only duplicate
[07:56] <lifeless> StevenK: oops-tools prunes the DB
[07:56] <lifeless> StevenK: datedir-repo prunes disk
[07:57] <lifeless> StevenK: and the API client is in just one place
[07:57] <StevenK> Yes, but you're duplicating logic between them
[07:57] <lifeless> StevenK: the CLI only
[07:59] <wgrant> There is some code that we should dedupe further
[07:59] <wgrant> But it's not completely terrible atm
[07:59] <wgrant> and it can't all be generalised
[08:04] <lifeless> writing a disk-dir implementation of the django orm terrifies me
[08:04] <lifeless> StevenK: thanks!
[08:05] <lifeless> StevenK: wgrant: I'll leave you(purple) to get the prune cronjobs raionalised at a convenient
[08:06] <wgrant> Of course :)
[08:10] <lifeless> wgrant: thanks
[08:12] <mvo> hello, it seems like exports for http://bazaar.launchpad.net/~ubuntu-core-dev/ddtp-ubuntu/ddtp-quantal/changes  stopped at Aug 16th for some reason, would it be possible to check if something is stuck/stale (lockfile etc)? it would be nice to get a updated package description export for the ubuntu beta2
[08:12] <czajkowski> wgrant: StevenK wallyworld_ one for you guys to kick or invstigate ?
[08:13]  * wallyworld_ runs away (my packing foo is zero)
[08:13] <wallyworld_> packaging even
[08:14] <dpm> wallyworld_, there's no escape. It's not about packaging, it's about bzr branches ;)
[08:14] <wgrant> wallyworld_: It's actually translations
[08:14] <wgrant> Which none of us have any clue on
[08:14] <wgrant> But let's see
[08:14] <wgrant> That date is a little suspicious
[08:14] <wgrant> I wonder if the import was interrupted by a DC move and left a lock around
[08:14] <wgrant> s/import/export/
[08:14] <wgrant> Since ddtp exports take forever
[08:15] <wallyworld_> ah, is that when the move happened
[08:15] <wgrant> August 18, but yeah
[08:15] <wgrant> Rather close
[08:15] <wgrant> 2012-09-26 05:11:44 ERROR   Failure in ddtp-ubuntu/quantal: LockContention(Could not acquire lock "(local)": )
[08:16]  * mvo has no clue either but hopes it just a "rm export-ddtp-quantal.lock"
[08:16] <wgrant> mvo: bzr break-lock lp:~ubuntu-core-dev/ddtp-ubuntu/ddtp-quantal
[08:16] <wgrant> should do it
[08:16] <mvo> \o/
[08:16] <wgrant> Hopefully it'll say there's a lock there from taotie on Aug 18
[08:16] <wgrant> It wasn't killed by the move, but exports were severely broken due to fallout from the move a day after
[08:17] <mvo> wgrant: hm, that did just return, no message no nothing?
[08:17] <wgrant> :(
[08:18] <wgrant> Let's see
[08:23] <wgrant> jam, jelmer, mgz: ^^ any ideas on the above?
[08:28] <czajkowski> wallyworld_: StevenK could one of you please help me out on https://answers.launchpad.net/launchpad/+question/209465
[08:29] <wallyworld_> czajkowski: i think if they use one of the supported bug trackers eg bugzilla etc then lp will import bug data but it will still be available in the external system too
[08:30] <wallyworld_> but i'm not 100% sure what happens the other way
[08:31] <jam> wgrant: http://bazaar.launchpad.net/~ubuntu-core-dev/ddtp-ubuntu/ddtp-quantal/.bzr/repository/lock/ and http://bazaar.launchpad.net/~ubuntu-core-dev/ddtp-ubuntu/ddtp-quantal/.bzr/branch/lock/
[08:31] <jam> show that no lock is currently held.
[08:31] <czajkowski> wallyworld_: ok thanks :)
[08:31] <wgrant> jam: Exactly
[08:31] <jam> I don't really knowt about the exception you saw.
[08:31] <wgrant> czajkowski: They won't be able to search for or report new bugs on Launchpad, but all data will still be there if they choose to reenable it
[08:31] <jam> It is possible to be a semi-genuine contention, if you are re-opening a branch in a script, and now one side is holding a lock, and the other is trying to do something.
[08:32] <wgrant> jam: It's only been happening on that branch since the move chaos
[08:32] <wgrant> Without code changes
[08:32] <wgrant> So it seems unlikely to be legitimate.
[08:32] <wgrant> I don't see howit can be "(local)" but without a URL
[08:32] <jam> well, we did upgrade bzr in the middle term
[08:34] <wgrant> It worked on Aug 16, we moved to a new server with significant drama on Aug 18, then it hung a bit until Aug 30, and from Aug 31 it's been giving that error
[08:34] <wgrant> Was there a bzr upgrade in those two weeks? Possibly...
[08:42] <cjwatson> tumbleweed: Oh, are you still looking for a db review for your edit-packagesets branch?  https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess has instructions on whom to seek db reviews from
[08:54] <tumbleweed> cjwatson: aha, I never looked there. Thanks
[09:52] <mvo> czajkowski, wgrant: sorry, I was in a meeting now, should I rather file a bugreport about the export issue instead of asking on irc? especially if its not as trivial as I had hoped?
[09:59] <czajkowski> mvo: probablly best that way the maintenance team can look at it
[10:00] <StevenK> Which export issue?
[10:01] <mvo> StevenK: lp:~ubuntu-core-dev/ddtp-ubuntu/ddtp-quantal is not getting translation updates anymore since ~1month
[10:09] <mvo> I filed bug https://bugs.launchpad.net/launchpad/+bug/1056752  now
[10:09] <_mup_> Bug #1056752: Translations export not working for lp:~ubuntu-core-dev/ddtp-ubuntu/ddtp-quantal <Launchpad itself:New> < https://launchpad.net/bugs/1056752 >
[10:50] <rick_h_> thanks for the qa wgrant
[11:23]  * mpt wonders what "div.first{*margin-right:4%;_margin-right:1.3%}" is supposed to do
[11:24] <mgz> screw with IE users for fun?
[11:25] <mpt> Neither *margin-right nor _margin-right is a valid property, as far as I know
[11:29] <mgz> the star property hack targets IE 7 and less, the underscore hack targets IE 6 and less
[11:29] <rick_h_> wheeee
[11:29] <rick_h_> css hacks ftw
[11:29] <mpt> oh I see
[11:30] <mgz> so, it's deliberatly invalid css to get older buggy browsers that misinterpret it as valid to apply specific rules
[11:30] <mgz> but... that's pretty bad, setting percent margins is likely to just break things anyway
[11:30] <mpt> I was just trying to figure out why bug reports had become unreadable, and it was because my custom Launchpad CSS had stopped working
[11:31] <mgz> and having different values for different browsers then makes working out why something looks funny even more entertaining
[11:31] <rick_h_> ah, well % css rules are generally a good thing as they keep things in scale for different browser sizes
[11:31] <rick_h_> we're not in the land of pixel perfect and such
[11:31] <rick_h_> curious what custom CSS you run with.
[11:32] <mpt> yay, fixed
[11:33] <mpt> rick_h_, http://paste.ubuntu.com/1228291/
[11:33] <rick_h_> mpt: cool
[11:34] <rick_h_> while I like smaller fonts I've often thought a lot of users must find it small
[12:35] <rick_h_> jcsackett: ping when you get a sec
[14:10] <rick_h_> abentley: a review for you if you get a chance please https://code.launchpad.net/~rharding/launchpad/info_type_events/+merge/126317
[14:10] <rick_h_> jcsackett: would appreciate your look as well if you have the bandwidth. ^^
[14:11] <rick_h_> I think this will address the manual usage and we'll see I guess when I follow up and integrate the change into place.
[14:15] <abentley> rick_h_: What happens if an item is private and a feature on the page is in beta?  That should show two banners, but you've made it a singleton, IIUC.
[14:16] <rick_h_> abentley: the beta code is in betabanner.js and has it's own singleton
[14:16] <abentley> rick_h_: cool.
[14:16] <rick_h_> that's just moved code, from the bottom to the top of the file so it's how it currently works
[14:17] <abentley> rick_h_: "@namespace lp.app.banner" reminds me that we haven't reached consensus about whether to separate namespaces from module names.
[14:18] <abentley> rick_h_: But you didn't change that, so that's alright.
[14:18] <rick_h_> abentley: yea, at some point I want to put together some notes/examples and see
[14:19] <rick_h_> I looked at a rename here, but it hit some 50 files and I didn't want to get into it with this
[14:19] <rick_h_> because we've started a lp.ui namespace and this would be good as lp.ui.banner.PrivacyBanner, lp.ui.banner.BetaBanner, etc
[14:19] <rick_h_> but for another day
[14:22] <jcsackett> rick_h_: ping. i lost history in irc, so the details as to why you needed me to ping you are lost to me. what's up?
[14:22] <abentley> rick_h_: Why attach the _singleton_privacy_banner to window?
[14:23] <rick_h_> abentley: to be explicit. That's what's happening itself, but making it explicit makes sure in all cases you're using a global instance
[14:23] <rick_h_> jcsackett: sorry, ping'd earlier because I didn't get how banner rendering worked with the .pt bits
[14:23] <danilos> deryck, hi, I've filed a few bugs related to specification privacy: bug 1056881, bug 1056891 and bug 1056893 - sorry if I made any duplicates, but I didn't find them
[14:23] <_mup_> Bug #1056881: Specifications privacy: subscribers can't see private blueprints <Launchpad itself:New> < https://launchpad.net/bugs/1056881 >
[14:23] <_mup_> Bug #1056891: Specification privacy: upcoming work won't load for anyone if there's any private data on it <Launchpad itself:New> < https://launchpad.net/bugs/1056891 >
[14:23] <_mup_> Bug #1056893: Specification privacy: no "private content" header on +upcomingwork page with private data <Launchpad itself:New> < https://launchpad.net/bugs/1056893 >
[14:23] <rick_h_> jcsackett: but basically just ping'd on the review since you looked at it yesterday with feedback
[14:24] <rick_h_> jcsackett: feel free to ignore
[14:24] <jcsackett> rick_h_: so all is well now? i'm happy to answer questions whenever. it's not the clearest of code, despite my best efforts at the time. :-P
[14:25] <rick_h_> jcsackett: well, I broke off rendering into a second step. Just events for now
[14:25] <jcsackett> rick_h_: dig.
[14:25] <rick_h_> so might bug you later on, but for now I"m cool
[14:25] <jcsackett> rick_h_: righto.
[14:26] <abentley> rick_h_: I don't understand the value of that explicitness.  Because there's no encapsulation, there's no longer a guarantee that it is a singleton.
[14:26] <rick_h_> abentley: window is a browser enforced singleton global space. It's to make sure you know where that's at and prevents people from looking for var definitions and such
[14:26] <rick_h_> for instance, in tests, I know I need to reset that window.var
[14:29] <deryck> danilos, thanks for filing the bugs.
[14:29] <abentley> rick_h_: Window is just a global.  It doesn't ensure there's only one instance of PrivacyBanner.  If I can set __singleton_privacy_banner to null, then getPrivacyBanner will create a second instance.
[14:29] <rick_h_> abentley: right, but the module is only loaded once. So it's set to null one on module load. And then never again
[14:29] <danilos> deryck, yw, thanks for getting this in, Linaro wants to use it asap :)
[14:30] <rick_h_> except in tests where I do that to do a proper teardown
[15:06] <abentley> rick_h_: Sorry, forgot I was reviewing before the call.
[15:06] <rick_h_droid> np
[15:12] <abentley> rick_h_: It doesn't seem very decoupled to be emitting privacy_banner:hide/privacy_banner:show.  If you know about the privacy banner, why not ns.getPrivacyBanner()._make_public ?
[15:14] <rick_h_> abentley: because in that case you need to deal with the instance
[15:14] <rick_h_> abentley: the future branch will get rid of the singleton code so you won't call anything. You'll just fire the event.
[15:15] <rick_h_> and ideally, you'll be firing the information type event, not the privacy banner event
[15:15] <rick_h_> so the calling code won't be using _make_public. What you'll have is banners and portlets listening for information_type:change/is_public/is_private events
[15:15] <abentley> rick_h_: Okay, makes sense.
[15:24] <abentley> rick_h_: r=me.
[15:24] <rick_h_> abentley: cool thanks for the review
[16:03] <jcsackett> abentley: you available to look at a branch that just fixes up sampledata?
[16:03] <abentley> jcsackett: sure.
[16:03] <jcsackett> abentley: awesome. :-) https://code.launchpad.net/~jcsackett/launchpad/remove-date_next_suggest_packaging-needs-sampledata/+merge/126475
[16:04] <abentley> jcsackett: r=me.
[16:04] <jcsackett> abentley: thanks!
[16:10] <robbiz^> Hi guys! I've some problems installing launchpad on my laptop, with chroot and rocketful-setup
[16:10] <robbiz^> can I ask someone of you how to fix it?
[16:22] <czajkowski> robbiz^: you might have more luck if you start to explain whats going on
[16:23] <czajkowski> or else posting to launchpad-dev mailing list
[16:24] <czajkowski> robbiz^: https://launchpad.net/~launchpad-dev
[16:25] <robbiz^> Ok...
[16:27] <robbiz^> Well my  postgresql database didn't start
[16:27] <robbiz^> the message is this
[16:28] <robbiz^> Error: The cluster is owned by user id 120 which does not exist any more
[16:29] <robbiz^> going through system folders I've no config file in /etc/postgresql/9.1/main
[16:34] <robbiz^> I have Ubuntu precise with chroot system as explained in dev.launchpad.net
[16:46] <jcsackett> sinzui: you free to talk for a bit?
[16:47] <sinzui> yes
[16:50] <robbiz^> Ok... Probably it's better to post on the mailing-list!
[16:50] <robbiz^> :)
[17:18] <sinzui> jcsackett, ding dong
[17:22] <sinzui> jcsackett, I think this test should pass, but it does not. It might be the origin of the 404 because mail rationales and canonical urls are need to explain why the email as received: http://pastebin.ubuntu.com/1228850/
[17:37] <jcsackett> sinzui: awesome.
[20:00] <lifeless> jcsackett: 'When this is improved' ? <- approved??
[21:33] <jcsackett> lifeless: Sample data branch?
[21:39] <jcsackett> lifeless: approved, yes.
[21:54] <lifeless> jelmer: hey, still interested in packaging lptools ?
[21:55] <jelmer> hi lifeless
[21:55] <jelmer> lifeless: no, not really after wheezy
[21:58] <lifeless> jelmer: have you been using bzr builddeb etc for it, or just regular packaging ?
[21:58] <lifeless> jelmer: I see 'new upstream snapshot' in the log - can't quite tell :)
[21:59] <jelmer> lifeless: I only use bzr builddeb for packages in bzr so that must be what I was using :-)
[21:59] <lifeless> jelmer: also, I haven't used the debian bzr facilities for a couple years - whats the current stuff for pushing there...
[21:59] <lifeless> jelmer: or perhaps I can convince you to do the upload of 0.2.0 and ITA it at the same time ?
[21:59] <jelmer> the last branch is @ http://anonscm.debian.org/bzr/bzr/collab-maint/lptools/unstable/
[22:00] <jelmer> lifeless: Sure, I'm happy to do another upload
[22:00] <jelmer> lifeless: do you mean RFA rather than ITA?
[22:00] <lifeless> yes, crossed wires
[22:00] <lifeless> I was thinking intent to abandon :)
[22:01] <jelmer> lol
[22:01] <jelmer> lifeless: but sure, happy to do another upload with 0.2.0 and the RFA
[22:02] <lifeless> jelmer: that would be awesome, thank you
[22:02] <lifeless> let me file it
[22:08] <lifeless> jelmer: actually, I'm going to O it
[22:09] <jelmer> lifeless: euhrm, okay
[22:09] <lifeless> jelmer: I doubt there will be another upload before I finish here
[22:09] <lifeless> jelmer: and after that I'll have other things to worry about, so saying I'd maintain it in the interim would be an exaggeration
[22:10] <jelmer> lifeless: sounds reasonable to me
[22:10] <lifeless> http://www.debian.org/devel/wnpp/ : "RFA...hey will maintain it in the meantime, but perhaps not in the best possible way. In short: the package needs a new maintainer. "
[22:10] <jelmer> lifeless: I originally thought that's what you meant
[22:10] <lifeless> vs
[22:10] <lifeless> O
[22:10] <lifeless> The package has been "Orphaned". It needs a new maintainer as soon as possible
[22:10] <czajkowski> wgrant: see pm
[22:10] <jelmer> since I think a RFA doesn't require changes to the package itself
[22:10] <lifeless> jelmer: I'm not sure O does either does it ?
[22:11] <lifeless> jelmer: adoption requires the change
[22:11] <jelmer> lifeless: it does, requires changing the maintainer to Debian QA team
[22:11] <lifeless> huh, inconsistent docs ftw
[22:11] <lifeless> jelmer: so, whats easiest for you?
[22:12] <jelmer> lifeless: if you file the O bugreport I can do an upload that changes the maintainer to the QA team
[22:12] <lifeless> will do
[22:16] <lifeless> jelmer: just waiting for the ack
[22:18] <lifeless> jelmer: bug 688916
[22:18] <_mup_> Bug #688916: 75-80% CPU-Usage (starting with 1.9.0beta1) <cpu> <Mixxx:Invalid> < https://launchpad.net/bugs/688916 >
[22:18] <lifeless> well, not that one :P
[22:20] <jelmer> (-:
[22:21] <jelmer> we've given up on critical bugs?
[22:21] <StevenK> Hm
[22:58] <sinzui> wgrant, https://code.launchpad.net/~sinzui/launchpad/bug-subselect-timeout/+merge/126566
[23:10] <StevenK> wallyworld__: http://theamazingios6maps.tumblr.com/
[23:16] <sinzui> jcsackett, r=me
[23:17] <jcsackett> sinzui: awesome, thansk.
[23:19] <sinzui> StevenK, https://devpad.canonical.com/~curtis/launchpad-critical-report/launchpad-criticals.html is updated.
[23:33] <StevenK> wgrant: So, lp-setup-lxc-build actually does a build
[23:34] <wgrant> StevenK: Is the build successful?
[23:35] <StevenK> It looks to run make schema too, it looks fine
[23:36] <StevenK> wgrant: lxc-stop: failed to stop 'lptests': Operation not permitted and ls: cannot access lptests: No such file or directory are a little concerning
[23:37] <wgrant> StevenK: You sure it's adequately root?
[23:37] <StevenK> wgrant: It's running under sudo ...
[23:37] <elmo> apparmor
[23:38] <StevenK> sudo lxc-stop -n lptests does not complain
[23:38] <StevenK> I may have to reach for set -x or run 'id' in the script
[23:39] <wgrant> The apparmor workaround shouldn't be necessary to get this bit working
[23:39] <wgrant> Just some stuff inside the container
[23:39] <wgrant> Like postgres
[23:39] <wgrant> And I think lpsetup does the apparmor disablement.
[23:39] <StevenK> Apparently not for nested
[23:39] <StevenK> According to the README
[23:39] <StevenK> But who reads those anyway
[23:43] <StevenK> wgrant: So the next step is to fire up lp-setup-lxc-tests?
[23:45] <wgrant> StevenK: Right, fill in the lp-setup-lxc-test template and then run something like 'lp-setup-lxc-tests -t lp.services.config' and see what happens
[23:46] <StevenK> Pain, misery and suffering is my guess
[23:46] <wgrant> And/or great success.
[23:46] <StevenK> Well, those aren't mutally exclusive. :-)
[23:53] <wgrant> StevenK: Any luck?
[23:53] <StevenK> wgrant: Just about to run it
[23:54] <StevenK> BLEH
[23:54] <StevenK> Forgot {ssh_key_path}
[23:55] <wgrant> Heh
[23:55] <wgrant> It's easy to do
[23:58] <StevenK> Rargh, single quotes