[00:16] <davecheney> mgz_: thanks for your help
[00:16] <davecheney> this is working a treat
[00:16] <mgz_> davecheney: ace
[00:16] <davecheney> a few small issues and i'll be able to land this branch
[00:16] <davecheney> thumper: a pint of grog for mgz_ !
[00:21] <thumper> awesome
[00:43] <thumper> hmm....
[00:43] <thumper> I'm seeing state/leadership package sometimes timeout after 20 minutes
[00:43]  * thumper smells race
[00:43] <thumper> but my --race doesn't work
[00:59] <mwhudson> it's totally possible to have logical races without memory races
[01:03] <thumper> sure
[01:57] <axw> thumper: why discard that PR about server->controller? is that rename not happening anymore?
[01:57] <thumper> axw: it is, but I'm going to retarget it against the new 'controller-rename' feature branch
[01:57] <thumper> as I feel that I'm going to break CI
[01:57] <axw> thumper: okey dokey
[01:57] <thumper> especially as I change some of the command stuff
[01:58] <thumper> and remove the feature falg
[01:58] <thumper> so I thought I retarget it all
[01:58] <thumper> hopefully a very short lived feature branch
[01:58] <thumper> as conflicts against master are going to be a biatch
[01:59] <axw> thumper: did you see my latest email about multi-env vs. azure?
[02:00] <thumper> I think so
[02:00]  * thumper goes to look again
[02:01] <axw> thumper: did not get a reply. just curious about how we're supposed to do create/destroy when an env has resources shared between machines
[02:01] <axw> setup/teardown, a la bootstrap/destroy
[02:01] <thumper> like what?
[02:01] <axw> thumper: in the case of azure: a resource group, subnet, network security group, storage account
[02:02] <axw> thumper: each env will have its own everything, except for a single virtual network that all envs are connected to
[02:02] <thumper> ok...
[02:03] <thumper> well, shouldn't we just hook into the create environment, and destroy environment endpoints?
[02:03] <thumper> when we destroy a controller, we take down all the hosted environments first
[02:03] <thumper> axw: waigani has been refactoring all our destruction code so it is nicer and more async
[02:03] <axw> thumper: yeah, but atm EnvironProvider just has "PrepareForCreateEnvironment" - I'm using htis but it doesn't feel quite right
[02:03] <axw> thumper: sounds good
[02:04] <thumper> you should use the create environment, not the prepare
[02:05] <axw> thumper: there is no "create environment" in EnvironProvider, at least not on master. maybe in a feature branch?
[02:05] <thumper> where are you looking?
[02:05] <thumper> hmm...
[02:05] <axw> thumper: https://github.com/juju/juju/blob/master/environs/interface.go
[02:05]  * thumper thinks...
[02:05]  * thumper looks
[02:07] <thumper> axw: actually, there is currently no function we call at all in the provider when creating a new environment
[02:07] <thumper> before there was never anything to execute
[02:09] <thumper> hmm...
[02:09] <axw> thumper: so I think we need a CreateEnvironment as well as a PrepareForCreateEnvironment
[02:09] <thumper> I think you may be right
[02:09]  * thumper greps for the Prepare...
[02:09] <axw> thumper: PrepareForCreateEnvironment is called (twice), and it is usable
[02:09] <thumper> hmmm
[02:10] <thumper> yeah, checking for valid Config
[02:10] <axw> thumper: i.e. I've got multi-env working in azure
[02:11] <thumper> axw: it feels better to have a separate CreateEnvironment call
[02:11] <thumper> that we call just once
[02:11] <axw> thumper: +1
[02:12] <axw> thumper: also, it's not obvious why Prepare is called twice (once before assigning UUID, once after) - would be good to have better docs on that
[02:12] <thumper> I believe it is the two step call we do
[02:12] <thumper> which we are looking to fix
[02:12] <thumper> the first is to ask for a config skeleton
[02:13] <thumper> and then the validation when the user passes it back
[02:13] <thumper> but to be honest, I'm not entirely clear
[02:13] <thumper> we are wanting to make the juju cli do the same as jem
[02:13] <thumper> and have all providers supply the configschema
[02:13] <thumper> oh...
[02:13] <thumper> can you make the new azure provider supply the configschema?
[02:14] <thumper> not sure if the old one did
[02:14] <axw> thumper: it didn't. I'll add it to the list.
[02:37] <thumper> axw: here is that branch retargeted to the controller-rename branch http://reviews.vapour.ws/r/3053/
[02:54] <wallyworld> axw: small one if you have a moment https://github.com/juju/charmrepo/pull/36
[03:44] <menn0> thumper: http://reviews.vapour.ws/r/3054/
[03:44] <menn0> thumper: adds "no tail" support to state.LogTailer
[03:44]  * thumper looks
[03:48] <thumper> menn0: why do we need to call tailer.Stop when we said "don't tail" ?
[03:50] <menn0> thumper: you don't ...
[03:51] <menn0> thumper: it's just in case the tailer isn't working during tests
[03:51] <menn0> thumper: like when I wrote the test but NoTail wasn't implemented yet
[03:51] <menn0> thumper: happy to reemove it if you think it's confusing
[03:51] <thumper> perhaps just a comment would be enough
[03:52]  * thumper sighs
[03:52] <thumper> state/leadership is failing for me again...
[04:01] <menn0> thumper: i've responded to the review
[04:06] <axw> wallyworld: reviewed
[04:06] <wallyworld> ty
[04:22] <thumper> waigani: http://reviews.vapour.ws/r/3056/
[04:22] <thumper> waigani: it is the earlier branch retargetted and many of the missed systems renamed too
[04:30] <mup> Bug #1454466 changed: Deployment times out waiting for relation convergence - nvp-transport-node in installing state <deploy> <oil> <juju-core:Expired> <juju-deployer:Invalid>
[04:30] <mup> <neutron-gateway (Juju Charms Collection):Expired> <nvp-transport-node (Juju Charms Collection):Expired> <https://launchpad.net/bugs/1454466>
[04:33] <mup> Bug #1454466 opened: Deployment times out waiting for relation convergence - nvp-transport-node in installing state <deploy> <oil> <juju-core:Expired> <juju-deployer:Invalid>
[04:33] <mup> <neutron-gateway (Juju Charms Collection):Expired> <nvp-transport-node (Juju Charms Collection):Expired> <https://launchpad.net/bugs/1454466>
[04:36] <mup> Bug #1454466 changed: Deployment times out waiting for relation convergence - nvp-transport-node in installing state <deploy> <oil> <juju-core:Expired> <juju-deployer:Invalid>
[04:36] <mup> <neutron-gateway (Juju Charms Collection):Expired> <nvp-transport-node (Juju Charms Collection):Expired> <https://launchpad.net/bugs/1454466>
[04:39] <waigani> thumper: shipit with a question about "controller environment"
[04:59] <davecheney> thumper: menn0 axw http://reviews.vapour.ws/r/3057/
[05:01] <axw> davecheney: shipit
[05:02] <menn0> axw: that was awfully fast!
[05:02] <davecheney> boom
[05:02] <axw> menn0: awfully easy review :)
[05:02] <davecheney> -2700 lines -> ship it!
[05:02] <axw> heh
[05:02] <menn0> I think axw has a bot that just automatically replies with ship it
[05:02] <axw> ;)
[05:03] <axw> in seriousness, I wish we had one for back/forwardports
[05:04] <axw> or a way to just not post to RB
[05:05] <wallyworld> axw: sorry, one more https://github.com/juju/charmrepo/pull/37
[05:08] <axw> wallyworld: you should probably use yaml.v1, it's in dependencies.tsv
[05:09] <wallyworld> axw: ah, yeah, thanks
[08:11] <anastasiamac> ericsnow: ping?
[09:00] <fwereade_> axw, I think you're probably right re manifold-in-different-package, but I'm really reluctant for some reason
[09:01] <fwereade_> axw, possibly because so many others are not yet sufficiently separate from their worker packages as to cleanly accommodate that?
[10:02] <frobware> dimitern, dooferlad: standup?
[11:10] <axw> fwereade_: sorry, I was away from IRC. I'm of two minds. On the one hand, it's obviously inherently tied to the worker, but on the other, it has a separate role to play (policy over starting the worker, and connecting the worker to other things). I think having it in a separate package just keeps the responsibilities clearer
[11:31] <fwereade_> axw, yeah, I think you're right. subpackage is probably not *really* the right place, but close enough for now
[12:16] <voidspace> perrito666: thanks
[12:18] <perrito666> voidspace: yw
[12:18]  * perrito666 overslept, rainy day, fresh drapes, impossible not to
[12:21] <frankban> cherylj: hi, could you please take a look at http://reviews.vapour.ws/r/3063/ when you have time?
[13:26] <jam> fwereade_: I realized late that alexisb moved our meeting time (relative to my tz at least). I need to take the dog out, but will try to be back for the meeting
[13:45] <alexisb> jam, we dropped but I am here if you want to chat post dog walk
[13:45] <Shawn_> Hello, I am trying to build the packages from source, how can i download the dependency packages individually instead using the makefile ?
[13:47] <jam> alexisb: hiya. I don't have anything specific. You dropped the meeting for today?
[13:47] <alexisb> jam, fwereade_ and I met for a moment and then dropped
[13:50] <jam> alexisb: you realize you really have nothing to say to eachother without me ? :)
[13:51] <alexisb> jam, so very true ;)
[13:58] <cherylj> frankban: did you have any write up on using the new bundle support that can go out into the release notes for 1.26-alpha1?
[14:11] <fwereade_> rogpeppe, do you recall why EnvironObserver has a mutex, and replaces its environ, instead of doing a SetConfig? environs are meant to be goroutine-safe...
[14:12] <fwereade_> rogpeppe, (I know it's from, what, 20 months ago :))
[14:19] <frankban> cherylj: no I don't but I can get it prepared
[14:19] <cherylj> frankban: that would be great.  Just enough to tell people it's there and how they can use it.
[14:21] <frankban> cherylj: cool, Makyo ^^^ would you like to prepare something about bundle deployment in core?
[14:22] <frankban> cherylj: will you have time to look at the branch today?
[14:25] <rogpeppe> fwereade_: i'll have a look
[14:25] <fwereade_> rogpeppe, cheers
[14:28] <rogpeppe> fwereade_: even if an Environ itself is goroutine-safe, a worker still doesn't want it changing underneath itself with no warning
[14:32] <cherylj> frankban: yes, I can.  I see you have two ship it reviews already.  Did you still want me to take a look?
[14:33] <frankban> cherylj: yes please, I need a review from a core developer
[14:33] <cherylj> frankban: ah, ok.  Will look at it this morning
[14:34] <frankban> cherylj: ty!
[14:41] <fwereade_> rogpeppe, sorry, why not?
[14:42] <fwereade_> rogpeppe, isn't that the point of it being goroutine-safe, that someone updating the config should be no cause for concern?
[14:42] <fwereade_> bother
[14:47] <fwereade_> rogpeppe, sorry, bad timing before
[14:48] <rogpeppe> fwereade_: np
[14:48] <fwereade_> rogpeppe, what's the problem with the environ config being updated under a worker? I rather thought that was the point of the boroutine-safety?
[14:49] <rogpeppe> fwereade_: if i'm writing a worker, i might be doing something on the basis of one attribute, but another attribute might change underfoot so it's inconsistent
[14:49] <rogpeppe> fwereade_: i think it's better if the config is treated as immutable
[14:50] <mup> Bug #1513084 opened: 1.20 cannot upgrade to 1.26-alpha1: run.socket: no such file or directory <1.20> <ci> <intermittent-failure> <run> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1513084>
[14:50] <fwereade_> rogpeppe, that sounds like a problem with the Config method alone then?
[14:51] <fwereade_> rogpeppe, (also: if a worker's depending on env config values from the env, not from state, isn't it already confused?)
[14:53] <rogpeppe> fwereade_: if that's an issue, why are we creating the env at all?
[14:53] <fwereade_> rogpeppe, to call methods that do something to the substrate
[14:53] <rogpeppe> fwereade_: ok, so those methods will depend on env config values in the env, right?
[14:54] <fwereade_> rogpeppe, yes, but that's the env's problem, not the client's
[14:54] <rogpeppe> fwereade_: so should the worker rely on two sources of truth for the config values from the state - the env and another watcher?
[14:56] <rogpeppe> fwereade_: currently a worker needs only to use the EnvironObserver, which gives it the config values from state (and an environment that can use them)
[14:56] <mup> Bug #1513096 opened: invalid agent version in environment configuration: "1.26-alpha1" <ci> <deploy> <juju-core:Triaged> <https://launchpad.net/bugs/1513096>
[14:57] <fwereade_> rogpeppe, what's the overlap between worker-relevant values and env-relevant values?
[14:57] <rogpeppe> fwereade_: i don't know. but i wouldn't want to rely on there being none ever
[14:58] <rogpeppe> fwereade_: having a single place to watch seems like a reasonable thing to me
[14:58] <fwereade_> rogpeppe, in practice, what the EnvironObserver is used for is to create an environ, hand it over to instancepoller, and never update it
[14:58] <fwereade_> rogpeppe, the instancepoller doesn't remotely care about what wwe're doing in the background, it just wants its instancegetter to work
[14:59] <rogpeppe> fwereade_: i'm slightly surpised the provisioner worker doesn't use it
[14:59] <fwereade_> rogpeppe, what would the point be? if it doesn't update the environ we still have to thread env-watching through every worker
[15:00] <fwereade_> rogpeppe, if it simplified its clients, then it'd be great, but as it is there's no reason to switch implementations to use that afaics
[15:03] <rogpeppe> fwereade_: presumably the provision *does* update its Environ when the environ config changes?
[15:03] <rogpeppe> fwereade_: ah yes, it does
[15:05] <fwereade_> rogpeppe, yeah -- and that one is also sl. different in that it has an interest in actual juju-model config as opposed to just the substrate config
[15:05] <fwereade_> rogpeppe, but I'm pretty sure that if it's paying attention to the substrate config it's DIW somewhere
[15:06] <rogpeppe> fwereade_: "dead in water" "doing it wrong" ?
[15:06] <fwereade_> rogpeppe, the latter was my intent :)
[15:06] <rogpeppe> fwereade_: it feels a bit racy to me
[15:08] <fwereade_> rogpeppe, only if the environ itself is, surely?
[15:08] <rogpeppe> fwereade_: not really.
[15:08] <rogpeppe> fwereade_: i don't like state changing underfoot
[15:09] <rogpeppe> fwereade_: i mean, it's *probably* ok
[15:10] <fwereade_> rogpeppe, I feel like the biggest worry is that few environs have ever been actually used from multiple goroutines, so their safety is not battle-tested
[15:11] <rogpeppe> fwereade_: there should be at least one cross-environment test that's designed to trigger the race detector in such cases
[15:13] <fwereade_> rogpeppe, sure, but the number of ways to subtly break safety tends to overwhelm any but exhaustive/invasive testing, and I don't think we really have anything sophisticated enough
[15:13] <rogpeppe> fwereade_: ah, i was being confused by the configObserver - it's only there for testing
[15:13] <rogpeppe> fwereade_: if a provider doesn't simply use a mutex, it's probably doing it wrong
[15:14] <rogpeppe> fwereade_: and that simple mutex logic can be easily tested with the race detector
[15:14] <fwereade_> rogpeppe, there's another way to approach it that I quite liked, but forget the details of
[15:14] <rogpeppe> fwereade_: i tend to just make a test like: go setConfig(); go getConfig(); go setConfig(); go getConfig()
[15:15] <rogpeppe> fwereade_: which will trigger a failure in the race detector if the appropriate mutexes aren't used
[15:15] <fwereade_> rogpeppe, right, but that's just 2 methods and still rather luck-dependent
[15:16] <rogpeppe> fwereade_: true that it's only 2 methods (it should probably be all of 'em), but i don't think it's that luck dependent
[15:16] <fwereade_> rogpeppe, I accept it'll probably fail most of the time, but I doubt it'll be 100% :)
[15:16] <rogpeppe> fwereade_: why wouldn't it be?
[15:18] <fwereade_> rogpeppe, it might happen to run them all serially by sheer coincidence, and never happen to flag the issue -- is it smarter than that? I thought it erred in fvaour of false negatives
[15:18] <rogpeppe> fwereade_: even if it runs them all serially, the race detector will flag it
[15:19]  * fwereade_ scrubs that bad data out of his brain then
[15:19] <rogpeppe> fwereade_: of course you can get false negatives if the code never actually accesses the memory in question
[15:19] <fwereade_> rogpeppe, cool
[15:19] <rogpeppe> fwereade_: it's a pretty good tool
[15:19] <fwereade_> rogpeppe, yeah, but that's not the case here
[15:19] <rogpeppe> fwereade_: i'm a big fan of race-detector-oriented tests
[15:20] <fwereade_> rogpeppe, indeed, I have a deep and abiding love for the race detector
[15:20] <mup> Bug #1511822 changed: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed <blocker> <ci> <regression> <wily> <juju-core 1.25:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1511822>
[15:20] <mup> Bug #1513096 changed: invalid agent version in environment configuration: "1.26-alpha1" <ci> <deploy> <juju-core:Triaged> <https://launchpad.net/bugs/1513096>
[15:20] <fwereade_> rogpeppe, ok, so, some go-spam-every-method tests would be good in general
[15:26] <rogpeppe> fwereade_: so presumably your motivation for the initial question was wondering why the instance poller aggregator isn't seeing env config changes?
[15:27] <fwereade_> rogpeppe, not so much, actually, I came across that later -- I was more thinking of running a separate EnvironObserver that *could* be shared by the various workers that use environs
[15:28] <rogpeppe> fwereade_: well, the current one can be in fact
[15:29] <rogpeppe> fwereade_: you could do the SetConfig locally in each worker as desired
[15:29] <fwereade_> rogpeppe, don't think so? there's only one Environ in the observer
[15:29] <rogpeppe> fwereade_: each worker would have its own Environ
[15:30] <fwereade_> rogpeppe, that's what I'm trying to get away from
[15:30] <rogpeppe> fwereade_: for reasons of efficiency?
[15:31] <fwereade_> rogpeppe, more that the env-watching is unnecessary extra complexity in a bunch of different workers
[15:31] <fwereade_> rogpeppe, and yeah, there's some efficiency improvement as well
[15:32] <fwereade_> rogpeppe, and it opens the door to us being able to actually manager rate limits sanely, instead of having a herd of N environs stampeding to talk to the same endpoint from a single agent
[15:32] <rogpeppe> fwereade_: the difficulty is that it's all bound up with environ config and that smears a bunch of semi-related attributes together
[15:34] <rogpeppe> fwereade_: i'm toying with the thought that workers shouldn't ever look at the environ config directly at all
[15:34] <fwereade_> rogpeppe, I do agree that env config is a mess; but AFAICS the potential for harm comes from people using the environ config -- ha, yeah
[15:34] <fwereade_> rogpeppe, can you think of any legitimate uses for .Config() for a client? :)
[15:34] <rogpeppe> fwereade_: but instead have the parameters passed in and derived from the config
[15:34] <fwereade_> rogpeppe, yeah, absolutely
[15:35] <rogpeppe> fwereade_: then you'd probably need to restart the worker when config relevant to it changed
[15:35] <fwereade_> rogpeppe, we just want to pass in something that knows how to ask for instances, and which isn't all whiny and needy about being updated by the same client who wants instances
[15:35] <fwereade_> rogpeppe, still not really understanding why not to SetConfig and be done with it?
[15:36] <fwereade_> rogpeppe, in the observer, I mean
[15:36] <rogpeppe> fwereade_: SetConfig and use chan struct{} ?
[15:36] <fwereade_> rogpeppe, no, I don't want the clients to have to care about environ config at all
[15:37] <rogpeppe> fwereade_: that's ok iff there's no overlap between the attrs used by the worker vs those used by the provider
[15:38] <rogpeppe> fwereade_: i wonder what it would take to split 'em
[15:38] <fwereade_> rogpeppe, well, at least in the instancepoller case, it doesn't care about env config at all
[15:38] <rogpeppe> fwereade_: i'm more thinking of the provider case actually
[15:38] <fwereade_> rogpeppe, in the provisioner case all I can think of is, uh, instance-reaping mode, whatever it's called
[15:38] <rogpeppe> sorry
[15:38] <rogpeppe> provisioner
[15:38] <rogpeppe> fwereade_: yeah
[15:39] <fwereade_> rogpeppe, which the provisioner shouldn't really know is to do with the env config anyway, it shoudl just be watching/asking for reaping mode
[15:43] <rogpeppe> fwereade_: one way to be more sure that the workers aren't doing anything untoward might be to make the Environ with Config and SetConfig methods that return an error or panic
[15:52] <fwereade_> rogpeppe, mm, yeah, I will poke around in that direction and see what happens
[15:53] <rogpeppe> fwereade_: that wouldn't be compatible with logic doing type inspection of the Environ, but i would hope that nothing is doing that anyway (and i've always considered it seriously misguided in the places we *are* doing it)
[15:53] <rogpeppe> s/hope that nothing/hope that nothing in the workers/
[15:55] <fwereade_> rogpeppe, yeah
[16:04] <natefinch> gc.ErrorMatches is horrible and bad, and anyone who uses it should feel bad.
[16:05] <fwereade_> natefinch, gtg out, would still be interested to hear more on this -- I'd say that *overbroad* ErrorMatches~s are the usual problem?
[16:06] <natefinch> fwereade_: the only time the *text* of an error message matters, is if it is shown to a user... which 99% of the time it is not
[16:06] <natefinch> fwereade_: we use it as a shorthand for "I expect this specific error to be returned"
[16:07] <natefinch> fwereade_: which is not what is actually being tested
[17:11] <rogpeppe> natefinch: i disagree. i think it's really helpful to see what our errors look like
[17:13] <rogpeppe> natefinch: the alternative is often just asserting that the error is non-nil, which isn't very helpful (i have discovered lots of places where we generated a really stupid or malformed error which we never knew about because of that)
[17:15] <natefinch> rogpeppe: the problem is that asserting the error message asserts a ton of information you don't actually care about.  Like how certain types serialize into strings, like how many levels of abstraction there are between you and the origin of the error
[17:16] <rogpeppe> natefinch: yes, i agree. that can be problematic too. but i think the upside of seeing what your error messages actually look like outweighs that.
[17:16] <rogpeppe> natefinch: i often finish an ErrorMatches string with .*
[17:17] <rogpeppe> natefinch: i've found the error string thing really helpful recently - i found one error that was mentioning the same URL 3 times in the same error message.
[17:18] <rogpeppe> natefinch: crafting decent error messages is important for the user experience
[17:18] <rogpeppe> natefinch: and the tests are usually the only place *we* will ever see them
[17:19] <rogpeppe> natefinch: if it hadn't been for ErrorMatches, we wouldn't have made the recent fix to the charm error messages ("charm or bundle not found" vs "entity not found") caught when ian was reviewing our juju-core changes in response to a charm dep update
[17:21] <natefinch> rogpeppe: sure, there are times when we show errors to users, and in those cases, error text matters.. but we use ErrorMatches *everywhere* in places we know the user will never see the message (logs don't really count).
[17:22] <rogpeppe> natefinch: logs definitely count
[17:22] <natefinch> rogpeppe: not down to the letter
[17:22] <rogpeppe> natefinch: so what would you do? just check that the error isn't nil?
[17:23] <natefinch> rogpeppe: no, check what you actually care about, that we detected a specific type of error and failed in an expected way.  Use a custom error type or something.
[17:23] <rogpeppe> natefinch: another issue i found recently was where an API test wasn't actually testing what it thought it was - the error was for an entirely different reason.
[17:24] <rogpeppe> natefinch: i don't think we should need a custom error type or value for every kind of error we want to test for
[17:24] <natefinch> rogpeppe: the thing that brought this up for me was that a test started failing on master because I added a level of indirection, so the error message had an extra section of "while you were doing  foo:"
[17:24] <rogpeppe> natefinch: yes, that's definitely the down side
[17:24] <rogpeppe> natefinch: it does make for more churm
[17:24] <rogpeppe> natefinch: but i still think it's worth it
[17:25] <rogpeppe> natefinch: (and i have thought about this quite a bit when making similar changes)
[17:25] <natefinch> rogpeppe: and the problem is that no one is actually thinking about what the error message says or means.  For example, to fix that test, I just copied what the new text is from the error and pasted it into the regex.  That's not really making our code or tests better.
[17:26] <natefinch> rogpeppe: imagine if we decided to change how tags print out, so now they print out as "tag: foo/0" ... we'd have thousands of broken tests.
[17:26] <rogpeppe> natefinch: when you did that, i hope you asked yourself the question "does this error accurately and reasonably represent the error that's being tested for?"
[17:27] <rogpeppe> natefinch: yes we would
[17:27] <rogpeppe> natefinch: but if we changed the representation of tag.String we'd have lots of other issues too
[17:29] <natefinch> rogpeppe: but there would be 1000 failing tests that are failing because they're testing something they don't actually care about.   certainly there are places that care what tag's String() function outputs... but that's not the only tests that would fial.
[17:29] <rogpeppe> natefinch: yes, it's a tradeoff
[17:30] <rogpeppe> natefinch: but i don't see a better alternative
[17:30] <ericsnow> rogpeppe: checking for specific error types (a la os.IsNotExist and errors.IsNotFound)
[17:31] <rogpeppe> ericsnow: so every different error message should have its own error type?
[17:31] <natefinch> rogpeppe: no, but they shouldn't all be effectively bare strings either
[17:31] <ericsnow> rogpeppe: arguably one for each equivalence class of error
[17:32] <rogpeppe> ericsnow: how do you decide that?
[17:32] <ericsnow> rogpeppe: through bikeshedding <wink>
[17:32] <rogpeppe> ericsnow: and adding hundreds of different error types is a serious maintenance burden
[17:33] <ericsnow> rogpeppe: unlike hard-coding checks for error strings ;)
[17:33] <rogpeppe> ericsnow: at least that's only in the tests and easily changed
[17:33] <rogpeppe> ericsnow: the problem with having error types is that they're a burden on every developer and need to be maintained as part of the API
[17:34] <rogpeppe> ericsnow: but often a given error might only have meaning within the context of a given implementation
[17:34] <ericsnow> rogpeppe: I'd argue that the errors you get *are* part of the API
[17:34] <rogpeppe> ericsnow: i agree totally
[17:34] <rogpeppe> ericsnow: and i think that any API should think very hard about the set of error types it exposes
[17:34] <ericsnow> rogpeppe: definitely
[17:35] <rogpeppe> ericsnow: which doesn't mesh well with tests that want to test internal functionality
[17:36] <ericsnow> rogpeppe: agreed, though often having to test internal functionality is a code smell
[17:37] <ericsnow> rogpeppe: regardless, as you said there are tradeoffs
[17:37] <rogpeppe> ericsnow: if you're aiming for high coverage, you have to do that in practice
[17:37] <rogpeppe> ericsnow: (and i think aiming for high test coverage is worthwhile)
[17:37] <ericsnow> rogpeppe: I'll leave it to katco to expound the higher plane that is dependency injection :)
[17:38] <ericsnow> rogpeppe: and I couldn't agree more about the importance of high test coverage
[17:38] <katco> quick, look over there!
[17:38]  * rogpeppe looks at the pretty birdy
[17:38] <natefinch> I'm with roger on internal tests.  I think they greatly increase the confidence you can have in your tests.  They make writing tests immensely faster, and they prevent you from mangling your exported API just to support testing.
[17:39] <katco> does anyone remember what the environmental var is for tabular status?
[17:41] <rogpeppe> katco: maybe JUJU_CLI_VERSION=2 ?
[17:42] <rogpeppe> katco: (haven't tried it, just scanned the code)
[17:42] <katco> that works
[17:42] <katco> rogpeppe: ty
[17:42] <rogpeppe> katco: np
[18:08] <mup> Bug #1513165 opened: Containers registered with MAAS use wrong name <juju-core:Triaged> <https://launchpad.net/bugs/1513165>
[18:17] <mup> Bug #1513165 changed: Containers registered with MAAS use wrong name <juju-core:Triaged> <https://launchpad.net/bugs/1513165>
[18:19] <mgz_> katco: got a sec? bug 1512399
[18:19] <mup> Bug #1512399: ERROR environment destruction failed: destroying storage: listing volumes: Get https://x.x.x.x:8776/v2/<UUID>/volumes/detail: local error: record overflow <amulet> <bug-squad> <openstack> <uosci> <juju-core:Triaged> <https://launchpad.net/bugs/1512399>
[18:20] <mgz_> why does the autogenerated cinder stuff have "https://cinder.example.com" in it at all? can't it just have the path?
[18:20] <mup> Bug #1513165 opened: Containers registered with MAAS use wrong name <juju-core:Triaged> <https://launchpad.net/bugs/1513165>
[18:20] <mgz_> issue is the calling code overrides the host, but not the scheme
[18:21] <mgz_> so, it breaks if the endpoint is not https
[18:23] <mup> Bug #1513165 changed: Containers registered with MAAS use wrong name <juju-core:Triaged> <https://launchpad.net/bugs/1513165>
[18:26] <mup> Bug #1513165 opened: Containers registered with MAAS use wrong name <juju-core:Triaged> <https://launchpad.net/bugs/1513165>
[18:32] <natefinch> katco: "Pull request successfully merged and closed. You’re all set—the natefinch:assign-worker branch can be safely deleted."
[18:41] <alexisb> mgz_, cherylj has been looking at lp 1512399
[18:41] <mgz_> alexisb: it's easy to fix, it's just katco's autogenration code needs changing to take an endpoint rather than do this weird overriding
[18:42] <mgz_> wanted to check with her before hacking it
[18:42] <alexisb> mgz_, ack
[18:42] <alexisb> I will stay out of it, thanks
[18:42] <mgz_> alexisb: no worries
[18:46] <katco> mgz_: natefinch: sorry was eating lunch
[18:46] <katco> natefinch: grats... feel like we should throw a party or something :p
[18:46] <natefinch> katco: right? :)
[18:46] <katco> mgz_: i believe axw has already modified the auto-generated code, so further modification is probably ok
[18:47] <mgz_> ...that's more like not okay then, unless he pull requested back to your repo?
[18:47] <mgz_> oh, or you mean he modified the generated file?
[18:48] <katco> mgz_: yes i think so
[18:48] <mgz_> yeah, seems like that... mehp, that make updating more annoying
[18:50] <mgz_> looks trivial
[18:50] <katco> mgz_: fwiw he asked first. we were both busy and i think the cinder project made some modifications that broke auto-generation w/o looking into it
[18:50] <perrito666> beautiful, this is what mongorestore says when file not found: don't know what to do with file
[18:50] <katco> mgz_: but yes, because of the layering approach, it should be very trivial :)
[18:50] <mgz_> katco: anyway, the code just needs to build urls in a sane way
[18:51] <katco> mgz_: should just have to modify protocol here: https://github.com/go-goose/goose/blob/v1/cinder/client.go#L25-L33
[18:51] <mgz_> an endpoint is not just a host, it's a scheme+host+path that you then append a path to
[18:51] <katco> mgz_: still, just need to modify that 1 function
[18:52] <katco> mgz_: and that's not even auto-generated code. that's goose
[18:52] <mgz_> katco: just + req.URL.Scheme = endpoint.Scheme in SetEndpointFn works for the bug as reported, but that code is still wrong
[18:52] <katco> mgz_: modify the path in the same place
[18:52] <mgz_> the auto gen code should append paths to the endpoint
[18:53] <mgz_> and having hardcodes fake urls is ugly.
[19:07] <natefinch> katco, ericsnow_afk, wwitzel3:  the tech debt bug to fix the tests: perrito666: nice error message
[19:07] <natefinch> lol wrong copy
[19:07] <natefinch> http://reviews.vapour.ws/r/3068/
[19:13] <natefinch> wwitzel3: why does the package_test.go file need a +build go1.3?
[19:13] <wwitzel3> the card said it did?
[19:14] <wwitzel3> I foobar'd my go install trying to install 1.2 so I could test the build flags
[19:15] <wwitzel3> so I'm playing with that right now, when I threw it at the bot through, it still didn't work, so I missed some
[19:15] <wwitzel3> natefinch: feel free to give it a try if you have 1.2
[19:15] <natefinch> wwitzel3: install go from source, it's easy and easy to switch versions
[19:16] <natefinch> (switching versions is just git checkout go1.2 and then make.bash)
[19:17]  * natefinch just switched from 1.4 to 1.2 in like 10 seconds)
[19:21] <natefinch> wwitzel3: every file that imports github.com/lxc/lxd is going to have to be +build go1.3 ... and every file that imports anything those files
[19:24] <wwitzel3> natefinch: so if the file that imports lxd is go1.3, all the files in the lxd package still have to have it?
[19:24] <natefinch> ahahahahahahahahahaha ....
[19:24] <natefinch> oh shit
[19:25] <natefinch> wwitzel3: go 1.2 doesn't have a "go1.3" build tag implemented
[19:25] <natefinch> waity wait... no, that should still work
[19:25] <natefinch> nevermind, sorry
[19:25] <natefinch> screwing myself up
[19:26] <natefinch> wwitzel3: if you do go install ./... it'll independently try to build that package regardless of whether anything else imports it.
[19:32] <natefinch> wwitzel3: it's looking like probably all of the provider/lxd files will need // +build go1.3
[19:32] <wwitzel3> great
[19:33] <natefinch> wwitzel3: I have most of the changes on my local machine... haven't run tests which will also need it.
[19:35] <natefinch> > Directory: /home/nate/src/github.com/juju/juju/provider/lxd
[19:35] <natefinch> > Command: /home/nate/go/bin/go test ./...
[19:35] <natefinch> > Output:
[19:35] <natefinch> ?   	github.com/juju/juju/provider/lxd	[no test files]
[19:35] <natefinch> > Elapsed: 0.131s
[19:35] <natefinch> > Result: Success
[19:35] <natefinch> Success!
[19:35] <ericsnow> cherylj: PTAL: http://reviews.vapour.ws/r/3067/
[19:36] <natefinch> wwitzel3: running a full compile of test code now, but I think I got everything
[19:37] <natefinch> hmm.....
[19:37] <natefinch> I bet just having github.com/lxc/lxd in dependencies.tsv is going to be a non-starter
[19:37] <natefinch> katco: ^
[19:48] <natefinch> wwitzel3: I'm getting some wacky compile errors in environs/bootstrap
[19:48] <natefinch> a bunch of these:
[19:48] <natefinch> ./bootstrap_test.go:79: cannot use env (type *bootstrapEnviron) as type environs.Environ in function argument:
[19:48] <natefinch> 	*bootstrapEnviron does not implement environs.Environ (wrong type for Bootstrap method)
[19:48] <natefinch> 		have Bootstrap(environs.BootstrapContext, environs.BootstrapParams) (string, string, environs.BootstrapFinalizer, error)
[19:48] <natefinch> 		want Bootstrap(environs.BootstrapContext, environs.BootstrapParams) (*environs.BootstrapResult, error)
[19:49] <cherylj> ericsnow: can you give me a quick explanation of what the bug was about?
[19:49] <ericsnow> cherylj: Go 1.5 disallows packages named "internal" from being used outside the package tree they are in
[19:50] <cherylj> oic
[19:50] <natefinch> it's a feature!  ... just not one we intended to be using ;)
[19:56] <natefinch> wwitzel3: I pushed a bunch of my changes here : https://github.com/natefinch/juju/tree/lxd-provider-flags
[20:04] <perrito666> ericsnow: I thought I should share the hapiness with you http://reports.vapour.ws/releases/3261
[20:04] <ericsnow> perrito666: nice! :)
[20:04] <perrito666> old restore is no more
[20:04] <perrito666> and CI is now using the new one which is faster
[20:05] <ericsnow> yay
[20:05] <perrito666> and, works flawlessly on HA
[20:19] <davecheney> can someone please review this to unblock me
[20:19] <davecheney> https://github.com/juju/utils/pull/170
[20:19] <davecheney> it's fairly uncontraversial
[20:21] <mgz_> davecheney: well, I disagree
[20:21] <mgz_> but fine
[20:22] <mgz_> the reason it's stalled is because this bullshit change-it-everywhere-or-nowhere problem
[20:22] <mgz_> there's no reason that our deps shouldn't change apart from people want to keep lock-step on them
[20:22] <mgz_> which is then... why are they even seperate github projects
[20:23] <mgz_> and this is not going to be different when the big-bang v2 change has happened
[20:24] <mgz_> people wanting to get a new fix in utils for a stable branch are going to cope
[20:24] <mgz_> there's no utils 1.24 or 1.25 at present
[20:27] <davecheney> mgz_: yaml.v1/2 is only renferenced from one file in juju/utils
[20:27] <davecheney> called trivial.go
[20:27] <davecheney> which contains one function
[20:27] <davecheney> WriteYAML
[20:27] <davecheney> i'm going to move that function back into juju/juju where it is used
[20:27] <davecheney> and end this madness
[20:27] <davecheney> and yes, i agree taht this upgrade everything at once thing is bullshit
[20:27] <mgz_> but the project is called utils! lets just stuff everything in there :)
[20:28] <davecheney> i hold that as prima facie evidence that putting version numbers in your import paths is a mistake
[20:28] <davecheney> i agree, creating a package called utils is bad enough
[20:28] <davecheney> then a repository called utils is asking for it
[20:28] <davecheney> at atlassian to try to counteract this we created a jar called 'bucket'
[20:29] <davecheney> so people would feel embaressed about using classes from it
[20:29] <davecheney> it didn't work, we ended up with bucket2
[20:29] <natefinch> davecheney: the problem is not version numbers in your import paths, its that we don't care about backwards compatibility in those branches, and we use godeps in addition for some BS busywork on top of it just for kicks
[20:30] <davecheney> objection!
[20:30] <davecheney> this is an unrelated argument
[20:30] <davecheney> yaml.v1 and yaml.v2 _ARE_ different
[20:30] <davecheney> it says so right in their name
[20:30] <natefinch> davecheney: yes
[20:30] <davecheney> the problem is one we have created for oursleves where we _WANT_ to think of them as the same
[20:31] <davecheney> so there is no argument about backward compatability
[20:31] <davecheney> if you want them to be backwards compativle, they'd have the same major version number
[20:31] <davecheney> according to the rules of gopkg.in
[20:31] <natefinch> davecheney: sorry, I was thinking more of our own repos, charm.v5 etc
[20:31] <davecheney> don't even get me started on v6-unstable
[20:32] <natefinch> lol
[20:32] <natefinch> yes
[20:33] <davecheney> and yes, i have no idea why we use godeps _and_ gopkg.in versioned import paths
[20:33] <davecheney> the fact that we have to do both says that neither of those alone is a workable solutin
[20:34] <natefinch> davecheney: honestly, the problem s till seems to be godeps.  that code doesn't expose yaml objects through its api, and I presume the yaml output is valid whether it's v1 or v2 of goyaml.
[20:34] <mgz_> katco: I'm going to murder the autogen-ness of this cinder stuff. The current upstream wadl doesn't make working code, and if we're not syncing we're not gaining anything for the pain of using this.
[20:34] <katco> mgz_: that's fine
[20:34] <natefinch> davecheney: so why do we even care if some helper function uses yaml.v2 instead of v1?
[20:34] <davecheney> natefinch: beacuse we have tests in juju that look for a precise string match
[20:34] <mgz_> katco: I pr'd some changes I needed to test, diff I get is http://paste.ubuntu.com/13105359
[20:35] <davecheney> v2 changes the string form, and handling of empty keys
[20:35] <natefinch> davecheney: well I think I know where the problem lies :/
[20:36] <davecheney> you get $0 for pointing out that our tests are fragile
[20:36] <natefinch> aww
[20:36]  * natefinch was ranting about gc.ErrorMatches earlier
[20:36] <mgz_> natefinch: the problem is not godeps, we have lots of code that depends on how json is handled, and it's part of our api stability contract
[20:37] <mgz_> which we're already not good on.
[20:38] <natefinch> mgz_: ....and there were tests that were failing because we changed how we handled stuff in this function....?
[20:39] <davecheney> natefinch: in this case, how yaml is rendered to the client
[20:39] <mgz_> not in dave's current case, that's just an error message change, but the charm stuff is scary
[20:40] <davecheney> there is also that yaml.v2 changes the handling of fields/map keys with empty values
[20:41] <davecheney> wow, worker/meterstatus/state.go:
[20:41] <davecheney> 47:     return errors.Trace(utils.WriteYaml(f.path, st))
[20:42] <davecheney> oh
[20:42] <davecheney> sorry
[20:42] <davecheney> that writeyaml doesn't return yaml
[20:42] <davecheney> it returns an error if it couldn't write
[20:42] <mgz_> eheh
[20:42] <waigani> review please: http://reviews.vapour.ws/r/3061
[20:43]  * perrito666 ponders buying a paper book after some time
[20:43] <davecheney> thumper: wow, utils.WriteYaml has a huge concurrency failbomb
[20:44] <davecheney>         prep := path + ".preparing"
[20:44] <davecheney>         f, err := os.OpenFile(prep, os.O_WRONLY|os.O_CREATE|os.O_SYNC, 0644)
[20:44] <perrito666> davecheney: did you actually read the DK book about go? is it good?
[20:45] <davecheney> perrito666: nope, both my physical and ebook copies are still on order
[20:45] <davecheney> but it has been reviewed by the whole go team
[20:45] <davecheney> so if you were looking for _the_ word on go
[20:45] <davecheney> you could not do better than that book
[20:45]  * perrito666 sends to sprint hotel
[20:48] <natefinch> davecheney: yeah, that writeyaml function is pretty awful
[20:48] <natefinch> davecheney: we have an atomic writefile somewhere
[20:52] <natefinch> (probably in a utils package somewhere ;)
[21:01] <thumper> menn0, waigani: boring rename branch http://reviews.vapour.ws/r/3056/
[21:02] <waigani> thumper: swap you: http://reviews.vapour.ws/r/3061/
[21:02] <thumper> davecheney: I bet many of our tests have certain concurrency expectations
[21:02] <thumper> waigani: looking
[21:02] <waigani> thumper: woops, I reviewed that one yesterday, but didn't publish it
[21:14] <natefinch> wwitzel3: my branch now compiles (including tests) on go 1.2
[21:15] <wwitzel3> natefinch: nice, we should just use that then?
[21:15] <natefinch> wwitzel3: yeah. probably. I'll PR it
[21:15] <wwitzel3> natefinch: make the PR and I'll review  :)
[21:17] <natefinch> wwitzel3: http://reviews.vapour.ws/r/3070/
[21:19] <natefinch> ericsnow, katco: super simple review to support go 1.2 in the lxd provider branch ^
[21:19] <thumper> waigani: "controller environment" vs "controller", I do think that it is worthwhile talking about both. Mark wanted the initial environment / state server environment to be called the "controller environment".
[21:19] <thumper> I have tried to do that in the places we talked about the other
[21:20] <thumper> the controller itself encompasses the whole thing (in my mind at least)
[21:20] <thumper> meaning the environment, and the machines and bits in that env
[21:21] <thumper> waigani: but I do take your point, and we should perhaps think a bit more on our language
[21:21] <thumper> at least grepping for "controller environment" shouldn't be too hard
[21:22] <ericsnow> natefinch: if you rebase against my lxd-fix-local-remote branch, you don't need to touch the instance and container/factory packages
[21:23] <natefinch> ericsnow: is that branch landing soon?
[21:25] <ericsnow> natefinch: not before we get the 1.3+ support we need
[21:25] <natefinch> ericsnow: well, this PR is so we don't need 1.3+ support
[21:25] <natefinch> )ish)
[21:25] <ericsnow> natefinch: just to trick the merge bot?
[21:26] <ericsnow> natefinch: strike that :)
[21:27] <ericsnow> natefinch: regardless, feel free to strip all the LXD-as-a-container code now rather than waiting for any of my code to land
[21:28] <katco> natefinch: how is this different from wwitzel3 's pr? http://reviews.vapour.ws/r/3064/
[21:28] <waigani> thumper: right. It's really about the concept we want to sell. "controller environment vs an environment in a controller" or just "controller vs environment". Either is fine, but we should consciously chose one and be consistent.
[21:28] <natefinch> katco: mine works ;)
[21:28] <wwitzel3> yeah
[21:28] <wwitzel3> lol
[21:28] <ericsnow> natefinch: also, I'm pretty sure we don't import github/lxc/lxd anywhere under provider/lxd so why is the build constraint needed there?
[21:29] <natefinch> ericsnow: transitive dependencies... since we're not building all the lxdclient code, the code that uses *that* code now won't compile
[21:29] <thumper> waigani: the tricky bit of this concept is that we have a controller that hosts environments, but also the controller environment that is the environment that contains the API server bits
[21:29] <waigani> yep
[21:30] <thumper> waigani: so I think I'm doing to defer changing these comments for now :)
[21:30] <waigani> okay, sure
[21:30] <ericsnow> natefinch: meh, I meant solve that a different way but that would be worse than sprinkling the build constraints all over :)
[21:32] <natefinch> ericsnow: you could make fake implementations of the lxdclient stuff for go1.2... but I think this actually might be ore clear and less real work.  Really didn't take long, and it'll be trivial to undo (even if it does touch a lot of files... it's just one line per file).
[21:32] <ericsnow> natefinch: right; not worth it
[21:36] <waigani> thumper: But I do think it's worth thinking about. AFAICS, fact that a controller is an environ is implementation detail  to support the API - as you say. It shouldn't be confusing the language we use to describe the overall design.
[21:36] <thumper> except it shows up whenever we talk about "all environments"
[21:36] <thumper> and environment commands work on the controller
[21:37] <thumper> I definitely agree that it is worth thinking about
[21:44] <waigani> thumper: I think it comes down to implementation details vs design. Are those details leaking into the design? If so, do we separate them (e.g. never speak of a "controller environment", rename env cmds on the controller to controller cmds) or do we update the design (e.g. always talk about "controller environment").
[21:45] <natefinch> katco, ericsnow: I think we need to talk about dependency injection for the purpose of testing, re: http://reviews.vapour.ws/r/3021/#comment18995
[21:45] <thumper> I don't think so... I think it depends a lot on context
[21:45] <thumper> you are either talking about the controller environment, and dealing with environment *things*
[21:45] <katco> natefinch: it's been queued for awhile. i have half an hour if everyone else does
[21:45] <thumper> or you are talking about the controller in a hosting capacity
[21:45] <thumper> the controller environment doesn't host environments
[21:46] <natefinch> katco: I have 15 minutes, which is probably not going to be enough.  Tomorrow?
[21:46] <thumper> but talking about environment things on the controller doesn't make sense really either
[21:46] <katco> natefinch: tomorrow is meeting day for me =/
[21:46] <natefinch> katco: I'm willing to sacrifice my 1:1 time to talk about this.  I think it's worthy.
[21:47] <katco> natefinch: we can do that if everyone is available
[21:47] <waigani> thumper: ah okay. In a similar way you could talk about a controller machine?
[21:47] <thumper> I'm not sure you would...
[21:48] <thumper> you may talk about an API server machine
[21:48] <thumper> but a controller machine doesn't really make sense
[21:48] <waigani> so what do we call what we use to call the state server machine?
[21:48] <thumper> a machine in the controller environment is ok...
[21:48] <ericsnow> katco, natefinch, wwitzel3: I'm game
[21:49] <thumper> personally I tend to still call them state server machines
[21:49] <katco> ericsnow: natefinch: wwitzel3: invite in the mail
[21:49] <thumper> :)
[21:49] <waigani> haha
[21:49] <natefinch> thumper, waigani: FWIW, I think that "talking out loud" about the new names for things is a very good way to nail down gaps in the vocabulary, and exposes places where names may be misleading.
[21:50] <natefinch> like state server machine :)
[21:50] <thumper> agreed
[21:50] <thumper> definitely think it needs a new name :)
[21:50] <thumper> like: Bob
[21:50] <waigani> lol
[21:50] <natefinch> +1 ship it
[21:50] <thumper> I used to use Eric all the time, from Eric the Viking
[21:50] <thumper> but I feel I have to stop that now that we have ericsnow
[21:51] <natefinch> way to mess it up ericsnow
[21:51] <ericsnow> mwahaha
[21:51] <thumper> ericsnow: how about you change your name?
[21:51] <thumper> perhaps "snowman"
[21:51] <cherylj> ericsnow: for this branch:  http://reviews.vapour.ws/r/3067/  Did you just do a rename for internal to private?
[21:51] <ericsnow> nah :)
[21:51] <ericsnow> cherylj: yep, that's it
[21:53] <natefinch> snowman sorta sounds like the codename for a mobster
[21:53] <cherylj> ericsnow: it's just showing up in a not-clear way in RB and github.  Like it shows that you modified something in internal/client/unitfacade.go, but it doesn't show that you deleted any of the old files
[21:53] <thumper> natefinch: haha
[21:54] <ericsnow> cherylj: yeah, GH is confused and RB isn't helpful when it comes to renames
[21:54] <natefinch> I heard he snowed someone just for looking at him wrong.
[21:54] <cherylj> bleh.  fun.
[22:08] <ericsnow> cherylj: in case it helps, I rebased that PR so GH is showing the changes correctly now
[22:10] <cherylj> ah yeah, that helps
[22:10] <cherylj> ericsnow: there were just a couple things
[22:10] <ericsnow> cherylj: thanks
[22:12] <mup> Bug #1513236 opened: Cannot build trusty armhf with go1.2 on from master <armhf> <blocker> <go1.2> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1513236>
[22:25] <thumper> who loves shitty rename branches? http://reviews.vapour.ws/r/3072/diff/#
[22:26] <ericsnow> katco: FYI, I have the payloads-into-master patch up
[22:29]  * ericsnow raises hand
[22:30] <katco> ericsnow: nice :)
[22:48] <katco> ericsnow: go ahead and merge your payloads branch into master
[22:48] <ericsnow> katco: k
[23:01] <ericsnow> katco: alas, master is blocked
[23:01] <katco> ericsnow: doh
[23:10] <davecheney> katco: ericsnow this may very well be an upstream bug
[23:10] <davecheney> looking at the ci dashboard
[23:10] <ericsnow> davecheney: k
[23:10] <davecheney> no builds for the crypto repo have run on arm for months
[23:10] <davecheney> and the go team turned off build faiure notifications a while back
[23:11] <davecheney> so yeah, there is that
[23:11] <davecheney> let me quickly check something
[23:11] <ericsnow> davecheney: thanks
[23:12] <davecheney> builds on go 1.5
[23:12] <davecheney> we might have to chalk this one up to go 1.2 being unsupported
[23:12] <davecheney> katco: please unblock the build
[23:12] <davecheney> we cannot fix this
[23:12] <davecheney> it is blocked on other work which has been scheduled
[23:13] <davecheney> but has not reasonable ETA that can be used to unblock the build


