[00:34] <rick_h__> woo! expenses filed. Only took 3 months
[00:38] <huwshimi> hehe
[00:40] <rick_h__> now that vegas is filed I feel less obligated to file london ones :)
[00:40] <rick_h__> huwshimi: hey, how goes? Wanted to check up on your branches
[00:40] <rick_h__> and let you know that hatch and frankban are working on the 'deleting things' problems in the back end
[00:40] <huwshimi> rick_h__: I have a million things in progress :)
[00:41] <rick_h__> so should be able to revisit that branch later on
[00:41] <rick_h__> huwshimi: yea, seems like it. I wanted to see what was up, anything stuck you need a hand with, etc.
[00:42] <huwshimi> rick_h__: I talked to hatch about landing the deleted states (they just won't be visible) and then hooking them up when that's done (hence me moving the card back)
[00:42] <huwshimi> If you'd prefer me to wait I can
[00:42] <rick_h__> huwshimi: hmm, ok. I trust you on it.
[00:42] <huwshimi> :)
[01:21] <rick_h__> hah, poor huw was a photo target a bit https://www.flickr.com/photos/7508761@N03/14730078876/in/photostream/
[01:24] <huwshimi> It's almost as if I was being followed :)
[01:24] <huwshimi> Nice photos!
[01:25] <rick_h__> hah, yea I was following you around a lot
[06:22] <urulama> morning all
[06:28] <huwshimi> urulama: Morning
[06:32] <urulama> huwshimi: anything particular regarding your cards on the board that need review or are in coding (to pass the message to the daily call)?
[06:33] <huwshimi> urulama: Only that I need second reviews on a couple of them. Thanks!
[06:35] <urulama> huwshimi: ok, np
[08:14] <urulama> frankban: morning
[08:14] <frankban> urulama: hi
[09:06] <urulama> frankban: do you know if rogpeppe is out today?
[09:06] <rogpeppe> urulama: i'm around
[09:06] <urulama> rogpeppe: oh, hi, sorry :D
[09:06] <rogpeppe> urulama: np :-)
[09:07] <urulama> rogpeppe: any news regarding the change of core to charm.v2?
[09:07] <rogpeppe> urulama: i've been around for hours :-)
[09:07] <rogpeppe> urulama: core is blocked until its critical bugs are resolved
[09:07] <rogpeppe> urulama: so no branches are landing that aren't fixing those bugs
[09:07] <urulama> rogpeppe: ok, tnx for the info
[09:07] <rogpeppe> urulama: i've got approval to land it though
[09:08] <urulama> rogpeppe: \o/
[09:12] <urulama> rogpeppe: didn't have time to ask before ... any sessions this week?
[09:14] <rogpeppe> urulama: this week and every week :-)
[09:14] <rogpeppe> urulama: tuesday night it was
[09:14] <rogpeppe> urulama: and absolutely rockin'!
[09:15] <urulama> rogpeppe: nice, glad to hear!
[09:15] <rogpeppe> urulama: it was good on the friday night in london actually. i presume you didn't try and fail to find it.
[09:16] <urulama> rogpeppe: we wanted to have a session today (with the gypsy swing band, and me cooking), but the weather is really bad :( well, after Nuremberg it is
[09:16] <rogpeppe> urulama: music and home cooking, the perfect combo :-)
[09:16] <urulama> rogpeppe: no, i was in the museum for nearly 4h ... i guess the sms didn't get through :(
[09:17] <rogpeppe> urulama: nope, i haven't got any sms messages from you since thursday
[09:18] <rogpeppe> afk for 10 minutes
[09:18]  * urulama lunches ... woke up early today
[10:13] <urulama> rogpeppe: what do you have in mind for the charm refactoring?
[10:13] <rogpeppe> urulama: i'd doing exactly as i suggested in my email to juju-dev
[10:13] <rogpeppe> s/i'd/i'm.
[10:15] <urulama> rogpeppe: aaa, the URL/ReferenceURL, cool
[10:24] <rogpeppe> urulama: https://github.com/juju/charm/pull/31
[10:25] <urulama> will take a look in 5min
[10:26] <rogpeppe> urulama: thanks
[10:31] <urulama> rogpeppe: found this work done by hazmat ... find it interesting https://github.com/kapilt/juju-tosca
[10:33] <rogpeppe> urulama: thanks for pointing to that
[10:47] <rick_h__> morning
[10:49] <urulama> rick_h__: morning
[10:58] <frankban> rick_h__: morning
[10:59] <frankban> guihelp: I need reviews/QA for https://github.com/juju/juju-gui/pull/469 . Thanks!
[11:10]  * frankban lunches
[11:21] <urulama> rogpeppe: i like how more uniform the code is now with new URL & referenceURL
[11:21] <rogpeppe> urulama: cool
[11:22] <urulama> rogpeppe: i see that you're already on the way to change the charmstore ... making charm.v2 obsolete (in a way)
[11:23] <rogpeppe> urulama: well, who knows who is already using charm.v2? :-)
[11:24]  * urulama makes a wild guess that all the users are mostly present here :D
[11:28] <rogpeppe> urulama: i don't mind leaving v2 behind. we don't need to maintain it.
[11:28] <rogpeppe> urulama: i do think it's important to change the version number though.
[11:29] <rogpeppe> urulama: BTW i'm just investigating to see what the Resolve method does. There don't appear any tests for it, and it's only called once in the entire of juju-core
[11:30] <urulama> rogpeppe: let's welcome our new charm.v3 :)
[11:30] <rogpeppe> urulama: let's :-)
[11:30] <urulama> rogpeppe: regarding core - makes sense, they do depend on full URLs
[11:41] <bac> morning
[11:46] <hazmat> urulama, context?.. that's an in progress oasis std thingy..
[11:47] <urulama> hazmat: i've done the voting for ODS talks and noticed your OASIS and Juju ... just passed the git url to rogpeppe as a curiosity
[11:47] <bac> hey rick_h__ can you decipher http://ci.jujugui.org:8080/job/jenkins-github-lander-merge/27/console
[11:49] <hazmat> urulama, oh.. nice
[11:50] <urulama> hazmat: are you targeting to make juju bundles easy to integrate into heat with tosca support?
[11:52] <hazmat> urulama, that's a secondary goal.. first goal.. is tosca import into juju.. outbound, we'll be an embedded an orchestrator... re heat i'd prefer to embed directly
[11:53] <urulama> hazmat: nice!
[11:53] <rick_h__> bac: otp, looking
[11:53] <rick_h__> bac: go into the workspace and do 'git fetch' and try to :shipit: again
[11:54] <bac> rt
[11:54] <rick_h__> bac: the workspace for that, not sure why it's empty, but I think that's the answer
[11:59] <rick_h__> frankban: will be 2min late here sec
[11:59] <frankban> rick_h__: np
[12:15] <bac> rick_h__, jcsackett: new jenkins-github-lander has been installed on both of our jenkins instances.
[12:16] <rick_h__> bac: ty much
[12:16] <bac> rick_h__: it is not released anywhere, right?
[12:17] <rick_h__> yay for safety
[12:17] <rick_h__> bac: no, not currently
[12:17] <bac> rick_h__: does curtis use it?
[12:17] <rick_h__> bac: can you ping mgz and let him know about the bug/update
[12:17] <bac> oh, ok
[12:17] <rick_h__> bac: they're using it, but they've got a fork they're using
[12:17] <rick_h__> with all the bug blocking landing/etc stuff
[12:17] <rick_h__> I've not looked where they're keeping their fork
[12:57] <rogpeppe> jrwren: i haven't seen any return type comment from you, FYI
[12:58] <rogpeppe> jrwren: ha, it came in a different thread
[12:58] <rogpeppe> jrwren: ignore me :-
[12:58] <rogpeppe> )
[12:58] <rogpeppe> jrwren: see http://godoc.org/labix.org/v2/mgo/bson#Getter
[12:59] <rogpeppe> jrwren: to implement an interface, the methods must have exactly the same type signature
[12:59] <rogpeppe> jrwren: so returning (string, error) would not work
[12:59] <jrwren> rogpeppe: oh, you are implementing some interface there?
[12:59] <jrwren> rogpeppe: I missed that bit. Is it a mgo interface?
[13:00] <rogpeppe> jrwren: it's mentioned in the doc comment for the method
[13:00] <rogpeppe> jrwren: bson.Getter
[13:00] <rogpeppe> jrwren: it's understood by the marshaling code that mgo uses to talk to mongodb
[13:00] <jrwren> ok.
[13:00] <jrwren> new to go and lack of coffee. It makes complete sense now.  ty
[13:03] <rogpeppe> jrwren: np
[13:07] <urulama> rogpeppe: have you seen the comment from Casey about urls?
[13:07] <rogpeppe> urulama: yeah
[13:08] <rogpeppe> urulama: i've been chatting with him on #juju-dev about it
[13:08] <urulama> rogpeppe: tnx
[13:18] <rick_h__> jcsackett: kadams54 around? can you guys take some time this morning to go through huw's branches please?
[13:19] <rick_h__> he's got 5 in review atm
[13:21] <urulama> rick_h__: ah, yes, i talked to huw this morning and he asked for second reviews on his branches
[13:22] <rick_h__> urulama: yep, we'll get those cleared out today one way or another.
[13:25] <bac> rogpeppe: on the charmstore charm review you mentioned the bug with godeps doing things in parallel.  i thought you fixed that weeks ago.
[13:26] <rogpeppe> bac: no, i didn't change the default
[13:26] <bac> ah, ok.  i misremembered that you did
[13:26] <rogpeppe> bac: (like a fool, i thought i'd have some time to investigate the actual issue :-])
[13:26] <rick_h__> rogpeppe: if we need the time we need to create a card and have it as something to get scheduled
[13:27] <rick_h__> rogpeppe: is this something we can file a bug for and then add the bug as a card to the board's backlog to get scheduled up?
[13:27] <rogpeppe> rick_h__: given that there's a workaround, i'm not sure it's worth scheduling our time for
[13:28] <rick_h__> rogpeppe: ok, is there a bug to document the issue/workaround?
[13:28] <rogpeppe> rick_h__: i've pushed a fix. the workaround is now in place for anyone that uses a fresh version of godeps
[13:28] <rogpeppe> rick_h__: (unless they explicitly use a -P flag)
[13:28] <rick_h__> rogpeppe: oh gotcha
[13:40] <jcsackett> rick_h__: on it.
[13:40] <hazmat> the voting interface on ods is kinda of baroque
[13:40] <urulama> hazmat: :)
[13:40] <rick_h__> jcsackett: <3
[13:41] <urulama> hazmat: i've searched using names, opened all links in different tabs ... that helped a bit
[13:46] <hazmat> urulama, i just want a listing to scan titles.. seems obvious
[13:46] <hazmat> paging through one at a time through 2500 submissions is inane
[13:46] <hazmat> their basically encouraging author/company/topic specific voting by forcing search
[13:47] <hazmat> instead of browsing
[13:49] <urulama> hazmat: search for "at" or "of" ... you'll get list of all
[13:49] <urulama> well, list of all that have these words ;)
[13:52] <hazmat> urulama, nice trick
[13:59] <rogpeppe> frankban, bac, jrwren: here are the changes to make the charm store use the new charm.v3 API
[13:59] <rogpeppe> https://github.com/juju/charmstore/pull/49
[14:01] <urulama> rogpeppe: tests failed
[14:01] <rogpeppe> urulama: yes, because charm.v3 hasn't landed yet
[14:02] <urulama> rogpeppe: how come? :D :D (just kidding)
[14:02] <urulama> jujugui: have to go now ... be back in 4h
[14:02] <rogpeppe> urulama: i am hoping that someone might get around to deciding that it looks ok
[14:02] <rick_h__> urulama: have fun
[14:02] <urulama> rick_h__: tnx
[14:03] <bac> rick_h__: joining 1:1 now
[14:11] <hatch> frankban is the card you have in review the same as the one I have in starting?
[14:12] <hatch> I thought you were on the pending removal changes
[14:14] <frankban> hatch: it's not the same, but it's related: it handles the db and ecs name changes, not the deployment panle ones
[14:14] <frankban> hatch: would you like to review it?
[14:15] <hatch> sure - you should be able to add one line and do my card as well
[14:15] <hatch> :)
[14:15] <hatch> I'll look in a minute
[14:15] <hatch> rick_h__ oh I see the email that's why you moved my old card back into coding
[14:15] <hatch> I thought LK was broken again
[14:17] <hatch> rick_h__ it was also my intention not to make those changes we had talked about on the front end, but on the back end
[14:17] <hatch> that's going to be a lot of code to ship to the client for that usecase
[14:18] <hatch> or should I just do it?
[14:24] <rick_h__> hatch: I thought per our conversation that was the work your card was going to be doing
[14:24] <rick_h__> hatch: that's why it was the target/blocker on release. It's a UX issue we need to fix right away, and the client has the abliity to do it in a pure autocomplete sense
[14:24] <rick_h__> hatch: and doing it server side is special casing the search needs for a single widget/component.
[14:25] <hatch> well we already hit a different endpoint for it
[14:25] <rick_h__> hatch: I'd like us to get the client side updated for the best UX
[14:25] <rick_h__> hatch: no, we don't
[14:25] <rick_h__> hatch: we add a query string flag to the search endpoint
[14:25] <rick_h__> that basically turns on 'prefix matching'
[14:25] <rick_h__> and does not filter/process results
[14:25] <rick_h__> hatch: call?
[14:26] <hatch> oh I thought it was a different endpoint because it had 'autocomplete' in the url
[14:26] <rick_h__> it's just a query string flag onto the same endpoint
[14:26] <rick_h__> and if we match on the start of a word is turned on/off based on that flag
[14:26] <hatch> ahh - well then that's broken
[14:26] <hatch> lol
[14:27] <hatch> the cf-mysql is in the matching results
[14:27] <rick_h__> so I'd prefer we try to get the client side widget fix in asap to fix the issue and make mark s happy and the fastest/best way to do that is in the client result
[14:27] <rick_h__> hatch: right, heh that's true. I think we broke that with ngraming
[14:27] <rick_h__> because we needed to match somethingCMS via searching for CMS
[14:27] <frankban> jcsackett: can I have a second review from you for https://github.com/juju/juju-gui/pull/469 when you have time
[14:27] <hatch> ok I'll fix this up
[14:27] <frankban> ?
[14:27] <rick_h__> hatch: ty
[14:28] <rick_h__> hatch: Makyo kadams54 and jcsackett are helping with huw's reviews that are outstanding. I'd appreciate it if you guys could help as the seconds.
[14:29] <rick_h__> mark the cards with the tags to prevent doubling up, but between the 4 of you guys should hopefully be able to move those 5 branches forward
[14:29] <rick_h__> oh, 4, one is in landing now
[14:29] <hatch> yeah I just shipped one
[14:29] <hatch> just doing the review on frankban's branch now
[14:32] <hatch> frankban I don't think this technique is going to work
[14:32] <hatch> the deployer bar results are built from the ecs
[14:33] <hatch> if the ecs values dont' change until deploy then we can't update the deployer bar
[14:33] <hatch> we need to use the 'old' method and loop through and update the appropriate records when it changes
[14:34] <frankban> hatch: unless the deployer bar uses the db to retrieve the model starting from its id
[14:35] <hatch> right but that's not how it's done now - right now the deployer bar listens for a 'changeSetModified' event then loops through the changeset
[14:35] <frankban> hatch: I am really trying to avoid these kind of ecs mutations
[14:35] <rick_h__> frankban: hatch so sounds like we need a matching update to the changelog rendering?
[14:36] <rick_h__> to pull from db at render time to go with this change?
[14:36] <jcsackett> kadams54: you're looking at https://github.com/juju/juju-gui/pull/466 right? i'm trying to make sure the card and the PR are the same ones.
[14:36] <hatch> frankban yeah I agree but it feels like we are doing it half way
[14:36] <frankban> hatch: if we need to mutate the ecs as a consequence of a user input, than that seems to me a fail
[14:36] <kadams54> jcsackett: correct
[14:36] <hatch> and we'll never be able to remmeber if we need to poll the db or the ecs
[14:36] <jcsackett> kadams54: awesome.
[14:37] <hatch> bbiab
[14:37] <kadams54> Ah crap, forgot about the two review thing and just shipped the onboarding PR.
[14:40] <kadams54> rick_h__: ^ should I come to standup prepared for the stocks and humiliation galore?
[14:40] <rick_h__> kadams54: you've been shamed, carry on
[14:40] <kadams54> :-)
[14:41] <rick_h__> kadams54: if you had any questions or want feedback on your review bribe a friend to peek at the landing change please
[14:41]  * kadams54 ponders which mentor would be the cheapest to bribe.
[14:42] <frankban> hatch: from my perspective, the db should be the single source of truth, and the idea of "changing a change in the changeset" doesn't feel so natural... I feel like it's going to be difficult to debug.
[14:43] <rick_h__> frankban: +1, but hatch's feedback is good that this branch will break rendering. This branch needs to update that to follow this convention in order to land. Am I understanding this correctly?
[14:44] <frankban> rick_h__: rendering is already broken on trunk: name changes are not reflected on the panel
[14:44] <frankban> rick_h__: my branch affects how you will solve that
[14:44] <rick_h__> frankban: ok, so existing bug. /me looks for a card for that
[14:44] <rick_h__> frankban: ah, that's why hatch is noticing, that's a card he's tryinug to do
[14:45] <frankban> rick_h__: yes
[14:45] <rick_h__> hatch: so why does frankban's changes not allow you to solve your cards with that in effect by repointing where the rendered names come from?
[14:46] <hatch> so my problem is that if we are going this direction (which I agree is a good one) the ecs needs to drop the extranious data and use the db as the source of truth on commit. The deployer bar then needs to listen to any changes in the db and then determine if it needs to update anything in it's list, and so-on
[14:46] <hatch> at the moment we are going only part-way there which is just going to get confusing and introduce potential bugs
[14:46] <hatch> I'd much rather get MV out the door then go back and fix things
[14:47] <rick_h__> hatch: frankban ok, let's chat post-standup and plan a path that will work for this
[14:47] <frankban> rick_h__: sure
[14:47] <rick_h__> otp atm and can't meet pre-call
[14:47] <hatch> np
[14:49] <jcsackett> frankban: safe to bet that you now don't need that second review? sounds like that PR may see some major changes.
[14:49] <hatch> maybe...
[14:49] <hatch> :)
[14:50] <hatch> jujugui call in 10
[14:52] <jcsackett> kadams54: i see you've got a card in review, but there's no pr up yet--is PR coming, or has this already been reviewed?
[14:52] <kadams54> Which card?
[14:54] <jcsackett> kadams54: "display services without machines ..."
[14:54] <jcsackett> is LK just not updating for me?
[14:54] <frankban> jcsackett: you are right I don't need that now. however, your I'd be interested in your opinion on the design decision if you want to take a look
[14:54] <jcsackett> frankban: ack, i'll take a look then.
[14:55] <kadams54> jcsackett: hmm… that should have a PR… one moment…
[14:55] <frankban> jcsackett: thanks
[15:00] <rick_h__> makyo_: call please
[15:12]  * makyo_ zooms back home
[15:17] <bac> rick_h__: i just posted two vacation requests and a holiday for september.
[15:22] <rick_h__> bac: cool loading
[15:28] <hatch> jujugui lf another review on https://github.com/juju/juju-gui/pull/465
[15:29] <rogpeppe> Makyo: reviewed
[15:31] <frankban> hatch: why the change list shown when you click deploy and the one displayed when you click "X changes" are two different code paths?
[15:32] <frankban> hatch: UX reasons?
[15:38] <hatch> frankban I'm not sure I didn't write this
[15:38] <frankban> hatch: ok
[15:38] <rick_h__> hatch: frankban ask jcsackett
[15:38] <rick_h__> hatch: frankban there is some UX diff and such, I know there was some talk of reuse when it was added but don't recall the final fallout
[15:38] <jcsackett> rick_h__: i think that was "sprint to demo" fallout.
[15:39] <frankban> heh
[15:39] <rick_h__> jcsackett: this is making the changes button work. That was after the sprint stuff
[15:39] <frankban> rick_h__, jcsackett: fine thanks
[15:39] <jcsackett> rick_h__: we've touched it since then, but i remember hitting the two paths before that.
[15:39] <frankban> rick_h__, jcsackett: refactoring that is a separate task
[15:40] <jcsackett> rick_h__: in any event, while there are some differences, you can probably extract that into something more common.
[15:40] <jcsackett> frankban: +1, it can def wait.
[15:46] <hatch> ok I just found this....live stream..... wowzers http://www.nasa.gov/multimedia/nasatv/index.html
[15:46] <rick_h__> man, I want to chromecast that fullscreen
[15:47] <hatch> right??!?!?!
[15:49]  * rogpeppe pulls the $$merge$$ trigger on https://github.com/juju/juju/pull/253
[15:49] <rogpeppe> fingers crossed
[15:50] <jcsackett> kadams54: ping me when you've got a PR up for your card.
[15:50] <rogpeppe> hatch: cool!
[15:50] <kadams54> Yup, writing up QA instructions right now. FYI, it'll require a real env.
[15:50] <hatch> rick_h__ people these days just don't seem to understand the amazeballsness of this stuff :)
[15:52] <jcsackett> frankban, hatch: y'all still dicussing the ecs/deployer issue? fwiw looking at frankban's PR i dig the approach, but i can see where it trips us up. i would like us to move in that direction though.
[15:52] <hatch> jcsackett sorry we already did
[15:52] <hatch> ended up with a good way forward
[15:53] <jcsackett> hatch: oh, i didn't want to be in the meeting, i just want to know the outcome. :p
[15:53] <hatch> oh ok then in that case...
[15:53] <hatch> when the deployer bar gets opened to list the tasks it will query the db when required for the real values instead of extracting them from the ecs
[15:53] <hatch> that way it doesn't actually have to listen to the db for changes
[15:53] <rick_h__> woot! phone upgrades ftw. 4.4.4 finally
[15:53] <frankban> jcsackett: good to know, we will follow that approach, I will just add a commit to that branch to also handle the deployer panel
[15:53] <hatch> and we aren't live updating the dom anyways
[15:54] <jcsackett> hatch: so you are going to tackle that for your branch then?
[15:54] <hatch> rick_h__ nice - on the Moto?
[15:54] <hatch> jcsackett no frankban will add it to his
[15:54] <rick_h__> hatch: yea, dev edition
[15:54] <hatch> nice
[15:54] <jcsackett> hatch: ah, ok. i'll take a look at frankban's PR when that commit hits then.
[15:54] <hatch> I'm not sure what I'm on (goes to grab phone)
[15:54] <jcsackett> well, take another look.
[15:54] <frankban> jcsackett: thanks, appreciated
[15:55] <rogpeppe> dammit, i missed my window of opportunity. juju-core is blocked again.
[15:55] <hatch> 4.4.2 here :) on the HTC One m7 retail edition :)
[15:55] <rick_h__> rogpeppe: saw that :(
[15:56] <hatch> how does it get blocked?
[15:56] <hatch> fialing CI?
[15:56] <rick_h__> hatch: yea
[15:56] <rick_h__> when you're big enough that stuff has to be landable before a CI run can complete.
[15:57] <rick_h__> may we never get that big :)
[15:58] <hatch> haha - their CI runs must take a while
[16:00] <rogpeppe> rick_h__: +1
[16:02] <rick_h__> rogpeppe: if you get some break time could you do us a favor as a juju-core friendly person? We need to generate the list/chart of containers that are valid for different machines/environments.
[16:02] <rick_h__> rogpeppe: what does juju allow? Does it even know the rules? I know AMZ can only have an LXC, for instance. And an LXC (local) I think can only have a KVM, etc
[16:03] <rogpeppe> rick_h__: jeeze, i have little idea. last i looked, the only place containers worked reliably was on maas (and perhaps openstack)
[16:03] <rogpeppe> rick_h__: does networking now work between containers on ec2?
[16:04] <rogpeppe> rick_h__: i know there's been lots of work in that direction, but i don't know what the current status is
[16:04] <rick_h__> rogpeppe: understood. I believe lxc containers should work. I know there was work for nested lxc on local. There's an email thread around that going on currently.
[16:04] <rick_h__> rogpeppe: right, I assumed at some point juju would say yes/no when a request was made that the rules would be encoded there in core.
[16:04] <rick_h__> rogpeppe: and you'd be best able to know where that might lie
[16:04] <rogpeppe> rick_h__: it's a rats' nest
[16:05] <rick_h__> rogpeppe: oh yay
[16:06] <rogpeppe> rick_h__: i'm not even sure it forbids you from starting containers that may not work
[16:06] <rogpeppe> rick_h__: thumper's the man to speak to about this stuff
[16:06] <rick_h__> rogpeppe: ok, my sadness levels are increasing.
[16:07] <rick_h__> rogpeppe: ok, will do. I'll add a card and will see what we can figure out. Thanks
[16:17] <jcsackett> rick_h__: where should we create cards that are dependent on ditching the mv flag? that whole updated unit count thing we discussed can't be done until we can rip out all the old scaling stuff, which won't happen until mv is gone.
[16:17]  * frankban bbiab
[16:18] <jcsackett> is that on deck, or further off?
[16:19] <hatch> frankban I updated your card on the board and deleted mine
[16:21] <rick_h__> jcsackett: sorry, was looking elsewhere. What unit count thing?
[16:22] <hatch> jujugui I still need one more review for https://github.com/juju/juju-gui/pull/465
[16:23] <jcsackett> rick_h__: maybe i didn't talk with you about this, just hatch. once we only have the new scale out there's a bunch of unit count handling we don't need to do anymore; i was starting in on killing it in the branch i just put up for review, and then realized it screwed up the w/o MV path.
[16:24] <jcsackett> basically: should refactors that depend on MV flag being gone go in on deck, or pool? that's the question. :p
[16:24] <rick_h__> jcsackett: I've been moving them to on deck
[16:24] <jcsackett> rick_h__: awesome, thanks.
[16:24] <rick_h__> jcsackett: but you're right, they're post-release cleanup cards
[16:24]  * jcsackett is excited to have that refactor done.
[16:30] <hatch> jcsackett you forgot to run lint again
[16:31] <hatch> :P
[16:35] <jcsackett> i have a pre push hook that keeps telling me it's ok.
[16:35] <jcsackett> but it seems to not run, or something.
[16:36] <jcsackett> sure takes a long damn time for not running anything.
[16:36] <hatch> lol
[16:36] <hatch> jcsackett review done, I added a couple comments, I'll hold off on QA until you take a look
[16:38] <jcsackett> hatch: responded.
[16:43] <hatch> jcsackett annnnd replied
[16:43] <hatch> :)
[16:45] <hatch> *grumble grumble grumble* I think the cs is doing an ingestion again
[16:47] <Makyo> rick_h__, I got two +1s from rogpeppe and jrwren on jujusvg.  Since we don't have CI hooked up, is that just a plain click-the-green-button merge, then?
[16:47] <Makyo> Just making sure I've got the process down
[16:47] <rogpeppe> Makyo: i'd say so
[16:48] <rogpeppe> Makyo: i'm guessing you made the changes i suggested?
[16:48] <Makyo> rogpeppe, yeah, and pushed.  Thanks for the suggestions - much simpler now.
[16:48] <rogpeppe> Makyo: cool, thanks.
[16:50] <rogpeppe> listening to some stuff I hadn't listend to in years. man, the start of mahler 1, 4th movement is quite something.
[16:50] <Makyo> Mahler's dreamy~
[16:51] <rogpeppe> Makyo: my grandmum gave me a tape of it when i was about 9; i don't think i've listened to it since the tape wore out about 10 years later :-)
[16:52] <rogpeppe> Makyo: i recently threw out a large box of tapes, but not before i made a copy of them all as a Spotify playlist...
[16:52] <Makyo> rogpeppe, yeah!  I did that with a bunch of CDs a while back (though some I had to buy off iTunes or the like if they weren't on spotify)
[16:53] <jcsackett> hatch: so we can move it into addUnits, but we're going to have to call it once for every unit that's added, b/c it requires the service and there's no guarantee that we're adding units of just one service.
[16:53] <jcsackett> which seems like a lot of churn.
[16:53] <hatch> dont' we have to do that anyways now that we are manually updating the unit_count?
[16:55] <jcsackett> hatch: no, we can do a bunch of addUnit ops and then sync once per service.
[16:55] <hatch> hmm
[16:55] <jcsackett> hatch: but nevermind, given we're going to kill this as soon as remove the mv flag i think it's temporarily fine.
[16:55] <hatch> what I'm trying to avoid is the introduction of bugs because someone forgot to call some obscure method in another part of the app
[16:56] <jcsackett> hatch: yeah.
[16:56] <jcsackett> we run it for every call of onDelta--clearly it can't be hurting us that much.
[16:56] <hatch> good point
[16:56] <kadams54> jcsackett: https://github.com/juju/juju-gui/pull/471 ready for QA and review.
[16:57] <jcsackett> hatch: of course now a ton of tests crap their pants.
[16:57] <jcsackett> hatch: i'll continue pursuing this after i review kadams54 branch.
[16:58] <hatch> jcsackett heh you should be able to just stub it out
[16:58] <jcsackett> hatch: yes. in like 90 places.
[16:58] <jcsackett> a *lot* of things deal with addUnits. :p
[16:58] <hatch> hmm, and you're saying that we will be removing this call in the near future?
[16:59] <jcsackett> hatch: ideally, but i can't guarantee a timeline.
[17:00] <jcsackett> i think you're right about moving it so we don't have a landmine for someone else.
[17:00] <jcsackett> and once we dig into this to remove it we may only be removing part of it.
[17:00] <jcsackett> kadams54: lint.
[17:00] <hatch> alright sounds good
[17:00] <kadams54> jcsackett: yeah, fixing :-(
[17:02] <jrwren> I don't know Mahler's 1st. I only know 5th, 9th, and 10th. 1st is good eh?
[17:06] <jcsackett> kadams54: so, machineData.id is how we know if the machine has a service?
[17:06] <jcsackett> the check seems a little obtuse to me, as it's written.
[17:07] <kadams54> I would switch it around… machineData.id is how we know if a service has a machine associated with it.
[17:07] <jcsackett> kadams54: no, it's fine, just making sure i understood.
[17:07] <jcsackett> obtuse to me doesn't always imply wrong. :p
[17:07] <kadams54> And yes, that's why the check has comments above it :-)
[17:11] <jcsackett> kadams54: updating my live env to check yours QA could take a bit.
[17:11] <jcsackett> in the meantime, juju-gui, https://github.com/juju/juju-gui/pull/471 needs a second review.
[17:11] <jcsackett> er, jujugui ^
[17:12] <rick_h__> Makyo: +1, just make sure that tests pass before hitting that button please
[17:14] <rick_h__> yay, meeting break. /me goes to get lunchables
[17:53] <jcsackett> kadams54: my local environment completely fubarred itself (nothing to do with your code)
[17:53] <jcsackett> i'm having to start up a new one, so further delays on QA.
[17:54] <kadams54> jcsackett: While I'm relieved that my changes didn't do it, sorry this QA is so painful.
[17:55] <jcsackett> kadams54: i always have *really* bad luck setting the source for the gui charm.
[17:55] <jcsackett> i'd say there's a 1 in 3 chance it'll crap out and never recover for me.
[17:56] <kadams54> guihelp: anyone know why juju websocket requests aren't showing up in Chrome's dev tools (Network tab, websocket filter enabled) for me?
[17:57] <rick_h__> kadams54: reload the page? The network tab must be open at the start of the page load to get them
[17:57] <hatch> kadams54 quit using Canary?
[17:57] <hatch> sorry - had to
[17:57] <kadams54> hatch: Hah! THe latest and greatest web dev tools is *why* I use Canary :-)
[17:57] <rick_h__> +1
[17:57] <rick_h__> hatch: :P
[17:58] <kadams54> rick_h__: I think that's likely the problem, thanks.
[18:00] <rogpeppe> jrwren: 1st is awesome.
[18:01] <rogpeppe> jrwren: but i might be biased 'cos it was the first i ever heard
[18:02] <jrwren> Melborn, Sydney or BBC ?
[18:03] <rick_h__> kadams54: call?
[18:03] <kadams54> rick_h__: ah yes, sorry, be right there in a minute
[18:11] <rogpeppe> bac, jrwren, urulama: https://github.com/juju/charmstore/pull/50
[18:11] <rogpeppe> rick_h__: FYI i now have goahead on the charm.v3 changes.
[18:11] <rogpeppe> rick_h__: will push tomorrow
[18:12] <rogpeppe> g'night all
[18:12] <urulama> rogpeppe: good night
[18:12] <urulama> rogpeppe: excellent news on v3!
[18:12] <urulama> rogpeppe: c u tomorrow
[18:12] <rogpeppe> urulama: yup
[18:12] <rogpeppe> urulama: ttfn
[18:13] <rick_h__> rogpeppe: woot
[18:13] <rick_h__> night rogpeppe
[18:17] <jrwren> rogpeppe: i almost asked about params.Error in the last review. :)
[18:32] <hatch> bac you're running Ubuntu in Fusion right? Which version are you using?
[18:32] <bac> hatch: yes.  let me look
[18:32] <bac> hatch: 6.0.4
[18:33] <hatch> thanks, I have Parallels which runs windows 8 awesome but I'm hesitant to upgrade to support the latest Ubuntu because their current Ubuntu support is so poor
[18:33] <hatch> are there any issues with it?
[18:33] <bac> hatch: the ubikey does not work with it (though i haven't checked since the latest update)
[18:34] <bac> hatch: other than that, i've had great success
[18:34] <hatch> doesn't the ubikey just act as a keyboard? :)
[18:35] <bac> no
[18:35] <hatch> oh I thought tha'ts how it worked
[18:35] <bac> ccccccdiltlgcvgvvfibkllgcjfiujkdkhtiucinnlcl
[18:35] <hatch> case, point
[18:35] <hatch> :P
[18:35] <bac> hey, works here
[18:35] <bac> :)
[18:35] <hatch> haha
[18:35] <hatch> hey it's even cheaper to buy fusion than parallels
[18:36] <hatch> nice I'll try the demo
[18:36] <hatch> er...trial as they call it
[18:36] <hatch> :)
[18:37] <hatch> I really tried to get Ubuntu working on metal on this thing but with the discrete gpu the battery life is like 20% what it is in OSX heh
[18:38] <bac> hatch: according to this post, it should work again as of 6.0.3
[18:38] <bac> https://communities.vmware.com/thread/462755?start=15&tstart=0
[18:38] <hatch> ahh cool
[18:38] <hatch> does hotplugging thunderbolt ports work?
[18:39] <hatch> I guess I'll figure out myself tonight, but curious :)
[18:39] <bac> hatch: and it isn't just being a keyboard, but accepting the SSO programming that was the issue, i think.  it was not being recognized.
[18:39] <hatch> SSO?
[18:39] <bac> hatch: ubuntu sso
[18:39] <hatch> ohh
[18:40] <bac> hatch: i don't have any thunderbolt devices i use within the VM
[18:40] <hatch> oh ok, my monitor is display port
[18:40] <hatch> guess I'll find out
[18:40] <bac> sadly i just stare at my laptop monitor
[18:40] <hatch> I've been doing that for a while but just switched back
[18:40] <hatch> need a 31" laptop monitor
[18:41] <bac> hatch: there is a display setting that make vmware use the retina properly.  i didn't notice when the put it in and was looking at fuzzy display until frankban showed me last week.
[18:41] <hatch> oh cool I'll be sure to remember to look for that
[18:49] <urulama> hatch, bac: or just use parallels ... it's faster/better in all aspects, well, except the price tag ;)
[18:50] <hatch> urulama that's the problem though, Parallels has caused me nothing but pain with Ubuntu
[18:50] <urulama> hatch: really? it works as a charm for me ;)
[18:50] <hatch> and their support is absolute @#$%^
[18:50] <bac> urulama: you charmed parallels?
[18:50] <urulama> :D
[18:50] <hatch> urulama what version of parallels are you on?
[18:51] <urulama> hatch: a, that is the trick ... always use latest
[18:51] <hatch> urulama when 14.04 came out no version of Parallels supported it, both virtualbox and fusion did
[18:52] <urulama> hatch: they did, all you had to do is rename some xorg.conf files coz compiz and parallels tools were out of sync
[18:52] <urulama> after that (3min job) all was fine ... i do admit that they should have fixed that asap
[18:53] <hatch> urulama if you have to hack xorg files when they had more than enough time to release a patch, even months after it was released, then something is wrong
[18:53] <hatch> I'm not sure I trust them inotherwords
[18:54] <urulama> hatch: i've been using them for 3 years, and i have to admit that version 9 is the worst one ... if the trend continues with v10, i'm also open for alternatives
[18:54] <hatch> that's good to know because I'm using 8, I think I'll give fusion a go
[18:55] <hatch> they are so focused on windows that they probably have one poor dev trying to make ubuntu work in their free time lol
[18:56]  * urulama sees "slack and low priority" kanban board ;)
[18:56] <rick_h__> jujugui going afk a bit until the AU calls. I'll be a bit late for those, swim class (if the rain stays away) please give huw the heads up later. We will have the AU calls though
[18:56] <hatch> urulama exactly!! Except we don't charge $99 for the GUI :P
[18:56] <hatch> rick_h__ sounds good
[18:56] <urulama> rick_h__: enjoy
[19:12] <bac> hatch: i got yubi to work in fusion
[19:13] <bac> hatch: the only issue is doing the personalization.  to do that the VM has to recognize it as a USB device not a keyboard.  once it is personalized it works as a keyboard in both OSs
[19:14] <hatch> interesting
[19:14] <hatch> I'll have to remember that
[19:14] <bac> hatch: and the key to that is adding a stanza to the .vmx file
[19:14] <bac> usb.generic.allowHID = "TRUE"
[19:14] <hatch> so you have to do that even running 6.0.4?
[19:14] <bac> sadly yes
[19:15] <bac> hatch: and doing that gives you the opportunity to steal laptop keyboard from os x.  yikes.
[19:16] <bac> s/steal/steal the/
[19:16] <hatch> not sure what you mean
[19:17] <bac> when you add that config, it makes the yubikey visible as a usb device that you can pick and assign to the VM.  it *also* makes the in-built keyboard visible and assignable to the VM, blocking OS X from seeing the keyboard.  not advised.
[19:19] <hatch> ohh yeah that wouldn't be advised heh
[19:20] <jcsackett> kadams54: i think you should find someone else to QA your branch--i have ascertained my juju is hosed, as it cannot bring up juju-gui locally or on ec2.
[19:22] <hatch> jcsackett you have the worst luck
[19:34] <kadams54> jcsackett: ugh. Sorry man. So… who's up for QA on the cursed branch?
[19:34] <kadams54> ;-)
[19:34] <kadams54> jujugui: ^
[19:59] <kadams54> guihelp: how does the ECS send commands over to core when the deploy button is clicked? I'd assumed websocket to RPC, but I'm still seeing nothing in web inspector (and that's even in plain vanilla Chrome).
[20:00] <hatch> kadams54 via the gui backend
[20:00] <hatch> it just executes teh env calls
[20:00] <hatch> but yes it is via websocket to a real env
[20:00] <kadams54> And the env function (at least in the case of go.js) makes the call via websockets to RPC, right?
[20:00] <hatch> correct
[20:00] <kadams54> Grr.
[20:00] <hatch> RPC calls via WS
[20:48] <hatch__> jujugui does anyone object to me excluding Oneric results from the autocomplete result list?
[20:49] <hatch__> they would still be in the search results, but not in the autocomplete
[20:49] <bac> hatch__: +1
[20:49] <hatch__> bac what in the case where it's only oneric charms?
[20:49] <hatch__> should I show then? or show nothing
[20:49] <hatch__> I'm thinking nothing
[20:49] <hatch__> 11.10 was a long a$$ time ago :)
[20:50] <hatch__> and not even an LTS
[20:50] <hatch__> and it's eol'd
[20:50] <hatch__> so yeah, not even going to show oneric stuff
[20:50] <hatch__> :)
[20:50] <bac> as long as they are in the full results i think it's ok
[20:51] <hatch__> ok done thx
[20:52] <urulama> jrwren, rick_h__: added few cards for charmstore charm as suggested
[21:01] <urulama> g'night all
[21:08] <rick_h__> kadams54: link me to what review you need
[21:08] <rick_h__> kadams54: I can do it tonight and have it ready for you in the morning
[21:09] <kadams54> rick_h__: https://github.com/juju/juju-gui/pull/471
[21:09] <kadams54> rick_h__: thanks
[21:11] <hatch__> one test to go then this new AC result list is done
[21:11] <hatch__> it's bumpin!
[21:11] <rick_h__> woot
[21:11] <rick_h__> happy dance worthy?
[21:11] <hatch__> definitely
[21:17] <hatch> I think think there is something borked with the ngramming, maybe when I get a moment I'll try and take a look at it though, it's putting the wrong values on some fields I think
[21:30] <hatch> jujugui I need two reviews and qa https://github.com/juju/juju-gui/pull/472 plz and thanks
[21:31] <hatch> jcastro ^ I'm pretty sure you'll be happy with the autocomplete results from this branch
[21:32] <hatch> jcastro oneiric charms no longer show up in the autocomplete list and you only ever get the 'best possible' charms listed for what you're searching for - the full search results still contain all results of course too
[22:09] <hatch> jujugui anyone available for a review ?
[22:13] <jrwren> hatch: i'm afraid to review it.
[22:14] <hatch> haha - have you had the GUI up and running locally yet?
[22:14] <jrwren> no.
[22:14] <jrwren> The most GUI that I've run is what juju-quickstart gives me.
[22:15] <hatch> ahh then yeah this might be a bit of work for ya
[22:15] <hatch> but the hacking guide should be good enough
[22:15] <hatch> you should go through it and make notes of where it falls short
[22:20] <huwshimi> Morning
[22:20] <hatch> goooood morrow
[22:20] <hatch> I have a good review for you huwshimi  https://github.com/juju/juju-gui/pull/472
[22:21] <huwshimi> Ugh
[22:22] <huwshimi> hatch: By good, I think you meant, eye melting
[22:22] <hatch> lol, just hand wave over the algo bits
[22:22] <hatch> and do the qa :D
[22:22] <hatch> the qa is the important part anyways haha
[22:24] <huwshimi> ok :)
[22:25] <hatch> bac so I have a very odd problem, the background of the VM is only 1/5th the size of the screen, but everything else has good resolution....
[22:37] <huwshimi> hatch, rick_h__: Are we doing an AUS call today?
[22:38] <hatch> huwshimi yes but rick is delayed
[22:38] <hatch> swimming lessons or something
[22:38] <huwshimi> Ah np
[22:38] <hatch> I plan on getting drunk at 5pm
[22:38] <hatch> so better hurry
[22:38] <hatch> lol jk
[22:40] <huwshimi> that would make an interesting stand up
[22:40] <huwshimi> or lean
[22:41] <hatch> haa
[22:41] <hatch> leanup
[22:41] <hatch> https://www.youtube.com/watch?v=Ywgync45Eis <--- lol funny kiteboarding vid
[22:45] <huwshimi> hatch: Weird we have a recommended mysql charm without an icon
[22:45] <hatch> the oneric one?
[22:45] <huwshimi> hatch: Nope precise
[22:45] <huwshimi> http://localhost:8888/precise/cf-mysql-1/:flags:/mv/?text=cf-mysql
[22:45] <hatch> ohh yeah
[22:46] <huwshimi> hatch: So when I do that search for mysql it suggests that one before the mysql one, seems wrong
[22:46] <hatch> yeah I think the ngramming is busted
[22:53] <rick_h__> huwshimi: jujugui call in 2?
[22:53] <huwshimi> rick_h__: sure
[22:54] <huwshimi> hatch: So when I type "mysql" it shows cf-mysql then mysql and when I typ "cf-mysql" it shows the same (cf-mysql then mysql). That doesn't seem like a great ordering
[23:31] <jrwren> hatch: lol @ your node charm hooks. :)
[23:31] <hatch> whaaaat
[23:31] <hatch> :)
[23:31] <hatch> you can't handle their epicness?
[23:32] <jrwren> Yes, I think that is what made me chuckle.
[23:34] <hatch> they are really simple
[23:36] <hatch> huwshimi let me know if you need any more reviews so we can get some of your branches landed
[23:36] <jrwren> Yes, it was just a surprise. Probably, a reasonable node hook reference. Maybe could be used as a node template in charm-tools
[23:37] <hatch> the only issue we had in writing it was that node doesn't provide synchronous shell-out methods
[23:38] <hatch> so everything had to be in callbacks
[23:38] <hatch> it made things which required many shell-outs to get ugly
[23:38] <hatch> those have since been changed
[23:38] <hatch> this for example https://github.com/hatched/ghost-charm/blob/master/hooks/balancer-relation-changed
[23:39] <hatch> it has to do it in order, but the code is not in order
[23:39] <jrwren> That is always the nature of node or really any CPS system.
[23:40] <jrwren> you could make it in order by using inline functions everywhere. I'm sure it would get fun when you nest 10 deep. :)
[23:41] <hatch> haha definitely an antipattern
[23:47] <huwshimi> hatch: A second review on https://github.com/juju/juju-gui/pull/467 might be good, unless you want to wait till I fix that QA issue
[23:47] <hatch> huwshimi yeah I'll wait, I'll be around all night
[23:48] <hatch> so just ping whwnever you need one
[23:48] <huwshimi> hatch: Np
[23:48] <huwshimi> hatch: Do you need a real env review for you pr https://github.com/juju/juju-gui/pull/472 ?
[23:48] <huwshimi> (QA)
[23:50] <hatch> huwshimi well you can also hack the default series if you like
[23:51] <huwshimi> hatch: Ah that might be easier
[23:51] <hatch> app.js getEnvDefaultSeries() change it to return 'trusty'
[23:53] <hatch> hmm it doesn't look like I can install chrome in my new vm
[23:53] <hatch> odd
[23:53] <huwshimi> heh
[23:54] <hatch> will try the 32 bit


