 I can remove them from this one if you like?
[02:45] <hatch> no it's ok as long as you know you'll use them
[02:45] <huwshimi> yep
[02:45] <hatch> ok +1'd
[02:46] <hatch> you can land it whwnever
[02:47] <huwshimi> hatch: Thanks!
[02:59] <rick_h_> hatch: what's up?
[03:00] <hatch> rick_h_ oh hey, the PR ci will need restarting
[03:00] <hatch> I was just about to grab the info
[03:00] <hatch> :)
[03:00] <rick_h_> hatch: gotcha, sec
[03:01] <rick_h_> hatch: I only see the prod one going
[03:01] <rick_h_> hatch: and that's in a test run to land
[03:02] <hatch> rick_h_ yeah I had to kill the one in the pr lane because it hung
[03:02] <hatch> so it will likely still be running...no?
[03:02] <rick_h_> hmm, tests are running atm
[03:02] <rick_h_> hmm, maybe it's this other one
[03:02] <hatch> right - not the landing script
[03:02] <hatch> the pr one
[03:02] <rick_h_> ok, killed one
[03:02] <rick_h_> hopefully that's the right one :)
[03:02] <hatch> haha we'll know shortly!
[03:03] <hatch> maybe this weekend I'll find some time to add the 'if running KILL IT DEAD' mode :)
[03:03] <rick_h_> it's supposed to do that :P
[03:03] <rick_h_> (cd build-prod && \ python ../bin/http_server.py 8888 2> /dev/null & \ echo $!>ci-check-gui-server.pid)
[03:03] <hatch> oh haha - well then, why does it give the ERADDRINUSE issue?
[03:04] <hatch> ohhh
[03:04] <hatch> that's not checking the node server
[03:04] <rick_h_> echo ci-check-gui-server.pid
[03:04] <rick_h_> ci-check-gui-server.pid
[03:04] <rick_h_> cat ci-check-gui-server.pid
[03:04] <rick_h_> 4360
[03:04] <rick_h_> kill `cat ci-check-gui-server.pid`
[03:04] <rick_h_> rm ci-check-gui-server.pid
[03:04] <rick_h_> hatch: oh hmm, yea then maybe it needs more of it
[03:04] <hatch> yeah I think it's the node server that throws the error
[03:05] <rick_h_> gotcha, yea well happy to run more pid/pid-checking to help it
[03:05] <rick_h_> doens't happen too often thankfully.
[03:06] <rick_h_> hatch: you hatch on launchpad?
[03:06] <hatch> yep
[03:06] <rick_h_> you're a rude man making me look it up on LP hatch :P
[03:07] <rick_h_> ok, you've got ssh rights. ssh<EMAIL_ADDRESS>[03:07] <hatch> lol sorry I was in the other room
[03:07] <rick_h_> don't mess up my server or I'll have to come to canada and drop you down a hole in the ground
[03:10] <hatch> lol yeah I wont be at it until this weekend for sure
[03:10] <rick_h_> at what?
[03:10] <rick_h_> you not in canada right now?
[03:10] <hatch> haha of course I am
[03:11] <hatch> I meant, I won't be breaking your server until this weekend
[03:11] <rick_h_> well don't do that!
[03:11] <hatch> :)
[03:14] <hatch> Ooo nice new column in the board
[06:43] <rogpeppe> mornin' all
[06:43] <huwshimi> rogpeppe: Morning
[06:54] <rogpeppe> huwshimi: hiya
[11:27] <rick_h_> morning
[13:15] <rogpeppe> rick_h_: hiys
[13:15] <rogpeppe> hiya
[13:15] <rogpeppe> even
[13:15] <rick_h_> rogpeppe: howdy
[13:16] <rogpeppe> rick_h_: the bundles parsing/verification PR is up at https://github.com/juju/charm/pull/9
[13:16] <rick_h_> rogpeppe: cool looking.
[13:16] <rogpeppe> rick_h_: it does all the internal verification, but doesn't verify against actual charms
[13:17] <rick_h_> rogpeppe: ok, can you create a bug/additional card to look into that part?
[13:17] <rogpeppe> rick_h_: ok, will do
[13:17] <rick_h_> rogpeppe: we're thinking that'd part of the publish side of things?
[13:17] <rick_h_> vs part of the actual model side here
[13:17] <rogpeppe> rick_h_: i'm thinking that it can live inside the charm package
[13:17] <rick_h_> outside you mean?
[13:18] <rogpeppe> rick_h_: no, inside
[13:18] <rogpeppe> rick_h_: something like BundleData.VerifyWithCharms([]*Charm) error
[13:19] <rogpeppe> rick_h_: which means it can be called by any client that happens to know the charms that the bundle service charm urls resolve to
[13:20] <rick_h_> rogpeppe: ok, looking through this pr and will see how it fits
[13:20] <rogpeppe> rick_h_: thanks
[14:13] <rick_h_> rogpeppe: how does such 'combining of errors' work? They're basically complete sentences. How does one take them and combine them more than just listing them out? Does it ', and' each or anything as part of this common practice?
[14:13] <rogpeppe> rick_h_: usually it just involves prefixing "something happened: " onto an existing error
[14:14] <rogpeppe> rick_h_: in this case, the final error might look something like "cannot verify bundle: placement "foo:bar" refers to non-existent service (and 303 more errors)"
[14:15] <rick_h_> rogpeppe: ok, but then we need to make sure to update the clients cli and webui to do this post processing. It seems like adding more places to catch the update than to make it work right
[14:15] <rogpeppe> rick_h_: all errors returned by the API are currently without capitals or periods
[14:15] <rogpeppe> rick_h_: so this just continues in the same vein
[14:15] <rick_h_> rogpeppe: right, and we've had to do work in the gui to try to parse them and make them presentable
[14:16] <rick_h_> rogpeppe: right, it's an existing issue I'm bringing up potentially attempting to address while we're here in the code
[14:16] <rogpeppe> rick_h_: if we're going to change that, i'd prefer to change the entire API
[14:16] <rogpeppe> rick_h_: rather than adding a single inconsisent place
[14:16] <rogpeppe> inconsistent
[14:16] <rick_h_> heh count me in :) but we're in control of this bit of code and we know that errors parsing the bundles will need to get in front of the users
[14:16] <rick_h_> so they can debug and fix them
[14:16] <rogpeppe> rick_h_: consistency trumps convenience IMHO in this case
[14:17] <rick_h_> rogpeppe: ok, then we should add cards for the core cli and the gui to update bundle errors when connect to the updated store so that we don't lose track of known usability issues that we should correct.
[14:18] <rick_h_> maybe bugs would be better since they can't be updated until a store update is deployed and used
[14:19] <rogpeppe> rick_h_: i'm not entirely sure it's a CLI issue - errors are currently printed in lowercase
[14:20] <rogpeppe> rick_h_: but i'll add an issue to the gui. are gui issues tracked in lp ?
[14:20] <rick_h_> Why would it be good to make the error message a complete english thought with proper writing in one place and not the other?
[14:20] <rick_h_> rogpeppe: yes, they are
[14:21] <rogpeppe> rick_h_: mainly because many things on the unix command line print stuff in lower case - there's honourable precedent :-)
[14:21] <rogpeppe> rick_h_: and it's less code, which is always a win in my book :-)
[14:27] <bac> rogpeppe: i've got the latest charmstore and tried to run 'make check' but get errors referencing missing testing items like MgoSuite, etc.
[14:27]  * rogpeppe goes to see what make check does
[14:28] <rogpeppe> bac: for the record, when dealing with go packages, i almost never run make
[14:28] <rick_h_> rogpeppe: but through CI and such make is the single interface all devs can use to hack/operate
[14:29] <rogpeppe> rick_h_: sure, it's useful for CI
[14:29] <rick_h_> rogpeppe: the make targets need to be valid and make check is the common target in all proejcts for a CI-like run through lint, test, etc
[14:29] <rick_h_> so in QA it's quite common to make check, make run, and then qa
[14:29] <bac> rogpeppe: i'm just looking at the README and it references 'make check'
[14:29] <rogpeppe> bac: ok
[14:31] <rogpeppe> bac: have you tried doing: godeps -u dependencies.tsv ?
[14:31] <rogpeppe> bac: it all seems to work for me
[14:32] <rogpeppe> bac: could you paste the exact errors you get?
[14:32] <bac> rogpeppe: https://pastebin.canonical.com/112262/
[14:33] <rogpeppe> bac: hmm, odd.
[14:34] <rogpeppe> bac: could you try doing "rm -r $GOPATH/pkg" then "go install ./..." and trying again?
[14:34] <bac> rogpeppe: from inside the charmstore directory?
[14:34] <rogpeppe> bac: yes
[14:36] <bac> rogpeppe: didn't help.  what version of juju/testing do you have? mine is b09...
[14:37] <rogpeppe> bac: b0941ff1bf4d3db1ffbbe09f75fa8383eae5764c
[14:37] <bac> same
[14:38] <rogpeppe> bac: do you see the same thing if you just run "go test" (in the same dir)
[14:39] <bac> rogpeppe: yes, and it is unsurprising.  if i look in juju/testing i see no MgoSuite anywhere
[14:39] <kadams54> Juju GUI architecture question: how do we connect to the juju state server?
[14:39] <rick_h_> kadams54: websocket
[14:39] <hatch> via websocket
[14:39] <hatch> and magic
[14:39] <bac> rogpeppe: if you look in juju/testing where do you find those defined?
[14:40]  * hatch shakes hands in the air
[14:40] <rick_h_> lots of magic
[14:40] <hatch> *magic*
[14:40] <rogpeppe> bac: in mgo.go
[14:40] <kadams54> rick_h_: Where at in the code?
[14:40] <hatch> heh well....
[14:40] <rogpeppe> bac: what do you see if you run "git status" in the juju/testing dir?
[14:40] <hatch> kadams54 I can get you the loc, one sec
[14:41] <bac> clean
[14:41] <bac> rogpeppe: there is no mgo.go in my juju/testing
[14:41] <hatch> kadams54 here is the websocket instance https://github.com/juju/juju-gui/blob/develop/app/store/env/base.js#L234
[14:41] <rogpeppe> bac: could you paste the entire output of your "git status" please?
[14:42] <hatch> kadams54 here is where we make the requests https://github.com/juju/juju-gui/blob/develop/app/store/env/go.js#L181
[14:42] <hatch> kadams54 did you have a specific question in mind?
[14:43] <bac> rogpeppe: i went to my juju/testing and did a 'git pull' and it got the mgo.go file along with lots of others.  why did the 'go get -u' and the 'godeps' not update it?
[14:43] <rogpeppe> bac: i don't know - that's why i wanted to see exactly what git status printed for you
[14:44] <kadams54> hatch: that satisfies my curiosity for now, thanks
[14:44] <rogpeppe> bac: AFAIK go get -u just does a git pull
[14:44] <bac> rogpeppe: this is what git status said before i did the manual pull: https://pastebin.canonical.com/112263/
[14:45] <rogpeppe> bac: thanks. i've no idea then. "go get -u" just runs "git pull --ff-only"
[14:46] <hatch> kadams54 np
[14:46] <bac> rogpeppe: i'm going to blow away everything and try again
[14:46] <hatch> hey cory_fu
[14:46] <rogpeppe> bac: that can be a good plan...
[14:47] <rogpeppe> bac: have you tried testing again now that you did the pull?
[14:47] <bac> well i just want to see if it is reproducible
[14:47] <rogpeppe> bac: wait!
[14:47] <bac> rogpeppe: i did and it passed
[14:47] <rogpeppe> bac: what does "git remote -v" print for you in the juju/testing dir?
[14:47] <rogpeppe> bac: too late...
[14:47] <rogpeppe> bac: darn
[14:47] <rogpeppe> but... it printed the right head
[14:47] <kadams54> Hey, who should we be sending design/UX questions to right now? Luca's out, right?
[14:48] <rogpeppe> jeeze, i dunno
[14:48] <hatch> kadams54 spencer
[14:51] <rick_h_> jujugui call in 9
[14:54] <bac> wow, crazy loud tsunami drill.  i guess that's what you want from a tsunami alarm.
[14:58] <hatch> what does one do when a tsunami alarm rings? Run inland?
[14:58] <bac> rogpeppe: so you'll know, i'm trying to set up and test the charmstore as we'd do for CI.  it looks like we have some problems with our dependencies. here's what i've done (mainly as stated in the README) : https://pastebin.canonical.com/112265/
[14:58] <makyo_> jujugui call in 2
[14:58] <bac> run downstairs, grab beer and camera, then go to the roof.
[14:59] <rogpeppe> bac: you need to do go get -t
[14:59] <hatch> ahh to the roof
[14:59] <hatch> I guess that makes sense :)
[14:59] <bac> rogpeppe: go get -t -v github.com/juju/charmstore  ???
[15:00] <rogpeppe> bac: in full, you'd need to run: go get -v -t -u github.com/juju/charmstore/...
[15:00] <rogpeppe> bac: the final "/..." is important
[15:00] <rogpeppe> bac: otherwise you won't get deps for subdirs
[15:00] <rick_h_> jujugui call now
[15:11] <kadams54> hatch: https://github.com/juju/juju-gui/pull/393 is ready for QA again. I want to hold off on sending this e-mail until this branch is landed and you can see stuff working/not working on upcoming.
[15:13] <kadams54> Here are the questions I'm planning on sending out, in case you want to review: https://gist.github.com/kadams54/681a40f7bd9d603a53bb
[15:15] <cory_fu> So, I'm still trying to understand how juju-gui connects back to the juju state server.
[15:15] <cory_fu> I thought maybe https://github.com/juju/juju-gui/blob/develop/app/app.js#L382 was where it got the address of the state server, but that just seems to be the connection to the GUI backend?
[15:15] <kadams54> cory_fu was unsatisfied with the "magic" explanation.
[15:15] <cory_fu> :)
[15:16] <bac> rogpeppe: adding the -t worked.  i'll update the readme
[15:16] <rogpeppe> bac: thanks
[15:16] <bac> rogpeppe: yeah, the ... was important too
[15:19] <kadams54> 948647
[15:19] <kadams54> ccccccdilrklllutrivjhvjttuigtldiclbejkuderdh
[15:19] <kadams54> Alright, that's it
[15:19] <cory_fu> I'm failing to understand how it can be using the public address for the juju-gui unit yet still have commands get to the state machine on machine 0
[15:19] <kadams54> ccccccdilrklnvjvvhbrtekkhcebgrrjeejurdfdvuvc
[15:20] <kadams54> guihelp: --^ (cory_fu, not my yubi spam)
[15:20] <cory_fu> kadams54: You don't have another USB slot more out of the way?  :)
[15:20] <cory_fu> Oh, yeah, thanks
[15:20] <hatch> cory_fu I'm not sure the question
[15:21] <kadams54> I realized what it is - when I'm cmd-tabbing, my pinkie is right over that USB slot. I may try the other one.
[15:21] <hatch> cory_fu kadams54  we don't connect directly to the juju state server
[15:21] <hatch> we connect to the gui server
[15:21] <cory_fu> hatch: Ok, so I need to know how the GUI server talks to the state server
[15:23] <hatch> it also uses websocket but from a python server
[15:23] <hatch> http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/files
[15:23] <hatch> that's the charm source
[15:24] <hatch> cory_fu so are you trying to write your own application with communicates with the state server?
[15:25] <cory_fu> hatch: Yeah.  I'm working on the Cloud Foundry charm and it turns out we're going to need to communicate with the state server, similar to how the GUI does
[15:26] <hatch> ok there is api documentation around that....
[15:26] <hatch> one sec I'll see if I can find it
[15:26] <hatch> at least I thought there was....
[15:27] <cory_fu> Ah.  I found what I needed.  :)
[15:28] <rick_h_> cory_fu: yes, the gui talks to the guiserver in the charm
[15:28] <rick_h_> cory_fu: and then it proxies all requests to the state server and intercepts a couple of special api calls like bundle deploys that juju doens't natively handle
[15:28] <cory_fu> Ok.  That's basically what I expected.  Thanks.  :)
[15:28] <hatch> cory_fu perfect....where was it ?
[15:28] <hatch> hah
[15:29] <rick_h_> oh heh, hatch has your back.
[15:29] <cory_fu> hatch: https://bazaar.launchpad.net/~juju-gui/charms/trusty/juju-gui/trunk/view/head:/hooks/utils.py#L140
[15:29] <rick_h_> cory_fu: yea, you're looking for http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/files/head:/server/
[15:29] <cory_fu> That function is exactly what I needed
[15:29] <hatch> ahh perfect
[15:29] <hatch> yeah the guy who does this work is off atm :)
[15:31] <hatch> good luck with the charm
[15:32] <cory_fu> Thanks.  :-)
[15:58]  * rick_h_ goes to make up some lunch
[16:23] <hatch> has anyone else been running into issues with yahoos cdn taking forever to respond?
[16:33] <hatch> oh our test suite....
[16:42] <hatch> jujugui looking for a review/qa on this first relations branch https://github.com/juju/juju-gui/pull/402
[16:42] <kadams54> hatch: looking…
[16:43] <hatch> thanks
[16:43] <hatch> kadams54 what was the issue with the previous qa issue on your branch?
[16:43] <hatch> https://github.com/kadams54/juju-gui/commit/be1356a686a51632160fae08a8570d7e59310a3a
[16:43] <hatch> that commit?
[16:44] <kadams54> It was the unitOrEvent variable that got renamed back to unit… it needs to be nulled out if it's actually an event rather than a unit.
[16:44] <kadams54> Yeah, that commit
[16:44] <hatch> ok cool - in the future can you use a real commit message :)
[16:44] <hatch> review looks good, qa'ing
[16:55] <hatch> kadams54 try a make clean and clean your cache (re huw's branch)
[16:56] <kadams54> hatch: yeah, I did both, still seeing the funky button.
[16:56] <hatch> hmm odd alright then
[16:57] <hatch> kadams54 adding a container without selecting a machine is kind of odd heh
[16:57] <hatch> because it creates a machine
[16:58] <kadams54> Yes. There's a lot of funkiness around MV in general.
[16:58] <kadams54> If you stick to the happy path, everything is all rainbows and unicorns
[16:59] <kadams54> Stray off and the world goes sideways.
[17:01] <hatch> ok one more small qa issue
[17:01] <hatch> one of these days I'll get all of you to stop using anchor tags :D
[17:01] <kadams54> Ah ha ha ha ha
[17:07] <kadams54> hatch: I'm puzzled about why that's happening for "Add container", but not "Add machine" - they both have the same handler function which does preventDefault().
[17:07] <kadams54> Giving span a try…
[17:07] <hatch> it happens for both for me
[17:08] <kadams54> What about on http://comingsoon.jujucharms.com/?
[17:08] <hatch> kadams54 it might need an e.halt()
[17:08] <hatch> basically anchors are stupid
[17:08] <hatch> and I'm not goign to change my mind on that :D
[17:08] <kadams54> Pffft, no way!
[17:09] <hatch> lol
[17:09] <kadams54> Jeff would totally call that out in review.
[17:09] <kadams54> ;-)
[17:09] <hatch> haha
[17:09] <kadams54> Oh good gravy
[17:09] <hatch> really though - anchors in a webapp are only useful if you're taking advantage of pjax
[17:09] <hatch> which we aren't
[17:09] <kadams54> spans don't have the right styling.
[17:09] <hatch> lol
[17:10] <hatch> this branch just won't die
[17:10] <hatch> kadams54 try using e.halt() instead of e.preventDefault()
[17:11] <hatch> jcsackett where did you use to get those shirts made up from the sprint?
[17:12] <kadams54> hatch: OK, that worked - change pushed.
[17:13] <hatch> even I'm getting sick of QA'ing this branch lol
[17:13] <hatch> you must be right pissed
[17:13] <hatch> haha
[17:14] <kadams54> I'm ready to be done, for sures
[17:15] <kadams54> Though I have a long list of stuff to turn into bugs and cards, so even after this one lands, it will live on.
[17:15] <kadams54> And that's aside from questions to send to design.
[17:17] <hatch> qa ok;d
[17:17] <hatch> land that!
[17:18] <hatch> kadams54 you'll probably want to move your branch-start card back and then create smaller cards from it
[17:18] <kadams54> Hmm… you're talking about the deleting machines/containers one?
[17:18] <hatch> yeah
[17:18] <hatch> there is a lot of work there
[17:19] <hatch> probably more than 4 days
[17:19] <hatch> judging by how long it took me to do the relations one heh
[17:19] <kadams54> OK. I already created a separate card for ghosted stuff.
[17:19] <rick_h_> hatch: kadams54 sorry, just catching the conversation drive by
[17:19] <rick_h_> hatch: kadams54 we do need to chat and plan out a path?
[17:19] <hatch> we does
[17:19] <kadams54> Sounds like it
[17:19] <rick_h_> standup linky?
[17:19]  * rogpeppe is done for the day
[17:19] <hatch> lata rogpeppe
[17:19] <rick_h_> rogpeppe: have a good evening
[17:20] <hatch> rick_h_ sure
[17:20] <rogpeppe> rick_h_: see ya tomorrow
[17:20] <rogpeppe> hatch: likewise
[17:20] <rogpeppe> g'night all
[17:44] <jcsackett> hatch: teespring.
[17:44] <jcsackett> hatch: was going to build another one for the last sprint, but alas the required minimum went up.
[18:04] <hatch> booo!
[18:04] <hatch> well this sprint there will be more people
[18:04] <hatch> hopefully I'll say something stupid again
[18:04] <hatch> er....
[18:05] <rick_h_> man, hatch you're making it too easy
[18:05] <hatch> lol
[18:05] <rick_h_> "it's not a matter of if...only a matter of when, and I want to buy the square for day #1"
[18:10] <hatch> haha
[18:12] <bac> rick_h_: in jenkins CI what is the authentication token?  do we just use the same one for all projects?
[18:13] <rick_h_> bac: each project can define one, I've just used the same one I think on the two projects
[18:13] <rick_h_> bac: but feel free to set a custom one for the store
[18:14] <bac> rick_h_: i don't understand what it is
[18:14] <bac> just a string?
[18:14] <rick_h_> bac: yea, just a private string
[18:14] <bac> pertaining to nothing?
[18:14] <bac> what is the point?
[18:15] <rick_h_> bac: in order to trigger a build via a url call (poor man's api) you can use the token to limit who can trigger a build
[18:15] <rick_h_> bac: it's like a shared secret kind of auth or poor man's api token
[18:15]  * bac feels safer
[18:15] <rick_h_> bac: actually not sure if the lander supports a key per project. :/
[18:15]  * rick_h_ checks code
[18:16] <rick_h_> bac: so it might need to be the same for the moment
[18:16] <bac> rick_h_: doesn't matter, i'll just use the same one
[18:16] <rick_h_> bac: ok cool
[18:18] <bac> rick_h_: and for each jenkins test run do i get a new "machine"?
[18:20] <rick_h_> bac: no
[18:20] <rick_h_> bac: not currently, we've not had to. That's something we might have to think about. I know the juju ci does create slave machines to test on
[18:20] <rick_h_> bac: I'd suggets we work with them on that side so that they can bring up machines across platforms, but we have a more simple sanity check for work.
[18:20] <bac> rick_h_: ugh, i just edited the juju-github-lander test script when i thought i was editing charmstore's.
[18:21] <bac> rick_h_: anyway to revert?
[18:21] <rick_h_> bac: no, there's a backup script that runs but not a good way to revert as the ini file isn't part of the lander's github project
[18:21] <bac> dang
[18:22] <rick_h_> bac: oh you mean in the build steps in the jenkins UI?
[18:22] <bac> rick_h_: yeah
[18:22] <rick_h_> bac: yea, no good way to restore without pita backup xml fun
[18:22] <bac> i replaced 'make test, blah blah' with the steps for charmstore
[18:22] <rick_h_> we have a full backup for doing a full restore but not easy to get 'this field'
[18:23] <bac> rick_h_: ok, i'll look at the makefile and see if i can figure it out
[18:23] <rick_h_> bac: hmm, yea it should be close to the other job
[18:23] <rick_h_> bac: which job did you edit?
[18:23] <bac> jenkins-github-lander
[18:24] <bac> http://ci.jujugui.org:8080/job/jenkins-github-lander/configure
[18:24] <rick_h_> bac: ah ok, I'll update
[18:25] <bac> make testdeps; make lint; make test
[18:25] <bac> ??
[18:25] <rick_h_> bac: updated, copied from the -merge version of the job
[18:25] <bac> oh cool
[18:25] <rick_h_> just removed the landing stage
[18:25] <rick_h_> having two jobs is a bonus sometimes :)
[18:35] <bac> rick_h_: for jenkins we specify the sha1 of the commit to test.  is that the sha of the branch that has been proposed? e.g. https://github.com/bac/charmstore/commit/7d8c2efae2517c3d1e01d8f686223d3a9ad1420c
[18:35] <bac> rick_h_: if it gets that sha at the end of the url, but doesn't know about the specific user, it can fetch it from github?
[18:36] <rick_h_> bac: yes, git watches the list of branches in the pr namespace and knows how to check out each commit sha
[18:36] <rick_h_> bac: so you can give it any commit in any pr and it'll checkout/test that sha
[18:36] <bac> nice
[18:36] <rick_h_> normally it just gets the latest sha in the pr
[18:42] <hatch> kadams54 did you review/qa my branch yet?
[18:42] <kadams54> In progress right now.
[18:43] <hatch> cool thx, i'm gona go grab some lunch
[19:31] <hatch> mmm check this out! http://www.withings.com/activite/en-US me wants
[19:33] <hatch> well except that it doesn't work with android
[19:33] <rick_h_> so I just watched a video and don't know anything more than when I started
[19:34] <hatch> rofl
[19:34] <hatch> I thought the same thing haha
[19:34] <rick_h_> it's a pretty fitbit?
[19:34] <hatch> yep
[19:34] <rick_h_> pass, I <3 my pebble steel
[19:34] <hatch> basically by the time it's released I will have forgotten about it
[19:34] <hatch> oh well
[19:34] <hatch> I want the Google watch
[19:34] <rick_h_> got a new awesome watch face that is nice and clean
[19:34] <hatch> that thing is darn cool
[19:35] <rick_h_> heh, that one will be tough. I'll be darn tempted to get my google now on my wrist
[19:35] <rick_h_> but I think that'll definitely a gen2 switch over
[19:35] <hatch> I'm kind of hoping they release it tomorrow, I'll be staring at my screen with my cc in hand waiting during the keynote
[19:35] <rick_h_> heh, I was glad I had no calls at noon
[19:35] <rick_h_> you can be sure the chromecasts in the house will be watching the keynote
[19:36] <hatch> of course it won't be available in Canada...so I'll have to have you buy it for me
[19:36] <hatch> lol
[19:36] <rick_h_> works for me
[19:36] <rick_h_> when two of them show up I'll just tell the wife I was getting it for you
[19:36] <rick_h_> and hide the other one :)
[19:36] <hatch> hahaha
[19:37] <hatch> there was a watch face competition for that watch....
[19:37] <hatch> I +1'd a couple....now where do they keep these +1's
[19:37] <hatch> hmm empty...
[19:37] <hatch> that's not right
[19:41] <hatch> https://plus.google.com/photos/+Motorola/albums/6025927350868561553
[19:42] <hatch> it's kind of too bad pebble didn't go colour and round :)
[19:45] <bac> rick_h_: ugh, our jenkins is precise but charmstore is not very precise-happy
[19:45] <hatch> time to switch back to warty
[19:46] <hatch> hmm that's an interesting failure in ci
[19:47] <rick_h_> bac: ok, well we can deploy a new jenkins server on trusty.
[19:48] <bac> rick_h_: man that would make life easier
[19:48] <rick_h_> bac: or we look at using jenkins/jenkins-slave to run the tests on a slave related machine
[19:48] <bac> trusty! trusty!
[19:48] <hatch> wait for my merge to land plz :)
[19:48] <rick_h_> bac: yea, I first thought we could move all of ci to trusty, but jujucharms and prodstack is still precise
[19:48] <bac> rick_h_: here's what i've got so far: http://ci.jujugui.org:8080/job/charmstore/configure
[19:48] <rick_h_> bac: so we'd need to get our prodstack envs moved as well
[19:49] <bac> rick_h_: the go-ness of it makes it kind of messy
[19:49] <rick_h_> bac: want to peek at the jenkins slave charm and see if we can more easily tie that in?
[19:49]  * rick_h_ is looking
[19:50] <bac> rick_h_: going to trusty would give me a modern version of go too.
[19:50] <rick_h_> bac: right
[19:50] <rick_h_> bac: but if we setup the slave machine, we have one place to view the results reports
[19:50] <rick_h_> but run the tests on another machine that can be the go-centric place and can be trusty easily without effecting current stuff
[19:50] <bac> we do or we don't?
[19:50] <bac> why the but?
[19:51]  * bac brb
[19:51] <rick_h_> bac: sorry, mixed stuff in there
[19:52] <rick_h_> bac: the CI config looks good. The tmp stuff reminds me of the lbox clean directory stuff from GUI heh.
[19:53] <rick_h_> hatch: build fail
[19:53] <hatch> yeah I re-triggered it
[19:53] <rick_h_> bac: hmm, no trusty jenkins-slave charm :( I would think that we could try to fork/push that.
[19:53] <hatch> not sure what the old issue was, but hopefully this one will work just fine
[19:57] <hatch> looks like it's running now
[19:57] <hatch> *crosses fingers*
[20:01] <bac> rick_h_: oh, i guess i should blow away that tmp dir
[20:01]  * bac wonders how long before i rewrite it all in python
[20:02] <rick_h_> bac: yea, wish sinzui and them weren't so under water and could chat/participate.
[20:02] <bac> rick_h_: i talked to sinzui earlier
[20:02] <bac> he gave me some references but they aren't doing anything exactly like this
[20:03]  * rick_h_ goes to check logs, assumed they'd have to do all the tests on precise/trusty and such across platforms
[20:03] <rick_h_> bac: ok, what do you think of the path forward of updating the jenkins-slave charm for trusty, get it deployed and wired up to ci.jujugui.org, and then moving the test runs of the store to there?
[20:04] <bac> rick_h_: it was all pm'd
[20:04] <rick_h_> bac: ah, ok nvm then
[20:04] <bac> rick_h_: https://pastebin.canonical.com/112297/
[20:06] <rick_h_> bac: interesting
[20:09] <bac> rick_h_: what has to be done to that charm? i don't see anything precise-specific in it
[20:09] <rick_h_> bac: ok, well I've got two worries. One that precise not working is a problem we'll need to solve. But I think that can wait until after we get stuff working
[20:09] <rick_h_> bac: I think the only thing we'll have to do is to fork it and push it up under the precise/ namespace
[20:10] <bac> rick_h_: the issue with precise are 1) old go that needs work-arounds, 2) no juju-mongo package backported.
[20:10] <rick_h_> bac: so I'd start by testing it out by just pulling it down and publishing it under either yourself or our juju-gui space we use for our own charm.
[20:10] <bac> ok
[20:11] <rick_h_> sorry ~juju-gui-charmers is the shared one
[21:25] <bac> jujugui: anyone have problems deploying local charms unless you specify --repository?  http://paste.ubuntu.com/7697163/
[21:26] <hatch> bac yes that is required
[21:26] <bac> hatch: well, it looked liked it guessed properly but didn't really since it appened /trusty
[21:26] <kadams54> bac: True confession: I've only ever deployed a local charm (the ghost one) via the GUI.
[21:27] <hatch> bac yea i haven't ever got that to work heh
[21:27] <bac> yeah, it doesn't come up often
[21:29] <hatch> bac what if you were in ~/charms and then did `juju deploy local:trusty/jenkins-slave` ?
[21:29] <bac> hatch: i think that would work
[21:35] <hatch__> bac it would be nice if we could go `juju deploy .`
[21:44] <Makyo> Two failures \o/
[21:44] <hatch> Makyo are you around?
[21:44] <hatch> oh hah
[21:44] <hatch> :)
[21:44] <Makyo> Yep
[21:45] <hatch> \o/ for failures
[21:45] <hatch> so my question :)
[21:45] <hatch> when we create a relation between two ghost services the information which is in the changeset is the service names not a reference to their models
[21:45] <hatch> so if the user changes the service name (it's not yet been deployed)
[21:45] <hatch> then the relation fails
[21:46] <Makyo> Hmmm.  Seems like an easy enough change.  I know we crammed that in last minute.
[21:46] <Makyo> "Easy enough" in the heaviest sarcasm quotes I can muster.
[21:46] <hatch> lol
[21:46] <hatch> sooooo I was thinking we should instead add an extra id to the models
[21:47] <hatch> and we use those id's for reference for the ecs stuff
[21:47] <hatch> then the models can change under it and it doesn't matter
[21:47] <Makyo> hatch, don't we already have those?  The 120947$ ids?
[21:47] <Makyo> Those don't change.
[21:47] <hatch> right, but I'm pretty sure those go away once it's been deployed....no?
[21:48] <hatch> I'll investigate further....but you don't see any issue with using the ghost id's then resolving them wherever they need to be resolved?
[21:48] <hatch> there are a few places where we rely on the id to display the information
[21:48] <Makyo> Well, sure, but once they're deployed, we already have a mechanism for replacing that info in future ECS records, right?
[21:48] <Makyo> YEah.
[21:49] <hatch> yeah ok cool
[21:49] <hatch> good thing we are agile haha, I'm not sure how anyone would have created a spec for this stuff :)
[21:51] <hatch> kadams54 hey, do you know why halt() worked this morning when preventDefault() didn't? I realized I told you to use it but didn't say why...
[21:53] <kadams54> hatch: I suspect it's because the click event is bubbling up?
[21:53] <hatch> yeah, halt calls preventDefault and stopImmediatePropagation so it stops it bubbling....this has caused us issues in the past when listening on containers for events so we try and use it sparingly
[21:54] <kadams54> Though I'm pretty annoyed right now… the merge CI build is failing on an IE error that is happening in a section of code (test_inspector_charm.js) that doesn't seem very related to anything I changed.
[21:55] <kadams54> Something in the "closes itself safely" test is causing hash URL pollution, which means test_cleanup.js fails at the very end.
[21:57] <hatch> ahh, check that there isn't an ANCHOR tag, being clicked without a preventDefault
[21:57] <hatch> :P
[21:57] <kadams54> :-)
[21:57] <kadams54> Believe me, I'm looking for that like a hawk
[21:58] <kadams54> But there's no click simulates in the test in question, so no easy suspects
[21:58] <hatch> well....if you have a few commits can you revert them back and see which introduces the issue?
[22:06] <kadams54> Haven't tried that yet, but the problem seems to be here: https://github.com/juju/juju-gui/blob/develop/app/views/viewlets/charm-details.js#L90
[22:07] <hatch> looking
[22:07] <kadams54> IE 10 interprets that line as "set the hash to '#'"
[22:07] <kadams54> Though I'm not sure why that would start failing right now
[22:07] <hatch> that line has been there for a while
[22:07] <hatch> yeah...
[22:07] <hatch> what r u working on?
[22:08] <hatch> or I suppose, do you have the code up somewhere
[22:08] <kadams54> Hah!
[22:08] <kadams54> You KNOW what I'm working on
[22:08] <kadams54> It's the same PR I've been working on!
[22:09] <kadams54> I can't land it because of this IE test failure.
[22:09] <kadams54> Need to get dinner now, but may bisect tonight
[22:10] <hatch> oh.....the same one?
[22:10] <hatch> that's the one that won't work
[22:10] <hatch> wth
[22:11] <hatch> yeah take a break :)
[22:12] <kadams54> Hmm…
[22:14] <kadams54> I'm pretty sure we do this to reset any tab info that might have been stored in the hash
[22:15] <kadams54> But the reality is that there doesn't appear to be a good cross-browser way to remove the hash.
[22:15] <kadams54> Still very puzzled as to why this would break now, and why it only breaks in IE. I get manually duplicate the same behavior in Chrome when I set window.location.hash in the console.
[22:15] <kadams54> But dinner calls.
[23:07] <huwshimi> Morning
[23:18] <jcsackett> morning, huwshimi.
[23:18] <huwshimi> jcsackett: Hey!
[23:19] <jcsackett> heya, how have you been?
[23:20] <huwshimi> jcsackett: Good thanks. Yourself?
[23:21] <jcsackett> i've been good. busy, but good. :)
[23:21] <huwshimi> :)
[23:56] <rick_h_> morning huwshimi
[23:56] <huwshimi> rick_h_: Hey


