[00:02] <mup> Bug #1563117 opened: api: data race adding local charm. <juju-core:New> <https://launchpad.net/bugs/1563117>
[00:14] <mup> Bug #1563117 changed: api: data race adding local charm. <juju-core:New> <https://launchpad.net/bugs/1563117>
[00:17] <mup> Bug #1563117 opened: api: data race adding local charm. <juju-core:New> <https://launchpad.net/bugs/1563117>
[01:55] <natefinch> is it just me, or is reviewboard broken?
[01:55] <natefinch> I'm not actually getting any diffs, just spinners that spin forever
[01:57] <mup> Bug #1558769 changed: unable to create-model in azure <juju-core:Fix Released by axwalk> <juju-core admin-controller-model:Fix Released by axwalk> <https://launchpad.net/bugs/1558769>
[01:57] <natefinch> hmm, no, maybe it's just the two specific reviews I was looking at. Weird.
[01:58] <axw> natefinch: not just you
[01:59] <natefinch> axw: ok, cool
[01:59] <axw> natefinch: I got some errors about it being out of space
[01:59] <natefinch> ahh
[01:59] <axw> looks like /tmp is full
[01:59] <natefinch> that would explain why some work and some don't, if some got cached or somethnig
[03:30] <mup> Bug #1545589 changed: Destroying a model leaves stale current-model file <destroy-environment> <juju-release-support> <juju-core:Fix Released> <https://launchpad.net/bugs/1545589>
[03:46] <axw> thumper: https://bugs.launchpad.net/juju-core/+bug/1534627 -- what's expected here? I vaguely recall Jess saying that models hang around after being "destroyed", and aren't actually removed from the DB until some time later
[03:46] <mup> Bug #1534627: Destroyed models still show up in list-models <conjure> <juju-release-support> <juju-core:Triaged> <https://launchpad.net/bugs/1534627>
[03:47] <thumper> axw: yes, the actual docs stay around so they can be queries, retrieved
[03:47] <thumper> axw: we should either show the model as dead
[03:47] <thumper> or not show it by default
[03:47] <thumper> I think by default we should just show alive models
[03:47] <axw> thumper: why do we do that? we don't do it for anything else
[03:48] <thumper> axw: because models are special, and it is handy to be able to watch them die
[03:48] <thumper> post mortemts etc
[03:48] <thumper> list models in apiserver should provide life or skip non-alive
[03:49] <axw> okey dokey
[03:49] <axw> thumper: and if someone tries to create a model with the same name?
[03:50] <axw> I wonder if we shouldn't disassociate the name when it's destroyed, so you can still reuse the name
[03:50] <thumper> IIRC we were going to have dead ones possibly renamed or only look for alive ones...
[03:50] <thumper> it is expected that you should be able to reuse the name
[03:50] <thumper> somehow
[03:50] <axw> ok
[04:18] <mup> Bug #1538652 changed: MAAS doesn't assign DHCP IP to new Node and doesn't update DNS table <maas-provider> <juju-core:Expired> <https://launchpad.net/bugs/1538652>
[04:51] <davecheney> https://bugs.launchpad.net/juju-core/+bug/1561375
[04:51] <mup> Bug #1561375: state: TestRegisterNoSecretKey unreliable <juju-core:Triaged> <https://launchpad.net/bugs/1561375>
[04:51] <davecheney> booo
[04:51] <davecheney> this is an upsream break
[04:51] <davecheney> go 1.6 is fine
[04:52] <davecheney> i'll log a bug upstream and let them deal with it
[05:23] <cherylj> could I get a trivial review from someone?  https://github.com/juju/juju/pull/4906
[05:31] <davecheney> no bot ?
[05:31] <davecheney> LGTM
[09:32] <TheMue> morning o/
[09:37] <frobware> fwereade_: space discovery... I was just trying to understand where this ended up in terms of when it was blocked... and not. I was running some git bisect script which added a container after bootstrap but my script often barfed because "spaces discovery is still in progress".
[09:47] <fwereade_> frobware, oops, sorry: how can I help?
[09:48] <fwereade_> frobware, I'm not sure what the current state of master -- I presume it's doesn't-block-logins-reliably? -- but MADE-model-workers doesn't try to block logins at all
[09:49] <fwereade_> frobware, and I haven't seen a merge conflict that looked related
[09:51] <fwereade_> frobware, IIRC that was where we left it when I hit it last time; I'm not opposed to login-blocking in itself, but if it doesn't actually block all problematic logins it's kinda pointless
[09:53] <babbageclunk> Gah, any way to see chat messages from a hangout after one has left the hangout? :( I mean, I can remember --upload-tools but it seemed like there was probably other useful info in there.
[09:55] <frobware> fwereade_: can we briefly HO to talk about it?
[10:01] <fwereade_> frobware, sure, back in standup?
[10:01] <frobware> fwereade_: yep
[10:26] <babbageclunk> Sweet, bootstrapped (although I got a warning about "space discovery still in progress" as well).
[10:39] <babbageclunk> voidspace: trying to deploy juju-gui to my cloud, I get this: ERROR storing charm for URL "cs:trusty/juju-gui-52": cannot retrieve charm "cs:trusty/juju-gui-52": cannot get archive: Get https://api.jujucharms.com/charmstore/v5/trusty/juju-gui-52/archive: dial tcp: lookup api.jujucharms.com on <IP_ADDRESS>:53: no such host
[10:41] <babbageclunk> I can get that url on the maas controller (which is <IP_ADDRESS>). I haven't been able to ssh into the juju controller (which is .17) - should I be able to?
[10:41] <babbageclunk> Ooh, just trying juju ssh.
[10:41] <babbageclunk> No, that didn't work.
[10:44] <babbageclunk> I was specifying the node wrong. I'm in - seeing if I can get the file from there.
[10:51] <voidspace> babbageclunk: yep, that's the thing to try
[10:52] <voidspace> babbageclunk: I'm *still* trying to get maas 2 working on this VM after it broke
[10:52] <voidspace> babbageclunk: a full remove kept failing, think I got it now and am re-installing
[10:52] <voidspace> babbageclunk: if not I'll just blow away the VM and start again
[10:52] <voidspace> babbageclunk: if this was automated it would be easier :-)
[10:54] <babbageclunk> voidspace: Ok, so it looks like the problem is that 192.168.17 (the juju node) has its nameserver set to .2 (the maas controller), while the maas controller (where the charm store request succeeds) has .1 as the nameserver.
[10:54] <voidspace> babbageclunk: how weird
[10:54] <voidspace> babbageclunk: that's set by maas in cloud-init I think
[10:54] <voidspace> babbageclunk: this is on 1.9
[10:54] <babbageclunk> voidspace: yes
[10:54] <voidspace> frobware: ^^^^ is this something you've seen?
[10:58] <babbageclunk> voidspace, frobware: maybe it's the fact that the cluster interface in the MAAS admin is set to be "DHCP and DNS"? Is that wrong?
[11:01] <voidspace> babbageclunk: no, that's correct
[11:02] <voidspace> babbageclunk: you could try just dhcp and see if that makes a different - I normally do both I think
[11:04] <frobware> fwereade_: http://rr-project.org/
[11:05] <babbageclunk> voidspace: ok. Best way to bounce a machine in juju?
[11:06] <babbageclunk> voidspace: should I just restart it from the maas ui?
[11:06] <voidspace> babbageclunk: try "juju reboot 1"
[11:06] <voidspace> babbageclunk: I'm kind of guessing
[11:06] <voidspace> babbageclunk: I normally bounce it in virt-manager
[11:06] <babbageclunk> voidspace: doh, missed that in the list.
[11:06] <voidspace> I knew we had a reboot command - for charms, wasn't 100% it was in the CLI
[11:07] <voidspace> manually restarting the machine restarts the machine agent anyway, so that's what I do
[11:08] <babbageclunk> voidspace: I went semi-scorched earth and did a destroy then bootstrap again.
[11:10] <fwereade_> babbageclunk, voidspace: I have a feeling that there's a bad interaction with juju-reboot, so I don't think you can juju run that, but you should be able to do something like `juju run --machine 2 "sudo shutdown -r now"`
[11:10] <fwereade_> babbageclunk, voidspace: hooks/actions can request reboots with juju-reboot though
[11:12] <voidspace> fwereade_: ah, thanks
[11:12] <babbageclunk> voidspace, fwereade_: despite being overkill, watching the bootstrap process again is giving me a bit better feel for what's happening (and which moving part is responsible for it), so it wasn't a complete loss.
[11:13] <fwereade_> babbageclunk, cool :)
[11:13] <fwereade_> babbageclunk, and ofc you could just `juju ssh 1` and do whatever you need there
[11:14] <babbageclunk> fwereade_: cool, thanks
[11:14] <fwereade_> babbageclunk, (and that should work even if the agent's having trouble, which can stymie juju run)
[11:20] <voidspace> hah, so MAAS was dying with internal server error
[11:20] <voidspace> spelunking in the logs found that going to the accounts page causes the web ui to attempt to shell out to bzr - which wasn't installed
[11:20] <voidspace> how odd
[11:22] <voidspace> babbageclunk: the "changing maas to not do dhcp over the whole subnet" may be new in a more up to date version of maas 2
[11:22] <voidspace> babbageclunk: I'm using the experimental3 ppa and when I configured dhcp I have to provide the range (which defaults to the whole subnet) which I didn't have to do previously
[11:23] <voidspace> babbageclunk: and I guess if it provides dhcp over the whole range then it has no static ips available
[11:25] <babbageclunk> voidspace: OK, so why can't my juju controller get to api.jujucharms.com? Is having the nameserver be the maas controller right?
[11:25] <voidspace> babbageclunk: that should be correct I believe
[11:25] <voidspace> frobware: ^^^
[11:26] <voidspace> babbageclunk: I have maas 2 running (finally I think - just trying enlisting) so can't check on 1.9
[11:26] <voidspace> just yet anyway
[11:31] <babbageclunk> voidspace, frobware: so presumably the problem is that the DNS server on the maas controller isn't responding correctly. I can see dnsmasq running on the maas controller.
[11:32] <voidspace> babbageclunk: it's not a problem I've had though
[11:32] <voidspace> babbageclunk: what if you try without maas providing dns
[11:32] <frobware> babbageclunk: can you deploy a node? If so, can you login to that node and resolve news.bbc.co.uk?
[11:33] <voidspace> frobware: he can deploy, but he then can't connect to the outside world
[11:33] <voidspace> I believe
[11:33] <frobware> voidspace, babbageclunk: where connect is just DNS?
[11:33] <babbageclunk> voidspace, frobware: that's right
[11:34] <frobware> babbageclunk: what do you have in your MAAS setup for upstream DNS queries?
[11:34] <frobware> babbageclunk: from the UI, choose "Settings", then part way down that page is ...
[11:34] <babbageclunk> frobware: checking now
[11:34] <frobware> babbageclunk: "Upstream DNS used to resolve domains not managed by this MAAS (space-separated IP addresses)"
[11:35] <frobware> babbageclunk: I have <IP_ADDRESS> (which is may gateway. You could add <IP_ADDRESS>
[11:35] <babbageclunk> frobware: Aha - I've never seen that page before!
[11:35] <babbageclunk> frobware: I'll add the gateway there.
[11:35] <babbageclunk> frobware: (Also I'll add it to my setup notes.)
[11:36] <frobware> babbageclunk: it's not a gateway though (assuming we're talking about the same thing)
[11:37] <babbageclunk> frobware: Sorry - sloppy terminology on my part. I think I mean it's the KVM switch? It's what's in the resolv.conf on the maas controller (where the name resolves fine).
[11:38] <frobware> babbageclunk: so presumably .1
[11:38] <babbageclunk> frobware: that's right
[11:45] <frobware> babbageclunk: any joy?
[11:46] <babbageclunk> frobware: yes! juju-gui is deployed, but the service's still showing status: unknown when I do juju status.
[11:47] <babbageclunk> frobware: If I ssh into the node I can see runserver.py running which seems to point to the gui charm
[11:48] <babbageclunk> But if I click through the HTTPS warnings I can get to the gui"
[11:49] <babbageclunk> Sweet, I'm in!
[11:50] <frobware> great
[11:56] <babbageclunk> So I think everything's working, other than the "unknown" status in the cli (which isn't reflected in the gui). Probably I won't worry about that.
[12:06] <voidspace> babbageclunk: yay
[12:06] <voidspace> babbageclunk: I'm going on lunch
[12:06] <voidspace> school holidays, so no school run for the next two weeks
[12:13] <babbageclunk> voidspace: cool cool, I'm going for a run to celebrate.
[13:19] <frobware> voidspace, babbageclunk: are you guys using "      maas | 2.0.0~alpha3+bzr4810-0ubuntu1 | http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
[13:19] <frobware> "
[13:23] <frobware> voidspace, babbageclunk: I see there's an alpha4 in ppa:maas/next
[13:27] <dooferlad> fwereade_: with https://github.com/juju/juju/compare/1.25...dooferlad:1.25-proxy-state-server-bug?expand=1 I am getting API authentication errors. I assume I am missing something else that I should know, but don't. Do you have time to help?
[13:31] <fwereade_> dooferlad, looking
[13:33] <fwereade_> dooferlad, AuthClient means "is this a user". would probably be a good idea if we did s/Client/User/ across most of apiserver
[13:34] <fwereade_> dooferlad, I think you want auth.AuthMachineAgent() || auth.AuthUnitAgent()
[13:35] <dooferlad> fwereade_: thanks. Will give that a go.
[13:37] <babbageclunk> frobware: yup, that's the version I'm running - sorry, had to spin up my 2.0 kvm to check
[13:38] <natefinch> fwereade_: yeah, our use of "Client" in the codebase is quite confusing at times
[13:38] <babbageclunk> frobware: do you think I should upgrade?
[13:38] <natefinch> fwereade_: we have the Client API and then a client for the Client API, but also a client for the non-Client API
[13:39] <frobware> babbageclunk: I was trying to reach your feature parity.
[13:39] <frobware> babbageclunk: ... and I'm not there yet. Hmpf.
[13:42] <fwereade_> natefinch, really? which is the, uh, non-client client?
[13:44] <natefinch> fwereade_: well, everything under api/ is a client wrapper for a facade
[13:45] <natefinch> fwereade_: where client in this context just means "consumer of the API", as in, client-server
[13:45] <natefinch> fwereade_: I guess mostly I find it confusing that we have an API facade called "Client"
[13:46] <natefinch> fwereade_: and then there's api/Client, which is the client wrapper for the Client facade
[13:47] <fwereade_> natefinch, right, got you
[13:47] <fwereade_> natefinch, if we didn't overload Client it would all make much more sense
[13:48] <natefinch> fwereade_: indeed.  Was just thinking about it with your talk of switching client to user, which makes a lot more sense... the Client facade is really the user-facing facade, and the rest are the juju-facing facades
[13:49] <voidspace> frobware: I've been using both next-proposed and experimental3 ppas
[13:50] <frobware> voidspace: going to try next-proposed
[13:51] <frobware> voidspace: I had problems with creating the admin account. not sure if that was just finger trouble.
[13:51] <voidspace> frobware: heh
[13:51] <voidspace> I would expect to
[13:51] <voidspace> or it's another new bug
[13:52] <frobware> voidspace: like I said to babbageclunk, I wanted to get to your state-of-the-maas2-world.
[13:52] <voidspace> frobware: ok
[13:53] <frobware> voidspace: I'd like to try this installation using LXD, but that may be adding yet more entropy...
[14:00] <fwereade_> natefinch, although really, the single monolithic Client facade is itself silly -- we probably ought to just explicitly separate internal/ from external/
[14:01] <natefinch> fwereade_: yeah, definitely.  maybe call them private vs public. Private is just for juju, public is for anyone who wants to write a client
[14:01] <natefinch> fwereade_: of course, if we call something a public API, we'd have to document it ;)
[14:03] <fwereade_> natefinch, that would... not be a bad thing ;)
[14:12] <voidspace> frobware: oops, didn't reply
[14:13] <voidspace> frobware: we're definitely *not* targetting container support in the first cut of MAAS 2.0 support
[14:16] <frobware> voidspace: ahh. I meant my MAAS 2.0 installation which was using LXD vs a VM.
[14:17] <mup> Bug #1563335 opened: creating hosted model: could not create state for new model: cannot create index: read tcp <IP_ADDRESS>:37017: i/o timeout <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1563335>
[14:17] <voidspace> frobware: you mean MAAS 2 *in* LXD?
[14:17] <frobware> voidspace: yep.
[14:17] <voidspace> instead of KVM
[14:17] <frobware> voidspace: correct
[14:17] <voidspace> frobware: ah cool
[14:17] <voidspace> would be lighter weight than KVM
[14:17] <voidspace> that's for sure
[14:18] <voidspace> frobware: I had to blow away both MAAS 2 installs
[14:18] <voidspace> frobware: I have it reinstalled in a fresh VM and am just updating that box
[14:18] <voidspace> frobware: I've also looked over Tim's code - it's pretty threadbare but it's a start
[14:19] <voidspace> frobware: as I said in my email I don't really understand what he means by his schema versioning stuff and I'm not convinced we need it anyway
[14:37] <babbageclunk> voidspace: to look at Tim's fork of gomaasapi, should I just git clone it, or use go get?
[14:40] <natefinch> babbageclunk: if you already have gomaasapi in your GOPATH, just git remote add Tim's fork and checkout his branch. if you don't have gomaasapi yet, go-get it first
[14:40] <babbageclunk> natefinch: great, that makes sense. Thanks!
[14:41] <natefinch> babbageclunk: welcome.  It takes a little bit to understand the way to combine real-world git environments and go, but once you get it, it's not too hard.
[14:42] <babbageclunk> Yeah, that was what I was fumbling with.
[14:43] <natefinch> babbageclunk: go get is more for end-users than developers, per se.  it's useful for setting up the right paths in your GOPATH for all the dependencies, but then to actually develop, you use the backing VCS to twiddle with what branches you're looking at.  Helps a ton to have the git branch in your prompt, btw.
[14:44] <voidspace> babbageclunk: clone
[14:44] <voidspace> babbageclunk: or https://github.com/juju/gomaasapi/compare/master...howbazaar:controller-interface
[14:44] <voidspace> babbageclunk: above link if you just want to see the differences
[14:44] <voidspace> babbageclunk: actually - I fork then pull rather than clone
[14:44] <babbageclunk> natefinch: Awesome, thanks
[14:45] <babbageclunk> voidspace: Yeah, that makes sense too, given that I'm expecting to do work on it,
[14:45] <voidspace> babbageclunk: what I actually do is fork gomaasapi, add howbazaar as a remote
[14:45] <voidspace> babbageclunk: and then I can checkout his branch or merge it into mine
[14:45] <natefinch> yeah, forking the original, then git remote add your fork to $GOPATH/github.com/juju/gomaasapi
[14:46] <natefinch> er $GOPATH/src of course
[14:46] <frobware> voidspace, babbageclunk: so this time (alpha3) I managed to get into a state where I have no cluster to edit... Hmpf.
[14:47] <voidspace> frobware: cool
[14:47] <voidspace> I'm running alpha3 too
[14:49] <voidspace> enlisted a node, now attempting to commission
[14:49] <voidspace> looks like it's working rather than trying to enlist again (the old bug)
[14:50] <mup> Bug #1563364 opened: UniterSuite.TestUniterSteadyStateUpgradeForce fails <ci> <intermittent-failure> <test-failure> <juju-core:Incomplete> <juju-core embedded-gui:New> <https://launchpad.net/bugs/1563364>
[14:50] <voidspace> hmmm... not proven yet - it seems to have stalled
[14:51] <voidspace> nope, done
[14:51] <voidspace> *great*
[14:51]  * babbageclunk highfives voidspace
[14:51] <voidspace> hah :-)
[14:51] <voidspace> o/
[14:51] <voidspace> o/\o
[14:55] <babbageclunk> voidspace: sorry to leave you hanging! Should have been watching more closely.
[14:55] <voidspace> hah
[14:55] <voidspace> no worries
[14:55] <babbageclunk> next time
[15:05] <mup> Bug #1563364 changed: UniterSuite.TestUniterSteadyStateUpgradeForce fails <ci> <intermittent-failure> <test-failure> <juju-core:Incomplete> <juju-core embedded-gui:New> <https://launchpad.net/bugs/1563364>
[15:08] <mup> Bug #1563364 opened: UniterSuite.TestUniterSteadyStateUpgradeForce fails <ci> <intermittent-failure> <test-failure> <juju-core:Incomplete> <juju-core embedded-gui:New> <https://launchpad.net/bugs/1563364>
[15:08] <mup> Bug #1563373 opened: bootstrap connection timed out <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1563373>
[15:08] <mup> Bug #1563380 opened: addresses for [] not found <ci> <deploy> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1563380>
[15:17] <mup> Bug #1563373 changed: bootstrap connection timed out <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1563373>
[15:17] <mup> Bug #1563380 changed: addresses for [] not found <ci> <deploy> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1563380>
[15:20] <mup> Bug #1563373 opened: bootstrap connection timed out <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1563373>
[15:20] <mup> Bug #1563380 opened: addresses for [] not found <ci> <deploy> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1563380>
[15:20] <mup> Bug #1563384 opened: could not exit restoring status: connection refused <backup-restore> <ci> <juju-core:Incomplete> <juju-core drop-maas-1.8-support-from-juju2:Triaged> <https://launchpad.net/bugs/1563384>
[15:26] <frobware> voidspace: did the drop-1.8 branch eventually happen?
[15:33] <voidspace> frobware: nope, need(ed?) a blessed master to get a blessed run on drop-1.8
[15:34] <voidspace> still no bless on master
[15:34] <katco> natefinch: ericsnow: hey, we can move the standup earlier for the next few weeks. what time works for you two?
[15:35] <mup> Bug #1563384 changed: could not exit restoring status: connection refused <backup-restore> <ci> <juju-core:Incomplete> <juju-core drop-maas-1.8-support-from-juju2:Triaged> <https://launchpad.net/bugs/1563384>
[15:35] <ericsnow> katco: whenever (FWIW, I liked having it at the start of my day
[15:35] <ericsnow> )
[15:36] <katco> ericsnow: is the old time ok?
[15:37] <natefinch> katco: we could do it an hour later...that way ericsnow doesn't have to start at 8 if he doesn't want to
[15:37] <katco> natefinch: ericsnow: completely up to him
[15:37] <ericsnow> katco: I'm fine either way
[15:38] <katco> ericsnow: natefinch: old time it is :)
[15:38] <katco> ericsnow: natefinch: do you two mind if we do a quick standup now to catch me up?
[15:38] <mup> Bug #1563384 opened: could not exit restoring status: connection refused <backup-restore> <ci> <juju-core:Incomplete> <juju-core drop-maas-1.8-support-from-juju2:Triaged> <https://launchpad.net/bugs/1563384>
[15:38] <ericsnow> katco: sounds good
[15:38] <natefinch> katco: sure, I was going to suggest that, actually
[15:50] <mup> Bug #1563400 opened: TestOneWorkerStartWhenStopping fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1563400>
[16:11] <mup> Bug #1563418 opened: TestModelDestroy fails <ci> <intermittent-failure> <test-failure> <juju-core:Incomplete> <juju-core drop-maas-1.8-support-from-juju2:Triaged> <https://launchpad.net/bugs/1563418>
[16:23] <natefinch> gah, somehow github reviews got set to wrapping at 60 characters on my screen... no idea how to fix it, but it goes away if I use incognito :/
[16:23] <natefinch> ahh... it was the sourcegraph plugin...
[16:31] <babbageclunk> voidspace: I'm reading through your and Tim's changes to gomaasapi, trying to understand what's going on there and trying to see how that would be used in the juju maas provider.
[16:31] <frobware> voidspace, babbageclunk: I can enlist, commission and deploy with alpha3 MAAS 2.0
[16:32] <babbageclunk> voidspace: also trying to match that up with the MAAS api docs so I can get a feel for it. Any other things I should be looking at?
[16:48] <katco> ericsnow: ping
[16:48] <ericsnow> katco: pong
[16:49] <katco> ericsnow: when you reach a stopping point, would you mind swinging onto 1560201 ?
[16:49] <katco> bug 1560201
[16:49] <mup> Bug #1560201: The Client.WatchAll API command never responds when the model has no machines <juju-release-support> <landscape> <juju-core:Triaged> <https://launchpad.net/bugs/1560201>
[16:49] <ericsnow> katco: k
[16:50] <katco> ericsnow: ty... critical priority =/
[17:11] <mup> Bug #1502158 changed: When HP DNS/service calls fail, juju could retry <ci> <openstack-provider> <ui> <juju-core:Won't Fix> <https://launchpad.net/bugs/1502158>
[17:42] <mup> Bug #1184457 changed: Stores user configuration outside of $XDG_CONFIG_HOME <apport-bug> <feature> <i386> <raring> <juju-core:Fix Released> <juju-core (Ubuntu):Fix Released> <https://launchpad.net/bugs/1184457>
[18:19] <arosales> hello, I wanted to do a quick sanity check for the Xenial archive in relation to juju.
[18:19] <arosales> As of today I see 3 juju packages, juju-core, juju, and juju2
[18:20] <arosales> juju-core and juju both are pointing at 1.25.0-0ubuntu3, and juju2 pointing at 2.0-beta3-0ubuntu1~16.04.2~juju1
[18:21] <arosales> at least on the s390 arch, thus for folks looking to install juju 2.0 on s390x in Xenial I am going to recommending to "sudo apt-get install juju2"
[18:22] <arosales> will this instruction change to "sudo apt-get install juju" for the 16.04 release?
[18:22] <natefinch> sinzui: ^ ?
[18:26] <natefinch> arosales: IIRC, 1.25 will stick with juju-core and 2.x will be juju... but I'm far from an authority on it.
[18:26] <katco> arosales: sinzui is definitely an authority on this. alexisb may also have some answers
[18:26] <arosales> natefinch: ok, and sounds like juju2 may just point at juju
[18:27] <arosales> that make sense
[18:27] <arosales> katco: ack
[18:27] <natefinch> arosales: that's my understanding
[18:27] <arosales> natefinch: ok, I'll run with that for now.
[18:27] <arosales> thanks katco and natefinch
[18:29] <rick_h_> arosales: we're working with the folks on this currently
[18:29] <rick_h_> arosales: juju will be the package everyone is to use and apt-get install to get juju
[18:30] <rick_h_> arosales: the others will be tweaked to point in ways to make sure the upgrade/etc works properly
[18:32] <arosales> rick_h_: and that the plan for 16.04 I take it, but today if folks want juju 2.0 from the archive they need to apt-get install juju2
[18:33] <rick_h_> arosales: right, so your question is "will apt-get install juju2 move to apt-get install juju" and the answer is yes
[18:34] <arosales> rick_h_: ok thanks
[18:54] <mup> Bug #1528932 changed: No images error when deploying services <2.0-count> <ci> <juju-core:Fix Released> <juju-core structured-metadata:Fix Released by axwalk> <https://launchpad.net/bugs/1528932>
[18:54] <mup> Bug #1531878 changed: TestBootstrapImage fails on i386 and ppc64el <2.0-count> <i386> <ppc64el> <test-failure> <unit-tests> <juju-core:Fix Released> <juju-core structured-metadata:Fix Released by axwalk> <https://launchpad.net/bugs/1531878>
[19:03] <natefinch> katco: https://golang.org/doc/go1.4#canonicalimports
[19:03] <natefinch> katco: (re: the comment on the package declaration)
[19:04] <katco> natefinch: ahhhh ok... thanks, i actually hadn't run into that in the wild yet
[19:05] <natefinch> katco: took me forever to figure out how to google for that... I remembered it being added, but not what it was called or when it was added
[19:05] <katco> natefinch: yeah. have you seen that used anywhere else?
[19:07] <natefinch> katco: not many places.  Most people are happy just to host on github.  Not sure how many people use gopkg.in or host their own redirector for their go code
[19:07] <katco> natefinch: my guess was they added that for some internal google thing
[19:09] <natefinch> katco: well, it was a kind of a pain in the butt if you *do* use gopkg.in and someone just go-gets the code from the github URL, it will be all wonky, because the root code will be under GOPATH/src/github.com/ but all the subfolders will be under gopkg.in/ because the imports all say gopkg.in
[19:30] <mup> Bug #1537152 changed: Can't re-create a model <juju-release-support> <juju-core:Triaged> <https://launchpad.net/bugs/1537152>
[19:40] <natefinch> ericsnow: do we let you elide the resource revisions when you publish a charm?  Wondering what the use case is for listing the latest resources for a charm are... seems like you'd almost always be getting specific revisions
[19:42] <ericsnow> natefinch: yes, you can omit the revision to use the latest one
[19:51] <natefinch> ericsnow: what is this doing? errgo.WithCausef(err, err, "")
[19:51]  * ericsnow waves hands
[19:51] <ericsnow> stuff
[19:52] <katco> ... lol
[19:52] <natefinch> this isn't the error return we're looking for
[19:52] <ericsnow> natefinch: it does what errors.Trace() does
[19:52] <ericsnow> natefinch: more or less
[19:54] <natefinch> ericsnow: I think the canonical way to do that is errgo.Mask(err, errgo.Any)
[19:54] <natefinch> ericsnow: which is also terrible, but slightly less terrible, IMO
[19:54]  * thumper likes trace
[19:54] <natefinch> thumper: +1
[19:55] <natefinch> honestly, trace is the only thing I really like about the errors packages... and even that, I'm sorta meh on
[20:00] <mup> Bug #1541393 changed: apiserver/logsink.log gets created while running unit tests <juju-core:Triaged> <https://launchpad.net/bugs/1541393>
[20:00] <mup> Bug #1543262 changed: keystone V3 support needed <openstack-provider> <uosci> <Go OpenStack Exchange:New> <juju-core:Fix Released> <https://launchpad.net/bugs/1543262>
[20:01] <natefinch> gah, it kills me that we pass around charm.URL as a pointer everywhere... why do we do that?  It's 5 strings and an int.  Just means we have to worry about nil pointers and modifying the caller's data, etc.
[20:07] <katco> natefinch: just 1 small point of disagreement... even with value types you still have to worry about default values
[20:07] <katco> natefinch: maybe the program won't panic (maybe), but it will still do the wrong thing
[20:10] <natefinch> katco: true... but pointers really just add a whole lot of extra pain. Like in eric's code where he's taking a pointer... but then just copies the value anyway so he doesn't accidentally overwrite the caller's data.
[20:10] <ericsnow> natefinch: alas, errgo.Mask doesn't work with errgo.Cause()
[20:10] <katco> natefinch: yes, agreed on all other points. and pass by value is the right thing to do for that type
[20:10] <natefinch> ericsnow: ug
[20:11] <natefinch> ericsnow: fair enough... I kinda figured you were doing a dance to make all the location and cause bits line up, but due to little exposure to errgo, I wasn't aware of that pattern.
[20:11] <ericsnow> natefinch: hmm, perhaps it would with errgo.Any...
[20:12] <ericsnow> natefinch: yeah, errgo is still hard to grok after using it for several days
[20:33] <mup> Bug #1554042 changed: Bootstrap, destroy-controller and kill-controller all fail after a failed bootstrap <2.0-count> <destroy-controller> <juju-release-support> <juju-core:Fix Released> <juju-core admin-controller-model:Fix Released by wallyworld> <https://launchpad.net/bugs/1554042>
[20:33] <mup> Bug #1558612 changed: creating hosted model config: maas-agent-name is already set; this should not be set by hand <2.0-count> <bootstrap> <ci> <maas-provider> <test-failure> <juju-core:Fix Released> <juju-core admin-controller-model:Fix Released by wallyworld> <https://launchpad.net/bugs/1558612>
[20:33] <mup> Bug #1558678 changed: manual bootstrap: PrepareForCreateEnvironment not implemented <2.0-count> <bootstrap> <ci> <manual-provider> <regression> <juju-core:Fix Released by axwalk> <juju-core admin-controller-model:Fix Released by axwalk> <https://launchpad.net/bugs/1558678>
[20:45] <mup> Bug #1557633 changed: status has duplicate entries for relationships <2.0-count> <juju-release-support> <juju-core:Fix Released by hduran-8> <https://launchpad.net/bugs/1557633>
[20:51] <mup> Bug #1557633 opened: status has duplicate entries for relationships <2.0-count> <juju-release-support> <juju-core:Fix Released by hduran-8> <https://launchpad.net/bugs/1557633>
[21:03] <mup> Bug #1557633 changed: status has duplicate entries for relationships <2.0-count> <juju-release-support> <juju-core:Fix Released by hduran-8> <https://launchpad.net/bugs/1557633>
[21:03] <mup> Bug #1559131 changed: unable to add-credential for maas <2.0-count> <conjure> <juju-release-support> <juju-core:Fix Released> <juju-core admin-controller-model:Fix Released by wallyworld> <https://launchpad.net/bugs/1559131>
[22:15] <mup> Bug #1563576 opened: juju 2 beta3 can't bootstrap to lcy02 <landscape> <juju-core:New> <https://launchpad.net/bugs/1563576>
[23:12] <davecheney> wow, the leankit UI really dsicourages you from commenting on cards
[23:12] <davecheney> add comment, click close, comemnt gone
[23:12] <davecheney> makr card blocked, close card, card not blocked
[23:13] <davecheney> to add a comment you have to go to the comment screen, add comment, click "add"
[23:13] <davecheney> THEN you have to go to the main card screen and click save
[23:13] <davecheney> don't do all those steps
[23:13] <davecheney> cmment is discarded
[23:13] <davecheney> yay
[23:28] <mup> Bug #1563585 opened: juju destroy-controller fails on existing controller after upgrade to Beta3 - ERROR getting controller environ: controller-uuid: expected string, got nothing <oil> <juju-core:New> <https://launchpad.net/bugs/1563585>
[23:36] <axw> ericsnow: assuming you fixed RB, did you just delete leftover stuff in /tmp? do other people have access to do that, in case you're away/unavailable?
[23:37] <ericsnow> axw: yeah, I just deleted all the /tmp/reviewboard.* directories (which hold temp diffs)
[23:37] <ericsnow> axw: anyone with access to the juju-ci4 environment can do it
[23:38] <axw> ericsnow: ok, cool, thanks
[23:38] <ericsnow> axw: np