[09:35] <nuovolnx> I would like to install ubuntu touch on nexus 6. Is it possible? Works well? Also I would like to know if the "morph" browser has an ad-suppression plugin?
[09:42] <ogra> nuovolnx, i dont think the ubports guys are around here anymore ... IIRC they tend to use telegram via https://t.me/ubports
[09:44] <nuovolnx> ogra: I don't have a telegram, I use linuxmint on my pc
[09:46] <ogra> well, there is a telegram-desktop snap you could use ... they are simply not on IRC, if you want to contact them look for other ways over at https://ubports.com/
[09:47] <ogra> but i fear telegram is the only interactive thing they offer
[09:47] <nuovolnx> ogra: To use telegram desktop I have to telegram account?
[09:48] <ogra> indeed
[09:48] <nuovolnx> ogra: :-(


[10:21] <mgz> is there any way to mark a merge proposal as superseding another retroactively?
[10:22] <mgz> the only other option seems to be to mark it as rejected, which is a little confusing in the record
[10:22] <mgz> story:
[10:22] <mgz> contributor makes change against lp:bzr and creates mp
[10:24] <mgz> suggested to retarget against lp:bzr/2.5 instead
[10:24] <mgz> so, new branch and mp created, both in the list as needing review
[10:35] <czajkowski> mgz: not sure I'll find out and let you know
[10:54] <wgrant> Morning mgz.
[10:54] <wgrant> mgz: I don't think you can.
[10:54] <wgrant> Rejecting it is probably the best here.
[10:55] <czajkowski> wgrant: thank you
[10:56] <mgz> thanks
[11:57] <pfarrell> hi
[11:57] <pfarrell> is something wrong with proposing merges?
[11:57] <pfarrell> I am trying to propose a merge of my branch
[11:57] <pfarrell> and when I click propose merge, I just get the spinning waiting logo beside the button
[11:57] <pfarrell> but nothing actually happens
[11:58]  * pfarrell has to run to a meeting, sorry
[13:03] <Pikkachu> isn't it possible to import only a subdirectory or file from an external branch?
[13:03] <Pikkachu> why aren't branches with the same url shared among all users given they're the same stuff and unchangeable?
[13:04] <Pikkachu> also, can I merge from a specific file only? I wanted myfork/file.c and merge from hg-imported/lots-of-irrelevant/but/here/file.c
[13:09] <jelmer> hi Pikkachu
[13:09] <jelmer> Pikkachu: "bzr merge" should allow you to merge in a single file or subdirectory from another branch
[13:10] <jelmer> it will bring across all of the history of the other branch though
[13:19] <Pikkachu> all of the history? you mean metadata, like I will only notice that single file but everything is stored in the back?
[13:19] <Pikkachu> if so that helps already for simplicity
[13:20] <jelmer> Pikkachu: yes
[13:34] <Pikkachu> ah ok
[14:03] <savvas> Any other suggestions/patches to try for bug #942994 ?
[14:07] <Pikkachu> jelmer: I think I'll use this http://i.imgur.com/5aL3C.png
[14:09] <jelmer> Pikkachu: seems reasonable
[14:09] <Pikkachu> thanks
[15:44] <kirkland> flacoste: hiya!  we're still hoping for private blueprints in LP asap...any update on a target date for that feature being delivered?
[15:58] <Adri2000> would it be a good idea if the package view (distro/+source/package) showed the vcs infos from the package?
[16:29] <Adri2000> well I filed a bug
[16:49] <danilos> czajkowski, hi, I wonder if you can help me get rid of wrong packaging links in Launchpad: https://launchpad.net/linaro/+packages?
[16:49] <czajkowski> danilos: which ones?
[16:49] <danilos> czajkowski, all of them
[16:50] <danilos> czajkowski, "linaro" is a meta project and should not be linked to any source packages (or we end up with weird pages like https://answers.launchpad.net/linaro)
[16:52] <czajkowski> danilos: so you want under the 11.05 series linux-linaro-mx51   all 3 removed?
[16:52] <danilos> czajkowski, yes
[16:52] <czajkowski> danilos: done
[16:53] <danilos> czajkowski, excellent, thanks a lot for the quick response!
[16:53] <czajkowski> danilos: np
[16:53] <czajkowski> danilos: if you find any more just shout
[16:53] <danilos> czajkowski, will do, ta
[17:10] <kuuko> I'm importing translations for my launchpad project, so I would like to have clarification on the relevant guide: It says that I must have the template file in it's own directory, template1/template1.pot; Does it mean that the directory must be named after the template file or can I use any directory name like locale or po?
[17:39] <wilx> Hi. How fast do changes to Launchpad make it to production on the servers?
[17:43] <rick_h_> wilx: depends. Once a change submitted, tested, etc, it's usually live within a couple of days
[17:43] <wilx> Ok.
[17:55] <lifeless_> wilx: Once its qa'd, it can be deployed within an hour if needed; we try to deploy as often as we can to keep the change size low - reduces risk of making the change
[17:56] <wilx> Ok.
[17:56] <wilx> That's cool. I sort of feared the answer would be few weeks. :)
[17:57] <lifeless> wilx: the only thing which needs a significant delay is schema patches and thats because they take downtime to deploy; we have a window around 0800UTC daily to deploy them
[19:03] <dobey> ok, https://launchpad.net/~ubuntu-docs is definitely not what i was expecting to see there :)
[22:41] <cnd> I remember git in lp being on the roadmap a few months ago
[22:41] <cnd> is that still planned?


[03:26] <lotuspsychje> good morning
[18:36] <matt3> is better opensource or closed ? ;)
[18:48] <tomreyn> that's impossible to tell because closed source is closed
[18:49] <ogra> well, not for everyone (someone has written it) 🙂
[18:49] <arraybolt3> Opensource generally has been higher-quality in my experience, presumably because more people are able to fix problems in it.
[18:56] <matt3> yes, thank you, and ...
[18:56] <matt3> i have done a lot of apps all open ...
[18:57] <matt3> you can study inside them ...
[18:57] <matt3> with closed no
[19:03] <matt3> you can study inside the app => you can study the source code ... :)
[19:09] <matt3> with opensource => you can study inside the app ;)
[19:14] <matt3> with closed source apps => you can only use them, the apps ...
[19:15] <matt3> closed apps => only use
[19:15] <matt3> opensource => use + study
[19:15] <matt3> opensource wins ;)
[19:21] <matt3> opensource => use + study + modify + rebuild + redistributed + gratis xD
[19:32] <matt3> with gnu license is ok ...
[19:35] <matt3> RMS => please no money xD
[19:35] <arrayboltCBook> This isn't exactly within the topic of this room.
[19:35] <matt3> ok
[19:43] <ogra> seeing teward's latest mail to -release i wonder why nobody packaged tor-browser as a snap yet ... feels like a natural candidate to lock into the snap sandbox
[19:44] <teward> *drops in from orbit*
[19:45] <teward> ogra: you could ask the Tor team
[19:45] <teward> they produce team browser
[19:45] <teward> tor browser*
[19:45] <teward> ffs autocorrect be sensible
[19:45] <ogra> lol, stop IRCing from android !
[19:45] <teward> ogra: i could look into it but :P
[19:45] <arrayboltCBook> team browser - the final merge of MS Edge and MS Teams! From the Tor team. D:
[19:45] <teward> ogra: i'm not, i'm IRCing from my computer.
[19:45] <teward> and it has an adaptive keyboard on it :\
[19:45] <teward> (tablet computer)
[19:45] <teward> aaaaaaaaaaaanyways
[19:46] <teward> ogra: i'd consider snapping it but the way Tor works under the hood is it writes a lot of data to its own work dir and i'm not sure if that worsk in the snap infra
[19:46] <teward> tor circuit caching, etc.
[19:46] <ogra> well, i guess they deemed it too hard ... browsers *are* non-trivial
[19:46] <arrayboltCBook> That sounds like a bind mount would fix that?
[19:46] <arrayboltCBook> Not sure if those work with Snaps though...
[19:46] <teward> arrayboltCBook: it wouldn't
[19:46] <teward> the other factor is
[19:47] <teward> torbrowser itself is designed to launch from userspace
[19:47] <ogra> as long as the dir is not a hardcoded path writes shouldnt be a prob
[19:47] <teward> so torbrowser-launcher takes into account that it writes to its own directory space
[19:47] <teward> and 'installs' torbrowser in userspace in the defined path in its launcher
[19:47] <teward> and sets up that path there
[19:47] <teward> it's a pain
[19:47] <arrayboltCBook> teward: This sounds more like it should be dropped from Debian since it's not even designed to work right in Debian and is unsafe.
[19:48] <teward> arrayboltCBook: Debian Privacy Team keeps it in there
[19:48] <teward> arrayboltCBook: you're talking about Tor Browser
[19:48] <ogra> well, if i have some spare time (in some other galaxy i guess 😛) i might take a look at it
[19:48] <teward> not torbrowser-launcher which in itself isn't unsafe
[19:48] <arrayboltCBook> Oh.
[19:48] <teward> torbrowser-launcher could theoretically be snapped and then it defaults to userspace (~/.torbrowser/) or some path for download/install
[19:48] <ogra> *at snapping it
[19:48] <teward> but that's its own hellhole
[19:49] <teward> ogra: if you manage to snap it make sure you get the OK from Tor beforehand
[19:49] <ogra> yeah, not sure that makes a lot of sense
[19:49] <arrayboltCBook> Maybe torbrowser-installer could be made as a Snap?
[19:49] <teward> and start with firefox snap as a base idea
[19:49] <teward> because it's technically Firefox rebranded
[19:49] <teward> and forked
[19:49] <ogra> i wouldnt release it ... just create a snapcraft.yaml and offer it to them ...
[19:49] <teward> arrayboltCBook: possibly.  wouldn't solve the problem for those who've installed it with ebs
[19:49] <arrayboltCBook> If it's designed to run in a user directory, then theoretically it should just download and install Tor from the official website and plop it into the user's home directory right?
[19:49] <teward> debs*
[19:49] <ogra> i got enough snaps in the store 🙂
[19:49] <arrayboltCBook> teward: True.
[19:49] <teward> arrayboltCBook: again, doesn't solve the current bug
[19:50] <teward> it's already packaged as a flatpak
[19:50] <teward> so it should be capable to snap the launcher tool
[19:50] <arrayboltCBook> What is the bug?
[19:50] <teward> you should learn to check mailing lists :p
[19:50] <arrayboltCBook> (On a different computer without my email.)
[19:50] <ogra> yeah, the launcher would be trivial i guess
[19:50] <arrayboltCBook> teward: Not everyone can access their email without turning around and using the computer behind them... alright I'll stop being lazy.
[19:50] <teward> arrayboltCBook: https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/2000077
[19:50] -ubottu:#ubuntu-discuss- Launchpad bug 2000077 in torbrowser-launcher (Ubuntu Lunar) "Download URLs are broken" [Medium, In Progress]
[19:50] <teward> the problem is the "fix" is invasive
[19:51] <teward> and isn't easy to nitpick
[19:51] <teward> because it's intermingled with a ton of other things
[19:51] <teward> it's one of those few packages where bugfixes and features come out at the same time in merges
[19:51] <teward> *sips caffeine*
[19:52] <arrayboltCBook> Blah.
[19:52] <ogra> lovely
[19:52] <arrayboltCBook> This is why Universe should be used carefully for anything security-conscious.
[19:52] <ogra> well, at least you get CVE fixes now
[19:52] <arrayboltCBook> With Ubuntu Pro, I guess?
[19:53] <ogra> yeah
[19:53] <arrayboltCBook> Does it cover Tor Browser?
[19:53] <teward> arrayboltCBook: i mean, technically, I'm all for getting this as an MRE exception
[19:53] <teward> but i don't think SEcurity would take it
[19:53] <teward> and put it in esm-apps
[19:53] <arrayboltCBook> teward: MRE?
[19:53] <ogra> if there would be an official CVE for it ...
[19:53] <teward> micro-release-exception
[19:53] <arrayboltCBook> Ah.
[19:53] <teward> there's usually not CVEs in torbrowser-launcher
[19:53] <ogra> yeah
[19:53] <arrayboltCBook> That personally sounds like it would be the best idea.
[19:53] <teward> but because this is an "odd case" I'm going a one-off MRE request here
[19:54] <teward> if that's approved it makes prepping the SRU's that much more easier
[19:54] <ogra> i think esm-apps is for CVEs only
[19:54] <teward> ogra: it is, and for Security team control
[19:54] <ogra> right
[19:54] <teward> it's also a PITA right now
[19:54] <teward> because users are being confused "Wait I need ESM to get any security updates now?"
[19:54] <ogra> it is still in its infancy
[19:54] <arrayboltCBook> Hmm. It will be interesting to see how this plays out, I'll keep my eyes peeled.
[19:54] <teward> (see the "apt integration is too much" bug)
[19:54] <ogra> yeah
[19:54] <teward> arrayboltCBook: yeah i use torbrowser-launcher so it's one of the things I keep an eye on
[19:55] <teward> it also takes care of *updating* tor browser too so
[19:55] <ogra> i'm rather worried what happens if yu dont opt in to pro ... imagine a 5y outdated install and the list of packages in the pro notice
[19:55] <arrayboltCBook> lol
[19:55] <ogra> likely multi-page output
[19:55] <arrayboltCBook> I mean wasn't this a thing back with Ubuntu Advantagetoo?
[19:55] <teward> ogra: "5 year old release, past standard support" = "Go upgrade ya ninny" on most platforms
[19:55] <arrayboltCBook> (add a space somewhere in there)
[19:56] <teward> arrayboltCBook: Ubuntu Pro == rebranded with othe changes Ubuntu Advantages
[19:56] <ogra> well, 4.9y then 😛
[19:56] <teward> at the core ESM is still ESM
[19:56] <arrayboltCBook> teward: I think he meant, as a system gets older, the list of unsupported Universe packages could get looooooooong.
[19:56] <ogra> arrayboltCBook, universe security updates were never a thing ... best effort at most
[19:56] <teward> arrayboltCBook: that applies for things in Main too sometimes
[19:56] <arrayboltCBook> Imagine someone installing Kubuntu 20.04, updating, and getting a heart attack.
[19:56] <ogra> that is the actual great thing about pro
[19:56] <teward> but yeah universe security is usually ONLY community provided stuff
[19:56] <teward> but Pro doesn't covera ll of universe either
[19:57] <ogra> it will ovr time
[19:57] <sarnold> *was*
[19:57] <sarnold> in practice it was basically "otto prepped mariadb updates" but very little else
[19:57] <arrayboltCBook> But if you're not getting the Pro universe updates ever because you don't use Pro but apt keeps telling you about what in Universe you're not getting updates for, that will likely gradually get longer, and longer, and longer, and just clutter the user's screen and maybe even scare them.
[19:59] <arrayboltCBook> If it could be shortened to "You have community-supported packages with security updates in Ubuntu Pro, run "pro list esm-apps" for more info", that might be helpful and still let users who don't use Ubuntu Pro rest easy.
[19:59] <sarnold> but perhaps they shouldn't be resting easy
[19:59] <ogra> yeah, i guess that will need some work eventually
[20:00] <ogra> like not showing the list of package but a summary once the number exceeds a threshold
[20:01] <ogra> if you have not cared for it when the output takes two terminal pages, you are unlikely to care for it in the future 🙂
[20:01] <arrayboltCBook> Not to pick on Canonical, they do a great job, but this seems like one of those things that maybe could have used some more forethought before publishing it. The fact that users think that their systems are being left insecure is an indicator that something needs fixed.
[20:02] <arrayboltCBook> Anyway, I'm sure they'll sort it out somehow eventually.
[20:02] <ogra> well, the users *are* unsecure ...
[20:02] <arrayboltCBook> Not any more than they've always been, and all of the important stuff has been taken care of, no?
[20:02] <ogra> so it is good if users think about it
[20:03] <arrayboltCBook> True, but they don't need to think we're strongarming them into using a freemium service that is actually optional.
[20:03] <ogra> not more than they have always been ... but now that is not necessary anymore and you *can* get them ... so it is good to tell them
[20:05] <arrayboltCBook> Anyway, my opinions are nothing more than opinions, Ubuntu is and for me always has been the best Linux distro, so I'll quit my griping and go back to doing more important things :P
[20:05] <arrayboltCBook> *for me Ubuntu is and always has been, I mean
[20:06] <ogra> well, the service has admittedly still rough edges ... and lots of room for improvement ...
[20:06] <ogra> prob is that you can no really do user testing like we do with other things during the non-LTS cycles
[20:06] <arrayboltCBook> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAC+C
[20:06] <ogra> so 22.04 is actually the test cycle for it
[20:07] <ogra> meow ?
[20:07] <arrayboltCBook> (cat learning to type)
[20:07] <ogra> 🙂
[20:10] <arraybolt3> (Fun fact that I learned thanks to the above incident, try pressing Shift plus an arrow key and see what happens.)
[20:11] <arraybolt3> Shift+Up Arrow = A, Shift+Down Arrow = B, Shift+Right Arrow = C, Shift+Left Arrow = D
[20:11] <arraybolt3> (At least on my two laptops that I'm using currently.)
[20:13] <sarnold> arraybolt3: it's staggering how many people are just *now* learning that we didn't support universe packages previously
[20:14] <arrayboltCBook> And people have been using Ubuntu without problems for years with that ignorance.
[20:15] <arrayboltCBook> I love the fact that Ubuntu Pro fixes that, it just seems it may be being pushed a bit too forcefully and in ways that cause technical difficulties.
[20:16] <arrayboltCBook> And tbf the forcefulness isn't even the problem, it's the "wow are users even going to be able to use apt without inconvenience now?" that's worrying me.
[20:17] <arrayboltCBook> Maybe they will be able to still use it without problems, but making our users have to wade through info they don't want to see to tell them about a service they don't want to use seems... unhelpful.
[20:19] <ogra> well, it is easy to quieten by dpkg-divert'ing one file
[20:51] <sarnold> arrayboltCBook: apparently that initramfs 'out of memory' thing is being fixed https://blog.jak-linux.org/2023/02/01/ubuntu-key-rotation/
[20:51] <arraybolt3> \o/


[10:37] <KGB-2> gobject-introspection upstream/latest d2e4abe Simon McVittie glib/ (2038 files in 78 dirs) * New upstream version 1.73.0+ds * https://salsa.debian.org/gnome-team/gobject-introspection/-/commit/d2e4abe
[17:52] <KGB-2> gnome-shell-extension-easyscreencast signed tags a4a2742 Samuel Henrique upstream/1.7.0 * Upstream version 1.7.0 * https://salsa.debian.org/gnome-team/shell-extensions/gnome-shell-extension-easyscreencast/tags/upstream/1.7.0
[17:52] <KGB-2> gnome-shell-extension-easyscreencast pipeline Samuel Henrique 416357 * pending (extract-source: pending; build: created; build i386: created; build source: created; test-build-any: created; test-build-all: created; test-crossbuild-arm64: created; reprotest: created; lintian: created; autopkgtest: created; blhc: created; piuparts: created)
[17:52] <KGB-0> gnome-shell-extension-easyscreencast pipeline Samuel Henrique 416357 * running (extract-source: running; build: created; build i386: created; build source: created; test-build-any: created; test-build-all: created; test-crossbuild-arm64: created; reprotest: created; lintian: created; autopkgtest: created; blhc: created; piuparts: created)
[17:57] <KGB-0> gnome-shell-extension-easyscreencast pipeline Samuel Henrique 416358 * pending (extract-source: pending; build: created; build i386: created; build source: created; test-build-any: created; test-build-all: created; test-crossbuild-arm64: created; reprotest: created; lintian: created; autopkgtest: created; blhc: created; piuparts: created)
[17:57] <KGB-0> gnome-shell-extension-easyscreencast pipeline Samuel Henrique 416358 * running (extract-source: running; build: created; build i386: created; build source: created; test-build-any: created; test-build-all: created; test-crossbuild-arm64: created; reprotest: created; lintian: created; autopkgtest: created; blhc: created; piuparts: created)
[18:04] <KGB-0> gnome-shell-extension-easyscreencast pipeline Samuel Henrique 416358 * [7 minutes and 17 seconds] failed (extract-source: success; build: success; build i386: success; build source: success; test-build-any: success; test-build-all: success; test-crossbuild-arm64: success; reprotest: failed; lintian: success; autopkgtest: success; blhc: success; piuparts: suc
[18:04] <KGB-0> shell-extensionscess)


[00:59] <vanhoof> kentb_out: \o/
[06:45] <superm1> hey anyone around that can chat with me a little bit about fixing up lirc in the maverick tree?
[06:47] <superm1> particularly what's there right now is going to oops left and right on 2.6.35, and after chatting with jarod wilson about, probably the best thing to do at this point is to rebase it on the stuff he's submitting for 2.6.36 at http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git;a=summary and pull lirc 0.8.7ish userspace into maverick
[06:50] <superm1> so mostly my question is how the best way to handle this is.  for the past few releases, lirc has lived in the ubuntu/ directory by hand injected tarballs.  would it be better to just stick with that model for now, and grab latest from his git and drop them in place with the intention that they get removed for ubuntu-n since they should be available without this hackery?
[06:51] <superm1> or is there still value in trying to merge/cherry pick/rebase commits out of his tree, shuffle them around and keep all that history if the stuff would only be around for one more release
[08:20] <apw> superm1, we've just taken tarballs from you in the past, so i don't think there is any value in doing anything else this time, especially if its coming in mainline in .36
[08:21]  * smb waves to apw
[08:21]  * apw waves
[08:24] <RAOF> apw: I did see that radeon+GRUB2+graphics mode bug, but it looked like you and Colin were on it, so I wandered off to less well-tended bugs.  Also, I don't think *my* radeon system is affected, although I haven't tried particularly hard to prod the beast.
[08:25] <apw> ahhh i think its fallen through the cracks
[08:26] <RAOF> Also, in Prague the radeon systems that seemed to have problems got magically better once we killed vga16fb with fire.
[08:27] <apw> RAOF, well thats good at least, that thing is sooooo old i am amazed it can even start
[08:46] <apw> RAOF, i wonder if you would have any time to cast an eye over that radeon/grub2 thingy, as i am about to vacation
[08:47] <RAOF> I shall see if I can reproduce on my local radeon.
[08:47] <RAOF> I'm in a radeon bugfixing mood.
[08:48] <apw> heh thanks man ...
[08:57] <RAOF> apw: In return, would you kindly pass your wandering eye over bug #586325 and accept the lucid task for me?
[08:57] <ubot2> Launchpad bug 586325 in linux (Ubuntu) (and 1 other project) "[i965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X (affects: 1) (heat: 57)" [Medium,Triaged] https://launchpad.net/bugs/586325
[08:59] <apw> RAOF, ahh your cursor patch finally made it round the houses
[08:59] <apw> nomination accepted, that sounds like a patch we'd consider for lucid, though its not tiny
[09:09] <TeTeT> apw: awesome, our customer will be all excited
[09:15] <apw> heh don't let them get tooo excited
[09:16] <JFo> apw, it seems you were right with your Natty Narwhal naming
[09:16] <apw> JFo, ?
[09:16] <JFo> when we were discussing what the next release would be named in fun
[09:16] <JFo> I think it was you that said something about natty narwhal
[09:17] <apw> heh narwhal i may have got, i doubt i'd have gotten natty
[09:17] <JFo> hmmm
[09:17] <JFo> well, we were close anyway :)
[09:17] <apw> heh ... at last natty is easy to type
[09:33] <JFo> indeed
[09:33] <JFo> for this natty new release
[09:41] <JFo> apw, do you know if we have SRU plans for bug 586325?
[09:41] <ubot2> Launchpad bug 586325 in linux (Ubuntu Lucid) (and 2 other projects) "[i965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X (affects: 1) (heat: 18)" [Undecided,Triaged] https://launchpad.net/bugs/586325
[09:42] <JFo> I didn't see anything in the bug suggesting we were considering it
[09:42] <JFo> but that doesn't mean we are not
[09:55]  * abogani waves all!
[09:55] <abogani> FYI I have updated -lowlatency kernel flavour in the git tree on Zinc if anyone could-would want review it.
[09:55] <abogani> Thanks in advance for all!
[09:55] <JFo> hiya abogani
[11:18] <lag> JFo: Are you in the UK?
[11:18] <JFo> lag, yep
[11:19] <JFo> in Oxford
[11:20] <lag> JFo: I wondered why you were on the internet at some ungodly hour this morning :)
[11:23] <JFo> heh
[11:23] <JFo> sprinting with the QA folks for a community of practice meeting
[11:23] <JFo> for the week
[11:24] <lag> Isn't that like doing community service at an old folks home or special school?
[11:25] <JFo> hah
[11:25] <lag> :)
[12:24] <luftikuss> What is "kernel mode setting" generally? https://wiki.ubuntu.com/X/KernelModeSetting: "X/KernelModeSetting: Kernel mode-setting (KMS) shifts responsibility for selecting and setting up the graphics mode from X.org to the kernel." I don't want to know what it does but rather I'd like to know what KMS is. (It occasionally produces error messages on my Ubuntu 10.04.1 computer.)
[12:25] <JFo> luftikuss, it is the changing of the screen resolution of your machine
[12:26] <JFo> it is handled by the kernel now versus X
[12:48] <luftikuss> JFo: Thank you for your information.
[12:49] <JFo> luftikuss, my pleasure :)
[12:54] <luftikuss> JFo: If the X server has crashed: Is there all I can do to analyze the cause to access the crashed computer via ssh and read the /var/log/Xor.0.log?
[12:55] <luftikuss> s/Xor/Xorg/
[12:55] <JFo> luftikuss, I'm afraid my X knowledge is rather limited.
[12:55] <JFo> this may be a better resource: https://wiki.ubuntu.com/X/Debugging
[12:55] <JFo> have you taken a look there?
[13:21]  * amitk just compiled a 12Mb kernel! \o/
[13:21] <amitk> sed -i -e's/=m/=y/' .config
[13:48] <apw> smb, is master.kernel.org up for you ?
[13:48] <smb> apw, yep seems ok
[13:49] <apw> smb, hrm, seems down for me
[13:49] <smb> apw, I see other people there, too. Must be some weird routing issue
[13:51] <apw> smb, yeah must be ... can get in there via frylock
[13:51] <smb> apw, local credentials busted?
[13:51] <luftikuss> JFo: What is a "paint-by-numbers fashion" in https://wiki.ubuntu.com/X/Debugging?
[13:52] <apw> smb, its a network level connection timed out
[13:52] <smb> apw, Weird indeed. Maybe the gov is upon you ;-P
[13:52] <apw> heh maybe indeed
[13:53] <luftikuss> JFo: ~$ dict paint-by-numbers
[13:53] <luftikuss> No definitions found for "paint-by-numbers"
[13:54] <smb> malen nach Zahlen
[13:54] <apw> luftikuss, to paint by numbers is a phrase meaning 'the easy way' it comes from books with black and white outline pictures with the number of the colour to use to fill each box
[13:54] <luftikuss> smb, apw Thank you for your help.
[13:55] <JFo> luftikuss, apologies, I was away at lunch.
[13:56] <tgardner> JFo, being "out to lunch" has its own connotations.
[13:56] <JFo> tgardner, :)
[13:56] <apw> smb, does that .de translation have the same meaning as in english
[13:56] <JFo> in that case, I am always "out to lunch"
[13:56] <smb> apw, In the literal sense. Its the name for that painting style
[13:57] <apw> but you wouldn't use it to mean 'easy' generally
[13:58] <smb> I don't think commonly. You might probably say it is like paining by numbers
[14:04] <apw> smb, heh ...
[14:04] <apw> confirmed i've triggered some counter-measure ... by logging in successfully ... changed IP address at home and its all fixed
[14:05] <diwic> *paining* by numbers, is that a freudian slip?
[14:05] <smb> apw, You must have been bad.
[14:05] <apw> probabally logged in 100 times today
[14:05] <smb> diwic, Must be. Or incompetence at the keyboard
[14:18] <jdub> hey there
[14:18] <jdub> have you guys been hearing about lucid block layer issues under kvm and xen?
[14:18] <jdub> https://bugs.launchpad.net/bugs/618529
[14:18] <jdub> ^ i filed that earlier
[14:18] <ubot2> Ubuntu bug 618529 in linux (Ubuntu) "kernel call traces from blk-core.c (affects: 1) (heat: 6)" [Undecided,New]
[14:18] <jdub> there's a link to a debian bug
[14:19] <jdub> i'm having regular freezes on my linode vm
[14:19] <jdub> and it looks like there are references to this being fixed around the place
[14:21] <smb> jdub, Depends a bit whether it is real freeze or just slow as hell. If things move on after a while (possibly a long while) it probably is the general problem with writeback
[14:23] <jdub> hmm
[14:23] <jdub> ah, well, i don't mean kernel freeze
[14:23] <jdub> just to be clear
[14:23] <jdub> disk, block or vm or something sure
[14:24] <jdub> i can type 'ps afx' over ssh, for instance, but it never* returns ;-)
[14:24] <jdub> * (may not have tested this to the ultimate conclusion of "never")
[14:24] <smb> Right, so in that case its likely that writeback (block layer)  has some issues. We are working on that
[14:26] <jdub> ah, known probs
[14:26] <jdub> lovely
[14:26] <jdub> particularly on xen/kvm?
[14:27] <smb> Yeah, just not that simple to come by (there is a set of 14 patches or so). No in general on higher io loads its seems and in particular when unmounting
[14:28] <smb> I saw the same kind of messages just yesterday while compiling kernels
[14:56] <jdub> smb: is it a lucid-worthy issue?
[14:58] <smb> jdub, Definitely. There are some tests I want to do which are next on my todo list. And then moving forward. But it should get fixed sooner than later.
[14:58] <jdub> sweet! thanks smb
[14:59] <jdub> in the mean time, i will keep an eye on my poor, suffering linde... and perhaps not post more big videos :-)
[14:59] <cooloney> quit
[15:00] <smb> There might be some test kernel mentioned in bug 585092. Though they might be slightly outdated or rather suited for systems not needing dkms packages (like binary gf drivers)
[15:00] <ubot2> Launchpad bug 585092 in linux (Ubuntu Maverick) (and 2 other projects) "giant IO delays on unmount (affects: 1) (heat: 65)" [Medium,Fix released] https://launchpad.net/bugs/585092
[15:11] <gzerphey> any reason I cant load backports jaunty with the 2.6.32-24-generic kernel?
[15:14] <tgardner> gzerphey, many, many reasons, not the least of which is "it won't work"
[15:16] <gzerphey> kind of what i thought
[15:17] <gzerphey> the reason i ask is that used to be a fix for the wireless disconnect problem with 2.6.x kernels but now im not sure what to do
[15:17] <tgardner> gzerphey, try a Lucid compat-wireless package?
[15:18] <smb> tgardner, In Jaunty?
[15:18] <apw> he has a lucid kernel no ?
[15:18] <gzerphey> yes im in lucid
[15:18] <tgardner> I guess thats why I assumed Lucid
[15:18] <smb> Ah ok. thought I read jaunty
[15:19] <gzerphey> i have tried 32-21 and 32-23 with little success
[15:23] <tgardner> gzerphey, have you tried linux-backports-modules-wireless-lucid-generic ?
[15:24] <gzerphey> yes
[15:24] <gzerphey> that loaded 32-24
[15:24] <gzerphey> also no help
[15:25] <gzerphey> are you guys familiar with the problem i am running into.... the wireless randomly disconnects and I have to disconnect and reconnect to get it operational again.  this seems to happen under load
[15:49] <superm1> apw, okay i'll get a patch together that does it that way then soon, thanks
[15:49] <JFo> bjf, do we still have testing images supposed to be building daily?
[15:49] <JFo> or whenever?
[15:50] <bjf> JFo: that's the theory though i don't check on them every day
[15:50] <JFo> looks like they last built on the 5th
[15:50] <bjf> JFo: i accept patches
[15:51] <JFo> bjf :)
[15:51] <JFo> not sure what is broken, but I'll have a look later. just wanted to make sure we actually expected them to be building regularly
[15:52] <bjf> JFo: i've added it to my stack for today
[15:55] <JFo> k, or if you like I can look at it next week
[15:56] <JFo> I do need to get my knowledge together on the testing images anyway
[15:56] <bjf> JFo: whoever gets to it first
[15:56] <JFo> k :)
[17:25]  * smb -> out
[17:47] <apw> ogasawara, ok i've started the sync for the ports meta into our tree
[17:47] <apw> generally we try and keep a vagly recent copy of that in our ports branch, so that it doesn't get lost
[17:47] <apw> obviously he is maintaining that currently
[17:48] <ogasawara> apw: sweet, thanks
[18:08] <bjf> JFo: i think i fixed the daily iso image building
[18:09] <bjf> JFo: am testing now
[18:09] <JFo> sweet!
[18:15] <bjf> JFo: but is anyone using them?
[18:20] <JFo> bjf, I am planning on testing them, but I keep getting sidetracked
[18:21] <JFo> I want to make sure we are building them well before I start giving them away
[18:50]  * tgardner knows its lunchtime somewhere.
[20:27] <kees> apw: should "linux-linaro" be added to https://wiki.ubuntu.com/Kernel/Dev/ABIPackages ?
[20:29] <apw> kees, probabally, though i've never seen it before :)
[20:30] <tgardner> apw, linux-linaro is a 1000 series, the most recent upload was 2.6.35-1002.6
[20:31]  * jjohansen -> lunch
[20:33] <apw> tgardner, do we have a meta package for l
[20:33] <apw> linaro ?
[20:33] <tgardner> apw, we do, its a branch in the maverick meta repo
[20:34] <tgardner> apw, I'd have thought the k-t list traffic would have twigged you to it
[20:34] <apw> tgardner, i thought it was there, just too lazy to confirm
[21:00] <bjf> tgardner: did i miss my time?
[21:01] <tgardner> bjf, we;re in mumble  just qwaiting
[21:07] <apw> pgraner, have you dropped me that goals email ?
[21:08] <pgraner> apw, nope in 5 mins or so
[21:10] <apw> pgraner, ok i'll go grab dinner
[23:24] <jjohansen> rebooting