[00:02] <darkxst> c_smith, I see about 5 facebook doesnt work bugs on launchpad!
[00:31] <c_smith> ah, might have to mark mine as a duplicate
[01:10] <bjsnider> c_smith, is empathy supposed to connect to facebook?
[01:20] <darkxst> jbicha, right I can reproduce the white background, but gee you have to be quick!
[01:21] <darkxst> atleast here, I have to lock the screen before the background dialog disappears
[01:21] <jbicha> I used ctrl+alt+l
[01:23] <jbicha> I can do the g-c-c update if you push a new g-c-c and g-s-d to your gsd38 ppa so that seb128 or whoever can test without having to build from source
[01:23] <jbicha> otherwise, I'll just wait for the g-s-d update to be approved
[01:48] <darkxst> jbicha, yes, but I only get about 1 sec to hit ctl+alt+L
[01:48] <darkxst> if that even
[01:48] <darkxst> sure I will push updates to ppa
[01:59] <jbicha> ok, I uploaded g-c-c to Ubuntu and pushed rev. 417 to g-s-d in the gnome3 bzr branch with one more update
[02:10] <c_smith> bjsnider, I believe it is, since it's a supported protocol (in 2 ways, one is a FB only way, the other is XMPP)
[02:20] <c_smith> looks like with Jabber for FB, I just get a network error.
[02:57] <bjsnider> is fb a chat network? obviously i know nothing about it
[02:57] <bjsnider> i thought it was just blogging and stuff
[03:01] <Zoiaguyver> FB has an XMPP server for instant messaging
[03:09] <darkxst> jbicha, rebased g-c-c and uploaded current g-s-d
[03:10] <c_smith> bjsnider, it's part of Facebook,
[03:10] <c_smith> in fact, FB = Facebook
[14:11] <Munchor> Hi, is it really a daily build if the last .iso is from September 3rd? http://cdimage.ubuntu.com/ubuntu-gnome/daily-live/current/ Am I looking in the wrong place?
[14:12] <jbicha> Munchor: thanks, we're fixing that now
[14:13] <jbicha> daily builds were disabled last week for the beta
[14:13] <jbicha> but they'll be turned back on now
[14:21] <Munchor> Beta release is like today or tomorrow then might I assume?
[14:27] <jbicha> Beta 1 was released last Thursday
[14:27] <Munchor> http://ubuntugnome.org/
[14:27] <Munchor> No announcement?
[14:33] <jbicha> there was https://lists.ubuntu.com/archives/ubuntu-gnome/2013-September/000615.html
[14:33] <jbicha> and we updated the topic of this irc channel
[14:34] <Munchor> great thanks
[15:19] <jbicha> darkxst: could you look into https://bugzilla.gnome.org/707769 seb128 will be unhappy until it gets fixed :|
[15:46] <davidbrooke> what is the easiest way to remove the user name from the top panel...using 13.10 beta?
[15:48] <ricotz> davidbrooke, "gsettings set org.gnome.desktop.privacy show-full-name-in-top-bar false"
[15:49] <davidbrooke> ty but how do I get to gsettings?
[15:50] <ricotz> ah and there is another one "gsettings set org.gnome.desktop.privacy hide-identity true"
[15:51] <ricotz> "gsettings ... " is a terminal command
[16:04] <jbicha> or you can use dconf-editor
[16:12] <davidbrooke> jbicha, ty I just completed it that way
[16:16] <davidbrooke> another question...
[16:18] <davidbrooke> I use mythtv....and a remote control....in 13.10 the remote control gets mapped as a keyboard and I don't want it as a keyboard....I want to use it via lirc but that is being overriden ....any ideas that will stop the remote control from being a keyboard?
[20:30] <darkxst> jbicha, thats not really an upstream bug, we added that feature
[21:26] <jbicha> we added the ubuntu-lock-on-suspend key but I think this is different
[21:31] <darkxst> jbicha, its the lid close action stuff added in ubuntu-lid-close-suspend.patch
[21:32] <darkxst> we take an inhibitor on lid switch
[21:40] <darkxst> jbicha, does the lid close sound play when lid action is set to None?
[21:40] <jbicha> you mean it's debian/patches/ubuntu-lid-close-suspend.patch that's the problem?
[21:40] <jbicha> there's a lid close sound?
[21:41] <jbicha> pulseaudio has been mostly broken for me with saucy (maybe a kernel bug) - sound will only work for a few minutes
[21:44] <darkxst> if do_lid_closed_action() gets called then there should be a sound
[21:46] <jbicha> you'll have to ask someone else as I don't feel like rebooting to get only 5 minutes of working audio :(
[21:51] <darkxst> jbicha, can you attach with gdb and set a break point?
[21:52] <jbicha> attach gdb to what?
[21:52] <jbicha> I've never learned how to use gdb
[21:53] <darkxst> gnome-settings-daemon
[21:54] <jbicha> can you give me step-by-step how to do that?
[21:56] <darkxst> first install gnome-settings-daemon dbg packages
[21:56] <darkxst> then
[21:56] <darkxst> sudo gdb --pid=$(pidof gnome-settings-daemon)
[21:56] <darkxst> b do_lid_closed_action()
[21:56] <darkxst> c
[21:57] <darkxst> then just close lid and see if gdb breaks on that function
[22:05] <jbicha> http://paste.ubuntu.com/6085396/
[22:07] <darkxst> Y
[22:10] <jbicha> http://paste.ubuntu.com/6085413/
[22:13] <darkxst> ok so it didnt break when you closed lid?
[22:15] <jbicha> uh I guess not, I just pasted all of what gdb output
[22:15] <jbicha> I only installed the g-s-d and glib dbgsym's
[22:16] <jbicha> here's the full output: http://paste.ubuntu.com/6085437/
[22:19] <darkxst> yeh, my guess is that do_lid_closed_action() not getting called due to the lid switch inhibitor
[22:38] <snwh> okay. who chose the waterdrop? :P
[22:42] <jbicha> snwh: you like it, right? ;)
[22:43] <snwh> I've been on Ubuntu GNOME for a few hours now
[22:43] <snwh> and I hate the waterdrop. ;)
[22:46] <jbicha> give it a few more hours :)
[22:47] <jbicha> darkxst: any idea why this doesn't do anything?
[22:47] <jbicha> gnome-session-inhibit --inhibit suspend --inhibit-only
[22:48] <jbicha> my computer still suspends when I close the lid with that running (I've rebuilt g-s-d locally without the lidclose patch)
[22:57] <darkxst> not sure but they are not the same as the logind inhibitors
[22:57] <snwh> jbicha, in a few more hours I'll have replaced it ;)
[22:59] <darkxst> snwh, sure, you are free to choose your own background if you don't like the default FootFall background
[23:00] <snwh> darkxst, I'm talking about the default system alert noise. I obviously know I can change the wallpaper :P
[23:00] <darkxst> oh
[23:04] <jbicha> oh
[23:05] <jbicha> we're so used to that by now
[23:06] <snwh> is the wallpaper also a waterdrop?
[23:10] <darkxst> wallpaper kind of looks like waterdrops!
[23:10] <jbicha> yes for 13.10
[23:13]  * snwh just installed over saucy in the / partition so his wallpaper was preserved in /home and he never seen the default
[23:18] <jbicha> the gray gnome foot is the default now
[23:21] <darkxst> jbicha, oops I gave you the wrong command ;) should have been 'b do_lid_closed_action'
[23:21] <darkxst> anyway I think I have fixed it now
[23:39] <darkxst> jbicha, http://paste.ubuntu.com/6085669/
[23:41] <darkxst> snwh, http://goo.gl/UMQ4ie
[23:43] <bjsnider> gray gnome foot is a big change over the blue vertical stripes and whatnot
[23:43] <bjsnider> or maybe that was just fedora's default choice
[23:43] <darkxst> stripes are on the lockscreen still
[23:44] <darkxst> I have no idea what fedora use as default
[23:52] <jbicha> darkxst: cool, that works


