[00:05] <pleia2> cleared out ubuntu-news-team queue to get the membership email through and added to the doc
[00:07]  * pleia2 returns to travels
[09:43]  * PaulW2U counts summaries - 8 to do
[16:49] <PaulW2U> all summaries done although I've deleted a couple that are not really relevant in a 2-week issue


[01:02] <valorie> {{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{hugs}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} @Sick_Rimmit
 @Valoriez Thanks
[07:08] <valorie> how's she doing?
[07:09] <valorie> @sick_rimmit
 I am afraid she is very poorly, all of the family are gathering. Her friend flew out of Sri Lanka last night and will be arriving similar time to me. My heart is breaking :-(
[07:18] <valorie> oh no!
[07:18] <valorie> {{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{hugs}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}
[07:18] <valorie> oh, I'm so sorry Rick
[07:18] <valorie> that's just not good news
[07:19] <valorie> please get all the real hugs you can stand
 @Sick_Rimmit Best wishes to you and your familiy. That is tough.
 https://launchpad.net/ubuntu/+source/spectre-meltdown-checker/0.28-1
 @Sick_Rimmit Best wishes.
[20:01] <valorie> acheronuk: nice, I hope that gets through from proposed soon
[20:03] <acheronuk> valorie: the very latest verions can be grabbed from https://github.com/speed47/spectre-meltdown-checker
[20:03] <valorie> I'd rather get something packaged
[20:04] <valorie> I figure if "they" have been stealing my datas, they have been doing it for awhile already
[20:05] <acheronuk> I'm not rushing too fast to update things. let them iron out the bugs in the hastily rolled out bugfixes first!
[20:12] <valorie> lol
[20:12] <valorie> they do some testing
[20:12] <valorie> I'm not cynical about *that* part
[20:13] <valorie> just cynical that we'll ever have actual security
[20:13] <valorie> because humans are leaky
[20:19] <valorie> https://www.theinquirer.net/inquirer/news/3024349/intel-amt-flaw-lets-attackers-take-control-of-laptops-in-30-seconds


[00:08] <niemeyer> Man.. the interaction between Launchpad pieces to create our workflow is never-ending
[00:08] <hazmat> :-)
[00:12] <niemeyer> Seriously.. bugs, bug tasks, milestones, projects, series, proposals, people, branches.. we use it all
[00:15] <_mup_> ensemble/managed-agent r344 committed by<EMAIL_ADDRESS>[00:15] <_mup_> managed machine agent
[00:18] <SpamapS> niemeyer: OOHHH YEAHHH <FLEX>
[00:19] <niemeyer> SpamapS: :)
[00:25] <hazmat> niemeyer, like i said.. i found it easier to just sync everything local..
[00:26] <hazmat> when working with any sort of report/ui on top of lp
[00:26] <hazmat> and then factoring in the speed of the average rest call.. and becomes a quick win
[00:32] <_mup_> Bug #838472 was filed: local-dev needs to manage/inspect the network <local-dev> <Ensemble:In Progress by hazmat> < https://launchpad.net/bugs/838472 >
[00:37] <_mup_> Bug #838476 was filed: local-dev provider needs a provider machine <local-dev> <Ensemble:In Progress by hazmat> < https://launchpad.net/bugs/838476 >
[00:45] <_mup_> ensemble/managed-agent r345 committed by<EMAIL_ADDRESS>[00:45] <_mup_> verify agent/process controls can be called multiple times
[00:46] <niemeyer> hazmat: It'd not help much I think.. even if you sync up everything locally, you still have all the linkage between the multitude of types
[00:47] <hazmat> niemeyer, you can collapse the types into app oriented docs/objs when syncing
[00:47] <hazmat> s/types/links
[00:47] <niemeyer> hazmat: Sure, but you're still processing everything up
[00:48] <niemeyer> hazmat: Almost done: http://goneat.org/pkg/launchpad.net/lpad/
[00:48] <niemeyer> It _looks_ like I just need to sort out series now
[00:48] <_mup_> Bug #838480 was filed: local-dev needs a way to manage a machine agent <Ensemble:New> < https://launchpad.net/bugs/838480 >
[00:49] <niemeyer> And then "push-review" is done.. :)
[00:54] <hazmat> niemeyer, nice
[00:54] <hazmat> niemeyer, re lpad.. looking much more complete
[00:55] <niemeyer> hazmat: Goes from branch to ready for review with no interaction
[00:55] <niemeyer> hazmat: Following all of our conventions
[00:55] <niemeyer> hazmat: Opens the preferred text editor for summary/desc
[00:55] <hazmat> niemeyer, awesome.. bug report + lp ?
[00:55] <hazmat> er mp
[00:55] <niemeyer> hazmat: push, bug report, mp, link everything
[00:56] <hazmat> niemeyer, great
[00:56] <hazmat> niemeyer, can i get a copy i? :-)  i just did like 4 of those by hand
[00:57] <niemeyer> hazmat: Oh, most definitely.. I'm doing that for the team
[00:57] <hazmat> niemeyer, nice that you can group all the lp interactions in parallel as well, really cuts down on the command time i would guess
[00:58] <niemeyer> hazmat: Exactly.. it does quite a few things in parallel
[00:58] <niemeyer> hazmat: With nice reporting to stdout and all
[00:58] <niemeyer> hazmat: It was also a good way to push the Launchpad API a bit forward.. I'll need it to continue on the store
[00:59] <niemeyer> That was my day today..
[00:59] <hazmat> niemeyer, yeah. that's great.. i know bcsaller was interested in using it, but needed alot of boilerplate classes to get going
[01:00] <niemeyer> hazmat: There's still a ton missing because the API is so huge, but the foundation is more laid down now
[01:00] <hazmat> niemeyer, good stuff.. i've done pretty well by local dev today.. i'm going to finish up some test for the provider, and move on to the service unit deployment with lxc tomorrow
[01:00] <niemeyer> hazmat: Wow, neat
[01:00] <hazmat> i'm very excited to start using it
[01:00] <hazmat> it will actually totally justify me getting an ssd
[01:00] <niemeyer> hazmat: I noticed a lot of things flying by today
[01:00] <niemeyer> hazmat: Feels like a good wave :)
[01:01] <niemeyer> hazmat: Haha :)
[01:01] <niemeyer> hazmat: It's worth it :)
[01:01] <hazmat> niemeyer, yeah... nice to get some interrupted time.. i've been neglecting the review queue though, i'll have a look at that tomorrow morning
[01:02] <hazmat> i know both you and william have some branches there that need attention
[01:03] <niemeyer> hazmat: Thanks, there are a few things we have to push forward there indeed
[01:58] <_mup_> ensemble/local-provider r345 committed by<EMAIL_ADDRESS>[01:58] <_mup_> wire in the managed machine agent and zk state initialization into provider bootstrap
[03:09] <_mup_> ensemble/local-provider r346 committed by<EMAIL_ADDRESS>[03:09] <_mup_> store zookeeper address into local provider storage, implement connect
[03:13] <hazmat> i started having this problem w/ lxc
[03:13] <hazmat>  ssh<EMAIL_ADDRESS>[03:13] <hazmat><EMAIL_ADDRESS>password:
[03:13] <hazmat> PTY allocation request failed on channel 0
[03:14] <hazmat> bcsaller, you seen that?
[03:14] <bcsaller> thats the issue with add-apt-repo asking for you to press enter I'd guess
[03:15] <bcsaller> http://paste.ubuntu.com/679240/
[03:15] <bcsaller> but not sure, if you change it off the ppa (where it doesn't add the repo) does it work?
[03:15] <hazmat> bcsaller, we're using cloud init in the container now?
[03:15] <hazmat> or is this something just inherent?
[03:15] <bcsaller> I don't use it for anything
[03:15] <hazmat> these are just on oneiric containers that used to be working for me
[03:16] <bcsaller> this isn't a cloud-init issue, its a change in python-softwareproperties
[03:16] <bcsaller> add-apt-repo started asking for confirmation when its got a tty on stdin
[03:16] <bcsaller> might be able to close stdin first and fake it out, not sure yet
[03:18] <bcsaller> or echo y | add-apt-repo...
[03:18] <bcsaller> since it only checks that it gets a newline
[03:21] <hazmat> ugh
[03:38] <_mup_> Bug #838565 was filed: Testing push-review <Ensemble:New> < https://launchpad.net/bugs/838565 >
[03:39] <_mup_> ensemble/local-provider r347 committed by<EMAIL_ADDRESS>[03:39] <_mup_> lxc utility to get a python dict mapping container name to runtime boolean status
[03:44] <_mup_> Bug #838566 was filed: push-review must be tested <Ensemble:In Progress by niemeyer> < https://launchpad.net/bugs/838566 >
[03:44] <_mup_> ensemble/local-provider r348 committed by<EMAIL_ADDRESS>[03:44] <_mup_> shutdown and destroy all containers when destroying environment.
[03:45] <_mup_> Bug #838568 was filed: push-review must be tested again <Ensemble:In Progress by niemeyer> < https://launchpad.net/bugs/838568 >
[03:59] <_mup_> ensemble/local-provider r349 committed by<EMAIL_ADDRESS>[03:59] <_mup_> check required packages installed with python-apt
[04:02] <niemeyer> Alright.. that was a loooong day..
[04:02] <niemeyer> Have a good time everybody
[04:02] <hazmat> niemeyer, indeed.. it was.. looking forward to using the new tool.. cheers
[04:03] <niemeyer> hazmat: Cheers!
[06:24] <_mup_> ensemble/local-unit-deploy r350 committed by<EMAIL_ADDRESS>[06:24] <_mup_> unit deployment with containers
[07:56] <smoser> SpamapS, bug 831505 should be fixed. we chose to redirect output to /dev/null rather than add '-y' as older versions of apt-add-repository dont know that flag.
[07:56] <_mup_> Bug #831505: add-apt-repository blocks cloud-init on oneiric <cloud-init (Ubuntu):Fix Released> < https://launchpad.net/bugs/831505 >
[11:42] <fwereade> is there any consensus solution (heh, I'd take any solution) to the problem of multiple methods with intentionally identical docstrings (eg MachineProviderBase.connect and ZookeeperConnect.run)?
[11:43] <fwereade> or is this just another "the price is eternal vigilance" situation?
[12:17] <hazmat> g'morning
[12:18] <hazmat> fwereade, i was wondering about that
[12:18] <hazmat> fwereade, i thought about using a decorator that pulled from the base class doc string
[12:18] <hazmat> its more relevant with abstract base classes that document the protocol
[12:19] <fwereade> hazmat: I had a similar thought, but it seemed a bit icky ;)
[12:19] <fwereade> hazmat: true
[12:20] <fwereade> hazmat: but then there are cases where the base specifies (say) :class:`ProviderMachine` and the base will want to say :class:`OrchestraMachine`
[12:20] <hazmat> fwereade, i used to use zope.interfaces as a primary doc point, and let the implementation stand alone, with a see ``interface.method``
[12:21] <fwereade> hazmat: I couldn't see anything that would be useful in enough cases to make it feel worth bothering
[12:22] <fwereade> hazmat: mm, handy in the right context
[12:24] <fwereade> hazmat: hey, is sphinx smart enough to connect things with unique names?
[12:24] <fwereade> hazmat: so :exc:`ProviderInteractionError` rather than :exc:`ensemble.errors.ProviderInteractionError`?
[12:25] <fwereade> hazmat: feels like a bit too much to expect, but if not I have to go back and fully qualify a bunch of stuff
[12:25] <fwereade> ah well
[12:27] <hazmat> fwereade, i believe it is
[12:27] <hazmat> we need to start genering the docs from source to find out
[12:27] <hazmat> jim mentioned he had an issue with it earlier
[12:28]  * hazmat tries to find a place in sf to stay next week for the lxc sprint
[12:32] <fwereade> hazmat: hm, I guess I should actually try generating them :/
[14:03] <hazmat> niemeyer, morning
[14:03] <niemeyer> hazmat: Morning!
[14:05] <fwereade> morning niemeyer
[14:05] <niemeyer> fwereade: yo!
[14:05] <niemeyer> How's everyone doing this morning?
[14:05] <niemeyer> Or rather, this X? :-)
[14:06] <hazmat> fwereade, great reviews, thanks
[14:06] <fwereade> not too bad :) and you?
[14:06] <hazmat> niemeyer, i'm still recovering from a  late night, but early wake up
[14:07] <fwereade> hazmat: cool, glad they're helpful -- I got a bit overwhelmed by the test failures so I kinda stopped half way through
[14:07] <hazmat> fwereade, yeah those suck
[14:07] <niemeyer> hazmat: Indeed! This must be pretty early for you given how late we were yesterday
[14:07] <hazmat> fwereade, i'm looking at the control deploy failures now
[14:07] <hazmat> very odd
[14:07] <hazmat> KeyInteruption in the middle of a test without hitting a keyboard
[14:07] <fwereade> hazmat: incidentally, should I WIP them when I mark them "needs fixing"? it seemed presumptuous, but on balance I think it's less helpful *not* to
[14:08] <fwereade> hazmat: (if that makes sense)
[14:08] <hazmat> fwereade, i think its appropriate when there's a test failure like this
[14:08] <fwereade> hazmat: cool, cheers
[14:08] <niemeyer> fwereade: Yeah, you have to take a decision there, of whether it'd be beneficial for the next reviewer to look at the changed branch, or if it doesn't make a difference
[14:08] <hazmat> fwereade, it really depends imo, if the changes for the review are substantial enough that a second reviewer would be better to have a look after the changes
[14:09] <fwereade> hazmat: sounds sensible
[14:26] <hazmat> looks like there was something in the lxc-lib branch which has a delta to trunk regarding placement policies
[14:37] <_mup_> ensemble/lib-zookeeper r340 committed by<EMAIL_ADDRESS>[14:37] <_mup_> revert changes from lxc-lib to ensemble/control, resolves some deploy test failures
[14:40] <jimbaker> hazmat, trial can raise a KeyboardInterrupt in _wait, see twisted.trial.unittest: http://paste.ubuntu.com/679811/
[14:49] <hazmat> jimbaker, thanks, thats very useful to know
[15:00] <fwereade> jimbaker: I've just been poking at sphinx docstring-grabbing; hazmat mentioned you might know of some problems
[15:01] <jimbaker> fwereade, indeed i did experience problems in generating docs using autodoc
[15:02] <jimbaker> fwereade, so did you just do the basic stuff of setting up autodoc through conf.py and linking in packages to be doc'ed?
[15:02] <fwereade> jimbaker: basically yes
[15:03] <fwereade> jimbaker: what was the problem?
[15:03] <jimbaker> fwereade, when i did that, i ran into a recursion error in docutils
[15:04] <jimbaker> fwereade, i assumed it was just bad some docstring that was breaking things and just needed to be isolated
[15:07] <fwereade> jimbaker: heh, haven't hit that yet -- btw, have I missed some option that will cause it to find and document *all* the docstrings?
[15:07] <jimbaker> fwereade, you expected that? ;)
[15:07] <fwereade> jimbaker: kinda :p
[15:08] <fwereade> jimbaker: the "auto" bit of the name "autodoc" got my hopes up a bit
[15:08] <jimbaker> fwereade, in fact so did i. but the sphinx project apparently thinks this is not so useful. there is a third party script to do that which i found
[15:09] <jimbaker> fwereade, to be honest, the mechanism they do have which is to require this be done in __init__.py is not so bad
[15:09] <fwereade> jimbaker: I noticed something like that, and then I started thinking about stripping test docstrings, and then I started doing something else
[15:09] <fwereade> jimbaker: indeed, quite sensible, may as well go with that then
[15:10] <fwereade> jimbaker: and I guess I'll build after every change and hopefully spot the recursing thing that way
[15:10] <fwereade> jimbaker: cheers :)
[15:10] <jimbaker> fwereade, indeed, i think it should pop out quickly
[15:20] <niemeyer> Holy crap.. our review queue is _amazing_
[15:23] <niemeyer> I'll step out for lunch.. may be a few minutes late for our meeting
[15:31] <robbiew> fyi, tweaked https://ensemble.ubuntu.com/ a bit last night....holler if there's an issue
[15:32] <_mup_> ensemble/lib-files r341 committed by<EMAIL_ADDRESS>[15:32] <_mup_> remove use of file_storage.path by some tests.
[16:12]  * niemeyer is around
[16:13] <niemeyer> robbiew: Ohh, video
[16:13] <niemeyer> robbiew: Great stuff, thanks man
[16:13] <robbiew> np
[16:14] <niemeyer> bcsaller, jimbaker, fwereade, hazmat: Call time?
[16:15] <fwereade> niemeyer: sounds goood
[16:15] <niemeyer> robbiew: Wanna join?
[16:15] <bcsaller> niemeyer: I'm around
[16:15] <jcastro> g+? I wouldn't mind listening in if you guys have the room
[16:15] <niemeyer> jcastro: We can put a few things away to accommodate you for sure
[16:16] <jimbaker> niemeyer, cool
[16:16] <robbiew> niemeyer: invite me...I'll join later, on a call
[16:17] <niemeyer> jcastro: Not entirely sure if I did the right thing when inviting you.. I used your canonical addres
[16:17] <niemeyer> s
[16:18] <niemeyer> Weird..
[16:18] <niemeyer> It broke down
[16:18] <jcastro> odd, never seen that error before
[16:19] <hazmat> just sent out a new invite
[16:19] <hazmat> g+ hangouts have been flakey for me on occasion
[16:20] <bcsaller> my camera isn't working, going to relog
[16:21] <jimbaker> still waiting on a g+ hangout
[19:21] <hazmat> these leaking temp files and dirs are a problem
[19:21] <hazmat> seeing lots of them
[19:23] <niemeyer> jimbaker: ping
[19:24] <niemeyer> bcsaller, hazmat: I've renamed a couple of blueprints to remove the redundant "ensemble-" prefix.. feel free to change further please
[19:32] <jimbaker> niemeyer, hi
[19:33] <niemeyer> jimbaker: Sent some private comments
[19:53] <SpamapS> http://paste.ubuntu.com/680072/
[19:53] <SpamapS> ^^ this test fails for me sometimes.. but not all the time
[19:54] <SpamapS> actually it fails every time
[20:33] <hazmat> SpamapS, interesting
[20:33] <hazmat> SpamapS, that's one of the tests that i found leaks files as well
[20:33] <hazmat> actuall a temp directory
[20:54] <_mup_> ensemble/ftests r1 committed by<EMAIL_ADDRESS>[20:54] <_mup_> Bootstraped simplistic functional test suite.
[20:57] <niemeyer> jimbaker: https://launchpad.net/ensemble/ftests
[20:58] <jimbaker> niemeyer, thanks
[20:58] <niemeyer> jimbaker: mkdir ensemble-ftests; cd ensemble-ftests; bzr init-repo .; bzr branch lp:ensemble/ftests ftests
[20:58] <niemeyer> jimbaker: Different line of development
[20:58] <niemeyer> jimbaker: Branches, merge proposals, etc, all as usual..
[20:59] <niemeyer> jimbaker: http://bazaar.launchpad.net/~ensemble/ensemble/ftests/files
[20:59] <niemeyer> jimbaker: Please preserve the structure and spirit in there.. churn should continue to be a shell-script too
[21:00] <niemeyer> jimbaker: Generate the html out of the output directory.. should be trivial
[21:00] <jimbaker> niemeyer, ok, taking a look at the skeleton
[21:01] <niemeyer> jimbaker: Leave environments.yaml and AWS credentials outside of the test suite itself, for now
[21:01] <niemeyer> jimbaker: So that it works with any deployment method based on who sets it up
[21:01] <jimbaker> niemeyer, sure
[21:01] <niemeyer> jimbaker: Not sure if that'll be a good idea, but let's try it
[21:02] <niemeyer> jimbaker: The tool to generate the html can be in Python or whatever you please, for convenience
[21:03] <niemeyer> jimbaker: It'll also have to take into account different runs of the tool
[21:03] <niemeyer> jimbaker: To produce the waterfall
[21:03] <jimbaker> niemeyer, i'm certainly glad i don't have to write everything in bash
[21:03] <niemeyer> jimbaker: :-)
[21:03] <SpamapS> devops_borat.. "If you are still do manual deployment, you need of know in devops we call it 'hand job'"
[21:04] <jimbaker> niemeyer, is it really necessary to have churn (what we discussed as the runner) be a shell script too?
[21:05] <niemeyer> jimbaker: Yes, it is, because it'll ensure you keep it simple
[21:06] <jimbaker> seems like a painful lesson in bash scripting, but ok
[21:07] <SpamapS> Hmm, so.. working on bug 813112 so I can make the package builds fail on test failure..
[21:07] <_mup_> Bug #813112: test suite cannot run without an ssh key <Ensemble:New> < https://launchpad.net/bugs/813112 >
[21:07] <niemeyer> jimbaker: It's more than that.. it's a lesson in simplicity.  I don't expect you'll need much more than what's there to solve our problem.
[21:07] <niemeyer> jimbaker: If anything at all.
[21:07] <SpamapS> http://paste.ubuntu.com/680131/
[21:08] <jimbaker> niemeyer, i'll see what it takes
[21:08] <SpamapS> That fixes it..
[21:08] <SpamapS> I suppose I should just throw it in the review queue.
[21:08]  * SpamapS waves his hands... nothing to see here
[21:08] <jimbaker> niemeyer, in particular, why are log/fatal defined in churn?
[21:09] <niemeyer> jimbaker: I don't get what you mean.. the functions seem self-obvious to me?
[21:11] <jimbaker> niemeyer, well why would you need them there? shouldn't it be the responsibility of the tests to produce output, as they do in the examples now?
[21:12] <niemeyer> jimbaker: Again, I don't understand what you mean..
[21:13] <niemeyer> jimbaker: I want to be able to type ./churn and have reasonable output presented to me
[21:14] <niemeyer> jimbaker: log is an incredibly trivial function that simply presents a message with a timestamp in it..
[21:14] <niemeyer> jimbaker: Why does that sound strange?
[21:15] <jimbaker> niemeyer, never mind
[21:15] <niemeyer> jimbaker: Done
[21:18] <niemeyer> I'll get some coffee
[21:27] <hazmat> niemeyer, is there a reason why the golang-weekly hasn't been updated in a month? does it depend on an upstream weekly release?
[21:27] <hazmat> yeah.. it looks like no recent weeklies
[21:28] <niemeyer> hazmat: I've been slacking
[21:28] <niemeyer> hazmat: I was just updating it _today_ though
[21:28] <niemeyer> hazmat: After lucio asked about it
[21:29] <niemeyer> hazmat: tip has been updated.. I'll poke the weekly now
[21:38] <hazmat> niemeyer, cool.. where does goinstall put files on disk for a go-lang package install?
[21:39] <hazmat> got it /usr/lib/go/pkg
[21:41] <niemeyer> hazmat: $GOPATH, if you set it as a user
[21:41] <niemeyer> hazmat: Otherwise it'll try to put in $GOROOT
[21:41] <hazmat> niemeyer, ic, just doing the package install
[21:41] <hazmat> niemeyer, so do you manipulate GOPATH when you have multiple packages in the same source tree
[21:41] <hazmat> niemeyer, i'm trying to run the formula tests, but it won't find the schema package for example
[21:42] <niemeyer> hazmat: Hmm
[21:42] <hazmat> do i need to goinstall the schema package? and then continually update it ?
[21:42] <niemeyer> hazmat: I may have to tweak that to work with GOPATH
[21:42] <niemeyer> hazmat: What I've been doing, and which should work, is to make install within the schema package
[21:42] <niemeyer> hazmat: The detail is that I have a local tip branch
[21:43] <niemeyer> of go
[21:43] <niemeyer> hazmat: This should work with GOPATH as well, though
[21:43] <niemeyer> hazmat: But I'll have to fix it
[21:43] <niemeyer> hazmat: The design was made in such a way that you can goinstall straight from Launchpad
[21:43] <niemeyer> hazmat: goinstall launchad.net/ensemble/go/schema works
[21:44] <niemeyer> hazmat: and so does goinstall launchad.net/ensemble/go/formula
[21:44] <niemeyer> hazmat: the latter will automatically perform the former even
[21:44] <hazmat> niemeyer, sure.. but if i'm testing a source tree which has multiple packages, then i'll need to constantly update those
[21:45] <niemeyer> hazmat: There are just some minor inconveniences right now because $GOPATH is a recent thing and hasn't been introduced across the board in all tools, so I'll have to tweak the Makefile a bit
[21:46] <hazmat> niemeyer, cool, it would definitely be a benefit to have packages tested together from the same tree, instead of having to version manage the installed against the src tree.
[21:46] <niemeyer> hazmat: How do you mean?  As I just explained, there are some details right now, but the design is that you'll have to do nothing besides goinstalling
[21:46] <niemeyer> hazmat: I think we misunderstand each other.. they are in the same tree
[21:47] <hazmat> niemeyer, goinstalling puts files in into the $GOROOT/pkg tree.. but say i have two interdependent package changes in the same src tree, i want to run make test, and have it use the src tree for both packages, not manually update the $GOROOT/pkg beforehand
[21:48] <niemeyer> hazmat: As I explained, you should use $GOPATH, not $GOROOT, and they'll all be in $GOPATH/src, in the same tree
[21:49] <niemeyer> hazmat: goinstall will soon also figure changes in dependent packages automatically, and rebuild/reinstall
[21:49] <niemeyer> hazmat: It's flaky right now because this area is being worked on, but the plan is pretty good
[21:49] <niemeyer> hazmat: Soon we'll need no Makefile iether
[21:49] <niemeyer> either
[21:50]  * hazmat looks up gopath
[21:51] <hazmat> interesting, sort of like an encapsulation of virtualenv into an environment variable
[21:53] <niemeyer> hazmat: Yeah
[21:56] <niemeyer> hazmat: If you want to test the code quick & fast without worrying about anything else, you can just install Go from tip with: hg clone https://go.googlecode.com/hg go; cd go; export GOROOT=$PWD; cd src; ./make.bash
[21:57] <niemeyer> hazmat: This will mean GOROOT is writable
[21:57] <niemeyer> hazmat: and it's why it works..
[21:57] <niemeyer> hazmat: I'll sort out the Makefiles in the future, though, so that GOPATH is taken care of in the Makefiles
[21:57] <niemeyer> hazmat: Sorry for the trouble there
[21:59] <hazmat> niemeyer, no worries, thanks for the info, i'll see if i can run the tests with that.. the remote version of launchpad.net/ensemble/go/schema is more recent than the one in the branch, so it gets undefined symbols for the renames
[22:00] <niemeyer> hazmat: Hmm
[22:00] <niemeyer> hazmat: Have you noticed that schema and formula are in the same branch?
[22:00] <hazmat> niemeyer, i have
[22:01] <hazmat> niemeyer, how do you install a src package with goinstall
[22:01] <niemeyer> hazmat: Have I screwed up something then?  Any branch should be self-consistent
[22:01] <hazmat> afaics, i have to rename the directories into import paths to use GOPATH
[22:01] <niemeyer> hazmat: goinstall "server.com/import/path"
[22:01] <niemeyer> hazmat: Why?
[22:01] <hazmat> niemeyer, that installs the remote version
[22:02] <niemeyer> hazmat: Unless you have a local version
[22:02] <hazmat> niemeyer, the remote version is incompatible with one of the packages in the branch, it needs to compile against the other package in the branch
[22:02] <hazmat> niemeyer, i'm just running make test from the formulas directory
[22:03] <hazmat> niemeyer, if there's a way to install the local version of the package that would work
[22:03] <niemeyer> hazmat: I don't understand.. the remote version works with the remote version.. branches work with the content of the branch
[22:03] <niemeyer> hazmat: It's like Python
[22:03] <niemeyer> hazmat: If you have a branch, ensemble.provider works with ensemble.state of the same branch
[22:03] <niemeyer> hazmat: There's no difference there
[22:03] <hazmat> niemeyer, is there some path variable you have to define for that? .. i'm trying to run 'make test' in the formula directory
[22:04] <niemeyer> hazmat: No.. as I explained, what I do is to: cd schema; make install; cd ../formula; gotest
[22:06] <hazmat> niemeyer thanks, that's what i needed
[22:07] <niemeyer> hazmat: http://paste.ubuntu.com/680159/
[22:08] <niemeyer> hazmat: And again, this is still pretty clumsy compared to what we'll have shortly..
[22:09] <niemeyer> hazmat: Once $GOPATH and gomake come fully to life, it'll be brainless..
[22:09] <hazmat> niemeyer, indeed that will be much easier
[22:09] <niemeyer> hazmat: Just gomake inside schema will do everything
[22:09] <hazmat> niemeyer, http://paste.ubuntu.com/680163/
[22:09] <niemeyer> hazmat: Define GOROOT
[22:09] <hazmat> k
[22:09] <niemeyer> hazmat: export GOROOT=/usr/lib/go
[22:09] <niemeyer> hazmat: If you're using the package
[22:10] <niemeyer> gomake would do that for you already, by the way
[22:11] <niemeyer> But since you'll be playing with it often, it's worth putting it in the profile
[22:11] <hazmat> niemeyer, i've got the standard go variables defined pointing at the system path
[22:11] <hazmat> s
[22:12] <hazmat> /usr/lib/go for goroot /usr/bin for gobin
[22:12] <niemeyer> Cool
[22:12] <hazmat> i've got  a previous install of the newer remote package version in goroot
[22:12] <hazmat> which is causing the problem
[22:12] <niemeyer> hazmat: But it was undefined in that paste, right?
[22:14] <hazmat> niemeyer, oh.. i assumed the newer version has the renames already in it.. it would have a different error regarding the package import if it wasn't installed
[22:15] <hazmat> if i remove the pkg from $GOHOME, and do the cd schema; make install; cd ../formula; gotest it fails with http://paste.ubuntu.com/680165/
[22:16] <niemeyer> hazmat: DEFINE $GOROOT!
[22:16] <niemeyer> :-)
[22:16] <niemeyer> Makefile:1: /src/Make.inc: No such file or directory
[22:16] <niemeyer> There's a $GOROOT variable before the /src/ in that line.. which is empty!
[22:16] <hazmat> hmm.. but its defined.. make test in the schema works fine
[22:17] <niemeyer> It's not defined, no
[22:17] <niemeyer> export GOROOT=/usr/lib/go
[22:17] <niemeyer> Or whatever it is
[22:17] <hazmat> http://paste.ubuntu.com/680169/
[22:17] <hazmat> yeah
[22:17] <niemeyer> hazmat: It's not defined..
[22:17] <niemeyer> hazmat: That's the error you're getting
[22:18] <niemeyer> hazmat: This is the first line in the Makefile:
[22:18] <hazmat> niemeyer, that's env | grep GO in the shell. it is defined
[22:18] <niemeyer> include $(GOROOT)/src/Make.inc
[22:18] <hazmat> ah
[22:24] <niemeyer> hazmat: Works now?
[22:39] <niemeyer> hazmat: Can't find a way to link blueprints and bugs in the API :-(
[22:39] <hazmat> niemeyer, nope.
[22:39] <niemeyer> hazmat: What's wrong now?
[22:41] <hazmat> niemeyer, same problems, if i install it complains about undefined schema.M, if i uninstall it.. it complains about it not being found
[22:41] <niemeyer> hazmat: Can you please paste the error?
[22:43] <hazmat> niemeyer, it was the sudo.. killing the env  variable i think
[22:43] <hazmat> nope.. still an error
[22:44] <niemeyer> hazmat: Same error?
[22:44] <hazmat> http://paste.ubuntu.com/680178/
[22:44] <niemeyer> hazmat: It's the same error.. GOROOT not defined
[22:44] <niemeyer> hazmat: Use gomake.. it'll export the variable fo ryou
[22:45] <hazmat> niemeyer, sweet! that works
[22:45] <niemeyer> hazmat: Woohay
[22:46]  * hazmat grabs some dinner
[23:26] <hazmat> niemeyer, yeah i don't see any way to attach a bug to the blueprint/spec via the api
[23:27] <hazmat> bummer
[23:27] <niemeyer> hazmat: Sadness.. let's see if the LP folks can give us a hand