[02:53] <ienorand> How do I take a package from sid and put in a ppa? the whole dput thing confuses me.
[07:19] <PerryArmstrong> why are the versions beyond hardy not supporting my monitor
[07:23] <PerryArmstrong> why is jaunty not supporting my monitor screen resolution
[07:30] <rww> PerryArmstrong: This is not a Jaunty support channel. Try asking in #ubuntu :)
[13:59] <tgpraveen> have a c/c++ programming question
[13:59] <tgpraveen> and do u know what setcolor() function does? it is in graphics.h
[14:01] <bazhang> tgpraveen, /join ##c++
[14:03] <tgpraveen> bazhang: thx. but the channel seems to be in overflow
[14:08] <bazhang> tgpraveen, I will part there, perhaps they will have room then; this channel is for karmic koala you realize :)
[14:08] <tgpraveen> bazhang: i know but i thought someone might be able to help me here
[14:11] <geser> tgpraveen: to which software does the file belong? is there no documentation?
[14:12] <tgpraveen> not able to acess that at the oment it is of turbo c which is in my college but am at home right now
[18:37] <BUGabundo> hi everyone
[19:09] <DanaG> heh, Karmic kernel config: enables drm_i915_kms... but defaults to i915_modeset=0.
[19:10] <BUGabundo> ah?
[19:10] <DanaG> first is the config option CONFIG_DRM_I915_KMS
[19:13] <BUGabundo> yes
[19:13] <BUGabundo> and sec?
[22:04] <FFForever> has the repo thawed yet?
[23:12] <pwnguin> is it highly inappropriate to ask how i might upgrade to 9.04 using only a regular CD (no net, no alternate.iso) in ubuntu+1?
[23:14] <pace_t_zulu> pwnguin: a little bit...
[23:15] <pace_t_zulu> pwnguin: this channel is now for Karmic
[23:15] <pwnguin> sigh
[23:15] <pwnguin> i can pretend ive got a karmic cd instead -- it cant have changed much yet ;)
[23:16] <pace_t_zulu> pwnguin: don't worry about it.. this channel is pretty dead at the moment anyway
[23:17] <pwnguin> thats what i figured. i probably wont upgrade the laptop to karmic for another month or so
[23:18] <pace_t_zulu> pwnguin: i take it you aren't watching the Kentucky Derby
[23:18] <pwnguin> nope
[23:18] <pwnguin> it looks like there's a script to upgrade with a CD now, thats only on the alternate
[23:19] <pace_t_zulu> pwnguin: have you been to https://help.ubuntu.com/community/JauntyUpgrades ?
[23:19] <pwnguin> yea
[23:19] <pwnguin> thing is i have the regular CD handy, not the alternate iso
[23:19] <pwnguin> and a very crappy network
[23:20] <pwnguin> i was thinking id just bring in a pressed CD when they arrive, but apparently it wont have what i need anyways
[23:20] <pwnguin> so i'll probably just download an alternate CD at home =/
[23:22] <morphir_> clear
[23:23] <morphir_> *ahem*
[23:24] <pwnguin> so who here made backups before upgrading to karmic?
[23:27] <pace_t_zulu> pwnguin: you can probably modify your /etc/apt/sources.list
[23:27] <pace_t_zulu> pwnguin: replace all references of 'intrepid' to 'jaunty'
[23:27] <pwnguin> the gui tools are refusing to work without a network
[23:27] <pwnguin> "cannot grab release notes"
[23:28] <pwnguin> and i think the regex upgrade method is depricated
[23:29] <pace_t_zulu> pwnguin: uncomment the first line ... it's the important one for you ... change "Intrepid Ibex" to "Jaunty Jackalope"
[23:29] <pace_t_zulu> pwnguin: hold on... Kentucky Derby is on
[23:30] <pwnguin> heh
[23:31] <pwnguin> pace_t_zulu: i think i'll just work around are not very smart firewalls and call it a day. thanks for the enthusiasm though
[23:32] <pace_t_zulu> pwnguin: you should modify sources.list and update the references
[23:32] <pace_t_zulu> and then upgrade through the upgrade manager
[23:34] <pace_t_zulu> pwnguin: good luck
[23:35] <pwnguin> pace_t_zulu: 29 minutes left
[23:35] <pwnguin> god bless incomptetant network admins
[23:36] <pwnguin> i'd take 3 days on my desktop