[23:11] <philipeschmulian> please help: i've got no sound! i installed ubuntu last week and everything worked fine... i started installing programs and stuff, everything still worked fine. then, yesterday, i turned my pc on and there has been no sound since! ubuntu still recognizes my sound card, and whenever i play music/videos/etc, it's like as if it was playing normally, but i get no sound! i've checked volume control and its NOT on mute, and its not my speakers either
[23:12] <niko> philipeschmulian: support channel is #ubuntu


[01:07] <Adys> my cursor seems to be disappearing regularly since a couple of days, any idea why? (using kdm+nouveau)
[01:08] <Adys> it still works, its just invisible
[02:06] <FloridaGuy> trying to go from 10.10 to 11.04....update-manager -d is screwed up are something.....type in my root password..keeps saying..invaild password
[02:07] <tzanger> ubuntu doesn't have a root password
[02:07] <FloridaGuy> root...sudo password..samething
[02:08] <FloridaGuy> root access
[02:08] <FloridaGuy> type in my password...update-manager -d...says invaild password
[02:08] <tzanger> hmm
[02:08] <tzanger> that is definitely unusual
[02:09] <FloridaGuy> i know..everything eles takes it
[02:10] <FloridaGuy> wasent there another way from cli that upgrades
[02:11] <FloridaGuy> i know there is update-manager -d...and something eles
[02:12] <rww> do-release-upgrade -d
[02:17] <FloridaGuy> do-release-upgrade -d works....update-manager-d dont...
[06:45] <alkisg> Hi, I tried dual booting Natty (with Evolution 2.32.2) and Lucid (with Evolution 2.28) with using my existing /home/alkisg
[06:45] <alkisg> Now I can see my emails on Natty, but not on Lucid.
[06:45] <alkisg> Has there been any file format change to Evolution? If so, how can I revert it?
[06:51] <susundberg> You might want to look at evolution changelog
[06:52] <susundberg> https://launchpad.net/ubuntu/+source/evolution/+changelog
[06:54] <alkisg> Hmm that's the Ubuntu package changelog, maybe I should be looking the Evolution source changelog instead
[06:55] <alkisg> But if there's been such an incompatible format change, a warning (like it happended in 2.24) would be required...
[06:55] <susundberg> That shounds fair..
[06:56] <susundberg> Have you checked if console or .xsession-errors gets any funny prints?
[06:56] <alkisg> Yup, and no, nothing in console
[06:56] <susundberg> (and i assume you can access the mails with say 'cat' -- that is permissions are ok)
[06:56] <susundberg> check
[06:57] <alkisg> I'm using the same UID/GID and /home/alkisg in both Natty and Lucid
[06:57] <alkisg> So apart from the permissions, evolution even uses the same settings...
[06:59] <susundberg> Mayby you could install backport (testing version) to Lucid ?
[06:59] <susundberg> (Or yes, downgrade natty might be better idea)
[06:59] <alkisg> Is evolution 2.32 available in lucid-backports?
[07:00] <alkisg> I'd downgrade if I could see my mails... :D
[07:00] <alkisg> But I can't, with evolution 2.28...
[07:00] <susundberg> Ah yeah
[07:00] <susundberg> since that didnt see the mails
[07:00] <susundberg> sorry :)
[07:00] <susundberg> did you find anything from the changelog?
[07:00] <alkisg> Nah np. /me looks for the changelog...
[07:14] <alkisg> Ah. Running evolution 2.32 from the console, I do see some attempts to "migrate config data"
[07:15] <alkisg> Now if I could find how to undo that silent, world-breaking migration...
[07:19] <susundberg> ;)
[08:10] <zniavre_> good morning
[08:11] <zniavre_> does unity-2d is the "same" than unity (regular) ?
[08:21] <delt> uh... hello
[08:23] <delt> was pointed here by #ubuntu about this live-disc image ....... http://cdimage.ubuntu.com/kubuntu/daily-live/current/natty-desktop-i386.iso
[08:23] <delt> 03:25 < ubottu> Natty Narwhal is the codename for Ubuntu 11.04, due April 28 2011 - Help and support (only) in #ubuntu+1 - Natty is unstable and is not intended for production systems.
[08:23] <delt> 03:26 < delt> oh thanks, NOW i know that.
[08:23] <delt> nm *sigh*
[08:28] <alkisg> Can I somehow prevent evolution from trying to move my ~/.evolution to ~/.config/evolution and to ~/.local/share/evolution?
[08:28] <alkisg> It breaks my Lucid / Natty dual boot...
[09:17] <twager> !nvidea
[09:19] <susundberg> !nvidia
[09:19] <susundberg> ?
[09:20] <twager> susundberg, Thanks...Poor spelling :-(
[09:20] <susundberg> ;)
[14:02] <manlymatt83> Hi folks.  While I realize 11.04 is unstable, what are people's experiences with it lately regarding stability?
[14:04] <rork> I'm using the kubuntu version with an ATI card, recently installed the alpha2. Couldn't install ATI drivers. I updated the day before yesterday and X broke, haven't looked into it yet.
[14:11] <bcurtiswx> im moving my .ssh and .gnupg folders to my natty partition and now when I try to bzr get it gives me a publickey error.. what am i doing wrong?
[15:15] <wmcinnis> hi
[15:51] <Pici> The problem with gnome-terminal being unresponsive that I talked about here the other day seems to be unrelated to g-t.  So, feel free to forget I mentioned it.
[16:28] <mphill> is anyone having issues with natty/compiz crashing, focus issues, unable to left click, etc?
[18:32] <zzillezz> hmm, i'm trying to install alpha2 from live session and I get an error from the installer telling my i don't have enough free space on my hard drive ...
[18:33] <zzillezz> when i do have enough space
[18:34] <charlie-tca> you need 4-6 GB
[18:34] <zzillezz> i have 190+ gb free on one partition (ext4) and 800+ gb free on another one
[18:35] <zzillezz> it's the second time i'm installing kubuntu 11.04 alpha2, on the same pc, and the first time went ok
[18:35] <charlie-tca> reboot and start over. Sometimes the thing mounts the drives and then won't use them
[18:36] <zzillezz> well, it went ok until i started messing with the graphics drivers :-)
[18:36] <charlie-tca> why would you mess with them on the live cd?
[18:37] <charlie-tca> it don't really like that... :-)
[18:37] <zzillezz> i didn't mess with them on the live cd, but when i first installed alpha2
[18:37] <zzillezz> alright, rebooting now, thanks for your help charlie-tca
[19:00] <zzillezz> alright, install worked :-)
[20:07] <Louis-DK_> Hi. I'm trying to upgrade an Ubuntu 11.04 using "sudo apt-get upgrade" Do you want to continue [Y/n]?  Extracting templates from packages: 100% Preconfiguring packages ... warning, in file '/var/lib/dpkg/available' near line 15183 package 'ibus-pinyin-db-open-phrase':  error in Version string '1/lib/modules/2.6.38-2-generic/kernel/drivers/scsi/scsi_transport_fc.ko': invalid character in version number warning, in file '/var/lib/d
[20:19] <Pici> Louis-DK_: This is an existing 11.04 install, or are you upgrading to 11.04 from a prior release?
[20:23] <Louis-DK_> Pici: It is an existing 11.04 install, but it's fixed. Renamed /var/lib/dpkg/available-old to available
[21:48] <zonkers> when 11.04 is released, do you think there will be a gnome shell 2.3 for it?
[22:04] <carl0s-> Right, I know this new X.org stack is the cause of some issues, but is that the cause of the weird stuff that's been going on with my x64 igfx based thing for a few weeks now? It's pretty much unusable. It's like a window that should appear doesn't actually appear, but the window that I *can* see, which is usually my browser, or Ooo, well that's unresponsive to my mouse input in the top left quarter of the screen, and I t
[22:04] <carl0s-> hink it's because of this 'ghost' window that hasn't actually visibly appeared. Is this known? I'm about to give up and load up x86 10.10 (I've had enough of npviewer.bin crashes so x86 will do I think).
[22:20] <carl0s-> nice one, cheers
[22:25] <Adys> got some issue here since today's upgrade on kubuntu. Desktop is completely empty - I can't see open apps / windows / panels or anything, even if they're active. I killed kwin and now i can, but even using other window managers i get the same issue
[22:25] <m3ga> i'm running natty in a chroot under debian and i getting upgrade failures due to upstart. if i'm installing in a chroot, why do i need upstart? also can't remove upstart because that removes just about everything.
[22:38] <Adys> okay, rm ~/.kde/share/config/plasm* fixed it
[23:10] <lamalex> does anyone know where I can find previous version of debs?
[23:10] <lamalex> i need to downgrade X
[23:11] <lamalex> (i know a huge pita)
[23:22] <gpc> lamalex: you may still have them in /cache/apt/archives
[23:22] <lamalex> gpc, i do not :(
[23:23] <lamalex> i dont know where they went
[23:23] <lamalex> but they're not there


[07:22] <tjaalton> RAOF: are there pending saucy backport uploads from mlankhorst still in NEW?
[07:38] <RAOF> tjaalton: In the precise NEW queue?
[07:38] <RAOF> I don't think so (there are some from tseliot, though)
[07:38] <tjaalton> hm ok
[07:38] <tjaalton> oem is expecting to get them there soon
[07:39] <tjaalton> i thought they were uploaded already
[07:39] <RAOF> I'll accept them once I've processed qt4-x11
[07:39] <RAOF> They're now in binary NEW.
[07:40] <tjaalton> right both are needed, backports and new nvidia stuff
[07:40] <RAOF> mlankhorst: Oh, by the way - why is there a bunch of undocumented maintainer-script changes in unity-2d?
[07:40] <tjaalton> maybe we'll get the rest uploaded today so you could process them tomorrow-ish :)
[07:43] <RAOF> mlankhorst: Bah. qt4-x11 has been superceded by a security update.
[07:45] <RAOF> There we go. All the prime stuff should be done now.
[09:18] <mlankhorst> RAOF: no idea, did I change it?
[09:18] <mlankhorst> @ qt4-x11 yeah I saw, needs a new fix
[09:18] <RAOF> mlankhorst: Well, it's in the debdiff, so you've clearly changed it over what's in precise.
[09:21] <mlankhorst> odd
[09:23] <mlankhorst> oh 0,0 files
[09:24] <mlankhorst> looks like it was because I built from source and the debclean didn't clean it up
[09:26] <mlankhorst> feel free to reject then
[09:27] <RAOF> Done.
[09:31] <tjaalton> mlankhorst: can the rest of the stack move now?
[09:32] <tjaalton> after these i mean
[09:32] <mlankhorst> win a bit
[09:32] <mlankhorst> I have a xorg-server saucy sru/mre to confirm first
[09:37] <tjaalton> ok
[09:47] <mlankhorst> tjaalton: can you sponsor qt4-x11 and unity-2d from https://mblankhorst.nl/etc
[09:51] <tjaalton> done
[09:54] <mlankhorst> RAOF: fixed :)
[13:28] <mlankhorst> yay my panda chroot crashes
[13:30] <tjaalton> so is the plan to get the xserver sru in saucy first and then the backports?
[13:30] <tjaalton> to precise
[13:31] <mlankhorst> yeah
[13:31] <mlankhorst> well at that point I can do a massive upload everything
[13:31] <tjaalton> thing is to get this all in before xmas though..
[13:32] <mlankhorst> better get verifying then!
[13:32] <tjaalton> I don't see anything in git
[13:32] <tjaalton> ubuntu-saucy branch is at 2:1.14.3-3ubuntu2
[13:32] <mlankhorst> there ya go
[13:32] <mlankhorst> pushed but it's trusty + a changelog entry, anyway
[13:32] <tjaalton> looks better :)
[13:33] <tjaalton> and it's uploaded to proposed?
[13:33] <mlankhorst> yeah
[13:33] <tjaalton> can't it be uploaded to precise now too?
[13:33] <tjaalton> might risk extra work though
[13:33] <mlankhorst> I'm waiting for someone to accept qt4-x11 and unity-2d
[13:33] <mlankhorst> at that point I can upload everything
[13:34] <tjaalton> ah, right
[13:34] <tjaalton> I'll poke the three bugs
[13:35] <mlankhorst> I'm poking llvmpipe some
[13:39] <tjaalton> kinda silly to file bugs for issues fixed in the point-release, since we have MRE in place..
[13:39] <tjaalton> :)
[13:39] <tjaalton> just waive it through
[13:40] <mlankhorst> erm except that some parts were fixed not in the mre
[13:42] <tjaalton> ah
[13:42] <tjaalton> in that case yes
[13:44] <mlankhorst> ah ah, wonder if this fix works..
[13:50] <mlankhorst> tjaalton: you can just start libreoffice
[13:50] <mlankhorst> and the crash bug is already fixed through pixman, I think
[13:50] <mlankhorst> this is just paranoia from my side
[13:54] <tjaalton> I don't want to crash my session :)
[13:54] <tjaalton> and the other machines are on trusty
[13:58] <jcristau> X :1 vt8?
[14:00] <tjaalton> right, I could crash my wife's session
[14:01] <mlankhorst> llvm is segfaulting somewhere
[14:03] <mlankhorst> ==12040==    at 0x83D8B28: (anonymous namespace)::ELFObjectWriter::WriteSymbolEntry(llvm::MCDataFragment*, llvm::MCDataFragment*, unsigned long long, unsigned char, unsigned long long, unsigned long long, unsigned char, unsigned int, bool) (in /usr/lib/arm-linux-gnueabihf/libLLVM-3.3.so.1)
[14:03] <mlankhorst> ==12040== Jump to the invalid address stated on the next line
[14:03] <mlankhorst> ==12040==    at 0xAC96AA2: ???
[14:03] <mlankhorst> ==12040==  Address 0xac96aa2 is 1,850 bytes inside a block of size 2,048 free'd
[14:03] <mlankhorst> ==12040==    at 0x482F7E4: operator delete(void*) (vg_replace_malloc.c:480)
[14:03] <mlankhorst> ==12040==    by 0x859FA51: (anonymous namespace)::LoopStrengthReduce::runOnLoop(llvm::Loop*, llvm::LPPassManager&) (in /usr/lib/arm-linux-gnueabihf/libLLVM-3.3.so.1)
[14:03] <mlankhorst> then it dies
[14:04] <tjaalton> k..
[14:19] <tjaalton> well I have the new pixman and it doesn't crash anymore
[14:20] <mlankhorst> yeah
[14:20] <mlankhorst> just grab old pixman
[14:21] <mlankhorst> still shouldn't crash :>
[14:29] <tjaalton> both are at stock versions, doesn't crash
[14:30] <tjaalton> another session running though if it matters
[14:32] <mlankhorst> hm fine I'll try myself
[14:39] <tjaalton> :)
[15:05] <mlankhorst> tjaalton: oh right, are you trying to reproduce on nvidia drivers?
[15:08] <tjaalton> no, intel
[15:14] <jcristau> intel's not really a good test case for exa
[15:14] <jcristau> oh but you tested the pixman bug too. hmm.
[15:24] <mlankhorst> *tries intel*
[15:28] <jcristau> i think i only tested xephyr and radeon actually
[15:29] <mlankhorst> that's more than me!


