[01:16] <SpamapS> jcastro: hahahahah no I made that for the Cloud Days presentation like 3 months ago. ;)
[01:24] <jcastro> SpamapS: I didn't know about it before
[01:24] <jcastro> I am going to steal it
[01:26] <SpamapS> jcastro: the one on the wiki is svg ... make sure to steal *that* :)
[01:26] <jcastro> We should ask someone on design to prettyfy it
[01:26] <SpamapS> yeah that would be cool
[01:27] <SpamapS> I'm hesitant to make the marketing assets more polished than ensemble itself tho ;)
[01:27] <jcastro> well, I see people are using it and reporting the annoyances
[01:28] <jcastro> robert collins just filed a few
[06:34] <niemeyer> Good morning all
[07:49] <niemeyer> fwereade: Morning
[07:53] <_mup_> ensemble/trunk r288 committed by gustavo@niemeyer.net
[07:53] <_mup_> Merged fix-status-scope branch from Clint [r=bcsaller,fwereade]
[07:53] <_mup_> Fixes ensemble status to work with multiple scope filters as per the
[07:53] <_mup_> help documentation. Tests were also adapted to reflect the arguments
[07:53] <_mup_> one should expect from argparse.
[08:08] <kim0> Morning all
[08:17] <niemeyer> kim0: Morning!
[08:17] <kim0> niemeyer: hey .. oh you're up so early :)
[08:17] <niemeyer> kim0: Yeah, I'm actually about to step back to try to sleep some more
[08:18] <kim0> have some nice rest then
[08:18] <niemeyer> Just couldn't sleep for a while, and decided to get up and do something useful
[08:18] <niemeyer> Thanks,  see you soon :)
[08:18] <kim0> :)
[08:22] <fwereade> niemeyer: hey! totally missed you, don't expect people on IRC at this time :p
[08:23] <fwereade> nice w/e?
[08:23] <fwereade> and hey kim0 ;)
[08:23] <kim0> fwereade: Hey Morning o/ :)
[08:35] <raphink> I think one should expect people on IRC at about any time
[08:36] <raphink> given there's people who live all around the globe (and even have internet access)
[10:16] <fwereade> I have a recollection that "fix released" currently means "merged into trunk" rather than actually "released" -- can anyone confirm?
[10:17] <fwereade> if so I can mark a couple of bugs "fix released", and tidy up kanban a little
[10:25] <kim0> raphink: yeah pretty much :) 
[10:40] <noodles775> Hi! Does anyone know if m_3 's psql branch is near ready for inclusion in principia ? https://bugs.launchpad.net/principia/+bug/803841
[10:40] <_mup_> Bug #803841: Formula needed (postgresql) <new-formula> <Ensemble Formulas:In Progress by mark-mims> < https://launchpad.net/bugs/803841 >
[11:15] <kim0> SpamapS: oh nice work on the graphic at http://askubuntu.com/questions/55179/what-is-the-purpose-of-the-bootstrapping-instance-ensemble :)
[11:15] <kim0> wonder if that should be added to the bootstrapping section of the user-tutorial
[11:56] <hazmat> g'morning
[11:58] <fwereade> hazmat: heyhey
[12:04] <hazmat> fwereade, how's your day so far?
[12:04]  * hazmat tries to figure out if there's a way to see what the service-config settings are for a service
[12:05] <fwereade> hazmat: ah, not too bad... I think I may have actually just run out of work for the moment, I was about to take a look at some reviews
[12:05] <fwereade> once I get confirmation from andres that cobbler-launch-machine works for him I'll have anothe 3 branches to propose
[12:06] <hazmat> fwereade, nice re cobbler, that's awesome
[12:06] <fwereade> and you; nice weekend?
[12:06] <fwereade> hazmat: there are a few more things we need to think about but I've been concentrating on getting parity with the spike branch
[12:08] <hazmat> fwereade, quiet weekend, don't remember much of it ;-) spent some time cutting a computer case with with a rotary blade so it could fit some 5x3 drive enclosures, also picked up a 4g hotspot device till my new internet connection is setup (my old isp sucked and 'accidentally' dropped me when i made an unrelated request).
[12:08] <hazmat> fwereade, do you have a local cobbler instance for testing or is it based on extraction from the spike w/ mocking?
[12:09] <fwereade> my local cobbler is, er, partially working
[12:10] <fwereade> most stuff I can test directly, but actually completing a netboot install of oneiric has had a long series of hilarious and bizarre problems
[12:10] <fwereade> I might grid my lions and have another go shortly but it's a dispiriting prospect ;)
[12:27] <fwereade> btw, hazmat, I was going to take a look at lp:~hazmat/ensemble/security-groups, but I'm a bit confused about its status
[12:29] <fwereade> it claims to depend on lp:~hazmat/ensemble/security-connection... which lp thinks exists, but bzr doesn't
[12:54] <hazmat> fwereade, it depends on lp:~hazmat/ensemble/security-connection-redux
[12:55] <hazmat> fwereade, i'm not sure what happened to security-connection branch, but lp doesn't like it.. the revisions are the same though
[12:58] <fwereade> hazmat: heh, ok, thanks :)
[13:11]  * hazmat pokes at fwereade  fds testing work
[13:11]  * fwereade wishes to make clear he has no idea what he's doing, and really appreciates fixes and explanations ;)
[13:12] <hazmat> fwereade, i'm curious to see if we manually run the gc how the numbers change
[13:12] <fwereade> hazmat: good idea
[13:13] <hazmat> fwereade, alternatively to scanning all fds, it might have been easier to just scan the /proc/pid/fd
[13:14] <hazmat> oh.. that's what's its doing
[13:15] <hazmat> 'self'
[13:15] <fwereade> hazmat: that's what I do, is there some code lying around still doing things the dumb way?
[13:15] <fwereade> hey, I don't think I fixed ... er ... the branch it was originally flagged on, whatever it was
[13:16] <hazmat> fwereade, yeah my mistake, looks fine, i hadn't seen the 'self' syntax before
[13:16] <fwereade> (and it turns out I did fix lp:~fwereade/ensemble/storage-file-objects :))
[13:16] <fwereade> hazmat: cool :)
[13:17] <hazmat> one other issue, if  a test fails and had temp files/dirs they stick around post test run
[13:17] <hazmat> not related to the branch, just a general test issue
[13:19] <fwereade> hazmat: I view that as a feature, myself: when a test fails I really like to be able to look at the problematic temp files ;)
[13:21] <hazmat> fwereade, so this is actually pointing out alot of failures in things that are okay
[13:22] <hazmat> fwereade, the addCleanup calls from lib/mocker.py run after teardown
[13:22] <hazmat> which take care of self.makeDir, self.makeFile afaicr
[13:22]  * hazmat double checks
[13:22] <fwereade> hazmat: gaah! nice catch :D
[13:22] <hazmat> mocker isn't deferred aware so the ordering is a little odd at times
[13:23] <fwereade> hazmat: I assumed teardown happened in tearDown, but you know what they say about assumptions :)
[13:23] <fwereade> (they make an ass of u and mptions... hmm, doesn't quite work like that)
[13:26] <hazmat> fwereade, i made a one line change to fix it against spurious tests, in the modified _run, if methodName=="tearDown": self.addCleanup(self._diff_fds)
[13:26] <hazmat> spurious failures that is
[13:26] <fwereade> hazmat: awesome, how much nicer does it come out?
[13:27] <hazmat> fwereade, not catching normal operations, reduces the problem almost entirely afaics
[13:27] <fwereade> hazmat: and I guess we're pretty safe from having further cleanups added at that point
[13:27] <hazmat> fwereade, doing a full run now
[13:28] <fwereade> hazmat, brb
[13:32] <fwereade> b
[13:36] <m_3> noodles775: currently the basic pg formula works.  authentication is wide open and there's no replication.
[13:37] <hazmat> hmm, trial has an addCleanup that masks mocker's addCleanup 
[13:37] <noodles775> k, thanks m_3. 
[13:37] <m_3> noodles775: I should get the acls working before inclusion into principia
[13:38] <RoAkSoAx> fwereade: howdy!!
[13:38] <fwereade> RoAkSoAx: heyhey!
[13:38] <fwereade> RoAkSoAx: nice weekend?
[13:38] <noodles775> m_3: Yep, sounds sane :) I've subscribed to the bug so I'll know when I can try it. Thanks mor working on it!
[13:39] <RoAkSoAx> fwereade: yeah!! busy though!! how was yours?
[13:40] <fwereade> RoAkSoAx: nice, very peaceful, cath and laura were still in the UK for most of it
[13:41] <m_3> noodles775: awesome, I'll keep it updated
[13:41] <RoAkSoAx> fwereade: cool ;)
[13:41] <RoAkSoAx> fwereade: anywas, what's your latest branch?
[13:42] <fwereade> RoAkSoAx: hmm :)
[13:43] <fwereade> RoAkSoAx: shadow-trunk is not yet updated with either lp:~fwereade/ensemble/cobbler-kill-machine or lp:~fwereade/ensemble/bootstrap-verify-storage
[13:43] <fwereade> but maybe best to skip bootstrap-verify-storage for now: I think it's good, but it could interact with launch-machine (which is merged)
[13:44] <fwereade> and I'd like to be sure of cobbler-launch-machine's status
[13:46] <RoAkSoAx> fwereade: ok
[13:47] <RoAkSoAx> fwereade: i'll work on top of shadow-trunk first then
[13:47] <fwereade> RoAkSoAx: awesome
[13:47] <fwereade> RoAkSoAx: if it looks healthy, I'll merge in 2 more and make 3 merge proposals
[13:50] <RoAkSoAx> fwereade: awesome!
[13:50] <fwereade> RoAkSoAx: it actually works?
[13:52] <fwereade> hazmat: I'm sorry, but I'm really confused about your security-* pipeline: would you please tell me exactly what order I should be looking at them in? I'm driving myself slightly insane
[13:53] <RoAkSoAx> fwereade: havent started yet
[13:53] <RoAkSoAx> will let you know as soon as I do
[13:53] <RoAkSoAx> fwereade: im updating all the cobbler-side pieces first
[14:03] <fwereade> hazmat: don't worry, I think I've figured it out
[14:36] <niemeyer> Good morning!
[14:37] <niemeyer> Hmm.. funny to say that twice in the same day
[14:38] <niemeyer> Aram, Aram2: Morning to both of you
[14:38] <Aram2> hi :-).
[14:38] <Aram2> I'm having some issues running the tests. http://pastebin.com/GPkiK7uZ
[14:39]  * niemeyer looks
[14:39] <Aram2> I assume it doesn't parse ~/.ensemble/environments.yaml ?
[14:40] <niemeyer> Aram2: Hmmm
[14:40] <niemeyer> Aram2: That's strange.. have you touched any code?
[14:40] <Aram2> no.
[14:40] <Aram2> latest rev from bzr.
[14:40] <niemeyer> Aram2: Let me try to run this test
[14:40] <niemeyer> Aram2: In theory, this test should be mocked
[14:40] <niemeyer> Aram2: Sorry, I actually mean that this part of the logic should be mocked
[14:41] <Aram2> I see.
[14:41] <niemeyer> Aram2: Test passes here
[14:41] <niemeyer> Hmm
[14:41]  * niemeyer reads the test
[14:42] <Aram2> how can I run only this tests and not all?
[14:42] <niemeyer> Aram2: Just take that last string at the end of your paste and put it after ./test
[14:43] <Aram2> also, I am using bzr branch lp:ensemble , I assume this is the branch I am interested about.
[14:43] <Aram2> ah, ok.
[14:43] <niemeyer> Aram2: It is indeed
[14:43] <Aram2> yeah, test fails.
[14:43] <Aram2> ensemble works though.
[14:44] <niemeyer> Aram2: Phew.. that's actually good
[14:44] <niemeyer> Aram2: If it passed it'd mean the failure would come from the interaction between tests, and would be harder to debug :-)
[14:46] <niemeyer> Aram2: Hah
[14:47] <niemeyer> Aram2: This test is actually broken, nevermind
[14:47] <Aram2> heh.
[14:47] <niemeyer> Aram2: It's just that pretty much all of us have the environment set up
[14:47] <niemeyer> Aram2: The real env, I mean
[14:47] <niemeyer> Aram2: Not ~/.ensemble
[14:48] <Aram2> aha.
[14:48] <niemeyer> Aram2: Many EC2 tools depend on the AWS_ACCESS_KEY_ID variable
[14:48] <niemeyer> Aram2: and it's partner (AWS_SECRET_ACCESS_KEY)
[14:48] <niemeyer> Aram2: Our tests should not depend on it to run, though
[14:49] <Aram2> yeah...
[14:49] <niemeyer> Aram2: For the moment, you can just disable this test
[14:50] <_mup_> Bug #819329 was filed: Tests depend on AWS_ACCESS_KEY_ID being set <Ensemble:Confirmed> < https://launchpad.net/bugs/819329 >
[14:51] <hazmat> niemeyer, good afternoon ;-)
[14:52] <niemeyer> hazmat: Hey!
[14:54]  * hazmat hands off review queue crown to fwereade 
[14:55]  * fwereade peers at it, and tries to put it on his foot
[14:58] <niemeyer> :-)
[14:58] <jcastro> robbiew: heya do you have those 5 reasons narrowed down? I need them for a slide
[14:58] <robbiew> yeah...but they aren't "blessed" yet
[14:59] <robbiew> need to run them by sabdfl with jono
[14:59]  * jcastro nods
[14:59] <robbiew> they are in the Messaging whatever
[14:59] <jcastro> ok
[14:59] <robbiew> one of the bazillion ensemble google docs
[15:02] <niemeyer> :)
[15:03] <niemeyer> Aram2: How's it going overall, btw?  Have you started doing any coding, or still at the understanding phase?
[15:04] <Aram2> Aram2: I have been busy a little bit... I have played with ensemble, read he current code and now I'm trying to make Go and Python work together nicely in some way.
[15:04] <Aram2> it would be nice if you could call one from the other but unfortunately you can'
[15:04] <Aram2> t :-).
[15:05] <niemeyer> Aram2: Right, agreed
[15:05] <niemeyer> Aram2: Note that for this experiment, you don't really have to make them play together
[15:05] <niemeyer> Aram2: The question is more how it'd look like if some pieces were ported over
[15:06] <Aram2> yeah.
[15:13] <_mup_> ensemble/states-with-principals r302 committed by kapil.thangavelu@canonical.com
[15:13] <_mup_> use constant for otp identity key in domain state dict, machine state tracks otp data reference.
[15:36] <fwereade> niemeyer, hazmat: security-otp-principal
[15:36] <fwereade> intended only to narrow the window of opportunity for a potential attacker, rather than anything stronger?
[15:37] <hazmat> fwereade, i'm in progress on a reply on the mp, the nutshell is your assessment is correct, there is a window till the otp is consumed that an attacker can gain access to the persistent principal credentials if they can get ahold of the otp prinicipal/data enroute.
[15:38] <fwereade> hazmat: thanks
[15:39] <fwereade> is there any way to review "approve so long as you file a bug about this shortcoming when you merge it"? :p
[15:39] <niemeyer> It would be mitigated by encryption, though
[15:39] <fwereade> niemeyer: sorry, what's encrypted?
[15:40] <niemeyer> fwereade: Nothing..
[15:40] <niemeyer> fwereade: It would :)
[15:40] <fwereade> niemeyer: ah :)
[15:40] <niemeyer> For now this is already good progress on top of what we do now 
[15:40] <hazmat> fwereade, atm i don't see a good way to manage that risk alternatively without a dedicated security agent.. we effectively create the structure with acls referencing the intended principal credentials within the cli which need to get past through at least one other process (which creates the intended connected client/agent) before they get to their destination
[15:40] <fwereade> niemeyer: absolutely, I don't want to reject it, just to make sure that we track the fact that it's a potential issue
[15:41] <niemeyer> fwereade: I know, I'm just explaining as well, rather than attempting to change your feeling about it :)
[15:41] <hazmat> niemeyer, encryption of the otp data? the decrypt key needs to be passed as well
[15:42] <fwereade> shall I file a bug then, and we can worry about it later?
[15:42] <hazmat> niemeyer, fwereade i'm totally open to alternate ideas on this
[15:44] <fwereade> hazmat, niemeyer: I think that at some stage in the future a security agent may be a good way around this (we could implement something that really did delete all unhashed records of the otp when it was first accessed) but for now I'm happy with it
[15:44] <niemeyer> hazmat: No, encrypt of the channel used to communicate back with zk with the key
[15:45] <niemeyer> hazmat: I think what you have is good progress already
[15:45] <hazmat> niemeyer, fwereade its unclear to me if alternate solutions would work well without such an interception gap without implementing a new zk auth mechanism
[15:45] <niemeyer> hazmat: We can easily hack ZK to implement real OTPs, or other mechanisms in the future
[15:45] <hazmat> niemeyer, sounds good
[15:45] <fwereade> cool, I'll approve and file
[15:45] <niemeyer> fwereade: Agreed
[15:47] <_mup_> Bug #819379 was filed: otp mechanism is vulnerable to interception <Ensemble:New> < https://launchpad.net/bugs/819379 >
[15:48] <hazmat> fwereade, thanks for the reviews!
[15:48] <fwereade> hazmat: a pleasure :)
[15:53] <SpamapS> kim0: thats an older graphic, though updated with new understanding. :)
[16:02] <robbiew> m_3: call time?
[16:02] <m_3> robbiew: yup
[16:06]  * hazmat enjoys googling for ensemble bugs
[16:08] <niemeyer> Lunch time.. biab
[16:14] <fwereade> need to pop out for a little while, bbs
[17:04]  * niemeyer pops back
[17:34] <RoAkSoAx> fwereade: so now the orchestra config should provide a storage-url?
[17:37] <fwereade> RoAkSoAx: yes
[17:38] <fwereade> it seemed foolish to assume it was *necessarily* on the same server as cobbler itself
[17:38] <RoAkSoAx> fwereade: what's the formatting? http://W.X.Y.Z/abc?
[17:38] <fwereade> RoAkSoAx: yep
[17:38] <RoAkSoAx> fwereade: well kind of but given that the cobbler server was the "orchestra" server it made sense to keep it there
[17:39] <fwereade> RoAkSoAx: fair point :)
[17:41] <RoAkSoAx> fwereade: yes cause the idea is to make orchestra automatically configure the webdav server
[17:41] <RoAkSoAx> fwereade: and have it up and running post installation and ready to serve ensemble
[17:42] <RoAkSoAx> fwereade: let's do this, if no storage-url is provided, then assume a default, which would be the <orchestra-server/webdav>
[17:42] <niemeyer> RoAkSoAx: Agreed, at least defaulting to it sounds like a good plan
[17:43] <fwereade> RoAkSoAx: then we can trim that back :)
[17:43] <fwereade> sure, happy to add that
[17:43] <RoAkSoAx> niemeyer: indeed
[17:43] <RoAkSoAx> fwereade: yeah! that will allow us more flexibility in case someone would like to chagne the storage somewhere else
[17:43] <fwereade> RoAkSoAx: ...but still nothassle people by asking them to configure it until they need it
[17:43] <fwereade> perfect
[17:43] <fwereade> cheers :)
[17:44] <RoAkSoAx> fwereade: indeed
[17:48] <daker> m_3, what's the status of the postgres formula ?
[17:55] <fwereade> I think it's the end of my day now; RoAkSoAx, I'll probably be back on later to merge that change through the plumbing and into shadow-trunk (and everywhere else it needs to be)
[17:55] <RoAkSoAx> fwereade: btw.. AFAIK, a "name" on a cobbler system cannot be changed
[17:55] <RoAkSoAx> fwereade: cool I'll continue my testing
[17:57] <RoAkSoAx> fwereade: and the changes on setting the provider-state using the UID doesn't really seem relevant because , as far as I can see, to be able to edit a system, you need to obtain the name of the UID
[17:57] <RoAkSoAx> so at the end it seems to be the same
[18:05] <m_3> daker: in progress... eta few hours
[18:06] <daker> ok
[18:07] <m_3> daker: have machine-based acls working (pg_hba)
[18:33]  * negronjl is away: out to lunch
[18:51]  * niemeyer finds his way through the maze of branches creates by fwereade ;-)
[18:51] <niemeyer> s/creates/created
[19:07] <fwereade> RoAkSoAx: belatedly: I just changed a system name, to prove I could
[19:07] <fwereade> RoAkSoAx: there's a rename button in the system list
[19:08] <fwereade> RoAkSoAx: I think you *can't* change a name while something else is holding a reference to it though
[19:09] <RoAkSoAx> fwereade: yeah maybe
[19:09] <RoAkSoAx> fwereade: btw...
[19:09] <RoAkSoAx> fwereade: the way how you obtaining the keys for clout-init user-data is broken
[19:09] <RoAkSoAx> as it makes clout-init to fail
[19:09] <fwereade> RoAkSoAx: bah :(
[19:10] <fwereade> RoAkSoAx: I thought I was doing it just the same as in EC2, didn't expect *that* of all things to be a problem
[19:10] <RoAkSoAx> fwereade: http://paste.ubuntu.com/656595/
[19:11] <fwereade> goodness me
[19:11] <SpamapS> negronjl: does redis support master<->master replication?
[19:12] <fwereade> I guess it's travelling a very different path to the one it takes on EC2
[19:16] <_mup_> ensemble/webdav-storage-prereq r318 committed by gustavo@niemeyer.net
[19:16] <_mup_> Merged generic-state-ops.
[19:16] <niemeyer> Please ignore this.. just a temp branch for review
[19:17] <niemeyer> fwereade: Hmm
[19:18] <fwereade> niemeyer: Hmm?
[19:18] <fwereade> (sorry, irresistible symetry)
[19:20] <niemeyer> fwereade: Sorry, just double checking
[19:21] <_mup_> ensemble/webdav-storage-prereq r318 committed by gustavo@niemeyer.net
[19:21] <_mup_> Merged generic-state-ops.
[19:21] <fwereade> niemeyer: I'm fretting that I've done something unforgivably dumb now :/
[19:21] <niemeyer> fwereade: No, I'm just a bit stuck on webdav-storage
[19:21] <niemeyer> fwereade: I can't find the proper review base
[19:22] <fwereade> niemeyer: is that one of the ones with 2 parents?
[19:22] <niemeyer> fwereade: I get a 600 lines diff on it, including things I already reviewed
[19:22] <fwereade> I seem to recall it requires cobbler-instance-ids as well
[19:22] <niemeyer> fwereade: Yes, but I'm taking that into account
[19:22] <niemeyer> fwereade: Yeah.. I'm merging both of these to form a base
[19:22] <niemeyer> There's still more, apparently
[19:23] <fwereade> niemeyer: hmm, not that I recall...
[19:23] <fwereade> niemeyer: I'm being called, bbs, I'll see if I can see what I've done
[19:24] <niemeyer> fwereade: Hmmm.. part of the diff is within one of the pre-req branches, actually
[19:24] <niemeyer> fwereade: Maybe it's just the diff that is bogus..
[19:24] <niemeyer> fwereade: Let me try something else
[19:26] <niemeyer> fwereade: Alright, I think I got it
[19:26] <niemeyer> fwereade: Don't move too fast.. I'll review it quickly before the diff disappears.. ;)
[19:27] <fwereade> niemeyer: back, shout if I can help at all
[19:27] <niemeyer> fwereade: Super, thanks
[19:34] <niemeyer> robbiew: ping
[19:46] <negronjl> SpamapS: no.  afaik redis only supports master-slave
[19:47] <SpamapS> negronjl: I wonder if we can take the redis-master and redis-slave formulas and just make a 'redis' formula..
[19:47] <negronjl> SpamapS:  i'll give that a shot
[19:48] <SpamapS> negronjl: also can redis slaves be promoted to masters?
[19:49] <SpamapS> negronjl: if thats the case (and not too complicated) then it might make sense to have them work in a ring.
[19:49] <negronjl> SpamapS:  afaik.  yes.  still reading a bit about redis
[20:17] <robbiew> jcastro: ping
[20:18] <jcastro> robbiew: pong
[20:28] <fwereade> ok, I think that really is it for me for now :)
[20:28] <fwereade> nn all
[21:07] <hazmat> niemeyer, the extra security work integrated into domain object creation (service, unit, machine) seems to have some impacts on total test run time, about 25-30% increases, for tests that heavily use the api.. the setup/teardown deltas are under 2%, its just the extra cost of manipulating the additional nodes afaics
[21:12] <niemeyer> hazmat: Hmm
[21:13] <niemeyer> hazmat: If you're comfortable the API is the right one, we can move forward with this no matter what
[21:13] <niemeyer> hazmat: and worry about optimization down the road
[21:14] <niemeyer> hazmat: We can do tricks like disabling the auth steps under controlled scenarios
[21:14] <niemeyer> hazmat: But I'd be happier to run them all the time until we're sure they are good
[21:15] <hazmat> niemeyer, yeah.. i tried seeing what i can do about optimization now, but i'm not seeing any quick gains, i've got most of the api encapsulated into a class, that i could switch toggle by test
[21:15] <hazmat> which might get things a bit closer
[21:15] <hazmat> niemeyer, sounds good re goodness
[22:43]  * niemeyer steps out for watching a movie..
[23:55] <_mup_> Bug #819562 was filed: ensemble.formula.tests.test_bundle fails on buildds <Ensemble:New> <ensemble (Ubuntu):New> < https://launchpad.net/bugs/819562 >
[23:57] <_mup_> Bug #819563 was filed: ensemble.formula.tests.test_bundle.BundleTest.test_executable_extraction fails on buildds <Ensemble:New> <ensemble (Ubuntu):New> < https://launchpad.net/bugs/819563 >