[00:50] <cleary_> hi folks
[00:52] <cleary> I've begun writing my first ubiquity plugin, and before I got much further I was hoping to brainstorm if what I'm trying to do with it is possible
[00:53] <cleary> we run live-image "trim client" desktops based on an ubuntu livecd. These are a standard image on every person's desk and a small amount of input is required by a user on startup to customise the environment eg default printer
[00:54] <cleary> currently this is provided in the desktop environment by a "wizard" dialog, and I want to move this outside the DE and I'm hoping ubiquity is the vehicle for that
[00:55] <cleary> my initial testing has sorted out creation of a plugin, inserting my own page(s), hiding existing pages, and naming pages via the debconf templates
[00:56] <cleary> I still need to suppress the final Install page (I haven't nutted that one through yet)
[00:56] <xnox> cleary: have you tried oem-config mode yet?
[00:56] <cleary> hi xnox - I have... a long time ago though
[00:57] <cleary> are you suggesting a fork of oem-config?
[00:57] <xnox> cleary: oem-config is merely a wrapper to call ubiquity differently, which already excludes partitioning, preparation and installation, but does the rest.
[00:57] <xnox> (e.g. language, keyboard and user name setup)
[00:58] <xnox> cleary: boot livecd, as soon as you see the keyboard symbol hit esc. using f6 choose oem-config mode.
[00:58] <xnox> Do the install "as if you are a big OEM" (aka Dell)
[00:58] <cleary> what's the cmdline switch for it?
[00:58] <xnox> reboot -> modify system -> double click prepare (that will finalise changes, this is the time to add your own ubiquity plugins / packages etc)
[00:58] <cleary> my livecds don't have a gfxboot option (yet) :P
[00:59] <xnox> that will get you a "gold image"
[00:59] <xnox> then the first boot will be what your users should see. And will be asked questions / setup etc.
[01:00] <xnox> try that just in a VM with stock ubuntu images, to get the feel for it, and see if it meets your needs or not.
[01:01] <xnox> it will make it much more clear what you can/can't/should/shouldn't do with ubiquity.
[01:01] <cleary> ok, will play now - thanks
[01:02] <xnox> cleary: i mean with nexus7 images we just build a chroot and install oem-config-frontend-gtk and let people flash it to their nexus7 & on first boot of that rootfs they get to setup their nexus7. Very lightweight solution.
[01:03] <cleary> xnox: the difference here is that these images are not installed to the harddisk
[01:03] <cleary> they run live in a ramdick
[01:03] <cleary> heh
[01:03] <cleary> disk
[01:04] <xnox> cleary: sure. one can do nfsroot boot or in ram execution of this stuff as well.....
[01:04] <xnox> cleary: e.g. we have casper on cds which allows to add persistent storage to store just the changes between boots.
[01:04] <xnox> cleary: edubuntu CDs can install thin-clients out of the box.
[01:05] <cleary> xnox: yep, sorry my requirements are not for persistant changes
[01:05] <xnox> based on ubuntu. It's very interesting how they do it with ltsp.
[01:05] <cleary> my explanations are generally not very clear, I apologise
[01:06] <xnox> cleary: fair enough, skip that. But note that our CDs have a lot of tricks up their sleeve and can do magical things =)
[01:07] <cleary> xnox: I tried teaching it a new trick once ;) https://bugs.launchpad.net/ubuntu/+source/casper/+bug/578109
[01:07] <ubot2> Launchpad bug 578109 in casper "plymouth copying progress counter for copy_live_to()" [Wishlist,Triaged]
[14:58] <psivaa> xnox: re: your comment on bug 1157690, none of the combinations of ctrl-alt-t or ctrl-alt-f1 brings the terminal or tty.
[14:58] <ubot2> Launchpad bug 1157690 in ubiquity (Ubuntu) "It's impossible to enter the user details in non-live session installations on 'Who are you?' screen when 'release notes' link was clicked and closed" [Undecided,Confirmed] https://launchpad.net/bugs/1157690
[14:58] <xnox> psivaa: =(
[14:58] <xnox> that means input is gone =(
[14:59] <psivaa> xnox: mouse clicks work ok though, and i dont know how to enable remote logging
[15:00] <psivaa> xnox: mouse clicks are also only to click the back button which does not help
[15:19] <ogra_> sounds like compiz is gone
[15:19] <ogra_> which tears down ctrl-alt-T
[15:20] <ogra_> do you have window frames ?
[15:21] <ogra_> s/frames/decoration/
[15:23] <psivaa> ogra_: i need to check again, ill paste a screen shot to the bug
[15:23] <ogra_> good
[15:32] <psivaa> ogra_: the bar with 'Install' is not present when the failure occurs, ive attached the screen to the bug now
[15:35] <xnox> ogra_: cjwatson: revert to metacity instead of compiz for raring release? These inputs problems are making the "install now" mode very flakey.
[15:35] <ogra_> if we can make sure it is cleanly removed ...
[15:35]  * xnox will just do that.
[15:35] <ogra_> i dont think we handle that atm since metacity used to be in desktop by default
[15:36] <xnox> ogra_: well it wasn't in quantal nor raring.
[15:36] <ogra_> was it removed ?
[15:36] <ogra_> :)
[15:36]  * ogra_ never checked :)
[15:36]  * xnox remembers that I still have an action to do autoremove in post oem-config.....
[15:36] <cjwatson> I doubt metacity will be acceptable
[15:36] <cjwatson> check with desktop before you do that
[15:37]  * ogra_ points out that we dont really have any compiz maintainer anymore
[15:37] <cjwatson> nor do we have a metacity maintainer
[15:37] <ogra_> true
[15:37] <xnox> cjwatson: as in, like in quantal. metacity used in ubiquity only, compiz in the desktop session.
[15:37] <xnox> cjwatson: ack will check.
[15:37] <cjwatson> well, ok, but still check
[15:37] <cjwatson> it might well surprise people
[15:40] <xnox> cjwatson: seb128 is ok with using metacity in ubiquity-only, and compiz installed and used for the actual installation.
[15:41] <ogra_> would still be intresting to know why it crashes in that context though
[15:41] <xnox> "<seb128> xnox, just roll back to what you had for raring if it's easier, we don't plan to spend lot of efforts on compiz at this point"
[15:41] <ogra_> since it works flawless in the live session
[15:41] <xnox> ogra_: well there are more dbus stuff available in live session. And I've recently noticed that something is now activating colord in ubiquity-dm =(
[15:42] <ogra_> gnome-settings-daemon does
[15:42] <ogra_> shoudlnt do any harm
[15:42] <ogra_> just adds noise to the logs
[15:42] <cjwatson> xnox: ok
[15:44] <xnox> ogra_: well it's unmanged/unkilled processes that may end up reparented to pid1 at the end of the installation.....
[15:46] <ogra_> ouch
[21:04] <stgraber> xnox: hey, it looks like you didn't test the OEM slideshow :) the ubuntuone slide was appearing completely empty on it
[21:04] <stgraber> I just fixed it in trunk so it's all good now (I'm testing all the slideshows pre-upload)
[21:52] <stgraber> xnox: also, your html was so invalid that the pot generator just crashed :)
[21:52] <stgraber> please remember to close your tags and not add a bunch of closing </div> at the end of the file for no reason ;)
[21:53] <stgraber> (music.html was broken too, so maybe you copied that one and got the brokeness from it)
[23:46] <xnox> stgraber: yeah, me and designers got confused about the html. It was ok in the preview, but I was suspecting it's invalid html as my gut-feeling DTD parsers was sending me alarm bells.
[23:46] <xnox> stgraber: and yeah, totally ignored OEM slideshow. Is it not the same?
[23:47] <stgraber> xnox: it's the same, but you need to symlink the various pages or they show up empty
[23:50] <xnox> stgraber: sounds like ubiquity-slideshow-ubuntu should provide oem-slideshow-ubuntu and be done with it?
[23:50] <xnox> package that is.
[23:50] <stgraber> I think there are a few slight differences in the slideshow, the exact slide list isn't the same, though content is usually shared