[12:30] <badserii> Hi! I have a question: what are minimal hardware resources to run Edubuntu stand-alone? I'm interested in CPU and RAM. Thank you!
[12:32] <Nubae> I'd say 256mb ram and 600mhz cpu for Intrepid+
[12:37] <badserii> Nubae: Thanks!
[12:43] <highvoltage> that's like very minimum too
[12:44] <highvoltage> don't expct to run openoffice and firefox with multiple flash pages at the same time :)
[14:54] <mistrynitesh> hello all, where do i link to bit-torrent file of latest edubuntu release?
[18:30] <Lns> http://ostatic.com/blog/linux-learning-and-little-kids
[18:40] <LaserJock> Lns: interesting, I wondering if the classmates really have Edubuntu on them or not
[20:48] <Lns> Anyone have any experience with installing/configuring a multi-user, "secure" wiki?
[20:48] <Lns> as in, users/groups have access to certain pages only
[20:49] <Lns> I'm trying to get something together that easily allows my techs and I to add information, and our clients to see THEIR info, but not other clients'.
[20:50] <Lns> Also, it must have a good file repository facility
[20:51] <LaserJock> would moin or mediawiki work?
[20:52] <alkisg> I think also a forum might fit your needs! :)
[20:54] <Lns> LaserJock: I've installed mediawiki, but it seems to not really incorporate easy user level access, etc
[20:54] <LaserJock> it's not horrible, but not easy no
[20:54] <Lns> alkisg: no, i need something that I can edit dynamically and have a "dashboard" of sorts for each client
[20:54] <LaserJock> you get to play around with PHP
[20:54] <LaserJock> moin at least is python
[20:54] <Lns> ianap :(
[20:55] <LaserJock> that hasn't stopped me much
[20:55] <alkisg> Lns, you can do both of them in a forum, the only thing you can't do is have history of edits...
[20:56] <alkisg> From my experience, it's easier for non-techs to handle...
[20:56] <Lns> alkisg: you're talking about a message forum?
[20:56] <alkisg> Yes, with some modules for attachments/file management
[20:57] <LaserJock> Lns: it might depend some on what you're really wanting to do with it
[20:58] <Lns> alkisg: i don't really see that as the best solution.. i need something that is easily searched for information, i.e. system passwords, info on the network, etc
[20:58] <Lns> having things like that in a message just doesn't seem like the best fit to me
[20:58] <alkisg> ...and wikis have better search facilities than forums?
[20:59] <Lns> imho wikis have a better overall layout for what i'm after
[21:01] <alkisg> I don't know about wikis so much, but I've worked enough with SMF, and I think it can do all the things you say... well, you know your needs best! :)
[21:01] <Lns> smf?
[21:01] <Lns> ah nm
[21:03] <Lns> alkisg: hmm, calendar support is nice...does it integrate with existing ical/webdav?
[21:03] <alkisg> Ah, don't know about that, we don't use a calendar!
[21:04] <Lns> i just implemented sunbird and webdav for shared calendars..as long as nobody uses outlook, it's a pretty slick solution!
[21:11] <Lns> how do you all manage passwords/confidential information while still keeping it easily available wherever you are?
[21:15] <LaserJock> Lns: I've used a wiki in the past
[21:15] <LaserJock> Lns: right now I just take my laptop with me wherever I am
[21:16] <Lns> LaserJock: what made you stop using a wiki?
[21:16] <LaserJock> maintaining it
[21:16] <LaserJock> I don't use it enough for personal use to really justify it


 The Lisp Badge Is a Self-Contained Computer Tailored to Lisp Programming … https://blog.hackster.io/the-lisp-badge-is-a-self-contained-computer-tailored-to-lisp-programming-43045a238dc3
 @RazPi
 @KMyers that is one sexy badge
 omg its on an atmega?
 I expected a pi zero or something
 I was looking up that resin printer because I'd like to make something shiny and translucent
 Like.. put a pi into a retro 90s styled case
 but make it feaasible to use
 @_@
 aaaaah XD
 Omg
 I found a legit Linux comic
 I'm happy
 @KMyers @AdamOutler @Ivoriesablaze https://herpaderp.party/0058.html
 https://herpaderp.party/0105.html
 @RazPi - I need to run by several stores this weekend vto look at computers. Want to tag along
 Ooh that could be fun, what computers are you looking at?
 I have to go to the insurance office today to get my number from them, my cough has lasted too long
 but that shouldn't take too long
 I basically need to see what the average computer a home based agent can buy on a limited budget
 @KMyers Where would you like to meet up? I'll get dressed and head out soon
 I need to run home to grab my laptop but anywhere is good for me
 If anyone is hearing to Walmart, keep an eye out for these flash lights. They are marked for $15 but ringing up for $5.00. It even includes batteries
 Hey I'm feeling adventurous, how do you feel about heading towards jupiter? I could contribute gas
 I am game
 This weekend I think is the weekend I'll get my freebsd sedrver up T_T
 awesome! Let me know when you're here, I'll star getting ready