[04:40] <jtv> stub: care to review this tiny reordering?  https://code.edge.launchpad.net/~jtv/launchpad/message-sharing-rearrange-commits/+merge/14342
[05:11] <stub> approved
[07:15] <jtv> hi mrevell!  I've written up that article about trying out Translations on staging.  Care to proof-read it?  (Warning: it's pretty long).
[07:16] <mrevell> jtv, I'd love to, thanks man. Wanna email it or do you have a link?
[07:16] <jtv> mrevell: the email is on its way
[07:17] <jtv> mrevell: what does strike me about it is how long it all gets, what with the bzr setup.  Wish there were some easy https-based way to get people started or something.  It's liberally interspersed with links to your documentation though.
[07:18] <jtv> (14:16:36) jtv: mrevell: the email is on its way
[07:19] <jtv> (14:17:44) jtv: mrevell: what does strike me about it is how long it all gets, what with the bzr setup.  Wish there were some easy https-based way to get people started or something.  It's liberally interspersed with links to your documentation though.
[14:07] <jtv> stub: removing the entire debug output stanza and gc.collect() from the script for production... that ok with you?
[14:07] <jtv> I mean, in the branch you reviewed
[14:07] <stub> jtv: Yup
[14:07] <jtv> thx
[17:01] <sinzui> barry: ping
[17:05] <sinzui> barry: noodles775_: flacoste: I hope for a review and an RC for https://code.edge.launchpad.net/~sinzui/launchpad/full-page-width/+merge/14427
[17:20] <flacoste> sinzui: why did you add a .full-page-width CSS class?
[17:21] <flacoste> sinzui: ignore me, i understand
[17:21] <flacoste> sinzui: can you add a comment above the CSS rule pointing to a test-case for it (what people should look at when they update it?
[17:22] <sinzui> There is no nest case for it. The behaviour was seen because the markup was invalid
[17:24] <sinzui> flacoste: I considered not adding the CSS rule. The nesting experience as a surprise. It was not something obvious, so I added a rule to prevent it from happening again. It is like the clear rules in the CSS that define after rules to ensure the core rule is consistent
[17:24] <flacoste> sinzui: that in a comment would be enough
[17:25] <sinzui> okay
[17:27] <sinzui> /* The content is already full width; the content should remain full width. */
[17:34] <sinzui> flacoste: The branch that landed the invalid markup was fixing the layout of two edit icons for webkit. There were no test changes, we just reviewed the UI
[17:54] <al-maisan> Hello EdwinGrubbs, could you please review https://code.edge.launchpad.net/~al-maisan/launchpad/parc-456551/+merge/14430 ?
[17:54] <al-maisan> It's a potential r-c candidate.
[17:57] <EdwinGrubbs> al-maisan: Im out of the office running an errand. Is this something i can review by just looking at the diff on my phone?
[17:58] <al-maisan> EdwinGrubbs: sure, http://pastebin.ubuntu.com/309759/
[17:58] <al-maisan> EdwinGrubbs: please note: it is the first 20 lines of the diff that matter.
[18:01] <al-maisan> EdwinGrubbs: I need to grab dinner but will be back later.
[18:02] <EdwinGrubbs> al-maisan: What is the last else?
[18:04] <al-maisan> EdwinGrubbs: the last else are primary archive (ubuntu) uploads
[18:04] <al-maisan>         else:
[18:04] <al-maisan>             archives = [self.policy.archive]
[18:09] <EdwinGrubbs> al-maisan: i dont quite understand the difference between the archive for the elif and the one for the else
[18:10] <al-maisan> EdwinGrubbs: the 'elif' clause is for uploads to PPAs
[18:11] <EdwinGrubbs> al-maisan: r=me
[18:11] <al-maisan> EdwinGrubbs: thanks!
[19:56] <Ursinha> all: do I have to do something else besides filing a merge proposal to get a db review from stub?


[01:04] <infinity> doko: Grr.  So, it's /usr/lib/arm-linux-gnueabihf/crtn.o that's vaguely broken.  Totally eglibc's fault.  Not sure how it got broken, though.
[01:46]  * infinity goes crosseyed at these Makefiles and decides to EOD instead.
[02:02] <cjwatson> doko_: not sure I really see the need for blacklisting python3.2.  the auto-sync wouldn't have brought it back anyway, and we have a poor record of pruning cruft from the blacklist.
[02:04] <cjwatson> from my point of view the more cases where auto-sync can dtrt automatically and the fewer things we have to add to the blacklist, the better
[02:04] <cjwatson> I realise this is a change from the crappy old pile of workarounds for sync-source.py -a
[08:46] <xnox> doko_: Yeah \0/
[09:24] <cjwatson> seb128: are you in the process of rebuilding stuff for libcogl11, and/or do you need help?
[09:25] <seb128> cjwatson, that's my plan for the morning, I should be fine without help thanks
[09:25] <cjwatson> cool, thanks
[09:29] <ogra_> Unpacking libreoffice-common (from .../libreoffice-common_1%3a3.6.2~rc2-0ubuntu5_all.deb) ...
[09:29] <ogra_> dpkg: error processing /var/cache/apt/archives/libreoffice-common_1%3a3.6.2~rc2-0ubuntu5_all.deb (--unpack):
[09:29] <ogra_>  corrupted filesystem tarfile - corrupted package archive
[09:29] <ogra_> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
[09:29] <ogra_> BAH !
[09:29] <ogra_> again
[09:29] <xnox> eagle-data is no longer built by eagle package but britney makes up an excuse "out of date on all arches: eagle-data"
[09:29] <ogra_> there is something seriously wrong with the panda livefs builder
[09:30] <ogra_> its the second day in a row it has decompression errors (yesterday it was gzip, not tar though but a similar error)
[09:31] <cjwatson> xnox: That's odd.  I'll look once I've dug myself out from under python-apt
[09:32] <xnox> thanks.
[09:35] <ogra_> hmm, did we change something wrt the adm group to be used beyond for reading logs ?
[09:47] <seb128> cjwatson, speaking of cogl ... it will stay in proposed until rebuilds are done right?
[09:47] <xnox> seb128: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt looks like yes.
[09:47] <seb128> cjwatson, is that info with the list of rdepends somewhere? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says "Valid candidate "
[09:48] <seb128> xnox, that page is a bit rough to read ;-)
[09:48] <xnox> seb128: see update_output.txt where britney "tries" to migrate "valid candidates" and fails to do so for cogl.
[09:49] <cjwatson> seb128: Yes, it will, and unfortunately not yet
[09:49] <cjwatson> Though there will be
[09:49] <xnox> seb128: apparently the format imprints in your brain after a while =)
[09:49] <Laney> or set up a transition tracker
[09:49] <seb128> cjwatson, ok, that's fine, getting the list is easy enough, I was mostly wondering if there was a page I didn't know about there
[09:50] <cjwatson> Unless you set up a transition tracker as Laney suggests then update_output is the only such page right now
[09:50] <seb128> ok, I will stick to "reverse-depends libcogl9" ;-)
[09:51]  * seb128 gets started
[10:16] <xnox> doko_: bug 1076305
[10:16] <ubot2> Launchpad bug 1076305 in python3.3 (Ubuntu Raring) "plat-x86_64-linux-gnu is still incomplete" [Critical,Confirmed] https://launchpad.net/bugs/1076305
[10:16] <xnox> breaks ubiquity & hence all live images.
[10:20] <tumbleweed> I had a quick shot at visualising dependencies in -proposed. But it doesn't show much... lp:~stefanor/+junk/britney-visualisation
[10:28] <Laney> got some sample output?
[10:32] <xnox> for me personally dependencies are easy enough to parse. It's the excuses which are confusing, i.e. the distinction between "building/queued to build" vs "actually failed to build"
[10:32] <xnox> requires an extra lookup on launchpad =)
[10:39] <doko_> xnox, that's not a bug. ubiquity using these looks like a bug ...
[10:39] <tumbleweed> Laney: http://people.ubuntu.com/~stefanor/excuses.dot
[10:39] <doko_> ev, cjwatson: ^^^
[10:39] <tumbleweed> Laney: as I said, not showing much
[10:39] <tumbleweed> I excluded eeverything outside dependency graphs.
[10:40] <tumbleweed> but it parses the britney output, and could do useful things with the other information...
[10:40] <Laney> mmm
[10:41] <xnox> doko_: hmm... we use it because python-dbus calculates max limit of time-out based on INT_MAX.
[10:42] <ev> well, DBus does, but yeah
[10:42] <xnox> doko_: but why should it not be exposed any more? I understand that int type in python3 is arbitrary precision, but it kind of helps to know that value in python when interfacing with C / compiled code.
[10:43] <xnox> ev: ack.
[10:46] <doko_> xnox, 3.3 generates this module at build time now, before, it wasn't updated for years. so it much depends which headers are included from in.h. you can't rely on this
[10:48] <cjwatson> MAX_DBUS_TIMEOUT is dead code anyway
[10:48] <cjwatson> I'll just remove it
[10:48] <xnox> ok.
[10:49] <xnox> doko_: and limits.h is not included? oh well, such is life.
[10:50] <cjwatson> doko_: from my point of view, feel free to close the python3.3 task
[10:55] <cjwatson> doko_: did you mean to close the seriesless task too?
[10:57] <doko_> cjwatson, done. I'm fine to reconsider this, but if it's just in our own code ...
[10:57] <xnox> hah, so it's eglibc2.16 at fault after all.
[10:58] <doko_> cjwatson, done. hmm, it only did show up after changing the raring task ...
[10:58] <cjwatson> Yes, usual behaviour when wontfixing series tasks
[14:00] <cjwatson> xnox: OK, so, I more or less have a fix for the eagle-data situation, but it will actually require *some* manual resolution since it has apparently deliberately started building on fewer architectures, which is a situation that requires forcing
[14:00] <cjwatson> xnox: But there was definitely a bug since it shouldn't have been showing as out-of-date on i386, so thanks for the heads-up
[14:04] <xnox> cjwatson: interesting. Well I synced it, so I did "babysit it" =)))))
[14:04] <xnox> cjwatson: did you respin ubiquity images? it's blocking qa to setup jenkins installer jobs....
[14:05] <xnox> if not, please do =)
[14:07] <cjwatson> xnox: respinning Ubuntu desktop now
[14:10] <xnox> cjwatson: thanks.
[14:11] <xnox> usb-creator also has INT_MAX usage & it does use MAX_DBUS_TIMEOUT. Should it just stop using that like ubiquity did?
[14:11] <xnox> ev: ^
[14:12] <ev> yes
[14:12] <xnox> ack.
[14:13] <cjwatson> harder in that case since it actually uses it, but you could just pick a large number
[14:13] <cjwatson> e.g. hardcode 32-bit INT_MAX
[14:13] <cjwatson> it's not like it needs to be larger
[14:14] <xnox> cjwatson: ack.
[14:25] <seb128> cjwatson, do you know why http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt is not getting cleaned for cogl?
[14:25] <seb128> cjwatson, I might be reading it wrong but we should have things mostly all rebuilt
[14:26] <seb128> how/where is the list of what blocks it still there?
[14:31] <cjwatson> seb128: it'll be waiting for things to finish building
[14:32] <cjwatson> seb128: update_excuses is a first pass of package-local checks, such as "is it built everywhere"; update_output is the second pass and considers only things that were allowed through the first pass
[14:32] <seb128> cjwatson, do we have a current list just to make sure I didn't forget any?
[14:32] <cjwatson> not unless you've set up a transition tracker
[14:32] <seb128> ok
[14:38]  * cjwatson makes archive-reports lots faster
[14:39] <seb128> is there documentation on setting up a transition tracker entry?
[14:39] <seb128> google is failing me
[14:39] <cjwatson> ask Laney or xnox
[14:39] <Laney> there's a simple README, but generally just copy an existing one
[14:40] <seb128> oh, http://people.canonical.com/~ubuntu-archive/transitions/readme.txt
[14:40] <seb128> ok
[14:41] <cjwatson> xnox: eagle forced in now
[14:42] <xnox> seb128: I tend to browse http://release.debian.org/transitions/ and try to find the most similar one.
[14:42] <xnox> seb128: and then tweak the .build-depends & .depends as appropriate.
[14:42] <seb128> xnox, thanks
[14:43] <Laney> there's a fair few examples in our repo now too, which helps
[14:43] <xnox> seb128: also `$ reverse-depends libfoo1 ` and `$ reverse-depends -b libfoo-dev` help a lot =))))
[14:43] <seb128> xnox, I went through the reverse-depends libfoo but I think I'm done and I've very low visibility if that's right or if I missed one
[14:44] <xnox> yeah, tracker helps in those cases. Plus it shows if any of them FTBFS.
[14:45] <Laney> cjwatson: I still see OLD_PROPOSED_MTIME at archive-reports:85; shouldn't that be updated too?
[14:47] <cjwatson> uh, what
[14:47] <cjwatson> oh, blast, that wasn't actually committed so I missed it
[14:47] <Laney> my fault, I didn't know it was VCSed
[14:47] <Laney> well, I saw that it had a branch pointing to Riddell so assumed that it was crufty
[14:47] <cjwatson> fixing
[14:47] <cjwatson> yeah, ignore that
[14:48] <cjwatson> it's just locally vcsed although I'm working on it with a bzr+ssh checkout now
[14:50] <cjwatson> Laney: better now, I think
[14:51] <Laney> I think that makes sense
[14:51] <cjwatson> this should make some difference to lillypilly's performance in general - it was periodically being caned by a zillion apt-get processes
[15:58] <cjwatson> Can somebody have a look at my grub2/precise-proposed SRU?  It blocks most of the rest of the SB stack.
[16:28] <stgraber> and there we go for the product manifest (currently only on staging): http://iso.qa.dev.stgraber.org/qatracker/series/20/manifest
[16:30] <xnox> stgraber: looks like we are ready to release =)
[16:31] <highvoltage> nice
[16:49] <xnox> we have a working image \0/
[16:49] <cjwatson> hooray
[16:49] <stgraber> quick, break it!
[16:49]  * xnox goes to rebase my ubiquity branches & partman merges
[16:50] <cjwatson> seb128: I don't understand why update_output thinks empathy is still uninstallable; if it's still that way tomorrow I'll poke at it then
[16:51] <seb128> cjwatson, thanks
[16:55] <bdmurray> slangasek: there is a 2nd (and probably older than the one you approved) webapps-applications in the quantal proposed queue, should it just be rejected?
[16:57] <slangasek> older, really? hmm, I guess so :/
[17:00] <bdmurray> slangasek: actually the dates inthe changelog are the same so I've no idea what is up
[17:36] <infinity> cjwatson: Looking at grub2/precise.
[17:37] <cjwatson> Thanks.  Sorry it's kind of long.
[17:37] <cjwatson> I know how the kernel guys feel all the time now.
[17:41] <infinity> The kernel folks seem to continue to be shocked to realise that I actually read their diffs, too. :P
[17:44] <infinity> cjwatson: Did you test this in a signing-capable PPA to test the results?
[17:44] <seb128> hum, ok, I went through what I think are cogl rdepends, not sure why it's not getting out of proposed, I will need help to understand why
[17:45] <infinity> seb128: I'll look at cogl after I'm done with this review.
[17:45] <seb128> cjwatson, is there anywhere I could check or I just better wait tomorrow when you said you would have a look to the empathy issue?
[17:45] <cjwatson> infinity: No
[17:45] <seb128> infinity, thanks, please let me know what you look at so next time I'm less stupid and can try to figure out the issue without pinging you guys
[17:46] <cjwatson> infinity: I did test-build locally and check that it looked about right
[17:46] <cjwatson> seb128: It's probably a bug in the migration code - no useful report
[17:46] <cjwatson> I tested empathy in chdist and it was fine there
[17:47] <infinity> cjwatson: If you don't have one set up, care to hand it to Andy to upload to his signing PPA?  Might be nice to see it doing what appears to be the right thing.
[17:47] <cjwatson> My guess would be YA bug in the partial-suite merging code
[17:47] <cjwatson> mkay
[17:47] <seb128> cjwatson, ok, I will let it to you guys then, thanks, let me know if I can help on anything
[17:47] <infinity> cjwatson: Though, I guess, modulo the actual signing bit, a local build should be about the same.
[17:47] <cjwatson> apw: would you mind fishing grub2 out of the precise queue and dropping it in your PPA?
[17:48] <apw> cjwatson, sure
[17:48] <infinity> https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=grub2
[17:48] <cjwatson> maybe with a slightly decremented version
[17:49] <apw> yep
[17:49] <infinity> 3.5~ppa1 works.
[17:52] <infinity> cjwatson: Why are we limiting linuxefi to amd64?  Surely, some day, there may be an i686 efi machine?
[17:52] <cjwatson> It failed to build on i386 for some reason I forgot
[17:53] <infinity> Check.
[17:53] <cjwatson> So I put it in the "worry about it when it happens" bucket
[17:53]  * infinity nods.
[17:53] <infinity> Maybe the ia32 vendors will stick with BIOS forever anyway.  Who knows.
[17:53] <cjwatson> There was talk about it on Atom
[17:54] <cjwatson> But anyway the amd64-only bit is in quantal too
[17:54] <infinity> Certainly not worth doing EFI for old skool (now embedded) i486/i586 stuff, so the Atom is the only likely concern.
[17:54] <apw> i thought most atom was 64bit capable now, even if one does put 32 on it
[17:54] <infinity> apw: Most new ones are 64-bit, but they're still producing 32-bit parts.  So, it's really what the vendors do with those parts.  We'll see.
[17:54] <cjwatson> Last UDS there were not-terribly-specific comments from some vendors that we might need 32-bit EFI at some point
[17:55] <cjwatson> But it's not reached the stage of being a problem
[17:55] <cjwatson> And even if they do, it might well not involve secure boot, since Windows 8 only supports UEFI in 64-bit mode IIRC
[17:56] <cjwatson> (Though this is just from reading articles six months ago rather than direct experience)
[17:56] <apw> cjwatson, grub2> is in my PPA -- https://launchpad.net/~apw/+archive/signing/+packages
[17:58] <cjwatson> ta
[17:58] <infinity> "This is only intended as a temporary measure." <-- Famous last words?
[17:59] <cjwatson> yeah yeah :)
[17:59] <cjwatson> In theory it still is
[17:59] <cjwatson> But I didn't get round to revisiting that decision before 12.10
[18:00] <cjwatson> I *suspect* that it can be reverted now that we know we're not requiring signed kernels (it predates that being clear)
[18:00] <cjwatson> But need to check and think about it a bit, and make sure it does something reasonable in the fallback path
[18:02] <infinity> cjwatson: Also, a patch pointing to bzr.lp.net imports as "upstream" is a bit strange, but whatever. :P
[18:02] <cjwatson> So I thought it better to backport something as close as possible to what we tested in 12.10, at least in terms of SB policy
[18:03] <infinity> cjwatson: Oh, absolutely, if we're going to mangle any of this branching, we need to do it in an unstable release first.
[18:03] <cjwatson> I generally use LP as the reference because savannah's loggerhead installation at least historically hasn't been very reliable
[18:03] <cjwatson> It's a mirror rather than an import though - upstream uses bzr
[18:03] <infinity> Oh, right.
[18:07] <cjwatson> I tried to keep the 1.99-specific mangling to the "supporting backports" patch wherever possible, although there are a few other details like the module list needing to be different for 1.99
[18:07] <cjwatson> I will confess I haven't actually tested this on SB because OMG the pain of setting all that up independently
[18:08] <cjwatson> I thought it was likely to be rather more economical to assemble it all in -proposed and then build images off that
[18:08] <infinity> Indeed.
[18:08] <cjwatson> But I can possibly try grub-mkrescue off apw's PPA or something
[18:08] <infinity> Well, images aren't necessary.  We could stage it all in a PPA and... Yeah.
[18:35] <infinity> cjwatson: The backport support thing wasn't as scary as I thought it would be.  Except for the whole utf8 handling bit.
[18:37]  * infinity blinks at his INBOX...
[18:37] <infinity> cjwatson: Did britney go crazy last night and copy apt 6 times in a row?
[18:41] <infinity> cjwatson: Okay, want to poke at http://ppa.launchpad.net/apw/signing/ubuntu/dists/precise/main/uefi/grub2-amd64/ and see if it seems to be what you think it should be?
[18:41] <infinity> cjwatson: I didn't see anything obviously broken in the diff, so I'm inclined to accept once you've had a poke at the PPA output.
[18:42] <bdmurray> why does the diff for shotwell in quantal proposed include a version that is already in quantal?
[18:42] <bdmurray> http://launchpadlibrarian.net/121739080/shotwell_0.13.0-0ubuntu2_0.13.1-0ubuntu1.diff.gz
[18:42] <infinity> bdmurray: The diff is generated against the last version that was in proposed.
[18:42] <slangasek> because queuediff diffs against the last version of the package that was in quantal-proposed :/
[18:42] <infinity> bdmurray: Longstanding bug.
[18:43] <bdmurray> is there a workaround?
[18:43] <infinity> Yeah, download the sources and diff yourself. :P
[18:44] <infinity> apt-get source foo && queue fetch foo && debdiff *dsc
[18:44] <infinity> (Or however you prefer to obtain A and B)
[18:45] <xnox> bdmurray: pull-lp-source $package [$distro[-$pocket]] is also nice.
[18:46] <infinity> I need to train my fingers to use that.
[18:47] <infinity> I assume it just does an API lookup for the latest published in $series, and then dgets it (ish)?
[18:52] <xnox> infinity: yeah. But it's clever and with $ pull-lp-source package it tries raring-proposed and then raring ;-)
[18:52] <xnox> and it fetches from librarian, not from archive mirrors.
[18:52] <xnox> so you can request _any_ version e.g. $ pull-lp-source package 0.3.2-21build3
[18:53] <xnox> also pull-debian-source does the same but for debian (again series or versions) and it fetches _any_ version from snapshots.debian.net =)))))
[18:53] <xnox> cunning pair of beasts.
[18:53] <infinity> xnox: I was just about to ask.
[18:53] <infinity> xnox: I hit snapshot and dget all the time.
[18:53] <infinity> xnox: This could prove a handy tool to train myself to actually use.
[18:54] <bdmurray> xnox: thanks
[18:54] <xnox> infinity: well I did wrapper scripts for both =))) to do grab-sync & grab-merge to bang ubuntu&debian versions together, show debdiff and test sbuild them. Handy for sponsorship.
[18:59] <xnox> this is packaging remaining tools needed to build nexus7 images on ubuntu.
[19:00] <xnox> sources were already part of the source package, but the binaries were not previously built.
[19:00] <xnox> please accept =)))))
[19:04] <infinity> xnox: Your changelog doesn't match reality. :P
[19:05] <xnox> infinity: in what sense?
[19:05] <infinity> xnox: Did you want it to be android-tools-fsutils or android-tools-ext4-utils?
[19:05] <infinity> xnox: Changelog says the latter, package says the former.
[19:06] <xnox> infinity: meh... i had three names and kept on changing them. the one that is actually built as a deb is the one I wanted.
[19:06] <infinity> Alright.
[19:06] <xnox> "fsutils"
[19:06] <xnox> sorry about confusion.
[19:06]  * xnox naming packages is hard
[19:16] <infinity> Grr, seb left just as I was about to tell him why cogl was broken. :P
[19:17] <infinity> Laney: Any urge to update gnome-desktop3 to >= 3.6.1?  That's snagging a bunch of stuff in proposed, and you're TIL.
[19:23] <xnox> infinity: tells us, why is cogl broken? =)
[19:46] <jbicha> oh, I guess gnome-desktop3 is my fault, I can upload the new version
[19:46] <xnox> infinity: lol ;-)
[19:49] <infinity> jbicha: Ahh, thanks.
[19:50] <infinity> xnox: It was that.  Or, rather, that a bunch of stuff is all snagged together, and some things depend on the new gnome-desktop, which doesn't exist yet. :P
[19:56] <jetsaredim> bdmurray: can you take a look at bug 205509 and let me know if I have put enough detail/info to get the fix picked up for quantal?
[19:56] <ubot2> Launchpad bug 205509 in transcode (Ubuntu) "tcdecode(dvdrip) fails to work" [Undecided,Fix released] https://launchpad.net/bugs/205509
[19:58] <jetsaredim> i suppose that question could also apply to ScottK and skaet
[20:00] <bdmurray> jetsaredim: the test case could use some more details but it seems fine to me
[20:01] <infinity> jetsaredim: Your test case isn'ta test case.
[20:01] <infinity> bdmurray: Jinx.
[20:01] <jetsaredim> suggestions?
[20:02] <infinity> jetsaredim: Test cases should just be something like "run 'foo-command --switch argument' and watch it fail before update, and succeed after"
[20:02] <jetsaredim> infinity: fair enough
[20:02] <infinity> jetsaredim: The point being that someone other than you should be able to follow the directions to reproduce, if required. ;)
[20:02] <jetsaredim> does it necessarily have to be the the exact command
[20:02] <jetsaredim> cause it's much easier to reproduce the issue through dvdrip
[20:03] <jetsaredim> since all the flags and whatnot are set for you
[20:04] <infinity> jetsaredim: Sure.  Doesn't matter what the testcase is, as long as it's descriptive steps that show the problem.
[20:04] <infinity> jetsaredim: Anyhow, it otherwise looks fine, and the 1-line diff isn't exactly hard to understand.
[20:04] <jetsaredim> sure
[20:05] <jetsaredim> what is the process for getting this into quantal-updates?
[20:05] <infinity> jetsaredim: Actually, the original bug description seems to have a command line that would be a reasonable test-case. :P
[20:05] <jetsaredim> not that it's a major earth-shattering issue but its bugging the hell out of me
[20:05] <jetsaredim> yea
[20:05] <jetsaredim> i was just about to copy/paste that
[20:05] <infinity> jetsaredim: The next step would be finding someone willing to sponsor the upload, if you're not an uploader yourself.
[20:05] <jetsaredim> yes, i'm not
[20:06] <infinity> Wow, old bug.
[20:07] <infinity> jetsaredim: Would you be able to test packages on both precise and quantal if someone (say, me) were to do the actual SRUs for you?
[20:07] <jetsaredim> i'm sure i could fire up a vm for precise
[20:08] <jetsaredim> i don't currently have this in a branch at the moment
[20:08] <jetsaredim> so i guess i'd need to do that first?
[20:08] <infinity> jamespage: Don't worry about that.  It's a 1-line patch, I'll JFDI.
[20:08] <infinity> Err.
[20:08] <infinity> jetsaredim: ^
[20:08] <infinity> jamespage: Nevermind, tab fail.
[20:08] <jetsaredim> heh
[20:08] <jetsaredim> kthen
[20:12] <infinity> jetsaredim: Oh, hrm.  Looks like precise has --enable-libmpeg2convert
[20:12] <infinity> jetsaredim: Can you confirm that in a VM?  I'll do the quantal SRU now.
[20:12] <jetsaredim> sure
[20:13] <jetsaredim> infinity: i'll have to do an install first but shouldn't take that long
[20:13] <infinity> Makes a more valid argument for the Q SRU, if it's a regression from precise.
[20:14] <jetsaredim> indeed
[20:18] <infinity> bdmurray: If you want to give the above 1-line diff a quick once-over, then we can get The Guy Who Knows How To Test This to test it soon. :P
[20:18]  * infinity hates verifying bugs where the test case, ultimately, starts with "obtain some data file you may not have".
[20:19] <slangasek> infinity: as far as I'm concerned, that's not a valid test case
[20:19] <jetsaredim> yea - unfortunately there's really not much use for transcode without a random datafile to "trans"
[20:20] <slangasek> if the test case can't be followed by someone who doesn't already have the environment/data/package, it's not a complete test case
[20:20] <infinity> slangasek: Well, in this case, I suspect it fails on nearly any vob.  But if you don't happen to have any vobs handy, I'm not sure it's sane to demand someone furnish you with one, rather than just asking them to test.
[20:20] <infinity> slangasek: And if the test case involves, say, a copyrighted vob you can't distribute...
[20:21] <slangasek> sure; in most cases you can probably link to whoever /is/ distributing it, though
[20:22] <infinity> slangasek: Link to, as in "Step 1: Buy a copy of Fight Club, director's cut, region 2"?
[20:22] <slangasek> heh, not so much
[20:22] <slangasek> "here's a torrent" <- wfm ;P
[20:22] <infinity> Naughty.
[20:22] <jetsaredim> i suspect that's why not too many people have commented on the bug
[20:23] <infinity> jetsaredim: That fine line between not wanting to admit you rip DVDs and wishing the tool worked right?
[20:23] <jetsaredim> indeed
[20:23] <infinity> jetsaredim: Thankfully, it's perfectly legal to rip copyrighted DVDs in many places that aren't the US. :P
[20:24] <slangasek> infinity: ahwell, I just wrote an SRU test case that says "make smoser test", so I'm clearly not as much a purist as I pretend either
[20:27] <infinity> slangasek: *laugh*
[20:33] <infinity> jetsaredim: If you're on amd64, the build's done, if you want to go forth and verify: https://launchpad.net/ubuntu/+source/transcode/3:1.1.7-2ubuntu1/+build/3967662
[20:33] <jetsaredim> precise still building
[20:34] <infinity> jetsaredim: I'm pretty sure it should be fine in precise, from looking at debian/rules, but verifying there would be nice too, sure.
[20:34] <xnox> doesn't like Big Bunny offer a *free* dvd. Can it be reproduced with that?
[20:34] <infinity> (I already invalidated my precise task)
[20:34] <infinity> xnox: I'm sure it can probably be reproduced with free data from somewhere.  On the other hand, with someone here right now who can test, I don't really care what data they use.
[20:35] <infinity> (In the absence of a tester, I likely wouldn't have SRUed at all)
[20:35] <jetsaredim> infinity: seems to workie on quantal
[20:36] <infinity> jetsaredim: Shiny, follow up to the bug with that info and set the verification-done tag, s'il vous plaît.
[20:40] <jetsaredim> let me know if you *do* want me to test the precise version
[20:42] <infinity> jetsaredim: Well, precise's debian/rules looks correct.  Based on that, I invalidated the precise task, so I'm not wildly picky.  If someone decides it doesn't work, they can reopen the bug on precise.
[20:42] <infinity> jetsaredim: (Looks like this regressed in Q when we synced with Debian, which had the flag disabled)
[20:42] <jetsaredim> ok
[20:43] <jetsaredim> i'm updating my precise vm at the moment and can verify shortly
[20:44] <infinity> jetsaredim: Alright, cool.
[20:44] <infinity> Laney: You're off the hook for gnome-desktop3, jbicha delivered.
[20:44] <jetsaredim> many thanks
[20:44] <Laney> I saw
[20:45] <Laney> what was snagged on it?
[20:45] <infinity> Let's see if this makes britney happy with the gnome/cogl/etc mess.  Should do.
[20:45] <Laney> I'd rather the person who made /that/ happen be on the hook (perhaps that was jbicha)
[20:45] <infinity> Laney: It was probably him, yes. :P
[20:47] <infinity> Laney: Yeah, it was his gnome-shell upload that bumped some deps to 3.6.1
[20:48]  * Laney nods
[20:50] <stgraber> infinity, cjwatson: QA tracker changes landed in production so we now have the manifest API and all the needed magic for his cycle.
[20:50] <stgraber> *this
[20:50] <infinity> stgraber: \o/
[20:50] <infinity> stgraber: Can you take a very long coffee break for a few days, so I don't feel like such a slacker?
[20:50] <infinity> stgraber: Thanks.
[20:51] <stgraber> :)
[21:00] <highvoltage> sometimes I wonder if stgraber really ever sleeps.
[21:00] <stgraber> oh I'm sure I'm sleeping a lot more than some of my colleagues ;)
[21:15] <infinity> highvoltage: What's "sleep"?
[21:18] <smoser> slangasek, thats fine. i did at least sniff the raring stuff.
[21:19] <smoser> but i didntn look at read-only iscsi root.
[21:26] <stgraber> infinity: I dumped the work items from the pad into https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-release-manifest-streamlining so I could mark mine as done, I'll let you do the rest of the drafting though :)
[21:29] <infinity> stgraber: Gee thanks, I was really worried someone else might draft it for me. :P
[21:31] <stgraber> infinity: no problem, I know how much you like drafting those, I wouldn't take that away from you ;)
[21:44] <slangasek> smoser: right; this is for the SRU to precise, to let your cloud-init stuff work in all its glory, so certainly needs more complete testing
[21:45] <smoser> sort of.
[21:45] <smoser> i'm fairly confident in the non-iscsi root case.
[21:46] <smoser> and, at least fo rth eime being, the iscsi-root case is covered as the images already have a patched mountall and patched cloud-init.
[21:47] <slangasek> smoser: you're using a non-distro patched mountall package for official Ubuntu cloud images?
[21:47] <smoser> no.
[21:47] <smoser> for the maas.ubuntu.com/images images.
[21:47] <smoser> which are only used in maas.
[21:47] <slangasek> hmm, alright
[21:47] <smoser> i wasn't happy about that.
[21:48] <slangasek> well anyway, I'd like you to not have to do that either
[21:48] <smoser> but... i'm using copied mountall from quantal.
[21:48] <slangasek> which is why I've pushed the mountall SRU to precise
[21:48] <smoser> right.
[23:32] <cjwatson> infinity: the structure of that grub2 build looks ok.  not tried actually booting as yet, as I say ...
[23:32] <infinity> cjwatson: Meh, booting is overrated.
[23:34] <infinity> That's a whole lot of tasks on bug 1075181...
[23:34] <ubot2> Launchpad bug 1075181 in shim (Ubuntu Precise) "Backport UEFI Secure Boot support for Ubuntu 12.04.2" [High,In progress] https://launchpad.net/bugs/1075181
[23:35] <cjwatson> I *think* I got them all
[23:36]  * infinity adds linux-lts-quantal-signed.
[23:37] <cjwatson> awesome, thanks.  will continue with the rest of the stack tomorrow
[23:38] <infinity> Cute that I can assign bug tasks to it, even though it only exists in a PPA.
[23:39] <cjwatson> infinity: britney/apt> six is a bit excessive, but if it gets a bit lost and runs multiple times during a single publisher run then that kind of thing can happen
[23:39] <infinity> cjwatson: Was the plan to also make this work with 3.2.0, or only with the backport kernels?
[23:39] <cjwatson> yeah, all you need is an SPN
[23:39] <cjwatson> only with the enablement kernels
[23:39] <infinity> Alright, then I'll delete the linux-signed task from there.
[23:39] <cjwatson> ok
[23:40] <cjwatson> 'cos otherwise we have to backport the efi handover protocol stuff
[23:40] <cjwatson> and meh
[23:42] <jbicha> infinity: gnome-desktop3 migrated but cogl is still stuck
[23:42] <infinity> jbicha: Fun.  Let me look why now.
[23:45] <infinity> jbicha: Hrm.  Looks installable to me now.  Let's see if britney tries harder this next cycle.
[23:47] <infinity> Oh, wait.  My "looks installable" apt run shows both libcogl11 and libcogl9 being installed.  I suspect that's ungood. :P
[23:49] <infinity>  libclutter-gst-1.0-0 : Depends: libcogl9 (>= 1.9.6) but it is not going to be installed
[23:49]  * infinity checks if a no-change rebuild will fix that.
[23:52] <infinity> jbicha: What I used to determine this, BTW: http://paste.ubuntu.com/1343991/
[23:53] <infinity> jbicha: Basically "explicitly don't install libcogl9, and try to install everything that britney was complaining about being broken".
[23:54] <infinity> jbicha: And for added fun, clutter-gst doesn't build against raring-proposed.  Is there a new upstream?
[23:54] <jbicha> infinity: oh yeah, it looks like we didn't even try to rebuild it
[23:55] <infinity> jbicha: I just tried, iz broke.
[23:57] <infinity> jbicha: Ahh, there's a 1.9 going on upstream, perhaps that's what we want.
[23:57] <jbicha> infinity: no, that's clutter-gst-2.0
[23:58] <infinity> Though, you'd think not, as that's un... Yeah.
[23:58] <infinity> jbicha: Well, either way, the 1.6 no workie, so needs fixing.
[23:59] <jbicha> infinity: ok at least we know where the problem is; I'll try poking on it tonight
[23:59] <infinity> jbicha: Danke.