[17:17] <apes_> Hello, I'm looking for some help with installing the Canonical Kubernetes distro. I am getting stuck one this step: " Juju Controller is initializing. Please wait. ... Waiting for address"
[17:17] <apes_> If I run "juju status" I just get this message: "ERROR no API addresses"
[17:21] <apes_> This is for localhost
[17:22] <apes_> Same thing seems to happen with "juju bootstrap localhost"
[17:24] <apes_> Debug output doesn't seem to give anything helpful
[17:38] <apes_> There's some kind of networking issue, but I'm not sure what
[17:38] <apes_> Logged into the container, and there's no network access


[00:01] <skaet> ubuntu desktops is up on the iso tracker now
[00:02]  * jibel syncing ubuntu desktop
[00:39] <patrickmw> it seems that we've had success by automating the server iso tests.  has there been an initiative to automate desktop and alternate iso tests?
[00:44] <fader> patrickmw: I know it's been discussed, but it's also a harder problem as ubiquity keeps changing
[00:44] <fader> Starting with the debian installer tests would probably be easier, though
[00:46] <patrickmw> fader: is ubiquity changing because of new features or workflows?
[00:47] <fader> patrickmw: Yes :)  It's been in flux the past few releases, so any work done on automating the testing would have to be redone for the next release.  Not sure if there are a lot of changes coming in natty or not though
[00:47] <fader> patrickmw: But if you want to start attempting to do some automation I'm sure the appropriate people would be able to answer those questions :)
[00:49] <patrickmw> fader: what I'm thinking is if the framework is designed around use case templates then updating the tests for a new release could be less of a pain (vs changing dozens of individual test scripts)
[00:50] <fader> patrickmw: At a *guess* we should be able to use mago once ubiquity is fully accessible, but I don't believe it is yet
[00:50] <fader> charlie-tca: ^^ Am I right in that?
[00:51] <patrickmw> mago also has several dependencies that are not pre-installed
[00:52] <patrickmw> Driving a VM with mago doesn't seem like an option either
[00:53] <patrickmw> definitely something to think about.  I have some primitive ideas bouncing around my head, but nothing solid yet
[00:53] <fader> Hmm, the dependencies I can't speak to, though it might be something we could change (and probably worth bringing up at the next UDS, if so)
[00:53] <fader> mago should definitely work in a VM though
[00:53] <patrickmw> in a VM yes
[00:54] <patrickmw> but, host with mago controlling a guest?
[00:54] <fader> patrickmw: I'd talk to ara about mago and automation and probably ev about ubiquity and hooking into it, but neither of them are online now (and are hopefully asleep! :) )
[00:54] <patrickmw> fader: yeah true
[00:55] <fader> Hmm, you shouldn't need mago controlling a guest -- if you used mago you should be able to run it inside the guest or on a real machine, either way
[00:55] <patrickmw> fader: one of new responsibilities now is to improve Mago's usability
[00:56] <fader> Excellent :)
[01:01] <charlie-tca> oops
[01:01] <charlie-tca> fader: I don't think all of it is, but I haven't run a full accessible install for a week
[01:01] <charlie-tca> It didn't activate after the install, though
[01:02] <fader> Yeah, I don't remember seeing any discussions on the ubuntu-accessibility list, but that doesn't necessarily mean people aren't working on it
[01:02] <charlie-tca> sorry, eating
[01:02] <fader> (As that's a low traffic list anyway)
[01:02] <fader> charlie-tca: NO EAT, ONLY TEST!
[01:02] <fader> :)
[01:02] <charlie-tca> we been discussing it. I got a screen reader install to run, but when it finished, it did not say it was done
[01:03] <charlie-tca> (which leaves the visually impaired sitting a very long time before deciding to restart)
[01:03] <charlie-tca> I got people testing today... ;-)
[01:04] <fader> \o/
[01:04] <fader> (About people testing, not about the a11y bugs, obviously)
[01:04] <charlie-tca> I will be running the accessible install tomorrow, to verify the test case before I post it
[01:04] <charlie-tca> right. I was shocked too
[01:54] <skaet> ubuntu dvd's have just gone up on the iso tracker.
[02:37] <skaet> edubuntu's dvd's are up on the iso tracker now
[03:45] <nobuto> Hi all, I am testing on this case http://testcases.qa.ubuntu.com/Install/DesktopLiveSession#Live%20Session%20Persistence
[03:45] <nobuto> When with <F6> and "persistent" option, casper-rw pertition is used. But when no input on gfxboot then press "try Ubuntu" in ubiquity, casper-rw pertition is NOT used.
[03:45] <nobuto> Is that bug? If so, is it already reported?
[08:07] <ara> good morning!
[09:24] <jibel> Hi all
[09:27] <ara> good morning jibel
[09:28] <jibel> Good morning ara!
[09:28] <jibel> ara, can you help with testing ?
[09:30] <ara> jibel, I was hoping to, but I don't have my spare netbook right now. I will help with VM, and will continue with HW tomorrow morning
[09:30] <kidsodateless> goodmorning to you ara and jibel
[09:34] <jibel> ara, thanks any help is welcome.
[09:34] <jibel> Good morning kidsodateless!
[09:35] <ara> I will resync my images to start with
[09:36] <jibel> Well, to start this shiny day, here is the list a totally untested images that needs some love this morning:
[09:37] <jibel> Ubuntu Studio Alternate i386
[09:37] <jibel> Mythbuntu Desktop i386
[09:37] <jibel> Edubuntu DVD amd64
[09:37] <jibel> Edubuntu DVD i386
[09:37] <jibel> Ubuntu DVD amd64
[09:37] <jibel> Ubuntu DVD i386
[09:37] <jibel> Upgrade Edubuntu amd64
[09:37] <jibel> Upgrade Edubuntu i386
[09:37] <jibel> Upgrade Ubuntu amd64
[09:37] <jibel> Upgrade Ubuntu i386
[09:37] <jibel> Upgrade Xubuntu amd64
[09:37] <jibel> Upgrade Xubuntu i386
[09:45] <jibel> anyone with a MS Windows partition could test Wubi and confirm bug 711562 ?
[09:45] <ubot4> Launchpad bug 711562 in wubi "wubi kubuntu failed to install: phase 2 stops with: Try (hd0,0): NTFS5: (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/711562
[10:15] <kidsodateless> hi guys, i'm currenly testing. why when I click the applications  on launcher I can't see any apps icon?
[10:58] <jibel> kidsodateless, testing which image on which environment (vm or real harware) ?
[11:01] <kidsodateless> jibel, in a real hardware. i'm using 20110201.1 ubuntu desktop i386
[11:06] <jibel> kidsodateless, file a bug against unity then.
[11:08] <kidsodateless> jibel: ah see, but i'm heading off, I'll make a way to test tomorrow.
[11:08] <jibel> kidsodateless, ok
[11:34] <jibel> For those freshly connected to the channel here is the list of images that are untested:
[11:34] <jibel> Edubuntu DVD amd64
[11:34] <jibel> Edubuntu DVD i386
[11:34] <jibel> Ubuntu DVD amd64
[11:34] <jibel> Ubuntu DVD i386
[11:34] <jibel> Upgrade Edubuntu amd64
[11:34] <jibel> Upgrade Edubuntu i386
[11:34] <jibel> Upgrade Xubuntu amd64
[11:34] <jibel> Upgrade Xubuntu i386
[11:34]  * jibel syncing ubuntu DVDs
[11:40] <pedro_> jibel, i can test ubuntu dvd i386, cannot test amd64 images :-/
[11:40] <pedro_> jibel, good morning btw :-)
[11:42] <jibel> pedro_, Good afternoon !
[11:44] <jibel> pedro_, cool, I'm syncing amd64 then
[11:46]  * jibel likes how zsync is able to start syncing an amd64 image from a copy of an i386 one.
[11:58] <jibel> Any tester for Wubi ?
[12:00] <jibel> New images of mythbuntu amd64 and ubuntustudio alternate amd64 are available for testing
[12:01] <davmor2> jibel: that would be where I would come in normally but have very little time sorry,  I believe that bladerunner
[12:01] <davmor2> can help though
[12:03] <jibel> davmor2, yeah, I'll ask him when he'll be online. I need a confirmation for bug 711562
[12:03] <ubot4> Launchpad bug 711562 in wubi "wubi kubuntu failed to install: phase 2 stops with: Try (hd0,0): NTFS5: (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/711562
[12:03] <jibel> this affects all the images
[12:04]  * jibel -> lunch
[12:04] <davmor2> jibel: If I get chance I'll have a look for you, but being as my boos is off and there are a bunch of stuff I need to test it might not happen
[12:37] <ara> jibel, is it expected that the 2d experience only has a small ubuntu icon (instead of the 10.10 applications / places / system)
[12:37] <ara> ?
[13:17] <jibel> ara, you mean when you login with a 'Classic Desktop' session ?
[13:37] <stgraber> highvoltage: going to test Edubuntu when you arrive at the office ?
[13:37] <stgraber> highvoltage: I'm going to do Ubuntu Alternate testing for LTSP, check if the fix I pushed two days ago fixed it
[13:40] <highvoltage> stgraber: ok great, yes I'll do so in a moment
[13:41]  * stgraber loves the new KVM box ;) Downloading at 8MB/s from cdimage !
[13:45] <davmor2> stgraber: where you at?
[13:46] <highvoltage> stgraber: shew, nice
[13:51] <stgraber> davmor2: currently I'm working remotely from Switzerland, flying back to Canada on Sunday. But the server is in a datacenter in Germany.
[13:51] <stgraber> with 100Mb/s internet and huge quota (5TB) ;) I run libvirt on it and access it remotely with NX. So I just have a remote desktop on it to start my VMs
[13:52] <davmor2> stgraber: nice
[13:54] <stgraber> cost me less than 50€ a month for the box, so it's actually cheaper than buying the hardware and connection (it's an i7 with 2x750GB and 8GB of RAM) :)
[13:55] <davmor2> stgraber: very nice see over here that would cost more to host than buy :)
[13:58]  * fader cranks up another round of syncing.
[13:58] <fader> Mornin', folks.
[13:59] <stgraber> morning fader
[13:59] <fader> stgraber: Howdy!
[13:59] <jibel> Hi fader
[13:59] <ara> jibel, yes, that's what I meant
[14:00] <fader> Hi jibel :)
[14:02] <fader> stgraber: How's Switzerland?
[14:02] <jibel> ara, I've a full menu there with application, places and system . So I think that one of us is facing a bug.
[14:02] <stgraber> fader: great, a lot warmer than Canada ;) Will be a shock flying back there on Sunday :)
[14:03] <stgraber> fader: it's actually a bit disappointing being in Switzerland in February and not seeing any snow :)
[14:04] <fader> Hehe
[14:04] <fader> stgraber: We have plenty in Boston I could send you
[14:05] <stgraber> hehe, no that's fine, they're making a good stock of it in Sherbrooke apparently, I'm sure there'll be some left when I arrive :)
[14:05] <stgraber> (schools are closed today over there because of snow and wind, so it must be quite bad ;))
[14:05] <davmor2> morning fader
[14:05] <fader> I can believe that it is
[14:05] <fader> davmor2: Hey dude
[14:16] <jibel> New images of Ubuntu Desktop i386 and AMD64 are available, time to resync.
[14:25] <patrickmw> jibel: is there a lag between the images being dropped and QA Tracker updating its "rebuilding" state?
[14:26] <jibel> patrickmw, probably a small delay because there are different systems involved why ?
[14:28] <patrickmw> jibel: just curious, I happened to refresh the build list and they didn't appear ready, only curious
[14:28] <patrickmw> jibel: it 7am, and I tend to repeat myself in the morning
[14:29] <patrickmw> jibel: oh and  its 7am
[14:40] <highvoltage> stgraber: I'm testing upgrades as well
[14:40] <highvoltage> stgraber: on upgrade it wants to remove blinken, dhcp3-client, gcompris, icedtea6-plugin, nanny, ubuntu-edu-preschool, ubuntu-edu-primary
[14:40] <highvoltage> stgraber: what's the best way to check why?
[14:46]  * highvoltage goes ahead with upgrade anyway
[14:48] <highvoltage> stgraber: is http://iso.qa.ubuntu.com/ right? is Edubuntu rebuilding or is the tracker out of date?
[14:49] <jibel> highvoltage, yes it is right. rebuilding all *desktop image to fix ubiquity and parted.
[14:50] <jibel> ubuntu desktop is ready and you can test edubuntu upgrades .
[14:50] <pedro_> jibel, the ubiquity fix is re the crash on selecting the language?
[14:51] <pedro_> cause i got one with the dvd image
[14:51] <highvoltage> jibel: ok
[14:51] <jibel> pedro_, ubiquity fix upon failure to contact geoip; parted fix for broken dmraid installations
[14:52] <pedro_> jibel, looks like the one i'm facing, thanks
[14:55] <jibel> The untested images at the moment are:
[14:55] <jibel> Ubuntu Desktop amd64
[14:55] <jibel> Ubuntu Desktop i386
[14:55] <jibel> Ubuntu Studio Alternate amd64
[14:55] <jibel> Upgrade Edubuntu amd64
[14:55] <jibel> Upgrade Edubuntu i386
[14:55] <jibel> Upgrade Xubuntu amd64
[14:55] <jibel> Upgrade Xubuntu i386
[14:56] <charlie-tca> I'll grab the upgrade Xubuntu i386 to start then
[14:56] <charlie-tca> power went out last night, takes a bit to get back everything again
[14:56] <pedro_> i'm syncing desktop i386
[14:57] <charlie-tca> I willl release note the VBox shutdown bug, too
[14:58] <jibel> And kubuntu desktop i386/amd64 are freshly baked and ready to test.
[14:59] <stgraber> highvoltage: dhcp3-client should be replaced by isc-dhcp-client, the others I'm not sure
[14:59] <stgraber> highvoltage: one way of doing it would be to let it remove them, noting which ones get removed, then try to install them manually ;)
[15:02] <highvoltage> stgraber: that's the plan! I was wondering if there was a more preferred way
[15:03] <highvoltage> stgraber: I filed a bug for that and linked on the tracker so that we don't forget about it
[15:03] <stgraber> highvoltage: you could probably run apt in very very verbose mode and try to guess why it's doing that, but considering the number of packages involved, it's easier to just debug it post-upgrade
[15:04]  * jibel running kubuntu tests
[15:05] <stgraber> highvoltage: what's weird is that you get some ubuntu-edu-* packages removed, but these shouldn't have any Depends, they should only have Recommends
[15:05] <stgraber> highvoltage: so I don't really see how they'd conflict with something and get removed
[15:09] <stgraber> highvoltage: LTSP on Ubuntu Alternate looks good, the d-i component seems to work fine this time ;) Hopefully the rest should work just as well as the ltsp-build-client I tested on Monday
[15:19] <charlie-tca> jibel: was the mythbuntu shutdown bug on a live desktop?
[15:20] <jibel> charlie-tca, live and not live.
[15:20] <charlie-tca> Thanks. same bug as fader, then
[15:21] <jibel> charlie-tca, I tihnk so, but since I don't no the inner details of mythbuntu and xfce I preferred to file a new one.
[15:21] <highvoltage> stgraber: great
[15:21] <charlie-tca> no problem. I know them too well
[15:22] <charlie-tca> I'm duping the bugs. We got the errors notice fixed, but are still working this logout thing
[15:27] <jibel> charlie-tca,  thanks!
[15:29] <stgraber> highvoltage: ltsp installs fine but doesn't boot, can't even debug as the client VM seems to panic (break=top doesn't work ...)
[15:30] <stgraber> highvoltage: initial dhcp works, tftp seems to work (initrd is huge ... 14MB), then I get stuck there
[15:32] <highvoltage> stgraber: can you file a bug so that we can add that to the release notes fwiw?
[15:33] <stgraber> highvoltage: I'm still trying to figure out if that's a LTSP bug or a VM bug
[15:33] <stgraber> highvoltage: I didn't have the issue when testing yesterday on my laptop
[15:38] <stgraber> highvoltage: ok, found the issue. It's a kvm/libvirt/gpxe bug apparently.
[15:39] <stgraber> highvoltage: the PXE loader was trying to load the .nbi image but couldn't interpret it properly. I updated the DHCP config to always return pxelinux.0 and it works fine now
[15:40] <stgraber> I guess my copy of gpxe on my laptop does it differently and either handles the .nbi properly or used pxelinux instead
[15:40] <highvoltage> ok
[15:41] <stgraber> argh, right, there's still one bug ... nbd-client gets stuck when trying to probe for a new version, blocking ldm ... I'm suspecting the new nbd-client to be the cause of that
[15:42] <stgraber> so we won't have a working ltsp for alpha-2 unless you remove /opt/ltsp/i386/usr/share/ldm/rc.d/I01-nbd-checkupdate and update the image
[15:43] <stgraber> I guess I should flag that package somehow so people don't merge it until we've tested it ;) I guess LTSP is probably the only user of nbd and so it'd be nice to make sure it still works ;)
[15:59] <stgraber> highvoltage: release noted LTSP on both Edubuntu and Ubuntu Alternate. We'll need a fix in both nbd-client and gnome-session to have it working.
[16:02] <skaet> thanks stgraber :)
[16:03] <skaet> is there a bug number?
[16:03] <stgraber> not yet but there will be soon
[16:11] <jibel> xubuntu i386/amd64 upgrade are still untested. Anyone ?
[16:11] <jibel> charlie-tca, are you testing xubuntu i386 upgrade ?
[16:11] <charlie-tca> testing now. Got 10.10 installed and starting the upgrade
[16:12] <charlie-tca> as soon as my syncs finish, I will run amd64 in VBox-ose
[16:12] <jibel> charlie-tca, Great! set the status of the testcase to 'started' please.
[16:12] <charlie-tca> by the way, jibel, I still can't get the puel edition to work
[16:12] <charlie-tca> I will mark them
[16:15]  * jibel installing xubuntu 10.10 amd64
[16:16] <charlie-tca> thanks
[16:56] <fader> Looks like new mythbuntu images are up... syncing
[17:02] <jibel> xubuntu desktop as well
[17:02] <fader> Hmm, myth amd64 seems to be crashing like xubuntu was for me last night
[17:03] <jibel> expect ubuntu dvd, edubuntu dvd, and kubuntu dvd soon
[17:03]  * pedro_ syncing again
[17:03] <pedro_> ok
[17:04] <jibel> fader, the logout crash ?
[17:04] <fader> Yuck, ubiquity is crashing but not leaving a crash dump :(
[17:04] <fader> jibel: No, ubiquity crashing
[17:04] <fader> I haven't tried to log out yet
[17:04] <jibel> shutdown/reboot I meant.
[17:05] <fader> Yeah.  That seems to work at least :)
[17:05] <jibel> fader, bug 710582 ?
[17:05] <ubot4> Launchpad bug 710582 in yelp (Ubuntu Natty) (and 5 other projects) "webkit does not implement "assert" sanely (ubiquity crashes after step 'Who are you', yelp segfaults) (affects: 4) (dups: 2) (heat: 30)" [Undecided,New] https://launchpad.net/bugs/710582
[17:06] <fader> jibel: Looks like it... I am about to try running ubiquity from a terminal to see if that gives any useful output, but the behavior is the same
[17:07] <jibel> fader, I've got the same problem on ubuntu desktop amd64, and no crash file.
[17:08] <fader> jibel: Yeah, looking through that bug I'm pretty confident it's the same one
[17:08] <pedro_> did anybody tried the OEM install on Ubuntu desktop image?
[17:08] <skaet> jibel,  looks like we've got fixes queued up for https://launchpad.net/bugs/708812, and https://bugs.launchpad.net/ubuntu/+source/unity/+bug/711964,  so we're going to go ahead with respinning ubuntu's desktop.
[17:08] <ubot4> Launchpad bug 708812 in compiz (Ubuntu) "compiz crashed with SIGSEGV in CompOption::value() (affects: 4) (dups: 2) (heat: 28)" [High,Fix released]
[17:08] <pedro_> the oem-config-prepare icon is not being shown there
[17:08] <skaet> should improve the user experience and may help with some others.
[17:09] <pedro_> could anybody confirm ?
[17:09] <skaet> pedro_,  there's a comment in the release notes on OEM config... but can't remember who made it.
[17:09] <skaet> log should have it.
[17:10] <fader> pedro_: If you can't find it in the release notes, let me know and I will attempt to reproduce it
[17:12] <jibel> skaet, Okay. What's the status for the ubiquity crash on amd64 ? (bug 710582)
[17:12] <ubot4> Launchpad bug 710582 in yelp (Ubuntu Natty) (and 5 other projects) "webkit does not implement "assert" sanely (ubiquity crashes after step 'Who are you', yelp segfaults) (affects: 4) (dups: 2) (heat: 30)" [Undecided,New] https://launchpad.net/bugs/710582
[17:14]  * skaet checking
[17:20] <pedro_> skaet, fader, the OEM config part at the release notes is regarding a crash when the network isn't  configured
[17:20] <pedro_> fader, could you please try to confirm the icon thing ?
[17:20] <fader> pedro_: Cool, I won't bother with it then.  Thanks :)
[17:20] <fader> Ah
[17:20] <fader> Heh
[17:20] <fader> pedro_: Sure, will do... amd64 or i386?
[17:20] <pedro_> it's different :-P
[17:21] <pedro_> fader, i386 please
[17:22] <fader> jibel: As expected, the ubiquity crash is only affecting the amd64 mythbuntu image
[17:22] <fader> FYI
[17:26] <fader> Argh, I wish virtualbox windows would stay on the virtual desktop where I put them
[17:26] <fader> Every time a VM display mode changes, it jumps to the current desktop
[17:27] <jibel> fader, that's bug 707930
[17:27] <ubot4> Launchpad bug 707930 in compiz (Ubuntu) "virtualbox window suddenly moves to another virtual desktop (affects: 1) (heat: 493)" [Undecided,New] https://launchpad.net/bugs/707930
[17:27] <fader> Hehe
[17:27] <jibel> :-)
[17:28] <fader> Thanks jibel :)
[17:28] <fader> I was just complaining and was too lazy to look for a bug :)
[17:40] <fader> jibel: I notice that you filed a bunch of mythbuntu bugs recently... did you happen to file one about ubiquity no longer prompting for the myth role on install?
[17:40] <fader> (i.e. 'backend', 'frontend', etc.)
[17:40] <fader> I looked in lp but didn't see one... I'll file it if you haven't already
[17:40] <jibel> fader, nope
[17:41] <fader> Cool
[17:41] <jibel> fader, it prompted me the first time I launched myth frontend.
[17:41] <fader> pedro_: I can't reproduce your bug... I have the 'prepare for shipping' icon on the desktop
[17:42] <fader> jibel: Weird.  I didn't get that, but maybe it's because of bug 711772
[17:42] <ubot4> Launchpad bug 711772 in mythbuntu-meta (Ubuntu) "cannot setup mythbuntu backend - Unable to connect to the database (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/711772
[17:42] <fader> Though it still seems like weird behavior compared to the past... you should be able to install just a frontend or just a backend system
[17:43] <jibel> fader, indeed, looking quickly at the mysql log, it seems that there is a syntax error, at the creation of the database, that may explain the other bugs.
[17:44] <fader> jibel: I think they're two separate bugs though... previously the behavior was to prompt the user for the role at install time.  So if you installed a frontend-only system, you would not get mysql server installed
[17:44] <fader> (Among other things)
[17:45] <pedro_> fader, ok thanks. will delete the image it might be something corrupted in my install then
[17:46] <fader> pedro_: No problem.  I did it in virtualbox if that makes a difference to you
[17:49] <pedro_> not really, i'm using virtualbox as well
[17:49] <charlie-tca> syncing the xubuntu desktop images again; apparently, I started with an older image
[17:52] <skaet> jibel, looks like we won't be spinning for the updated ubiquity,  its got a dependency with glew, and will take some time to untangle and get right, looks like.
[17:52] <skaet> s/ubiquity/unity/  sigh
[17:53]  * skaet has a crosswire on those two package names - sorry.
[17:54] <jibel> skaet, no problem I've a translator when there's a crosswire on package names ;-)
[17:54] <jibel> skaet, so we are waiting for DVDs and is that the last respin ?
[17:55] <skaet> jibel,  there is going to be a respin on the UEC images coming down
[17:55] <skaet> as soon as the uploads are in.
[17:56] <jibel> skaet, good.
[17:56] <skaet> but that's all I'm aware of at this point, unless we see 710582 getting fixed.
[17:57] <stgraber> Ubuntu DVD is ready for testing
[18:00] <skaet> jibel,  looks like UEC images won't get updated,  build problems there too.  *sigh*
[18:00] <skaet> ah well, at least you have some new shiny DVD images to play with. ;)
[18:00] <jibel> ugh :/
[18:00] <jibel> Great syncing
[18:01] <jibel> To all, DVDs are available, sync and go !
[18:01] <pedro_> syncing already ;-)
[18:28] <jibel> charlie-tca, will you test xubuntu i386 (again) ?
[18:28] <charlie-tca> yup
[18:28] <charlie-tca> syncing them
[18:29] <jibel> charlie-tca, Thanks !
[18:29] <charlie-tca> You are welcome
[18:47]  * pedro_ testing ubuntu dvd i386
[19:08] <marjo> GrueMaster: will you be able to test Ubuntu ARM Preinstalled omap3?
[19:08] <GrueMaster> Already have.
[19:09] <marjo> GrueMaster: iso tracker not updated?
[19:09] <marjo> with your results?
[19:09] <GrueMaster> tracker is giving me issues.
[19:09] <marjo> GrueMaster: ah ok
[19:09] <GrueMaster> I click update, and it deletes my results.
[19:09] <marjo> oops
[19:10] <marjo> jibel, stgraber: any suggestions for GrueMaster?
[19:10] <marjo> jibel: can you mark it for him?
[19:10] <marjo> please?
[19:10] <GrueMaster> I've got it marked now.
[19:10] <GrueMaster> May be a firefox issue.
[19:11] <stgraber> hmm, weird, it's usually close to impossible to remove a result from the tracker ;)
[19:11] <stgraber> might be some weird caching issue
[19:11] <marjo> GrueMaster: oh ok; thx
[19:11] <marjo> stgraber: ack
[19:12] <GrueMaster> I'm still testing omap3/omap4 images, but no show stoppers.  I will update after each bug I find, so it (hopefully) stays current.
[19:12] <marjo> anybody available for Ubuntu DVD amd64 (20110202.1) ?
[19:12] <marjo> GrueMaster: thx much
[19:13] <kamusin> I have downloaded latest natty iso for i386 and when I selected install to hard disk, after 10 seconds (around) it crashes :(, this is not reproducible if you chose try ubuntu in live mode
[19:13] <marjo> charlie-tca: can you please mark Xubuntu Desktop i386 as "started" if that's the case?
[19:13] <charlie-tca> Oh, that's the one still syncing here.
[19:14] <marjo> charlie-tca: ack
[19:14] <charlie-tca> yes, it gets slower ...
[19:15] <patrickmw> i could use some guidance reporting a bug.  I've noticed that when the installer runs without an internet connection the system hangs after clicking reboot now.  would I report this as an ubiquity bug?
[19:33] <charlie-tca> Okay, need someone else to try the xubuntu desktop 64 install. Everytime I get through the installer in the live environment, I get no slideshow. I get a spinner
[19:33] <charlie-tca> and nothing happens. Clicking anything in the menu or launcher panel stops the spinner
[19:33] <charlie-tca> VBox-ose 4.0
[19:36] <stgraber> Edubuntu DVDs are ready for testing !
[19:39] <skaet> :)
[19:40] <charlie-tca> patrickmw: sounds like ubiquity, yes.
[19:46] <patrickmw> thank you, charlie-tca
[19:53] <charlie-tca> Xubuntu 386 desktop install works. Xubuntu 64 desktop install fails completely
[19:54] <charlie-tca> skaet, jibel : what ever the last update was, Xubuntu 64 fails completely now. It won't install after completing all the screens.
[19:56] <skaet> charlie-tca, ack.  :(
[19:58]  * skaet looking to see if she can find a bug, so charlie-tca can cross check if its same as other symptoms already seen on amd64
[20:10] <skaet> charlie-tca, is your bug the same as: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/710582
[20:10] <ubot4> Launchpad bug 710582 in yelp (Ubuntu Natty) (and 5 other projects) "webkit does not implement "assert" sanely (ubiquity crashes after step 'Who are you', yelp segfaults) (affects: 4) (dups: 2) (heat: 32)" [Undecided,New]
[20:10] <charlie-tca> looking
[20:10] <skaet> or something different?
[20:11] <charlie-tca> looks like it might be, I filed it as bug 712093
[20:11] <ubot4> Launchpad bug 712093 in ubiquity (Ubuntu) "Xubuntu Desktop 64 fails to install from live desktop (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/712093
[20:11] <charlie-tca> It is a silent fail, so it is possible
[20:12] <charlie-tca> looks like a good bet it is the same.
[20:14] <skaet> charlie-tca, thanks.
[20:14] <charlie-tca> Thank you, skaet. The syslog matches
[20:22] <jibel> marjo, I'm on mad64 dvd,
[20:23] <jibel> amd64 not mad :-)
[20:23] <marjo> jibel: thx, but don't be mad!
[20:23] <jibel> stgraber, highvoltage, can you test edubuntu dvds ?
[20:24] <highvoltage> jibel: doing that right now. i386 seems ok
[20:24] <jibel> highvoltage, Great, thanks !
[20:24] <highvoltage> jibel: I'll need someone else to confirm that amd64 is broken, I'm testing it under kvm but the installer window just disappears after I fill in the user details
[20:24] <charlie-tca> I will try the 64-bit install again with the workaround in the release notes
[20:25] <charlie-tca> highvoltage: bug 710582
[20:25] <ubot4> Launchpad bug 710582 in yelp (Ubuntu Natty) (and 5 other projects) "webkit does not implement "assert" sanely (ubiquity crashes after step 'Who are you', yelp segfaults) (affects: 5) (dups: 3) (heat: 40)" [Undecided,New] https://launchpad.net/bugs/710582
[20:25] <jibel> highvoltage, that's the webkit but
[20:25] <jibel> *bug
[20:25] <highvoltage> ah, we should note that explicitely in the edubuntu release notes as well then :)
[20:25] <charlie-tca> We should have broken mythbuntu too
[20:26] <jibel> All upgrade testcases done \o/
[20:26] <jibel> charlie-tca, yes it is
[20:31] <bdmurray> jibel, stgraber: it seems to me that Ubuntu QA Website isn't tagging bugs iso-testing since mid January
[20:37] <jibel> bdmurray,  pfff :/
[20:37] <jibel> bdmurray, I'll have a look.
[20:37] <marjo> jibel: thx
[20:37] <jibel> bdmurray, it looks like the time at which sone server have upgraded to lucid, isn"t it ?
[20:37] <bdmurray> jibel: great thanks!  I just happened to notice it by chance - it seems like we should monitor it somehow. re lucid: that might be
[20:37] <stgraber> bdmurray: probably the script died a while ago. I used to be restarting/fixing it before but lost access to the box on Lucid's release week ...
[20:37] <stgraber> bdmurray: will fix it when I get access again
[20:38] <charlie-tca> xubuntu 386 desktop installed good
[20:42] <marjo> charliet-tca: thx
[20:52] <jibel> bdmurray, the job is running, there's no output so I don't know if it's updating something. I'll let it run for a while and we'll see.
[20:54] <bdmurray> jibel: okay, I'll keep an eye out
[20:56] <jibel> bdmurray, you can keep your eye in, the job failed
[21:01] <bdmurray> jibel: Does it look fixable?  I'd be happy to do it
[21:10] <skaet> jibel, can you confirm that https://bugs.launchpad.net/ubuntu/+source/rekonq/+bug/711513 is fixed on AMD64 with the recent images?  or is it still a problem that needs documentation.
[21:10] <ubot4> Launchpad bug 711513 in rekonq (Ubuntu) "rekonq crashed with SIGSEGV on amd64 (affects: 1) (heat: 6)" [Undecided,New]
[21:13] <jibel> skaet, sure, fixing the tracker, reporting a crash in software-center and doing that right after :-)
[21:14] <skaet> jibel,  :)  thank you!
[21:14] <marjo> jibel: watch out for skaet (aka taskmaster/release manager)
[21:20] <fader> Is anybody working on edubuntu amd64 at the moment?  If not I'll hit it once it syncs
[21:21] <jibel> skaet, I confirm that the recent image does *not* fix the problem
[21:29] <highvoltage> fader: please do!
[21:29] <fader> highvoltage: Heh, just saw that you're doing them.  I'll do an install to double-check since that never hurts :)
[21:30] <fader> Might as well since I sync'd the DVD
[21:32] <highvoltage> fader: ok, it seems like you will just need to remove the ubiquity-slideshow-edubuntu package to work around bug 710582
[21:32] <ubot4> Launchpad bug 710582 in yelp (Ubuntu Natty) (and 5 other projects) "ubiquity crashes on amd64 architecture. was: webkit does not implement "assert" sanely (ubiquity crashes after step 'Who are you', yelp segfaults) (affects: 5) (dups: 3) (heat: 40)" [Undecided,New] https://launchpad.net/bugs/710582
[21:33] <fader> highvoltage: Hmm, yeah I've seen that bug multiple times on different amd64 images.
[21:33] <fader> But it seems like if we're removing a package it's not a valid ISO test...
[21:47] <charlie-tca> jibel: got the 64bit install to work by removing "ubiquity-slideshow-xubuntu"
[21:48] <jibel> charlie-tca, okay that's a great workaround but that doesn't mean that the testcase pass.
[21:51] <skaet> jibel,  thanks for confirming,  will add it to the release note list.
[21:51] <jibel> marjo, bdmurray, the tagging job is back to work.
[21:52] <marjo> jibel: thx much
[21:55] <bdmurray> jibel: okay, I guess there'll be some bugs to review
[22:06] <charlie-tca> jibel: why not? It completes the installation completely with the release notes workaround. If it failed, the image needs to be fixed for the release?
[22:07] <highvoltage> fader: sorry, of course you have!
[22:08] <fader> highvoltage: No need for sorries :)  I'm just grumbling about that bug.
[22:08] <jibel> charlie-tca, The testcase doesn't state that you can remove a package to complete the installation. it makes the it invalid.
[22:10] <charlie-tca> Then we have no 64bit alpha2 images?
[22:11] <charlie-tca> wait
[22:11] <highvoltage> well, at least not desktpo ones
[22:11] <charlie-tca> I don't have a valid test case for this now. With Xfce4.8, nothing is right
[22:11] <jibel> charlie-tca, I don't know, I'm just QA not the release manager.
[22:14] <marjo> skaet: ^^^
[22:14]  * charlie-tca adds the xubuntu test cases to his list of things to fix
[22:15]  * skaet looking up some Xfce4.8 refs she saw to see if same.
[22:15] <jibel> argh, live session amd64 fails. Hard lock :(((
[22:15] <jibel> marjo, can you test with your eeepc ?
[22:26] <hggdh> charlie-tca: you remember the bug # -- install with encrypted disk, when entering the passphrase the prompt is redisplayed char per char?
[22:27] <charlie-tca> let me look for it
[22:27]  * hggdh is trying to search LP, but getting timeouts
[22:30] <charlie-tca> searching...
[22:31] <charlie-tca> I don't have the number here
[22:32] <charlie-tca> bug 566818?
[22:32] <ubot4> Launchpad bug 566818 in plymouth (Ubuntu Maverick) (and 2 other projects) "[Lucid] cryptsetup passphrase prompt during boot: every character typed repeats the prompt (affects: 17) (dups: 3) (heat: 103)" [Medium,Confirmed] https://launchpad.net/bugs/566818
[22:33] <hggdh> charlie-tca: perfect, thank you very much!
[22:33] <charlie-tca> You are welcome
[22:55] <skaet> jibel, all - Help please,  when tagging a bug as iso-testing,  could you make sure that its marked against natty release, so I can find them?   Have been working through the iso tracker and finding some that weren't.
[22:55]  * skaet marking them as I find them, but afraid she'll miss some.
[23:13] <hggdh> skaet: roger wilco
[23:14] <skaet> thanks hggdh.  :)
[23:20] <patrickmw> can some one with ltsp testing experience assist me.  The ltsp server and my test vm can ping each other.  I have updated /etc/ltsp/dhcpd.conf to account for my subnet config.  The thin client can not connect (unable to connect.)  Maybe some one can push me in the right direction
[23:21] <grunthus> Hi, this may be an obvious question, relating to testdrive...
[23:21] <grunthus> I'm trying to learn packaging, from MOTU guides. It is suggested to use testdrive for latest dev ISOs
[23:21] <grunthus> Problem is when I install a system (Natty) via testdrive,
[23:22] <grunthus> it doesn't persist in the virtual machine after reboot.
[23:22] <grunthus> patrickmw: sorry to cut across you there, didn't see your post!
[23:22] <patrickmw> grunthus, np, but i think i can help
[23:23] <patrickmw> grunthus, are you using amd64?
[23:23] <stgraber> patrickmw: is that ltsp test for alpha-2 testing ?
[23:23] <grunthus> patrickmw: yes
[23:23] <stgraber> patrickmw: if so, it's already release noted that it won't work
[23:23] <patrickmw> grunthus, there is a bug
[23:24] <grunthus> Ah.
[23:24] <patrickmw> bug 683260
[23:24] <ubot4> Launchpad bug 683260 in casper (Ubuntu Natty) (and 2 other projects) "persistence doesn't work on liveusb (affects: 12) (dups: 2) (heat: 66)" [High,Confirmed] https://launchpad.net/bugs/683260
[23:25] <patrickmw> stgraber, i looked, i must've missed it
[23:25] <patrickmw> stgraber, thanks
[23:26] <grunthus> Hmmm. patrickmw, I wonder if that bug will affect the testdrive, which is a virtualiser, instead of a flashdrive?
[23:27] <patrickmw> grunthus, ive had the same thing happen with vbox.
[23:28] <grunthus> OK. Perhaps I should leave testdrive and just set up a VM in the traditional way.
[23:28] <grunthus> patrickmw: I'll grab the development ISO of Natty.
[23:28] <patrickmw> grunthus: cool
[23:29] <grunthus> Thanks for help
[23:29] <patrickmw> yw, grunthus  :)


[00:53] <balloons> phillw, fetzed
[00:53] <balloons> fixed topic
[00:53] <phillw> balloons: thanks, I was trying to persuede an IRC op to do it :D
[00:53] <balloons> np
[03:20] <Guest48939> I was looking for Nicholas Skaggs
[03:20] <Guest48939> ?
[03:21] <phillw> Guest48939: he is away from his computer, can I help you at al?
[03:21] <phillw> *all?
[03:22] <Guest48939> hi Phillw, Harry Hawk here.. I'm starting to do some testing.. he had requested some screen shots of an error i'm getting with software updater
[03:22] <Guest48939> I was going to ask him if he wanted those shots emailed or uploaded some where
[03:22] <Guest48939> i'm not at the stage of drafting a formal bug report
[03:23] <phillw> Guest48939: ahh, you just answered my next question :)
[03:23] <phillw> Guest48939: are you a member of the ubuntu-quality mailing list?
[03:24] <Guest48939> yes I just joined a few days ago and rather a newbie
[03:24] <Guest48939> i'm testing on a Nexus 7
[03:25] <phillw> Guest48939: if the file size of the pics is not too big, you can mail them to the ubuntu-quality mailing list
[03:26] <phillw> As you are chatting to nicholas, I'd suggest sending to<EMAIL_ADDRESS>with cc: ubuntu-quality
[03:26] <Guest48939> thanks
[03:26] <Guest48939> fyi, 7 files each just under 1 Mb
[03:27] <Guest48939> Thanks Phillw
[03:27]  * Guest48939
[03:27] <phillw> if you get an error report saying the images are too big, give me a ping and I'll sort something else out.
[03:27] <Guest48939> Thanks
[03:40] <Guest48939> bye
[09:51] <chrisccoulson> hmmm, seems that none of my jobs in jenkins are running :/
[10:37] <jibel> chrisccoulson, from the log, it's a network problem: com.sun.jersey.api.client.ClientHandlerException: java.net.NoRouteToHostException: No route to host when it checks if there is a new version in the ppa