[01:05] -BottyMcBotFace:#ubuntu-news- ::Fridge:: Ubuntu Weekly Newsletter Issue 619 @ http://fridge.ubuntu.com/2020/02/24/ubuntu-weekly-newsletter-issue-619/ (by guiverc)
[15:14] -BottyMcBotFace:#ubuntu-news- ::OMG!Ubuntu:: New Dark Mode Setting Lands in Ubuntu 20.04 ‘Focal Fossa’ Dailies @ https://www.omgubuntu.co.uk/?p=164386 (by Joey Sneddon)
[17:15] -BottyMcBotFace:#ubuntu-news- ::Planet:: Ubuntu Blog: Quick-add KVMs for MAAS @ https://ubuntu.com/blog/quick-add-kvms-for-maas


[04:14] <hopp3r> hi
[04:14] <hopp3r> sorry I was being off topic in #ubuntu
[04:14] <hopp3r> but I stopped when I was told to D:
[04:18] <Jordan_U> hopp3r: You were trolling. That's something that you should know is not OK, without being warned.
[04:18] <hopp3r> Jordan_U: well, I didnt, and now I did
[04:18] <hopp3r> Im sorry, ill never do it again D:
[04:18] <hopp3r> iv never had a problem with #ubuntu before
[04:19] <hopp3r> in *
[04:24] <Jordan_U> hopp3r: Can we continue this in a few hours?
[04:25] <hopp3r> Jordan_U: was about to go to sleep, what time will you be on tomorrow?
[04:25] <hopp3r> or can I just talk to another op?
[04:25] <Jordan_U> I'm not sure when. You can talk to other ops though.
[04:26] <hopp3r> hurrrr, what about dax , he looks like a reasonable staffer who has a freenode cloak and looks nice :D
[04:26]  * hopp3r pokes Dave2
[04:26] <hopp3r> err
[04:26] <hopp3r> dax*
[04:26] <dax> hopp3r: I'm not a named op in #ubuntu, and thus don't plan on removing your ban, as I've told you repeatedly.
[04:26] <hopp3r> well then why do you have voice?
[04:26] <dax> hopp3r: because I'm a member of network staff
[04:27] <hopp3r> x.x
[04:27] <hopp3r> you think christel is around?
[04:27] <dax> hopp3r: I doubt it. christel is also not a named op in #ubuntu.
[04:27] <pangolin> no freenode staff member is going to unban you in #ubuntu
[04:27] <dax> this ^
[04:27] <hopp3r> pangolin: you a ubuntu staff member?
[04:27] <pangolin> hopp3r: come back in about 12 hours or so and talk to Jordan_U then.
[04:28] <hopp3r> really? is noone else here a ubuntu op?
[04:28] <hopp3r> whatever
[04:28] <pangolin> I am an ubuntu op
[04:28] <hopp3r> =oh
[04:28] <pangolin> come back in 12 hours or so.
[04:28] <hopp3r> x.x
[04:29] <hopp3r> well why cant you help me?
[04:29] <hopp3r> whatever, yeah ill come back then
[04:29] <pangolin> because you are well aware of the channel rules jasonn
[04:29] <pangolin> and I don't want to help you right now. Jordan_U can help you tomorrow.
[04:32] <pangolin> hopp3r: Please part this channel as per the no idling rule us sucky ops make up randomly.
[04:33] <hopp3r> that is a stupid rule
[04:33] <hopp3r> but its your channel
[15:28] <Pici> "synapticon"  Is that one of the new Transformers?


[00:55] <blackboxsw> bogdanteleaga, it seems in juju2 that behavior has changed from juju1 for the websockets api call to "Action" "RunOnAllMachines". It looked like juju1 would return the synchronous results of the RunOnAllMachines call as the api response complete with Stdout and Stderror for the commands run. It appears that juju2 now returns immediately from a RunOnAllMachines call with a response that lists a bunch of actions still in "pending" s
[00:55] <blackboxsw> tate. So our responsibility is to sniff action deltas  from the Allwatcher Next queue for action changed deltas. Does that sound about right?
[00:57] <blackboxsw> I mentioned some misunderstandings I was having with RunOnAllMachines to cherylj a bit earlier today and it sounded like you might have a bit of additional context on what changed in juju2 for the Run* api calls.
[00:58] <blackboxsw> ... just wanted to queue up the question for tomorrow. Will check in later
[04:31] <xbox360pll> =D:)=);D =D ;D:P=) :D:D :P :):P :P=D :D;D:>=D;D=D;D=);D:) :D ;D :P =D=) :)=D=D =D;D =) :> ;D=D :>:P =D:) =):P=) :D=D :P :) :)=D ;D:D :P :> :D :) ;D =D :P=):D =) ;D=)
[10:59] <dimitern> I'm trying to follow https://jujucharms.com/docs/devel/developer-layers-interfaces and looking at existing examples
[11:00] <dimitern> Is the version: significant? Do I need to define both interface.yaml and metadata.yaml (for the 'peers: ...' section), or just peers.py and interface.yaml?
[11:18] <stub> dimitern: Just peers.py and interface.yaml. 'version' is only documentation at the moment, but may one day be used for 'juju relation-add' or just flagging charms in need of maintenance.
[11:19] <dimitern> stub: OK, less stuff to care about keeping in sync :) thanks!
[11:21] <dimitern> stub: can I define config settings in the interface layer somewhere, so they are available in peers.py?
[11:25] <stub> dimitern: I don't think so, no. I'm told you are not supposed to put implementation in the interface layer, so you might be overreaching. I think interface layer is just supposed to catch events and set states so the charm or layer providing the real implementation can hook in, and an API for driving the protocol. I'm still somewhat fuzzy on this.
[11:27] <dimitern> stub: I see, that makes sense
[11:28] <dimitern> stub: I looked at existing examples and most of them just set/clear states.
[12:54] <bbaqar> Hey guys. What could be going wrong if i see a unit in an error state in juju status but when I resolve it it gives the error that the unit is not in an error state.
[12:55] <bbaqar> all services on the node are configured and running properly
[12:56] <rick_h_> bbaqar: is this from the Juju GUI?
[12:57] <bbaqar> no from the CLI
[12:57] <bbaqar> juju stat --format=tabular
[13:45] <jcastro> who's in the mood to unpromulgate mediawiki-scalable?
[14:11] <bluetack> Can anyone tell me if there is a way for an action to trigger a hook? I can't seem to find anything in the docs
[14:17] <stub> bluetack: Your action is running in a hook context, so you could just call ../hooks/whatever
[14:18] <stub> bluetack: But probably better to factor out the common functionality into a library, and have both the hook and action call it.
[14:20] <marcoceppi> jcastro: unpromulgated
[14:20] <bluetack> I tried a library (writing in python), but despite may __init__.py files all over the place, I couldn't import a sibling folder. How would I have a common library directory accessible to both actions and reactive dirs?
[14:20] <stub> bluetack: If this is for reactive charms, you might want https://github.com/juju-solutions/charms.reactive/pull/66
[14:20] <stub> bluetack: Also, if you want imports to work sanely with reactive you want https://github.com/juju-solutions/charms.reactive/pull/51
[14:21] <stub> bluetack: $CHARM_DIR/lib is in your reactive hook's PYTHONPATH, so you can put things in there.
[14:21] <bluetack> I do and I do, but they're not merged in yet
[14:24] <bluetack> stud: I'll give the ../hooks/whatever approach a try for now. thanks
[14:24] <bluetack> stub
[14:24] <bluetack> my intentions are purely honourable
[14:24] <stub> bluetack: It might be ./hooks/whatever - I think the cwd is $CHARM_DIR
[14:25] <bluetack> stub: can I reuse an existing hook?
[14:25] <bluetack> i.e. I dont have a hooks folder yet
[14:27] <marcoceppi> bluetack: you shouldn't need to create any hooks, they're generated during the build process
[14:27] <bluetack> understood. thankyou
[14:36] <shruthima> hi kwmonroe , how can i use "resource-get" option in the python code...? could you please provide links of any charms written in python using resources ..!!
[14:39] <kwmonroe> shruthima: check out charm-svg: https://jujucharms.com/u/marcoceppi/charm-svg
[14:39] <kwmonroe> shruthima: search resource_get in this source: https://github.com/marcoceppi/layer-charmsvg/blob/master/reactive/charmsvg.py
[14:41] <shruthima> thanks kevin :)
[14:42] <shruthima> kwmonroe: In IBM_IM charm for amulet testing how resources will be fetched..?
[14:44] <shruthima> we have noticed u have removed 00-setup file and added tests.yaml
[14:51] <shruthima> kwmonroe : i have tried to deploy ibm-im charm using amulet but is not fetching resources it is failing at timeout ..
[14:54] <cory_fu> mthaddon: Hey, are you around?
[14:54] <mthaddon> yep
[14:54] <kwmonroe> shruthima: the ibm-im charm will fetch the placeholder resources from the store when the charm deploys.. it's expected to fail, but i see the status message it was waiting for is incorrect.  fixed here: http://bazaar.launchpad.net/~kwmonroe/charms/trusty/layer-ibm-im/switch-to-resources/revision/19#tests/01-deploy.py
[14:56] <cory_fu> mthaddon: You're listed as the maintainer of https://jujucharms.com/nrpe-external-master/  I'm looking to merge https://code.launchpad.net/~aluria/charms/precise/nrpe-external-master/donotremove-hostdefs/+merge/290957 since it has been approved, but because we have a new publish / promulgation process, I need it to be pushed & published into the maintainer's namespace (either yours personally, or an appropriate group) from which I can re-promulgate
[14:57] <kwmonroe> shruthima: until we can host the real resources (i think we've been calling that "resources phase 2" during our calls), we'll just test that the charms deploy and  we see the right status message for the placeholder resources.
[14:57] <cory_fu> mthaddon: The end goal of this is to give more power to the maintainers to publish updates directly
[14:57] <shruthima> kwmonroe : is it like once the resources are in charm store only we can test amulet?
[14:57] <shruthima> oh k thanks kevin :)
[14:58] <mthaddon> cory_fu: we're migrating away from that charm to https://jujucharms.com/nrpe/trusty - is there a reason you'd prefer nrpe-external-master?
[14:59] <kjackal> Hey marcoceppi do you have any news for me regarding charmers? Thanks
[15:00] <cory_fu> mthaddon: I don't prefer it.  Just trying to get an approved MP merged in.  Are you to the point where we can unpromulgate nrpe-external-master entirely and get that change applied against cs:trusty/nrpe if applicable?
[15:02] <mthaddon> cory_fu: both charms are owned by ~charmers which you're a member of so you should be able to merge and promulgate yourself, no?
[15:03] <cory_fu> mthaddon: The point is that we're doing away with ~charmers ownership of promulgated charms in favor of ownership by the maintainer (or group, if more appropriate).
[15:03] <cory_fu> And the one bit that I can't do is push & publish to the new namespace in the store.
[15:03] <cory_fu> marcoceppi: Do we have a write-up of this new process somewhere?
[15:05] <mthaddon> cory_fu: I'm familiar with the new process, I just wasn't aware you were actively unowning things from ~charmers
[15:09] <rick_h_> cory_fu: https://jujucharms.com/docs/devel/developer-getting-started
[15:11] <cory_fu> rick_h_, mthaddon: By new process, I specifically meant the fact that promulgated charms are no longer to be owned by ~charmers and that we are transitioning them as they are touched during review
[15:12] <cory_fu> I also believe marcoceppi was working on an email to the mailing list with a full list of charms that will need to be transitioned out of ~charmers ownership
[15:12] <rick_h_> cory_fu: ah, yea that's not in the charmstore section or the charmers getting started section
[15:16] <cory_fu> Again, this is what I've been told by marcoceppi, so I'd like to get his feedback, but I think he's on a call and is going to get annoyed at me pinging him.  ;)
[15:16] <rick_h_> cory_fu: no, you're correct on the goal and how things are built
[15:16] <rick_h_> cory_fu: we want to celebrate the true authors and make it clear it's not all canonical/one team that is responsible for the charms
[15:17] <cory_fu> Indeed
[15:17] <mthaddon> cory_fu: I'm not sure what to suggest in terms of that specific charm. I may be listed as the maintainer in the charm itself, but we consider it pretty much obsolete at this point. Is there a suggested approach for that case?
[15:19] <rick_h_> mthaddon: cory_fu so are they compatible at all? e.g. can we provide a migration math and move over?
[15:19] <cory_fu> Yeah, if it's consider obsolete, then we should look at deprecating, migrating people off, and unpromulgating
[15:20] <aisrael> petevg: psst, don't forget to check the lock icon in the review queue ;)
[15:20] <cory_fu> aisrael: He can't
[15:20] <rick_h_> cory_fu: and with the new process you can move what charm is promulgated and it maintains a history so we can look at a true migration path
[15:20] <mthaddon> but we don't have any way of migrating people off do we? surely that's up to them
[15:20] <aisrael> cory_fu: how so?
[15:21] <petevg> aisrael: yeah. I don't have permission to set the locked status. I think that I'm officially waiting for the new review queue to launch to get it.
[15:21] <mthaddon> rick_h_: nrpe supports the functionality of nrpe-external-master, but you need to set some specific config options. Not sure if that qualifies as a migration path
[15:21] <cory_fu> aisrael: Locking doesn't work for him or kjackal.  Some bug due to them being newer accounts that was deemed not worth fixing since we're about to move to a new RQ platform anyway
[15:22] <aisrael> cory_fu: fair point. I meant to point out that the nagios stuff petevg just reviewed were locked to me, so I could have saved you some time
[15:22] <petevg> aisrael: right. I guess I could look at the locked icon :-) Whoops.
[15:22] <aisrael> tl;dr, unit tests in the nagios charm in the store are completely busted, so no tests are going to pass
[15:23] <cory_fu> aisrael: There is also an issue with the charmhelpers code synced into the proposed branch as well, though
[15:24] <aisrael> cory_fu: Yeah, one of many problems with the charm :/
[15:24] <cory_fu> mthaddon: Are the config options different than the ones you would set with nrpe-external-master?
[15:25] <mthaddon> cory_fu: yes, you need to set new config options if you're migrating from nrpe-external-master to nrpe
[15:25] <rick_h_> cory_fu: mthaddon so it'd be interesting to see if the upgrade charm hook in nrpe could help manage an upgrade from nrpe-external-master to itself
[15:25] <cory_fu> rick_h_: From the store page, it doesn't look like cs:precise/nrpe-external-master is used in any bundles.  Do we have any other usage stats to see if it's being actively used such that we shouldn't simply unpromulgate it?
[15:26] <stub> nrpe-external-master is precise, nrpe is trusty. People need to redeploy to switch anyway.
[15:27] <rick_h_> cory_fu: looking
[15:27] <cory_fu> stub: Good point
[15:29] <cory_fu> rick_h_: I feel like we need a better way of indicating to users that something is no longer recommended without breaking their stuff right away.  Something like a flag we could set on the charm store that would cause Juju to emit a deprecation warning when deploying the charm.  *shrug*  Just a thought
[15:36] <rick_h_> cory_fu: so https://api.jujucharms.com/charmstore/v4/nrpe-external-master/meta/stats/ suggests it's getting used twice today, 5 times this week, etc.
[15:36] <rick_h_> cory_fu: so it's not a big footprint, but does exist?
[15:39] <cory_fu> rick_h_: Also, I suppose the fact that there's a MP against it means that it's being used
[15:39] <cory_fu> So I'm not sure what the appropriate action to take here is
[15:39] <stub> I'd lay money it is entirely Canonical internal, and a decent chance of all that being CI systems.
[15:42] <cory_fu> aluria: Since this is your PR, care to chime in?
[15:42]  * stub wanders off into the night
[15:43] <aluria> cory_fu: hey, I think I don't have perms to merge it
[15:43] <cory_fu> aluria: :)  Not looking for you to merge it.  Looking for your input on the conversation about it being dropped in favor of cs:trusty/nrpe
[15:44] <cory_fu> And whether the usage of cs:precise/nrpe-external-master is entirely Canonical IS / CI
[15:44] <cory_fu> If so, it looks like the right approach is to transition
[15:44] <aluria> cory_fu: aah sorry... we're using it in several deployments but will start moving to lp:charms/trusty/nrpe in future ones
[15:47] <rick_h_> cory_fu: so I think we unpromulgate it, move it to the new namespace, publish it to the juju list and update the readme perhaps
[15:47] <rick_h_> cory_fu: and let folks like aluria know, maybe look for any other comitter in the "recent" tree
[15:47] <cory_fu> aluria: Do you know if that PR is applicable to nrpe as well?
[15:48] <cory_fu> rick_h_: New namespace being ~mthaddon?
[15:48] <aluria> cory_fu: it's not.... nrpe-external-master is written in bash while nrpe is in python (but will need to write a MP for nrpe too)
[15:48] <rick_h_> cory_fu: if he wants it there, or we had an ~unmaintained, or we can do some ~deprecated-promulgated
[15:48] <cory_fu> aluria: Yeah, sorry, I meant the fix in general, not the specific patch
[15:49] <aluria> cory_fu: issue is very specific, and it also needs to be addressed in nrpe charm --- hacluster charm is a subordinate for OpenStack endpoints, and deploys /var/lib/nagios/exports/service__${hostname}_blabla.cfg and host__${hostname}.cfg
[15:50] <aluria> cory_fu: nrpe charm thinks there's only one host definition and removes all to recreate the non-subordinate hostdef one
[15:51] <aluria> you can end up having service defs without host defs --- patch only removes host defs without service defs
[15:51]  * mthaddon is +1 to moving it to a team with a name like ~unmaintained or something
[15:53] <cory_fu> aluria: Ok, I opened it as a bug on nrpe: https://bugs.launchpad.net/charms/+source/nrpe/+bug/1595612
[15:53] <mup> Bug #1595612: Be more selective in deleting host__*.cfg files <nrpe (Juju Charms Collection):New> <https://launchpad.net/bugs/1595612>
[15:53] <aluria> cory_fu: ta
[15:54] <cory_fu> rick_h_, mthaddon: I'm also +1 to moving it to ~deprecated or ~unmaintained.  I wonder if we should promulgate it from there for a short period to give people like aluria a chance to transition
[15:54] <cory_fu> The short-term transition could just be adding the namespace, of course
[15:55] <cory_fu> Also, the question remains about merging this PR.  I assume we need to get that fix in during the move.
[15:57] <arosales> kwmonroe: do you know if there are docs on how to use the docker box?
[16:00] <aluria> cory_fu: I ran into this bug which I think it's already solved -- https://bugs.launchpad.net/charms/+source/nrpe/+bug/1473205
[16:00] <mup> Bug #1473205: nrpe charm creates checks with _sub postfix, breaking compatibility with nrpe-external-master <canonical-bootstack> <nrpe (Juju Charms Collection):New> <https://launchpad.net/bugs/1473205>
[16:02] <cory_fu> arosales: https://github.com/juju-solutions/charmbox
[16:03] <cory_fu> The README is pretty good on it
[16:04] <cory_fu> That one is designed for dev & testing.  If you want a Docker image for just deploying using Juju, you can use the lighter-weight jujubox: https://github.com/juju-solutions/jujubox
[16:04] <cory_fu> arosales: ^
[19:53] <marcoceppi> cory_fu: I've gone a bit off the deep end, but I think it's for the best
[19:54] <marcoceppi> cory_fu: https://github.com/juju-solutions/layer-apache-php/pull/5/files
[19:55] <marcoceppi> cory_fu: what I'd like to do, is build a layer tactic that merges apache.yaml to layer.yaml prior to validation
[20:03] <cory_fu> marcoceppi: +1 I've been meaning to update the apache-php layer to use layer.yaml for some time but never use it so didn't have the time or motivation
[20:04] <cory_fu> I suppose a custom tactic would be one way to handle migrating.  How many charms are using that layer currently?  Maybe we can submit patches against them all?
[20:06] <magicaltrout> oooh look at that
[20:06] <magicaltrout> you can spy on charm summit submissions  in google forms :)
[20:07]  * magicaltrout bookmarks that page
[20:51] <magicaltrout> marcoceppi: out of interest excluding merlijn's uploading issues, are their restrictions on resource sizes ?
[20:53] <marcoceppi> magicaltrout: not that I'm aware of
[20:53] <marcoceppi> magicaltrout: probably around the 50 GB size we have to start asking hard questions
[20:53] <marcoceppi> like "why" and "what"
[20:53] <magicaltrout> lol okay
[20:59] <marcoceppi> magicaltrout: wait
[20:59] <marcoceppi> you can see the submissions?
[21:00] <marcoceppi> magicaltrout: eheh, not anymore ;)
[21:03] <magicaltrout> :(
[21:03] <magicaltrout> didn't think that was on purpose :P
[21:14] <marcoceppi> Google forms comes with, by default, "allow users to see summary" which is follish
[21:14] <marcoceppi> foolish, even
[21:14] <magicaltrout> hehe
[21:14] <magicaltrout> well i didn't notice the first time
[21:14]  * magicaltrout should pay more attention
[22:09]  * magicaltrout has plans afoot to transfer all of his data center ops to DC/OS and Juju... because..... why not...
[22:09] <magicaltrout> reap what you sow and all that
[22:09] <magicaltrout> marcoceppi: you guys need to get 2.0 out so I can deploy without fear! ;)
[22:14] <marcoceppi> magicaltrout: that sounds awesome
[22:14] <marcoceppi> magicaltrout: yeah, I'm pumped for 2.0 landing, we're really close to RC's which means we'll be upgradability between releases
[22:14] <magicaltrout> woop
[22:14] <magicaltrout> oh also on a slightly different note
[22:15] <magicaltrout> http://www.darpa.mil/news-events/2016-06-17 with my NASA hat on I should be working on this soon
[22:15] <magicaltrout> now I have no idea about what will actually happen, but most of the Darpa stuff gets open sourced
[22:15] <marcoceppi> bad ass!
[22:15] <magicaltrout> so automatic model discover over juju big data sounds pretty cool
[22:15] <magicaltrout> so if they do make is ASL I'll make sure we can stand up whatever is produced
[22:16] <magicaltrout> there's a bunch of the last darpa/nasa project I'm slowly working with some of the JPL guys on bringing to Juju, dark web crawling and stuff
[23:21] <cholcombe> anyone around that knows mojo?


[00:10] <cjwatson> infinity: I seem to remember you saying that some compilers seemed to be generating non-armhf binaries on armhf; were you aware of fpc being in that category?  (dozzaqueux build failure)
[00:20] <infinity> cjwatson: Yes, it's a glibc bug I'm trying to hunt down.
[00:20] <infinity> cjwatson: Lazy compilers (like fpc) don't regenerate the eabi ELF headers, but rather trust that crt*.o are correct and blindly link them, and crt*.o are no longer being generated with correct eabi headers.
[00:21] <infinity> There was a massive refactoring of how crt*.o are generated in 2.16, just need to hunt down how that broke.
[00:21] <infinity> (It does affect things built with GGC, as it generates the correct bits itself)
[00:23] <infinity> s/does/doesn't/
[00:32] <cjwatson> Right, thanks.
[01:09] <infinity> cjwatson: Tomorrow's a day off for me, so I may do some upstream hunting of said glibc bug, given that I have no grand plans.
[01:40] <stgraber> someone's been busy processing SRUs. thanks!
[01:47] <cjwatson> Just trying to compensate a little for the pile I've been adding for SB
[02:32] <xnox> =)
[02:32]  * xnox ponders how to make enigmail add hard << thunderbird dependency, such that britney stops thunderbird migrating without a matching/updated enigmail.
[02:40] <infinity> xnox: It used to have one, and it was removed, to be fair. :P
[02:40] <infinity> xnox: But that was a loooong time ago.
[02:41] <infinity> xnox: Back when extensions could stay compatible for years, all the needed was a manifest that wasn't over specific.
[02:41] <infinity> s/the/they/
[02:41]  * xnox grumbles
[02:42] <infinity> Anyhow, it's not hard to add it back.
[02:42] <infinity> You'll probably want to talk to Chris or Micah, and make sure it's committed to the right bits for them to not lose it again.
[02:43] <xnox> well there is a new upstream point release...
[02:43] <infinity> Yeah, those shouldn't be breaking compat for extensions anyway...
[02:43] <infinity> Well, didn't use to. :/
[02:44] <infinity> The New World Order may play more fast and loose with ABI.
[02:44] <infinity> I dunno.
[02:49] <xnox> the diff is big in the point release, it vaguely suggests api changes.
[02:51]  * xnox goes to have my second sleep
[06:40]  * infinity glares at erlang-jiffy's continued failure on PPC.
[06:55] <infinity> Grr, and it doesn't fail on my local PPC machine.  That's disconcerting.
[07:39] <infinity> Aaand, this is because perl is segfaulting only on ppc64 kernels, which I don't run locally.
[07:39] <infinity> I think it might be bedtime, rather than caring about that.
[10:57] <psivaa> cjwatson: xnox: I could not see raring desktop & server images for today and yesterday. Is it due to any known reasons?
[11:01] <cjwatson> psivaa: For desktop, I'm not desperately convinced that all the livefs builders are working properly for raring yet - I'm not seeing any logs from other than amd64 or powerpc.  I don't know whether that's the root cause though.
[11:01] <cjwatson> Hm, maybe that's not it
[11:01] <cjwatson> The logs seem incomplete
[11:02] <cjwatson> Oh, here, stuck builds
[11:02] <cjwatson> Looks like celbalrai had a sad
[11:02] <cjwatson> I'll chase it up
[11:02] <psivaa> cjwatson: thanks, out of curiosity is http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/raring/ the place to look for jobs?
[11:03] <psivaa> or is there any other place for me to see live logs ?
[11:03] <cjwatson> livefs-build-logs/raring/ubuntu/ is earlier in the process
[11:03] <cjwatson> But it's not totally helpful here because of the exact way it all got stuck
[11:03] <cjwatson> I had to look at the process list on nusakan
[11:04] <psivaa> ahh ack, get it. thanks
[11:11] <xnox> cjwatson: do we have any kind of nagios-like monitoring to check the timestamps of the logs & check for hung processes?
[11:12] <xnox> e.g. such that a query "why images are not built on day X" can be answered automatically.
[11:12] <cjwatson> No
[11:12] <xnox> =/
[11:12] <cjwatson> But I would rather make it not hang this way, than entrench the problem by monitoring for it
[11:13] <xnox> ack.
[11:13] <cjwatson> A single dead builder shouldn't snarl up the whole system
[12:03]  * ogra-cb_ would still appreciate if someone could let linux-nexus7 out of NEW
[13:48] <xnox> cjwatson: is it intended to only have /casper/vmlinuz.efi.signed on the desktop cd? and no /casper/vmlinuz ? my non-sb & non-uefi VM fails to boot =)
[13:48] <cjwatson> That's intended, but the breakage isn't
[13:48] <xnox> ack.
[13:48] <cjwatson> Let me fix that quickly
[13:49] <cjwatson> Hmm, there were problems with 8.3 limitations
[13:49] <cjwatson> Argh
[13:50] <cjwatson> I'll have to change ubiquity to make this work, I think
[13:51] <xnox> hmm???? the iso doesn't boot, so I don't get ubiquity yet....
[13:51] <cjwatson> It's complicated
[13:51] <cjwatson> Yes I know, but trust me :)
[13:51] <xnox> =))))
[13:52] <xnox> ok. I'm guessing if "8.3 limitations" and "Argh" are mentioned it's all that ugly.... =))))
[13:55] <TheLordOfTime> is this where i'd come to ask whether an SRU actually made it to -updates for precise?  (to confirm something)
[13:55] <TheLordOfTime> or should i be asking elsewhere
[13:55] <cjwatson> xnox: Basically the answer is probably to call it vmlinuz.efi instead so that isolinux can be told to boot from it, but if I do that then I have to change everything that expects to be working with .efi.signed
[13:55] <cjwatson> TheLordOfTime: http://people.canonical.com/~ubuntu-archive/pending-sru.html
[13:55] <cjwatson> TheLordOfTime: Or rmadison
[13:56] <TheLordOfTime> cjwatson, rmadison works only when you're on an Ubuntu system.  I'm not.  and its not a pending SRU, its one that i was informed was already complete.
[13:56] <xnox> cjwatson: ack and sigh.
[13:56]  * TheLordOfTime wants to confirm that
[13:56] <cjwatson> TheLordOfTime: It works fine on Debian too if you give it the right URL
[13:56] <cjwatson> TheLordOfTime: And, uh, you apparently miss my point
[13:56] <TheLordOfTime> cjwatson, again, implies you're on Linux or Debian
[13:56]  * TheLordOfTime sighs
[13:57] <TheLordOfTime> whatever, i'll just go check via the code system
[13:57] <xnox> TheLordOfTime: http://pad.lv/u/$pkgname
[13:57] <cjwatson> TheLordOfTime: If it's in -proposed and not -updates, it'll be listed on that page; if not, it won't
[13:57] <cjwatson> TheLordOfTime: Or check https://launchpad.net/ubuntu/+source/PACKAGE/+publishinghistory
[13:57] <xnox> TheLordOfTime: and in that url see the publishing history / full changelog.
[14:11] <Mirv> hi! we've one bamf cherry-pick in precise SRU queue, and we'd like to get it handled into precise-proposed since we'd already have the next SRU brewing after it...
[14:14]  * Mirv carefully highlights infinity to point to the above ^ as per vanguard list in wiki
[14:15] <Mirv> it's been in the queue for a week, and then it should spend another week at least in proposed
[14:43] <cjwatson> Mirv: Sorry for the delay.  Accepted now.
[14:56] <Mirv> thanks!
[15:49] <cjwatson> xnox: signed kernel> should, I *think*, all be fixed tomorrow
[15:50] <xnox> cjwatson: ack. I will verify ;-) Thank you.
[15:50] <xnox> cjwatson: are you doing this fix for 12.04.2 as well?!
[15:51] <xnox> or not affected?
[15:51] <cjwatson> Not affected yet, but I probably will backport it.
[15:52] <cjwatson> Once we know it all works.
[15:52] <cjwatson> For 12.04.2 we want to ship only the signed kernel on the image, which is what provoked this breakage.
[15:52] <cjwatson> The precise backport of SB support is only partly complete as yet; I'm waiting on some more SRU queue processing.
[16:52] <Laney> can I copy up brasero from q-updates to r-proposed?
[16:53] <cjwatson> Sure, if there are no changes from quantal to raring, and if you can get it to not time out (there are some problems in this area at the moment)
[17:10] <Laney> heh, I'm guessing the timeouts are to do with binaries somehow (initially forgot -b and it didn't time out in several runs, but now reliably does with -b)
[17:11] <cjwatson> Yes
[17:24] <cjwatson> (self-rejected to replace it with a fix from raring)
[20:19]  * cjwatson sets up raring milestones as agreed at UDS (I think)
[20:20] <cjwatson> persia: You have a work item on foundations-r-schedule which is annotated as "must be done within a week of UDS"
[20:46] <ScottK> cjwatson: For flavours doing traditional Alpha/Betas (Kubuntu is one), we were hoping to get the traditional milestones too.
[20:47] <cjwatson> Hm, messy, but OK, let me see
[20:50] <ScottK> Thanks.
[20:50] <cjwatson> ScottK: ddone
[20:50] <cjwatson> *done
[20:50] <ScottK> Excellent.
[22:02]  * ScottK gives up on trying to run remove-package from an airplane.
[22:04] <ScottK> If you try to clean up quantal-proposed, don't remove culmus and gdebi.  I got that far before the latency was too high.
[23:19] <stgraber> ^ thanks
[23:19] <infinity> NP.
[23:52] <xnox> is britney EOD ? last update 17:17
[23:54] <infinity> It's crashing.
[23:55] <xnox> =(


[16:37] <Toni_Link> Hi. I installed Ubuntu 17.10, "gnome-session" and my desktop are pretty fantastic. But I can't realize how to change thy GDM theme. How to change?


[00:04] <CarlFK> smb_tp: what kernel parms?
[00:08] <smb_tp> You mean to boot. Try with nothing special. I would rather get the stuck case if it is still happening and then some timer dump
[00:08] <CarlFK> -
[00:13] <CarlFK> pauses, and Fn+SysRq un-pauses it, so I don't get a chance to hit Alt anything
[00:14] <CarlFK> dmesg coming up..
[00:16] <smb_tp> CarlFK, Oh, that was a keyboard that that needs fn for sysrq. Well anyways, I would think all keys will do that. Still it might me interesting to have that info or that from /proc/timer_list (which is the same). Just to see how the timers are set
[00:16] <CarlFK> oh crap - I bet you want /proc/timer_list from that kernel?
[00:16] <CarlFK> i just booted back to the one that runs X
[00:17] <smb_tp> CarlFK, Yeah, sorry
[00:17] <CarlFK> meh - my mistake.
[00:25] <CarlFK> smb_tp: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/254668  there ya go.
[00:35] <smb_tp> CarlFK, Thanks for that. The nohz timer looks not too bad at this time. The one from nanosleep looks a bit high on  first unqualified glance. But that might still be ok.
[00:36] <smb_tp> But that will be for later...
[00:41] <smb_tp> At least it didn't trigger any of the new warnings, so we know what is _not_ the problem
[00:41] <smb_tp> *sigh*
[01:37] <pgraner> smb_tp: why the *sigh*?
[10:30] <Xan3> hi
[10:30] <Xan3> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/262742
[10:31] <Xan3> i have add lspci -vvnn to this bug, it can help u?
[18:47] <pepie34> Hi xorg takes 60% of cpu since the last radeon/ATI xorg driver update
[18:47] <pepie34> it seems like a different version of DRI and xorg drive
[18:48] <pepie34> I can't see any clue on Xorg log
[22:21] <Evas> hi all i have a problem with 2.6.27 and the driver of the usb edge modem MT503HS.. it compile fine on 2.6.24 but not on the 2.6.27 intrepid kernel
[23:29] <elements> Is it possible to install the Intrepid kernel on Hardy to test them out?
[23:30] <elements> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/264742
[23:30] <elements> I want to report back on that bug but don't know how to do it best.
[23:31] <elements> Should I download latest Intrepid and boot live from the DVD or should I install the Intrepid kernel on Hardy?
[23:41] <amitk> elements: yes it is, you need to enable the intrepid repo (/etc/apt/sources.list), install just the kernel and then disable the repo. Or just download the .deb packages.