[08:03] <JamesTait> Good morning all! :)
[11:37] <mandel> ralsina, ping!
[11:37]  * mandel is back :)
[13:08]  * mandel lunch
[13:37] <daveonearth> Ola Ubuntu Oners :)
[13:38] <daveonearth> Just saw this feature in dropbox
[13:38] <daveonearth> http://www.jotform.com/dropbox/
[13:38] <daveonearth> And Identified it as a brilliant and must have for UbuntuOne
[13:40] <dobey> daveonearth: tell the jotform developers to get on it? :)
[13:44] <daveonearth> dobey, I am just about to get in touch with them :) I also thought it might be a great task to add directly in UbuntuOne?
[13:45] <dobey> daveonearth: i don't see any way to do that, which doesn't involve building a web forms service
[14:16] <daveonearth> Dobey my suggestion is only that U1 offer a URL to it's user that can be cloaked and has a form to upload to a dir in U1 folder?
[14:20] <dobey> daveonearth: any web service could use the REST API to store files in a user's U1 files account
[14:21] <dobey> we don't have fine-grained access control though, so any service you authorize to access your files can access all your files
[15:04] <mmcc> hi folks. quiet backlog! no standup again today?
[15:22] <dobey> mmcc: indeed; also, you've only be on-line for 10 minutes :)
[15:22] <dobey> there's only 4 of us working today
[15:30] <mmcc> heh, I was looking at the web irclogs too, but I guess that has some lag :)
[15:31] <dobey> ah
[15:44] <dobey> ok, must get lunch. bbiab
[16:15] <mmcc> brb, coffee
[16:51] <rye> dobey: u1.to has the upload facility... when it works
[16:52] <rye> does anybody know how to get ubuntuone pairing record on 12.04 for couchdb?
[16:57] <dobey> rye: "don't" but also you can install desktopcouch-ubuntuone though it might be broken
[17:01] <rye> dobey: well, contacts syncing was not said to be discontinued, so it is expected to be working
[17:02] <dobey> rye: it is not installed/enabled by default, we don't provide a ui to install/enable it, and we announced we would be dropping support for it. until we turn off the server, it will continue to randomly work or not work, depending on an innumerable number of variables over which no man has any control :)
[17:07] <rye> dobey: AttributeError: 'module' object has no attribute 'DBUS_CRED_PATH'
[17:07] <rye> dobey: with nightlies :(
[17:08] <dobey> eh?
[17:08] <dobey> rye: what version exactly?
[17:09] <dobey> rye: or is that from desktopcouch?
[17:10] <rye> dobey: that's from desktopcouch, frankly speaking i don't see any announcement regarding the future of contacts syncing
[17:10] <dobey> https://lists.ubuntu.com/archives/ubuntu-desktop/2011-November/003474.html
[17:11]  * dobey needs to poke about getting desktopcouch pulled from the archive for 12.10
[17:13] <dobey> rye: just saw this too: http://askubuntu.com/questions/161640/what-should-i-do-if-i-didnt-recieve-the-verification-email-for-ubuntu-1
[17:18] <rye> dobey: contact ISD
[17:20] <rye> dobey: answerred
[17:20] <rye> r
[17:21] <dobey> thanks
[17:21] <mmcc> dobey: if you have some time, I have a Needs-Information for your Needs-Fixing on https://code.launchpad.net/~mikemc/dirspec/add-exefind/+merge/113782 (and I made some changes to that branch)
[17:24] <dobey> ok, will re-review and answer shortly
[17:25] <mmcc> thanks.
[18:50] <dobey> it's brain thinking time
[19:04] <mmcc> lunch eating time, over here.
[20:17] <dobey> hrmm
[20:17] <dobey> on win32/darwin, is sys.frozen a boolean or what?
[20:19] <mmcc> checking...
[20:21] <dobey> searching the interwebs is not helpful
[20:22] <mmcc> nope, it is not ...
[20:22] <dobey> and all the examples i see are using hasattr()
[20:23] <mmcc> right - it's apparently not defined in the sys module, it's set by py2exe and py2app's bootloaders.
[20:23] <dobey> right
[20:23] <mmcc> py2app sets it to a string, either 'macosx_app' or 'macosx_plugin'
[20:24] <mmcc> cx_freeze sets it to a boolean
[20:24] <dobey> ah-hah
[20:24] <mmcc> (True, obv)
[20:24] <dobey> sys.frozen only exists in the executable. It is set to "console_exe" for a console executable, to "windows_exe" for a console-less gui executable, and to "dll" for a inprocess dll server.
[20:24] <mmcc> and apparently, pyinstaller also sets it to a bool
[20:25] <dobey> ok
[20:25] <dobey> so falling back to None should be fine then
[20:25] <mmcc> yeah, I think so
[20:25] <dobey> was just making sure it wasn't getting added as an attribute that was set to None :)
[20:26] <dobey> because that would be fun...
[20:26] <mmcc> I guess we could simplify the platform check a bit, and just check sys.frozen against 'console_exe' or 'macosx-app' or whatever, but actually, then we'd get two cases for windows, so...
[20:26] <mmcc> yeah
[20:27] <dobey> yeah i'm not sure we want to do that exactly
[20:28] <mmcc> yeah, no, probably not
[20:41] <dobey> mmcc: ok, finally got some comments added to that proposal. hopefully what i said makes sense, and i don't sound like an oppressive tyrant :)
[20:42] <mmcc> ha, dobey. thanks for looking at it carefully. If we're going to try to unify things to pay down tech debt, it's worth getting it right.
[20:42] <mmcc> now I'll go read it and we'll see how oppressed I feel
[20:42] <dobey> heh
[21:05] <mmcc> I'm beginning to think the cross-project exe finder is a bad idea
[21:06] <mmcc> I'm writing up what the API would look like if we avoid passing in a module, which I agree is kind of gross
[21:10] <dobey> well, it's better than writing the same code N times i guess :)
[21:15] <mmcc> dobey, I guess that depends on what you think of how it looks with explicit parameters - I just updated the merge with another comment with some details.
[21:16] <mmcc> if N = # projects instead of # callsites, it might be OK, and the code would definitely be simpler
[21:17] <mmcc> a good deal of this complexity is because we want to use it for sso and u1_client / controlpanel, and we want dirspec to avoid knowing anything about its clients
[21:18] <mmcc> if I wrote one version for sso and one for ubuntuone/platform/ipc, each one could be simpler - you could use the module's __file__ and a local app_names dict, and it wouldn't be so weird
[21:19] <dobey> well it wouldn't be weird, because those aren't libraries that people might use for finding stuff.
[21:19] <dobey> so they can be very specific
[21:20] <mmcc> exactly.
[21:20] <dobey> and obviously putting in specific things to a generalized place, will seem weird
[21:20] <dobey> but part of those specific things, is also the duplication of some generic code
[21:20] <dobey> and just read your comment
[21:21] <dobey> will need to do a bit more brain thinking on it
[21:21] <mmcc> sure, while you do that I'll think about your other point - why we need to / shouldn't do the 'python ' prepending...
[21:35] <mmcc> dobey, I wrote more words about that issue, on the MP. basically, I agree it shouldn't be in the module. we probably shouldn't have to do it at all, but I'm not sure it's worth fixing/replacing buildout before I can move forward on this...
[21:41] <dobey> mmcc: ok, i'm not sayinf we should fix/replace buildout as a means of blocking this branch. i do think it needs further discussion though, and i'd like to avoid diverting the core issue of the branch (unifying the find_me_an_executable stuff), by also having that in the branch. perhaps prefixing python in the calling method when needed, for now. mostly i don't understand why this code would ever launch anything that wasn't instal
[21:42] <dobey> anyway, i will also think about that some more as well
[21:44] <mmcc> oh, I didn't think you were saying fix buildout first, I was just trying to give my understanding of why it's currently necessary to prepend python when running from source.
[21:45] <mmcc> the reason it'll launch things that aren't installed is e.g. when I'm running controlpanel from source while trying to fix bugs, it will need to run syncdaemon from source - at least on darwin there's no good 'general' installed location to default to looking in - either it's all in the same packaged wrapper or it's all in wherever we put the source trees.
[21:45] <dobey> right, i understand the /usr/bin/python thing and python path thing. what i don't understand, is why this is happening at all; iow, what is running stuff from the tree where this is a problem?
[21:46] <dobey> ah ok
[21:46] <mmcc> s/packaged wrapper / packaged app bundle/
[21:46] <mmcc> and the app bundle takes a long time to build, so you really want to be able to run it from the source trees
[21:47] <dobey> right. thanks
[21:47] <dobey> i will think on it a bit more, knowing that
[21:47] <mmcc> cool. thanks
[21:48] <dobey> and am out of here for now. i'll comment tonight or in the morning, whenever i think of more useful words to put there :)
[21:48] <dobey> later
[21:51] <mmcc> ok, bye dobey. thanks again


[00:00] <callan> I asked what was happening, I was refused any information from you guys because I have to go through staffers even though this is an issue with ubuntu
[00:00] <callan> then I leave and some idiot starts talking like I'm in on it and there's a conspiracy against "the council"
[00:00] <callan> tomaw: I talk to you
[00:01] <callan> you assure me nothing is wrong, you're dealing with it and the is not some big thing against the arch offtopic channel
[00:01] <callan> despite there being now like 20 staffers in it idling
[00:02] <callan> and now out of nowhere I get told you've sent phrakture a warning to keep the channel in line
[00:03] <callan> this secrecy stuff is, frankly, retarded. if you're going to start sending me warnings about the channel how about you be a bit more transparent about what's happening
[00:03] <callan> it's not some ubuntu trolling headquarters
[00:03] <MenZa> 'you' being who, specifically?
[00:04] <callan> ubuntu ops? staffers? hell if I know
[00:04] <callan> I ask questions I get pushed around to other people
[00:04] <MenZa> Bureaucracy, in all its glory, does have some disadvantages, callan.
[00:05] <MenZa> Now, I've tried to distance myself from this 'issue' in the past, because frankly, I don't know much about it.
[00:05] <callan> I wish I knew much about it
[00:05] <callan> because I'd love to clear it up
[00:06] <callan> I feel terrible archlinux is being branded as some some group of professional trolls and I want to change that
[00:06] <MenZa> callan: So let me confirm; you're an op in #archlinux-offtopic, yeah?
[00:06] <callan> yes
[00:06] <MenZa> I also absolutely agree.
[00:07] <callan> I'm glad you're actually talking to me, it was really insulting how I was treated last time for something so trivial
[00:07] <MenZa> To be honest, it sounds like someone should sit down and talk this through intently - you and a number of other ops - and our IRC Council, depending on how your organisational structure is
[00:07] <MenZa> just so we can clear this up completely
[00:07] <callan> I'd love to
[00:07] <MenZa> because it's, frankly, annoying me not knowing anything about it and constantly hearing about it
[00:07] <MenZa> :P
[00:08] <MenZa> In that case, I suggest you send an e-mail to the IRC council mailing list and invite them to such a meeting.
[00:08] <callan> is there somewhere I can read about the "irc council"?
[00:09] <callan> and are you really constantly hearing about it? because I haven't heard a thing in about a month
[00:09] <Seeker`> all I am aware of is that we occasionally get groups of trolls in #ubuntu, and one thing these users have in common is that they are all in #archlinux-offtopic
[00:10] <MenZa> keep in mind though; the IRC Council is up for elections currently, so there may be a delay in response.
[00:10] <MenZa> but I most definitely think that'd be the way to go about solving this issue.
[00:10] <MenZa> (again, not knowing much about it)
[00:10] <MenZa> The e-mail is<EMAIL_ADDRESS>[00:10] <MenZa> Certainly, callan - https://wiki.ubuntu.com/IrcTeam/IrcCouncil
[00:11] <MenZa> callan: to sum up, the IRC Council is the body which organises the #ubuntu* namespace.
[00:11] <callan> Seeker`: it is a coincidence I believe, I am often active and I've never seen any organization in the channel and even warned against it
[00:11] <callan> MenZa: thankyou very much
[00:11] <callan> really
[00:12] <elky> callan, the issue tends to be that the archlinux-offtopic channel gets turned in to a organisation base by these trolls. they can at times be seen coordinating in there.
[00:13] <elky> they use it to boast about what they managed to do, who they managed to tick off, give running commentary of who they're currently harrassing -- that sort of thing
[00:13] <callan> I guess I can agree with you there. I've seen that
[00:14] <elky> and when ops sit back and watch it, it's sort of taken as tacit approval, by both the trolls, and us.
[00:14] <callan> I've got no problem banning people who are continually acting up
[00:15] <callan> but I've never really seen any proper logs of it happening either
[00:15] <elky> but youve seen the scheming...
[00:16] <callan> once or twice I've seen the boasting but I'm not completely convinced the channel is some base of operations like is being made out
[00:17] <callan> would staffers prefer I left it so they can keep track of this stuff or that I just ban people straight out
[00:17] <elky> we dont want it to be either, but whilever they're allowed to encourage each other and boast about their spoils there, then it's hard to see that it isnt.
[00:18] <callan> as far as I am concerned I don't care what the people do as long as they don't do it in the channel
[00:18] <elky> you would have to ask staffers directly. we're just namespace ops
[00:18] <callan> but maybe staffers want to fix the root of the problem?
[00:18] <callan> ok
[00:18]  * MenZa points out that trolling is against the Freenode guidelines, and think it's any self-respecting op's duty to enforce those in their channel.
[00:19] <MenZa> We ask our users to respect the freenode rules, in addition to our own governance documents.
[00:19] <callan> agreed
[00:19] <MenZa> So it's really quite simple then, isn't it? :)
[00:19] <callan> I guess in the best case scenario that channel shouldn't even exist because it's pretty seedy
[00:19] <callan> but if we kick them out of there they go back to the main channel
[00:19] <callan> and ever since the offtopic channel became proper it's done wonders for the main channel
[00:20] <elky> we sometimes say the same about our own offtopic channel, but believe it or not, kicking them out of there is just as easy as kicking them out of the main channel.
[00:20] <MenZa> We keep a strict rule of not allowing anything but support in #ubuntu. -offtopic is for (just about) everything else.
[00:20] <elky> letting someone stab you as a compromise for not cutting your throat is a bit silly.
[00:21] <MenZa> elky loves her analogies.
[00:21] <elky> because they're *good* :P
[00:21] <MenZa> I never said they weren't :P
[00:21] <callan> ok this has definitely been helpful. I'll keep stricter and I'll try and organize some sort of meeting
[00:21] <callan> anything else I need to know?
[00:21] <MenZa> (you can ask elky - she sits on the council)
[00:22] <elky> i think that's all i have to say for now. i'm at work and behind on things because i was off sick last week
[00:23] <callan> elky: would it be better to just send an email then?
[00:23] <elky> cant hurt to.
[00:24] <MenZa> niko: you alright there?
[00:24] <callan> alright I might as well get out of here then before I get awkwardly asked and then removed
[00:24] <callan> thanks for your help
[00:31] <niko> MenZa: yes
[00:35] <MenZa> heh
[00:35]  * niko looks at hole with all cables
[00:48] <Flannel> Howdy Anacranom, how can we help you today
[00:48] <Anacranom> sorry, was just looking to see if iWolf was in here, he's giving bad/incorrect info...
[00:49] <wgrant> Anacranom: What in particular?
[00:50] <Anacranom> let me know if i was the one incorrect since the change to 9.10 i am not yet fully familiar with
[00:50] <wgrant> Are you talking about the root thing?
[00:51] <Anacranom> he told me "No" thath gksudo gedit... was not right way to edit the xorg.conf,,, that you needed root
[00:51] <Anacranom> and it went on from there untill i let the,,, well always let the last word go to... lol
[00:52] <Anacranom> wasn't trying to cause probs, just wanted to see if he was a new op or if i was wrong?
[00:53] <elky> Anacranom, he was wrong.
[00:54] <wgrant> Anacranom: You said 'or nano', without sudo. Perhaps he misinterpreted that.
[00:54] <wgrant> Other than that, his assertions about needing root were correct, if slightly unclear.
[00:54] <Anacranom> ok, because i can own up to it when i am, and can correct myself and give appologies,,, but I would always like to know the correct
[00:54] <Anacranom> maybe
[00:55] <elky> gksudo gedit is correct though, dont fret that.
[00:56] <Anacranom> well i said "or nano" as i noticed while i was typing the other guy suggested nano..
[00:56] <Anacranom> well anyway,, TY for your time
[02:53] <KB1JWQ> Guest13970 is nick changing and trolling a bit each time.
[02:53] <KB1JWQ> Fun to trace the lastlog on him.
[02:54] <wgrant> Yup.
[02:54] <wgrant> I'm watching.
[02:54] <KB1JWQ> wgrant: Ah, I leave it in your capable hands then. :-)
[03:12] <KB1JWQ> Heh, he's gotten worse, wgrant
[03:14] <tsimpson> hmm, the wiki has died
[03:14] <KB1JWQ> That's not good.
[03:15] <tsimpson> help.ubuntu.com is still up, most of the docs should be there
[03:16] <tsimpson> !search wiki.ubuntu.com
[03:16] <tsimpson> !search help.ubuntu.com
[03:17] <tsimpson> there must be more than that...
[03:18] <tsimpson> ah, it only returns 10 results
[03:22] <Flannel> tsimpson: help.ubuntu.com is where help docs go, wiki.ubuntu.com is where team stuff happens
[07:19] <dholbach> good morning
[08:57] <jussi01> !search grub
[08:57] <jussi01> !grub2
[08:57] <jussi01> !no, grub2 is <reply>GRUB2 is the default Ubuntu boot manager in Karmic. For more information and troubleshooting on GRUB2 please refer to https://wiki.ubuntu.com/Grub2
[08:58] <jussi01> !grub2 > jordan_u
[08:58] <jussi01> hiya Jordan_U
[08:58] <Jordan_U> Hi
[08:59] <jussi01> Jordan_U: something we can help with?
[09:00] <Jordan_U> Just wanted to discuss whether having a specific !grub15 is a good idea
[09:00] <jussi01> !scope | Jordan_U
[09:01] <Jordan_U> I origionally wanted to add it before I added that section to the wiki page
[09:01] <Jordan_U> I guess it makes less sense now that I have
[09:01] <jussi01> :)
[09:01] <jussi01> Jordan_U: youve gone about it correctly, by adding it to the wiki
[09:02] <Jordan_U> I agree with you now that I think about it, so thank you.
[09:32] <KB1JWQ> FYI, Avash has been booted for trolling a number of channels earlier.
[09:32] <KB1JWQ> Seems on topic in #ubuntu, but figured I'd throw that out there.
[09:54] <ikonia> eyes are open
[09:55] <ikonia> avash has been a problem in #ubuntu before
[11:49] <jussi01> [13:46:46] <Riddell> that'll be the archive open
[11:49] <jussi01> Thoughts on whether we should now re-open #ubuntu+1?
[11:50] <bazhang> sparr would insist on it!  :)
[11:50] <elky> you're going to have a hard time if you dont.
[11:51] <jussi01> hrm, I disagree. still think we should be waiting on alpha 1. but meh...
[11:51] <jussi01> hrm
[11:52] <jussi01> maybe I change my mind...
[11:52] <jussi01> [13:50:33] <Riddell> there's only three alphas this time, and two betas
[11:53] <elky> jussi01, if you dont, we'll just direct every person who asks for +1 to PM you directl.
[11:54] <topyli> i think the idea is to release a working system, so the beta period is long
[11:54] <bazhang> #jussi+1
[11:54] <topyli> #jussi+01
[11:54] <bazhang> hehe
[11:54]  * jussi01 declines to join...
[11:54] <jpds> Lucid is open NOW.
[11:54] <bazhang> :0
[11:54] <jpds> See -devel.
[11:54] <jussi01> jpds: thanks for repeating...
[11:55] <elky> jpds, read up, dear
[11:55] <jpds> jussi01: You are welcome.
[11:58]  * jpds finishes his coffee.
[12:12] <jussi01> oh dear. we are going to have a lot of openweek# in -classroom this week.... https://wiki.ubuntu.com/UbuntuOpenWeek
[12:30] <topyli> oh and a session on behavioral irc research
[13:47] <Amaranth> People keep joining #ubuntu-classroom-chat and asking #ubuntu-like questions
[13:48] <pleia2> Amaranth: I've just been explaining things to them
[13:48] <pleia2> it happens :)
[14:06] <jrib> topyli: hrmm, what's that about?
[14:07] <topyli> jrib, i just mangled the topic of jussi's irc talk on thursday
[15:56] <tsimpson> @channel #ubuntu+1 plugins.PackageInfo.defaultRelease lucid
[15:58]  * jpds adds lucid to ubot2 and ubot4.
[16:00] <jpds> OK, this could be an issue
[16:02] <tsimpson> I just copied the karmic.list and karmic-backports.list and run sed -i 's/karmic/lucid/g' lucid*
[16:02] <tsimpson> *using archive.u.c rather than a local mirror
[16:02] <jpds> Yeah, that's what I did, but now I'm out of diskspace, re: -irc.
[16:02] <tsimpson> ah
[16:03] <Amaranth> oh, are we opening it now?
[16:03] <Amaranth> it seems the toolchain is done, lucid is open for normal uploads
[16:03] <tsimpson> Amaranth: the archive is open, but it's pretty much just karmic atm
[16:06] <Amaranth> tsimpson: I hope to get a rather major change to compiz uploaded to lucid this week so changes are starting to happen :)
[16:07] <tsimpson> I know, but it's not exactly "usable" now is it ;)
[17:03]  * MenZa pokes Amaranth
[18:27] <tsimpson> voyager1: how can we help you?
[18:27] <voyager1> no problem
[18:28] <tsimpson> if you don't have an issue we'd request you part this channel, so we know who needs help
[18:28] <tsimpson> !idle
[20:24] <ikonia> fyi: crude - aka derek_smart appears to be a regular in #archlinux-offtopic now, shock horror, stop the presses
[23:13]  * genii-around slurps a coffee
[23:19] <ikonia> is #ubuntu+1 open yet ?
[23:19] <ikonia> I thought it was, it appears not to be
[23:20] <ikonia> any thoughts on clearing u-r-p yet?
[23:29] <mneptok> IIRC, it was cleared a few days back.
[23:29] <ikonia> lots in it now
[23:32] <Pici> its +if #ubuntu-offtopic
[23:32] <Pici> when it gets smaller we'll kick the rest of the people out
[23:34] <mneptok> Pici: why not now?
[23:34] <jpds> Err, dudes.
[23:34] <jpds> -bugs.
[23:34] <Pici> ugh
[23:34]  * Pici checks the bantracker
[23:34] <jpds> Just saying.
[23:35] <Pici> jpds: thanks for the heads up
[23:35] <Pici> mneptok: Because we had discussed earlier that we'd do it later ;)
[23:35] <mneptok> ack
[23:36] <Pici> Also, its never a good sign when I go to search on a name on the bantracker and theres already an autocomplete for it.
[23:37] <ikonia> ha ha ha
[23:39] <nalioth> mneptok: not cleared, just closed
[23:40] <Pici> Actually, I can't seem to find a ban for limcore in -bugs, although there are ones for #u and #u-offtopic
[23:40] <ikonia> he's not banned from -bug
[23:45]  * genii-around ponders this tetrahedral head apparel
[23:46] <Flannel> genii-around: It's important to always have 1d4 at your disposal
[23:47] <genii-around> Geez, AD&D


[00:56] <chu> daftykins: I see you too!
[00:57] <daftykins> ERMAGERD
[00:57] <daftykins> *ermatux
[05:02] <lotuspsychje> good morning to all
[05:03] <Bashing-om> lotuspsychje: o/
[05:03] <lotuspsychje> hey Bashing-om
[05:05] <Bashing-om> lotuspsychje: Not much at all going on . Been an off session .
[05:06] <lotuspsychje> kk tnx for the headsup
[05:21] <lotuspsychje> JonesyJ: thats your nex nick?
[05:21] <lotuspsychje> new
[05:22] <JonesyJ> yeah other one is taken
[05:22] <lotuspsychje> kk
[07:20] <ducasse> good morning
[07:39] <jink> 'sup.
[07:40] <ducasse> snow :(
[07:42] <jink> Heh. :)
[07:46] <ducasse> cat seems utterly perplexed and shocked at this phenomenon :)
[08:25] <oerheks> best thing is to roll the cat in the snow
[08:25] <oerheks> :-D
[08:26] <ducasse> that would make me an enemy for life :)
[08:28] <oerheks> shake that cat-diner, and see
[08:28] <ducasse> how's your weather today, oerheks?
[08:28] <oerheks> Dry, 8'C, little cloudy
[08:30] <oerheks> Bought a bakfiets yesterday, going to show mom later on
[08:30] <oerheks> http://imgs.advertentiex.nl/upload/Origine-bakfiets-fietsfabriek-995-zwart-10339.jpeg
[08:30] <oerheks> but 1st i will have coffee now
[08:31] <ducasse> sounds like a plan :) congrats on the new bike
[08:31] <oerheks> 3 wheel has to go, not really comfy to ride
[11:18] <BluesKaj> Hi folks
[22:08] <TJ-> !ram
[22:10] <daftykins> another one? :)


[00:18] <cholcombe> is there a list somewhere of the allowed types in actions.yaml?
[00:18] <cholcombe> i thought there was but i'm having trouble finding it now
[00:20] <cholcombe> ah ok i see. it's the json schema types.  Nevermind.  http://json-schema.org/latest/json-schema-core.html <-- for future people
[00:23] <arosales> man zeppelin doesn't like zenial or spark stand-alone or both
[00:23] <arosales> debug continues
[00:23] <arosales> but dinner calls
[00:23] <arosales> s/zenial/xenial :-)
[00:34] <cholcombe> lazyPower, 2 new interfaces today thanks to icey's help: https://github.com/cholcombe973/juju-interface-ceph https://github.com/cholcombe973/juju-interface-backup
[07:36] <jacekn> marcoceppi: so I understand what you are saying I just completely disagree with that approach. If you "charm pull-source" for an official, curated charm you should absolutely get official and curated layer. Not one from someone's personal branch who may have decided to add "rm -rf" there just for laugh
[07:37] <jacekn> marcoceppi: defaulting to more secure approach is always good, especially if it's so trivial to do
[08:07] <jamespage> gnuoy, before I raise any more reviews
[08:07] <jamespage> can you sanity check one of https://review.openstack.org/#/q/topic:network-spaces
[08:07] <gnuoy> sure
[08:07] <jamespage> the delta is pretty small
[08:08] <gnuoy> jamespage, duff grammer in README.md
[08:08] <jamespage> gnuoy, hah
[08:09] <gnuoy> jamespage, when you say "deployer" in the README do you mean that syntax is valid for both juju-deployer and juju native deployer and if not maybe its worth being explicit?
[08:10] <jamespage> gnuoy, I was intentionally vague
[08:10] <jamespage> the juju v4 bundle format in juju supports it
[08:10] <gnuoy> haha ok :)
[08:14] <gnuoy> jamespage, other than that cinder lgtm
[08:14] <jamespage> gnuoy, can you comment on the README and I'll update all of them
[08:18] <gnuoy> jamespage, done
[08:22] <kjackal> hey people, is there a way to tell amulet to "attach" to an existing set of charms instead of deploying them from scratch? I am trying to save up some time while writing tests.
[08:25] <gnuoy> kjackal, not that I know of but let me know if you find a way!
[08:26] <kjackal> ok gnuoy
[08:44] <deanman> Hi, do you keep logs of this channel somewhere?
[08:46] <magicaltrout> deanman: http://irclogs.ubuntu.com/2016/03/31/%23juju.txt
[08:46] <deanman> magicaltrout, thanks
[08:58] <kjackal> gnuoy, running the same test for a second time will not redeploy the charms so it does more or less an attach
[08:59] <gnuoy> kjackal, well, you still loose time while it looks at the deployment, I want a way for it to jump straight to the functional tests themselves
[09:00] <kjackal> yes, true
[09:09] <Sophie_> hello my dear folks
[09:10] <Sophie_> I got a trouble situation here...
[09:54] <jacekn> would anybody have time to have a look at my collectd subordinate review? https://bugs.launchpad.net/charms/+bug/1538573
[09:55] <mup> Bug #1538573: New collectd subordinate charm <Juju Charms Collection:New> <https://launchpad.net/bugs/1538573>
[09:58] <magicaltrout> jacekn: you had your turn, back of the queue now! ;)
[10:00] <jacekn> magicaltrout: the queue is a lie! If you don't ask here you don't bet review ;)
[10:00] <jacekn> s/bet/get/
[10:01] <magicaltrout> true
[10:32] <deanman> magicaltrout, apart from irc logs retention on the link you gave me is there any other alternative that you can suggest for following discussion here offline ?
[10:33] <magicaltrout> yeah, spin up the juju big data quickstart, ingest the log files into hadoop and run a bunch of Map Reduce textual analysis over it.....
[12:39] <neiljerram> Did the Ubuntu keyserver have a problem in the last hour?  I was seeing GPG key retrieval fail during bundle deployment; then suddenly it started working again...
[13:10] <marcoceppi> jacekn: there is no official curated layer. YOUR layer is the official one, we don't store layers, and you're the trusted upstream because we trusted you to put the charm in the store
[13:13] <jacekn> marcoceppi: trust level can change easily, social engineers just wait for holes like this (gain trust, get something into the charmstore and then exploit it by modifying their layer)
[13:32] <marcoceppi> jacekn: but modifying the layer won't affect the charm in the store
[13:35] <jacekn> marcoceppi: no but it will affect everybody who wants to develop the charm or those who want to compose right before deployment for new hotness
[13:36] <marcoceppi> jacekn: but that's on /them/ to validate the source they're building
[13:36] <jacekn> marcoceppi: I really can't see why keeping layers in non-personal branches is a bad idea
[13:36] <marcoceppi> jacekn: we don't own any branches anymore
[13:36] <marcoceppi> jacekn: launchpad ~charmers as we know it is dead
[13:36] <jacekn> marcoceppi: sorry but realying on people fails sooner or later
[13:36] <jacekn> marcoceppi: oh really? So all new charms in the charmstore are under personal branches?
[13:36] <marcoceppi> jacekn: there is no "personal branch"
[13:37] <marcoceppi> there's no branch
[13:37] <marcoceppi> it's just a blob upload
[13:37] <marcoceppi> promulgation is a pointer to the namespace it was uploaded to
[13:37] <marcoceppi> and we gate allowance of people updating promulgated charms
[13:37] <marcoceppi> we do all the QA we do now, but the person who created the charm "owns" the space
[13:37] <jacekn> marcoceppi: so what happens if I delete my LP account one day?
[13:38] <marcoceppi> jacekn: who cares? it's gone. The charms will still be in the store it's fine
[13:38] <jacekn> marcoceppi: well those who might want to submit patches will care, if there is no branch there is no way to raise MP
[13:39] <marcoceppi> jacekn: well, we have a way to change ownership of a promulgated source, and people can pull the charm - as it is compiled - and uncompile it since we have a manifest that tracks the files and what layers they came from
[13:39] <marcoceppi> it can be rebuilt somewhere else
[13:39] <marcoceppi> or just updated in place
[13:39] <marcoceppi> the charm store is the single source of truth regardless where upstream development is
[13:40] <marcoceppi> what happens if an upstream's code goes away one day
[13:40] <marcoceppi> the packages in the archive won't suddenly break
[13:40] <jacekn> marcoceppi: if I wipe my LP accont there will be no layer to pull
[13:40] <marcoceppi> jacekn: I can reconstruct your layer, from the built charm
[13:40] <mbruzek> Hi guys do we have the key/value "configuration" (in layer.yaml) documented anywhere? Like how do I get those values and what would be a good case to use them?  Asking for a friend.
[13:41] <marcoceppi> mbruzek: not quite documented much anywhere - yet, but we do have a few examples
[13:41] <jacekn> marcoceppi: wow all this seems super weird and is IMO asknig for trouble. In any case - the error that was noticed is NOT picked up by the latest stable charm-tools
[13:41] <jacekn> marcoceppi: so I can't even test the fix
[13:41] <mbruzek> marcoceppi: is it mostly the big data guys?
[13:42] <mbruzek> marcoceppi: I would like to send my friend an example.
[13:42] <jacekn> marcoceppi: and of course I'm not too happy about fixing something that's clearly not a requirement when I use stable tools
[13:43] <marcoceppi> mbruzek: https://github.com/juju-solutions/layer-basic/blob/master/lib/charms/layer/__init__.py
[13:43] <marcoceppi> from charms.layer import options
[13:43] <marcoceppi> options('layer-you-want-options-from')
[13:44] <marcoceppi> mbruzek: how to define options: https://github.com/juju-solutions/layer-basic/blob/master/layer.yaml
[13:44] <marcoceppi> mbruzek: how to set them: https://github.com/marcoceppi/layer-gitlab/blob/master/layer.yaml
[13:44] <marcoceppi> jacekn: if you don't want to put a repo key. Don't.
[13:45] <mbruzek> marcoceppi: thank you
[13:45] <jacekn> marcoceppi: well that's apparently waht's blockin my charmstore submission
[13:45] <marcoceppi> it's not, it was a suggestion
[13:46] <jacekn> marcoceppi: ok so it's very unclear to me what's going on with my submission. tvansteenburgh reviewed it but the only feedback he provided was a repo key. Does it mean it's approved other than that?
[13:46] <jacekn> marcoceppi: I suspect you can see that I'm getting increasingly upset by the review process ;)
[13:47] <marcoceppi> jacekn: sure, we're tyring to build an extensive and fruitful ecosystem, but if you don't want to contribute to that by simply point to your upstream layer repo, people just won't know where to contribute to the charm and we'lljust have a bunch of forks of the compiled artifact
[13:48] <marcoceppi> we'll simply do it for you, prior to promulgation
[13:48] <marcoceppi> the review process is two fold. One to make sure charms are sane and two - to help educate charmers as the ecosystem evolves
[13:50] <jacekn> marcoceppi: sorry but saying that I don't want to contribute is not fair. I've been trying to get this charm promulgated for the past 2 months and I chased it more times than I can count
[13:51] <marcoceppi> jacekn: yes, and the review queue is old, outdated and the team reviewing is small and over burdened
[13:51] <marcoceppi> jacekn: these aren't unique to you, it's something everyone has had to sufferthough and no one is happy about
[13:51] <marcoceppi> jacekn: we're aggresively building a new review queue and process as the entire way charms are uploaded and submitted to the store is changing
[13:51] <marcoceppi> jacekn: the goal of this is to stream line the process so that review times go from months and weeks to days and hours
[13:52] <marcoceppi> jacekn: all while juju 2.0 is being built and a shift of process is happening
[13:52] <marcoceppi> jacekn: we appreciate your patcience and feel the same strain
[13:53] <marcoceppi> if you have an actual problem with the idea of a repo key, I suggest mailing the list so it can be hashed out, if you're just tired of waiting and making a stand we'll just add the key for you
[13:53] <lazyPower> mbruzek - we have examples of layer options in the docker layer as well
[13:53] <jacekn> marcoceppi: that layer BTW is still being developed but because CS submissions are so slow I just froze it to get it thorugh the review. One it's in the charmstore there will be updates coming. So every week of delay is bigger delta to review later
[13:53] <marcoceppi> jacekn: we understand, again, we have the same problems and no one is disagreeing
[13:54] <jacekn> marcoceppi: I don't have real problem with that other than it's something I had no chance of knowing about because stable tools don't care and it's causing yet another delay
[13:54] <marcoceppi> in two weeks, if we can get the dev time, we'll be launching a beta of the new review queue which will allow you to iterate in the store outside of the review process
[13:54] <jacekn> marcoceppi: and I can't test it using stable tools so I can't really fix it
[13:55] <marcoceppi> jacekn: our stable tools are in this same flux, we have a 2.1.2 of charm-tools in the devel ppa and pypi -it's considered stable but we're waiting for them to land in xenial before ocnsidering them released
[13:55] <marcoceppi> welcome to the most awkard time of the ecosystem
[13:55] <marcoceppi> if you don't feel comfortable adding it, we'll take care of it
[13:56] <deanman> I have a setup of a single VM running locally and using manual provider to bootstrap it and it works fine when deploying inside lxc but as soon as i move inside a proxied network it gets stuck endlessly trying to setup the agent on the container. Any hints/clues what could be wrong?
[13:56] <deanman> (environments.yaml has proper proxy configuration)
[13:57] <jacekn> marcoceppi: cool, thanks. FTR feel free to point at my branch I don't mind I just can't comfortably do it myself because of testing
[13:58] <marcoceppi> jacekn: understood, we have charm-tools in pypi and ppa:juju/devel if you want to test in a lxd machine or virtualenv in the future
[13:59] <jacekn> ack
[13:59] <marcoceppi> jacekn: we hope to have it in xenial and /stable in the next two week
[13:59] <jacekn> marcoceppi: nice!
[14:00] <marcoceppi> jacekn: where are you doing your layer dev?
[14:01] <jacekn> marcoceppi: in a LTS VM (currently trusty)
[14:01] <marcoceppi> jacekn: ah, so not pushed anywhere?
[14:02] <marcoceppi> deanman: what version of Juju?
[14:02] <jacekn> marcoceppi: ah sorry that's what you meant. It is in LP https://code.launchpad.net/~jacekn/canonical-is-charms/collectd-composer
[14:02] <marcoceppi> jacekn: <3 thanks
[14:03] <marcoceppi> jacekn: charm LGTM, promulgating
[14:03] <deanman> marcoceppi, 1.25.3
[14:03] <jacekn> marcoceppi: thanks! It's 1.25.3-trusty-amd64 if you want to know (from juju table PPA). I think you can see the trend with "stable" here ;)
[14:03] <marcoceppi> jacekn: hum, so it should work, but you said manual provider so I just realized I don't think cloud init gets run on manual provider which means the proxy stuff won't be put in place
[14:03] <marcoceppi> deanman: ^^
[14:04] <marcoceppi> deanman: can you `grep -ri "proxy" /etc/apt/apt.conf.d` on the manual machine? do you get any hits?
[14:06] <deanman> marcoceppi, has several entries
[14:06] <jacekn> marcoceppi: sorry I don't get it. What's the problem with the proxy?
[14:06] <marcoceppi> jacekn deanman: juju passes proxy information with cloud-init which I don't think gets run in a manual provider bootstrap, but I coudl be wrong
[14:07] <tvansteenburgh> stub: have you used your juju-wait plugin with juju2 at all?
[14:07] <jacekn> marcoceppi: that part I understand but how does it relate to my charm?
[14:07] <deanman> marcoceppi,
[14:07] <marcoceppi> jacekn: wrong ping, sorry, meant to ping deanman
[14:07] <deanman> marcoceppi, "/etc/apt/apt.conf.d/42-juju-proxy-settings:Acquire::http::Proxy "http://......."
[14:08] <marcoceppi> jacekn: you're charm is fine
[14:08] <jacekn> marcoceppi: hahaha OK!
[14:08] <marcoceppi> deanman: hum, so that's good. is it failing to bootstrap or failling to set the LXC up?
[14:09] <deanman> deanman, it's failing both to deploy on lxc and on bare machine with --to 0. "Waiting agent to finish".
[14:10] <marcoceppi> deanman: can you grab the logs?
[14:10] <deanman> marcoceppi, machine? unit ?
[14:10] <marcoceppi> deanman: all?
[14:11] <lazyPower> mbruzek - have a sec to review a hotfix patch?
[14:11] <mbruzek> yes
[14:11] <lazyPower> mbruzek - we're broken in master :( - https://github.com/juju-solutions/layer-docker/pull/30/files
[14:13] <lazyPower> I should probably get an amulet test written to stress that compose functionality just moved into the wheelhouse... mbruzek  - do you want that befor eyou do the review? I can bust something out in the next ho ur
[14:14] <mbruzek> lazyPower: I didn't see tests, so I am building and will test it manually here
[14:14] <lazyPower> ack
[14:30] <deanman> marcoceppi, http://paste.ubuntu.com/15568095/
[14:31] <deanman> marcoceppi, ls -lh /var/cache/lxc/cloud-trusty/ is empty even several minutes after deploying, not downloading image?
[14:31] <marcoceppi> deanman: it looks like it's failing to hit itsefl after proxy
[14:32] <marcoceppi> that's the EOF
[14:32] <deanman> marcoceppi, could be a no_proxy env issue then ?
[14:32] <marcoceppi> deanman: add <IP_ADDRESS> and <IP_ADDRESS> and <IP_ADDRESS> to no_proxy
[14:53] <mbruzek> lazyPower: +1 merged the docker layer
[14:53] <lazyPower> ta mbruzek , thanks for the priority review
[14:54] <mbruzek> lazyPower: thanks for sending me quality code
[14:55] <deanman> mbruzek, first link on README at layer-docker points to non-valid URL.
[14:55] <mbruzek> deanman on it
[14:56] <lazyPower> oh wow it says "composer" in there
[14:56] <lazyPower> thats some old text :D
[14:57] <deanman> yeah, that confused me while trying to understand how to build my layer docker charm. I think i found some other references that need update too, sec...
[14:59] <deanman> https://jujucharms.com/docs/1.25/authors-charm-with-docker this also points to wrong "composing documentation" link.
[15:14] <mbruzek> https://github.com/juju-solutions/layer-docker/pull/32
[15:14] <A-Kaser> H
[15:14] <A-Kaser> Hi
[15:14] <mbruzek> deanman: Please review this change based on your suggestions.
[15:19] <deanman> mbruzek, done
[15:19] <mbruzek> Thank you
[15:21] <mbruzek> deanman: thanks for helping us improve
[15:27] <lazyPower> A-Kaser o/
[15:32] <deanman> marcoceppi, are you still around ?
[15:35] <A-Kaser> have you tips t debug an error when i run charm build
[15:36] <A-Kaser> I have this error "TypeError: list indices must be integers, not str" but no more information about which file
[15:37] <tvansteenburgh> A-Kaser: please put the `charm build` output in a pastebin
[15:37] <marcoceppi> A-Kaser: also -l debug might help
[15:38] <marcoceppi> deanman: what's up?
[15:38] <A-Kaser> http://pastebin.com/c3LrVRi7
[15:38] <deanman> marcoceppi, the no_proxy didn't seem to work out. http://paste.ubuntu.com/15568500/
[15:40] <tvansteenburgh> A-Kaser: can you paste your layer.yaml too?
[15:40] <marcoceppi> A-Kaser: try upgrading to 1.11.2
[15:42] <tvansteenburgh> A-Kaser: actually, paste your metadata.yaml
[15:42] <deanman> lazyPower, the juju deploy local:<series>/<charm-name> works for me, the one you are proposing is also for stable or for 2.0 ?
[15:42] <lazyPower> deanman - that goes away in juju 2.0
[15:42] <A-Kaser> ok brew charm-tools is only 1.11.1 I'm cloning the source
[15:43] <tvansteenburgh> A-Kaser: i think you have a malformed metadata.yaml
[15:43] <deanman> lazyPower, ok maybe have both at README because if you land there from stable docs then it might be confusing if it's not working ?
[15:44] <marcoceppi> A-Kaser: crud, that's my bad. I'll make sure 1.11.2 is in brew. A-Kaser it may be easier to just install from pip in a virutalenv on your OSX machine
[15:45] <marcoceppi> A-Kaser: virtualenv ~/charm-tools; . ~/charm-tools/bin/activate; pip install charm-tools==1.11.2
[15:45] <A-Kaser> metadata : http://pastebin.com/R2EhNDVg
[15:45] <marcoceppi> A-Kaser: 1.11.2 is the last 1.X build, 2.0 and beyond are a bit different and wont' work as expected until they're packaged in brew
[15:46] <marcoceppi> A-Kaser: ah, your metadata is also a bit off
[15:46] <A-Kaser> marcoceppi: I have installed charm-tools there 2 days
[15:46] <marcoceppi> A-Kaser: that requires: packages: - screen should be in layer.yaml not metadata.yaml
[15:47] <marcoceppi> A-Kaser: as an example: https://github.com/marcoceppi/layer-gitlab/blob/master/layer.yaml
[15:47] <marcoceppi> A-Kaser: that requires: section is for relations, not packages
[15:47] <A-Kaser> ok I've removed packages lines thx
[15:48] <A-Kaser> charm build work , thx
[15:49] <marcoceppi> A-Kaser: cheers
[15:49] <marcoceppi> A-Kaser: expect a new charm-tools 2.0 build in homebrew in the next week or so
[15:51] <A-Kaser> I use juju2 but charm-tools 1.x , is it a problem ?
[15:54] <marcoceppi> A-Kaser: no, no problem
[15:55] <marcoceppi> A-Kaser: charm 2.0 will be much nicer when you go to upload charms to the store, but it's more or less the same build command, etc
[16:47] <jamespage> thedac, some comments on https://code.launchpad.net/~thedac/charm-helpers/apparmor/+merge/290096
[16:47] <thedac> jamespage: thanks.
[16:54] <jamespage> ok taking a break - may be back later...
[17:42] <thedac> jamespage: pushed up fixes
[17:43] <Prabakaran> Helo Team, Hope you all doing great  I was trying to use ibm-base-layer and as confirm by matt it uses juju 2.0 so i was trying to install juju 2.0 in my machine by following the link https://jujucharms.com/docs/devel/introducing-2 and found it has steps for aws setup only and I am not able to install local lxc containers. Can you please advise on how to set up local lxc containers in juju 2.0.
[17:44] <c0s> I ingested a bigger dataset from gh-archive this time and ran some analysis on it http://<IP_ADDRESS>:9090/#/notebook/2BEZN4985
[17:49] <marcoceppi> c0s: sweet
[17:49] <c0s> wheee ;)
[17:50] <mbruzek> Prabakaran: LXD is the new name for the local lxc provider: https://jujucharms.com/docs/devel/config-LXD
[17:51] <cory_fu> c0s: Sorry I haven't been available yet to work on the actions.  RQ and meetings have taken up my whole day
[17:51] <mbruzek> Prabakaran: You might be having issues because the local directory changes for Juju 2.0.  From ~/.juju to ~/.local/share/juju
[17:52] <cory_fu> mbruzek: Is that true?  The ibm-base-layer requires 2.0?
[17:52] <cory_fu> Is it using resources?
[17:53] <mbruzek> not yet but very soon, the ibm-base-layer is using the "terms" feature
[17:53] <mbruzek> that is only in 2.0
[17:53] <cory_fu> Ah, right.
[17:53] <c0s> cory_fu: no worries
[17:53] <c0s> the main thing that I have unblocked you ;)
[17:54] <c0s> commits to *juju* repos over a couple of weeks back in January http://<IP_ADDRESS>:9090/#/notebook/2BEZN4985/paragraph/20160331-172642_1279078054?asIframe
[17:56] <cory_fu> c0s: For the action to submit a job, is there any value to making it able to schedule the job to run repeatedly?
[17:57] <c0s> I'd say yes
[17:58] <cory_fu> c0s: And would cron be the best way to do that?
[17:58] <c0s> Not sure if Zeppelin has a REST call for that... but with spark-submit, spark-shell, and other CLI tools we should be able to
[17:58] <c0s> yup
[17:58] <c0s> cron always is the best ;)
[18:01] <cory_fu> c0s: I see the Zeppelin REST API has endpoints for cron jobs.  Does that schedule a given notebook to be re-run periodically?
[18:02] <c0s> I think yes, that' for the whole thing
[18:03] <c0s> cory_fu: kwmonroe, this http://<IP_ADDRESS>:18080/ doesn't look right
[18:03] <c0s> I have ran a bunch of the Z jobs on that cluster yet it doesn't show any
[18:10] <cory_fu> c0s: Can you check the log on the Spark unit and see if it has anything?  juju debug-log -i spark/0
[18:11] <cory_fu> juju debug-log -i spark/0 --replay
[18:12] <bugrum> on juju2 what is the proper way of deploying a charm?
[18:12] <c0s> sec
[18:12] <rick_h_> bugrum: ? juju deploy mysql? what charm are you looking for?
[18:12] <bugrum> I got juju up and running (thanks to LiftedKilt) and am now trying to deploying openstack on top of it
[18:13] <bugrum> juju2 says it can't resolve URL "cs:openstack"
[18:13] <c0s> cory_fu: nothing, it just hanging there
[18:13] <c0s> do I need to run something at the same time?
[18:14] <cory_fu> Bah.  I think the -i option doesn't work very well with 2.0
[18:14] <cory_fu> c0s: You might have to just `juju ssh spark/0` and view the log on there (sudo less /var/log/juju/unit-spark-0.log)
[18:16] <c0s> there's a bunch of juju messages (what seems to be from the deployment) cory_fu
[18:18] <kwmonroe> cory_fu: c0s, fyi, -i with juju 2.0 needs "unit-spark-0" and not "spark/0"
[18:18] <c0s> but looking under /var/log/spark I see that the process is running history server like this
[18:18] <c0s>   org.apache.spark.deploy.history.HistoryServer hdfs:///user/ubuntu/directory
[18:18] <cory_fu> ORLY?
[18:18] <cory_fu> Good to know
[18:18] <c0s> +1 kwmonroe
[18:18] <kwmonroe> c0s: what user is running that HistoryServer process?  ubuntu?
[18:19] <c0s> notices the different name while browsing the logs manually
[18:19] <c0s> yes kwmonroe
[18:19] <kwmonroe> c0s: as ubuntu on the spark/0 unit, can you "hdfs -dfs -ls -R /user/ubuntu/directory"?
[18:19] <c0s> interesting hdfs:///user/ubuntu/directory/application_1459442777673_0001.inprogress
[18:19] <kwmonroe> ahh
[18:20] <c0s> there's nothing else in this directory, so the history server is correct
[18:20] <kwmonroe> so it's writing stuff.. that's good.
[18:20] <c0s> well, sparsly
[18:20] <c0s> I have ran at least 3 different jobs, they all complete now
[18:20] <c0s> that's the only trace of it
[18:20] <kwmonroe> i wonder if the spark slaves or zepp is configured to use <IP_ADDRESS> as the history server
[18:20] <c0s> it's not in progress for sure
[18:21] <c0s> is there any way to check the configs using juju? Or shall I just manually look at it?
[18:22] <kwmonroe> c0s: run ~/sparkpi.sh from the spark/0 unit and then check your :18080 URL.  that will tell us if spark-submit jobs are making it to the historyserver
[18:22] <c0s> so, /etc/spark/conf/ would be the correct place to check, I presume
[18:22] <c0s> ok, runnig
[18:23] <kwmonroe> yeah c0s, i dunno what (if any) history server config is possible for zepp
[18:23] <c0s> and I can see http://<IP_ADDRESS>:18080/?page=1&showIncomplete=true new job in there
[18:23] <kwmonroe> ok, so spark-submit works directly on the unit.  when you ran your z jobs earlier, were they using spark-submit through zeppelin?
[18:23] <c0s> kwmonroe: I don't know if Zepp has to do with it. These are just spark jobs
[18:24] <c0s> yeah... so, why Zepp's jobs aren't showing?
[18:24] <c0s> nits
[18:24] <kwmonroe> may need to dig into the /var/log/zeppelin/* on the spark unit
[18:24] <c0s> nuts
[18:24] <c0s> lemme check
[18:25] <cory_fu> kwmonroe: Have you run in to services getting stuck on "Waiting for agent initialization to finish" and having this in the logs over and over: http://pastebin.ubuntu.com/15570047/
[18:25] <kwmonroe> yeah cory_fu
[18:25] <kwmonroe> juju upgrade-charm <foo>
[18:25] <cory_fu> Is there a bug open for this?
[18:26] <c0s> judging by this tail -f zeppelin-ubuntu-plugin-0.out
[18:26] <c0s> the spark jobs are running as needed
[18:26] <c0s> I see the output in the file
[18:26] <c0s> like ------ Create new SparkContext yarn-client -------
[18:26] <c0s> and the progress indicators
[18:27] <c0s> crazy
[18:29] <kwmonroe> cory_fu: you sure it's a bug?  i hit that when i deploy a local charm, hackity hack hack, rebuild and try to deploy the new rev of that local charm... at which point there's a mismatch between my $JR charm and unit-0's charm, which i was ok with.  upgrade-charm to refresh unit-0 seemed like the right thing to require in that case.
[18:29] <c0s> and I am quite positive that last night the jobs were displayed in the history server UI
[18:30] <cory_fu> kwmonroe: This was on a fresh deploy
[18:30] <cory_fu> Though I did keep my bootstrap node around and just created a new model
[18:31] <kwmonroe> c0s: what spark execution mode are you in?  or rather, what is the MASTER envvar set to?
[18:31] <cory_fu> Still, I think Juju should definitely handle that better.
[18:31] <c0s> yarn-client
[18:32] <c0s> according to the Zep's configuration
[18:35] <kwmonroe> c0s: is it possible spark's job history won't work in yarn-client mode?  juju expose resourcemanager and go take a look at that UI to see if your jobs are listed there.
[18:35] <c0s> well, the sparkpi stuff runs in the yarn-client mode too
[18:36] <c0s> and it is logged
[18:36] <c0s> kwmonroe: ^^
[18:37] <kwmonroe> that, c0s, is a mighty fine point.
[18:39] <c0s> :)
[18:40] <c0s> anyhow, perhaps isn't a huge issue, but looks like a minor bug to me. However, I am still using the bigtop-dev bundle, so it might be expected to be a bit flaky I guess
[18:41] <cory_fu> Well, we're planning to release those bundles so it shouldn't really be flaky
[18:43] <c0s> agree cory_fu
[18:43] <c0s> what I was saying is that this is still in development, so some regressions are possible
[19:19] <c0s> kwmonroe: is it possible to add say kafka to an already deployed bundle?
[19:23] <kwmonroe> you bet c0s!  "juju deploy cs:~bigdata-dev/trusty/apache-kafka kafka"
[19:23] <kwmonroe> but then it'll wait for zookeepers, so you'll need to "juju deploy cs:~bigdata-dev/trusty/apache-zookeeper zk" and "juju add-relation kafka zk"
[19:24] <c0s> ok, let me try that ;)
[19:24] <c0s> thanks!
[19:24] <c0s> what the worst could happen
[19:24] <kwmonroe> there is no try c0s.  just do it.
[19:24] <c0s> ok, kwmonroe - I won't try ;)
[19:24] <kwmonroe> :)
[19:34] <c0s> kwmonroe: shall I scale up ZK to 3 nodes as well? Or 1 will do ?
[19:39] <admcleod1> hello
[19:40] <admcleod1> c0s: i dunno if he replied, but 1 zk is fine
[19:41] <c0s> it seems to be holding for the POC purposes, yes
[19:41] <c0s> thanks!
[20:08] <c0s> kaffffffka
[20:08] <lazyPower> shouted to the tune of "KHAAAAAAN"
[20:10] <c0s> yes lazyPower
[20:10] <c0s> alongside with the sound of my sobbing ;(
[20:20] <kwmonroe> c0s: sobbing because everything went great?  sobs and frownie faces of joy?
[20:34] <arosales> kwmonroe: is the latest code for the hadoop charms still at lp?
[20:34] <arosales> for example hdfs master I get directed to
[20:34] <arosales> https://code.launchpad.net/~bigdata-charmers/charms/trusty/apache-hadoop-hdfs-master/trunk
[20:34] <arosales> from https://jujucharms.com/apache-hadoop-hdfs-master/trusty/9 which is the promulgated version
[20:38] <arosales> kwmonroe: that doesn't look like a reactive charm though . . . .
[20:38] <arosales> cory_fu: ^
[20:38] <cory_fu> arosales: No, all of the new charms are on github
[20:39] <cory_fu> Also, hdfs-master is the oldness.  apache-hadoop-namenode is the newness
[20:39] <deanman> anyone using brew charm-tools 1.11.1 ?
[20:39] <arosales> cory_fu: ya I also thought all the new charms were in git
[20:40] <arosales> cory_fu: but this is the current recommeded charm
[20:40] <arosales> cory_fu: it is just the case that we haven't got the git charms to be the recommeded ones?
[20:40] <cory_fu> arosales: I'd like to fix that right now.  I'm going to start promulgating charms and bundles
[20:40] <cory_fu> After this meeting
[20:40] <arosales> cory_fu: ya super confusing atm
[20:41] <arosales> cory_fu: also as a result of that, if any of the charms at https://jujucharms.com/big-data change please file a bug on https://github.com/CanonicalLtd/jujucharms.com/issues
[20:47] <arosales> deanman: ah brew still probably at the 1.x versions
[20:47] <arosales> deanman: hitting any issues?
[20:47] <deanman> arosales, yeah when trying to $charm build
[20:51] <deanman> arosales, and this would be the tailed output when using -l DEBUG http://pastebin.ubuntu.com/15571120/
[20:53]  * arosales looking at pastebin
[20:53] <mbruzek> Hey deanman the brew release of charm-tools is a bit behind the other ones. I would recommend setting up an venv and pip installing charm tools until the new version is available.
[20:55] <arosales> deanman: I saw a similar error but on ubuntu I needed to install venv package
[20:55] <deanman> mbruzek, No problem mbruzek, i'm building from within the ubuntu VM (which runs 1.11.2).
[20:55] <arosales> deanman: your running this on osx?
[20:55] <deanman> arosales, Yes
[20:55] <deanman> on ubuntu with 1.11.2 it works just fine
[20:55] <arosales> ok, deanman it looks like the dep is broken in brew
[20:55] <arosales> aisrael: are you still looking after charm-tools in brew?
[20:56] <aisrael> arosales: Marco's been doing it
[20:56] <aisrael> I think
[20:56] <arosales> aisrael: if so could you take an action to update to the latest, possibly even 2.0 that marcoceppi is going to put into xenial?
[20:56] <arosales> marcoceppi's brewing for osx :-)  I bet he has been keeping that a secret :-)
[20:56] <lazyPower> deanman - do you have git installed?
[20:56] <marcoceppi> arosales: it's already on my list, it'll be out tomomrrow
[20:56] <arosales> aisrael: could you follow up with marcoceppi though?
[20:56] <lazyPower> i assume yeah but there's only a few paths that end in that error
[20:57] <arosales> marcoceppi: ok
[20:57] <lazyPower> and its typically due to not having unzip, git, or  one of the other smallish dependencies that we're shelling out to invoke
[20:57] <arosales> deanman: are you ok to leverage ubuntu in the vm for now?
[20:58] <lazyPower> mbruzek - oh i figured out why its tanked, we never got the restructuring merge done
[20:58] <deanman> arosales, Yeah it's fine, just asking if you wanted to raise an issue on github
[20:59] <lazyPower> mbruzek https://github.com/juju-solutions/charms.docker/pull/14  -- when you have time <3 its kidn of big but most of it is documentation updates for the charms.docker api
[20:59] <arosales> deanman: thanks. Sounds like marcoceppi is going to update brew soon
[20:59] <lazyPower> deanman - that particular issue has been patched. https://github.com/juju/charm-tools/issues/159
[20:59] <lazyPower> deanman - is there a remote on your git repository? or is it a local git repo only?
[21:00] <deanman> deanman, Yeah i do have a single remote setup
[21:00] <deanman> lazyPower, ....
[21:01] <lazyPower> deanman do you have bzr installed?
[21:01] <lazyPower> if any of those libs are in a launchpad repo, its gonna die with that error as it tries to bzr branch the remote
[21:01] <lazyPower> s/libs/layers
[21:02] <deanman> lazyPower, a private remote repo, not a launchpad repo
[21:02] <lazyPower> deanman - can i see a pastebin of your layer.yaml?
[21:04] <deanman> lazyPower, if only pastebinit on mac didn't complain about "Bad API request...", gimme a sec
[21:04] <deanman> lazyPower, Single liner -> includes: ['layer:docker']
[21:04] <lazyPower> and thats not in lp
[21:04]  * lazyPower is puzzled now
[21:05] <deanman> lazyPower, fails after copying tox.ini
[21:08] <lazyPower> deanman - do you have virtualenv installed?
[21:08] <lazyPower> and/or pip
[21:09] <deanman> after installing virtualenv with pip the build goes through
[21:09] <lazyPower> \o/ paydirt
[21:09] <lazyPower> https://github.com/juju/charm-tools/blob/v1.11.1/charmtools/build/tactics.py#L622 - was the clue
[21:10] <lazyPower> thats poopy though, i'm pretty sure this error messaging was patched with the future revs
[21:10] <lazyPower> so its more apparent whats happened
[21:10] <deanman> removed virtualenv and bug reappeared, so definitely installing virtualevn was the key !!
[21:12] <lazyPower> https://github.com/juju/charm-tools/blob/v2.1.2/charmtools/build/tactics.py#L636  - doesn't look like it unless we patched it on the invocation of this in utils
[21:15] <LiftedKilt> what does juju-gui-console-enabled do in the juju-gui charm?
[21:18] <lazyPower> LiftedKilt - it opens my garage door. plz dont toggle that option
[21:20] <jrwren> afaik, nothing. it may have been used in the past.
[21:23] <marcoceppi> arosales: was waiting for the packages to settle
[21:24] <LiftedKilt> lazyPower: I'm toggling it furiously now
[21:24] <LiftedKilt> jrwren: so no plans to re-enable it then?
[21:25] <lazyPower> LiftedKilt: schenanigans!
[21:25] <jrwren> LiftedKilt: none that I have heard.
[21:26] <jrwren> We probably did not delete it because it would break bundles which specify it, but we could mark it obsolete and document that it is unused and is a no-op
[21:28] <LiftedKilt> but it sounds like a cool feature haha
[21:32] <arosales> marcoceppi: ya I figured you wanted to updated with what we put into xenial
[21:33] <arosales> marcoceppi: appreciate all the work you have been putting into charm{tools} and getting it out there for folks
[21:33] <A-Kaser> re
[21:48] <A-Kaser> my charm create a new service but no units
[21:48] <A-Kaser> juju debug-log show me nothing, another way to see log ?
[21:49] <lazyPower> A-Kaser - did you deploy it via dragging on the gui or something? there's a scenario where you can stage a service without any allocated units, so you can do things like upload resources, tweak config
[21:49] <A-Kaser> juju deploy local:trusty/spark-notebook
[21:49] <lazyPower> *then* you can add units to kind of "flush" the whole operation into the environment, but if thats not what you did, i'm uncertain why you got a service declaration without any units though
[21:49] <admcleod1> c0s: with the bigtop puppet deploy, how do you define the role of the machine you're deploying to?
[21:49] <A-Kaser> it's my own charm, may be I have missing something
[21:50] <c0s> admcleod1: there are two ways
[21:50] <A-Kaser> s/missing/missed/
[21:50] <c0s> you can just specify FQDNs for master nodes (NN, spark, etc.) and then the rest of the nodes will be worker nodes.
[21:51] <c0s> or you can do more complex settings of the roles via hiera
[21:54] <c0s> admcleod1: you can check https://github.com/apache/bigtop/blob/master/bigtop-deploy/puppet/hieradata/bigtop/cluster.yaml for more info
[21:54] <c0s> search for roles
[21:55] <c0s> the complexity, mostly, comes from the fact that you need to maintain different hiera configs on different nodes
[21:55] <c0s> where's the simpler method would mandate uniformed configs
[22:00] <admcleod1> c0s: right, thanks
[22:00] <admcleod1> c0s: ah yeah ok pretty straight forward
[22:01] <c0s> yeah, we are simple folks ... over there ;)
[22:01] <c0s> in our corners of them woods
[22:02] <c0s> bloody hell, what damn Kafka doesn't have a thin client?
[22:02] <c0s> what's the point of having all this crap laying around if every Joe and Frank needs to write tons of custom code to handle all that parallelism ;(
[22:03] <c0s> damn hipsters
[22:03] <admcleod1> hah
[22:31] <c0s> kwmonroe: cory_fu, admcleod1, looks like apache-kafka-14 is pulling in
[22:31] <c0s>   "url": "https://s3.amazonaws.com/jujubigdata/apache/x86_64/kafka_2.10-<IP_ADDRESS>-89ede9a.tgz"
[22:31] <c0s> which has the bug KAFKA-1711
[22:31] <c0s> not sure if this is because of that, I can not even writing anything into a topic
[22:36] <c0s> perhaps not as I can write data to a topic using juju actions
[22:36] <c0s> weeeird
[23:19] <arosales> cory_fu: how would you suggest to pull in admcleod1 branches into github/juju-solutions for the hadoop HA bits?
[23:20] <kwmonroe> why would you want to do that arosales?
[23:20] <kwmonroe> it's not ready to merge into the juju-solutions namespace
[23:22] <kwmonroe> or, admcleod1 can push his HA-enabled charms to his namespace, and we can bundle that into a bundle-ha.yaml in the apache-core-batch-processing bundle (which does live in juju-solutions)
[23:23] <arosales> kwmonroe: I guess I just need to understand how the juju-solutions name space is used
[23:25] <arosales> kwmonroe: for example if I wanted to submit a merge request against the new HA bits. I have the following questions
[23:25] <arosales> 1. how do I find them
[23:25] <arosales> 2. where do I submit issues
[23:25] <arosales> 3. where so I submit branches against
[23:30] <cory_fu> arosales: github.com/juju-solutions/apache-hadoop-namenode is the upstream.  To work on features, we fork that to our personal namespace, work, and then when it's ready submit a PR against the upstream.
[23:31] <cory_fu> Once HA is ready, there will be a PR and once that's merged, it will be in juju-solutions
[23:31] <arosales> cory_fu: seems that doesn't give a lot of opportunity for folks collaborate on the branch before pushing to a final version
[23:32] <arosales> but completely agree that during early dev personal name space works well
[23:32]  * arosales just wondering if there should be a deb branch off of http://github.com/juju-solutions/apache-hadoop-namenode
[23:32] <cory_fu> arosales: You can fork Andrew's repo and submit PRs back to him
[23:32] <arosales> that has early bits folks want others to test
[23:32] <c0s> I am struggling to come up with a good data ingest example for Kafka ;(
[23:33] <arosales> cory_fu: and thats one way, but now I have to follow your namespace, kwmonroe, kjackal, admcleod1, and anyone elese for the dev version
[23:33] <cory_fu> arosales: We can also have branches on the juju-solutions repo, but the "typical" GitHub workflow is to fork and submit PRs from your personal namespace
[23:33] <arosales> cory_fu: +1 on personal name space to hack.
[23:33] <arosales> cory_fu: my noob questions is where do I go to collaborate on the dev versions
[23:34] <arosales> cory_fu: if the answer is ping here and find out who's personal namespace has the dev branch I can do that
[23:34] <arosales> cory_fu: just wanted to be sure that was the correct process before I started filling issues against kjackal  and admcleod1 namespace
[23:35] <cory_fu> So, with this workflow, there isn't really a single dev version.  There are multiple feature branches.  We had that before, but they lived in a single namespace and eventually got merged into bigdata-dev just prior to release.  So bigdata-dev was more like staging
[23:35] <cory_fu> arosales: If we think it would be easier, we can do branches within the upstream repo.  I'm not against that
[23:36] <arosales> cory_fu: you guys are the experts here :-) I just wanted to play nice with your workflow
[23:36] <cory_fu> We'll discuss it during sync tomorrow
[23:36] <arosales> cory_fu: what ever is working for you guys I can follow, I just simple didn't know
[23:36] <arosales> cory_fu: sounds good
[23:37] <cory_fu> arosales: You can also see all the forks pretty easily on the GH website
[23:37] <cory_fu> Just click the number next to "Fork"
[23:38] <LiftedKilt> If I can deploy xenial and trusty machines on maas with juju, and maas is telling me that a wily machine is deployed but my juju controller still shows pending, where would one go to troubleshoot that?
[23:39] <arosales> cory_fu: gotcha and that works when there are a few folks to guess who branch is the dev version I should submit issues against, but when more folks get involved (ie start branching) that guess may be a little hard, but perhaps look at that problem when it occurs.
[23:40] <cory_fu> arosales: Or you could just submit all issues against the upstream
[23:41] <arosales> cory_fu: true, as long as I have found the right dev branch to find the issues, which is the crux of my questions
[23:42] <marcoceppi> busy day , time to wind down
[23:42] <arosales> LiftedKilt: I would start with at least "juju debug-log" and see if that gives you any useful pointers
[23:42] <marcoceppi> juju kill-controller
[23:42] <marcoceppi> Waiting on 5 models, 20 machines, 22 services
[23:43] <marcoceppi> $_$
[23:43] <arosales> LiftedKilt: and I am guessing you are using maas 1.9 and juju 2.0?
[23:43] <LiftedKilt> arosales: correct
[23:44] <arosales> I *think* the maas team and juju team are working on compatibility between those two versions
[23:44] <LiftedKilt> arosales: ERROR verification failed: no macaroons
[23:45] <LiftedKilt> arosales: I know they've been working on maas 2 and juju 2 due to the new maas api, but I didn't know they had compatibility problems with 1.9?
[23:45] <arosales> any juju-devs around that can confirm that?
[23:45] <arosales> LiftedKilt: I may very well be wrong
[23:45]  * arosales is going to pop into juju-dev and confirm
[23:46] <LiftedKilt> yall got any more of them macaroons?
[23:46] <LiftedKilt> just need to borrow one real quick. I promise not to eat it.
[23:47] <arosales> macaroons way tastier that cookies
[23:47] <arosales> s/that/than/
[23:49] <arosales> c0s: were you looking for a stream set?
[23:50] <c0s> not exactly
[23:50] <rick_h_> arosales: LiftedKilt we're workiing on juju 2 and maas 2.0
[23:50] <rick_h_> arosales: LiftedKilt 1.9 should be peachy
[23:50] <arosales> LiftedKilt: juju-core folks say maas 1.9 and juju 2.0 should work together
[23:50] <LiftedKilt> rick_h_ arosales: any idea why juju debug-log is complaining about no macaroons?
[23:51] <c0s> here's the main dilemma: Kafka is poorly suited to work with a variety of data sources out of the box. It is a message bus, after all, so you need all sorts of sinks, consumers, etc for each particular case
[23:51] <rick_h_> LiftedKilt: hmm, that sounds like a bug to be honest.
[23:51] <c0s> hence, developing a generic enough data flow (ie without writing a bunch of special code) is a challenge
[23:52] <c0s> I was thinking may be we should experiment with something like SpringXD to provide a good pipeline building tool. Which is integrated with Kafka pretty well, it seems
[23:52] <arosales> LiftedKilt: can you post what you are seeing at http://paste.ubuntu.com/
[23:52] <LiftedKilt> I noticed all my wily charms were failing, so I tried to add-machine a couple wily machines to see if I could independently get them to work
[23:52] <c0s> or Gobblin to build ETL-like flows
[23:53] <rick_h_> LiftedKilt: they're failing to deploy via deploying wily based charms?
[23:53] <rick_h_> LiftedKilt: can you speak to what you're deploying and how?
[23:53] <LiftedKilt> arosales: https://paste.ubuntu.com/15572264/
[23:53] <c0s> or if we are to focus on collection- or aggregating-like use cases, then Flume+Kafka
[23:54] <c0s> but bare Kafka seems to be too bare to start using is without any preps.
[23:54] <LiftedKilt> rick_h_: sure - attempting to deploy the openstack-lxd bundle
[23:54] <arosales> c0s: perhaps prep the data before sending over to kafka
[23:54] <rick_h_> LiftedKilt: do me a favor, try juju status --format=yaml
[23:54] <c0s> arosales: you still need to connect to data
[23:55] <LiftedKilt> rick_h_: when I noticed it was hanging on provisioning the machines, I created a new model and tried adding a machine there manually
[23:55] <LiftedKilt> https://paste.ubuntu.com/15572272/
[23:55] <c0s> having a source isn't enough. You need to have source-specific sink
[23:55] <c0s> or producer
[23:55] <arosales> c0s: ya the data format for a gernal case . . .
[23:56] <rick_h_> LiftedKilt: gotcha, so can you juju ssh 0 ?
[23:56]  * arosales also looking up SpringXD c0s
[23:56] <rick_h_> LiftedKilt: and check out if anything is fishy in the /var/log/juju/xxxxx log files
[23:56] <c0s> BTW, out of the box setting up kafka on top of spark-zeppelin bundle doesn't let me to use their producer script in the shell session. Not sure if it's a bug or not
[23:56] <LiftedKilt> rick_h_: juju ssh 0 hangs
[23:57] <rick_h_> LiftedKilt: hmm, can you manually ssh to the machine IP?
[23:58] <LiftedKilt> rick_h_: It would let me it I had the key set up
[23:58] <arosales> c0s: does seem like an issue
[23:58] <rick_h_> LiftedKilt: the yaml status says the machine is deployed?
[23:58] <rick_h_> LiftedKilt: oh heh
[23:59] <arosales> c0s: got it on the board to investigate
[23:59] <c0s> arosales: it is either a differences in the environment between what I get via 'juju ssh kafka/0' and 'juju action do kafka/0...'
[23:59] <c0s> or else
[23:59] <c0s> ok, will add a ticket now
[23:59] <LiftedKilt> rick_h_: yeah it's bizarre - it sees that it's up, but yet at the same time doesn't
[23:59] <c0s> will dig more into this later... getting to the end of my rope today :/


[13:20] <mumrikmoose> ok I am pretty sure this is a FAQ: I get frequent xruns at buffer size 128 (44.1k) while I also would prefer even shorter latency
[13:21] <cfhowlett> #opensourcemusicans would know
[13:22] <AiOGajo> Hi all
[14:16] <F_> hi I upgraded from 16.10 to 17.10 and the keyboard stopped working on my dell latitude e6230. I can't seem to log in or get command line at start up
[17:42] <mumrikmoose> rt kernel seems to work better however no nvidia support it appears :(


[01:21] <ShippD> a question about 13.10
[01:22] <ShippD> all apps have disappeared can not search with any results
[01:24] <holstein> ShippD: you tried as a different user?
[01:25] <ShippD> no
[01:25] <holstein> ShippD: i should have said, try as a different user
[01:25] <ShippD> or as guest?
[01:26] <ShippD> will do
[01:33] <ShippD> same thing
[01:35] <holstein> ShippD: i would just check for updates.. who knows
[01:35] <holstein> ShippD: whats the issue?
[01:35] <ShippD> no apps show in unity dash
[01:35] <ShippD> can not search for them either
[01:35] <ShippD> nothing shows
[01:36] <holstein> ok.. but it might, and likely will break
[01:37] <ShippD> cant get much worse
[01:39] <holstein> ShippD: you can still launch applications from the terminal, correct?
[01:39] <jo-erlend> still very early in development so bugs must be expected.
[01:39] <jo-erlend> holstein, or alt+f2 should work as well.
[01:39] <jo-erlend> ShippD, what about the apps-lens?
[01:40] <ShippD> yes from dash
[01:40] <holstein> i would install something like kupfer, for if something breaks..
[01:40] <ShippD> i mean
[01:40] <ShippD> terminal
[01:41] <ShippD> no from apps-lens
[01:41] <jo-erlend> ShippD, what does that mean?
[01:41] <jo-erlend> you don't see any apps at all in the apps-lens either?
[01:41] <ShippD> right
[01:42] <jo-erlend> weird.
[01:42] <ShippD> very
[01:42] <ShippD> ok i will back up the whole story
[01:42] <ShippD> software center would not open so uninstalled it reinstalled and now this
[01:43] <jo-erlend> particularly since you don't get any results as a guest user either. Otherwise I'd expect that something like unity-lens-applications had crashed or something.
[01:43] <jo-erlend> yes, there's a bug in software-center.
[01:43] <ShippD> yeah
[01:43] <ShippD> i noticed
[01:43] <holstein> someone asked about that the other day...
[01:43] <ShippD> works fine on my old dell so yeah a bug
[01:43] <jo-erlend> holstein, that might've been me, but I guess I'm not alone. :)
[01:43] <holstein> ShippD: on 13.10?
[01:44] <ShippD> 13.10
[01:44] <holstein> ShippD: why run 13.10 so many places?
[01:44] <jo-erlend> ShippD, then you haven't installed upgrades, I think, because that looks very much like a programming error.
[01:44] <holstein> its not a "bleeding edge" distro.. its literally not out yet
[01:44] <ShippD> i know
[01:44] <holstein> yeah, if you have the same version both places, you should have the same issue
[01:44] <ShippD> just used it on old dell first then put it on here
[01:45] <ShippD> old dell is for testing
[01:46] <jo-erlend> holstein, I'd be kinda scared if _that_ bug was hardware dependent. :)
[01:48] <jo-erlend> ShippD, does your apps-bug survive a reboot?
[01:48] <ShippD> yes
[01:49] <jo-erlend> hmm. Interesting. Did it start very recently?
[01:49] <ShippD> this am
[01:49] <jo-erlend> ?
[01:49] <ShippD> today
[01:50] <jo-erlend> so there's a chance I just haven't received the update yet.
[01:50] <ShippD> just ran sudo update
[01:50] <jo-erlend> aha.
[01:51] <jo-erlend> there is an update for the apps-lens waiting for me. Guess I'll wait a little while for that one then. :)
[01:51] <ShippD> there is a update running now
[01:52] <jo-erlend> 7.0.0+13.10.20130702-0ubuntu2 is waiting for me.
[01:52] <jo-erlend> but that doesn't seem to fix any bugs.
[01:53] <ShippD> hmmm
[01:53] <ShippD> installing 89 mb update now
[08:26] <FernandoMiguel> muurning
[11:11] <BluesKaj> Hey folks
[11:12] <penguin42> Hey BK
[11:14] <BluesKaj> hi penguin42
[11:16] <FernandoMiguel> hey guys
[11:17] <BluesKaj> hi FernandoMiguel
[13:02] <Leonard_Hofstadt> hi
[13:03] <Leonard_Hofstadt> i got some issues
[13:04] <hachre> thanks for that info, leonard
[13:09] <BluesKaj> hachre, he missed your sarcasm
[13:09] <hachre> hah yea
[16:11] <lidanti> quick question, is the version of the nvidia driver in saucy working with the current 1.14 xserver?
[17:27] <johnjohn101> is this still broken on vmware player. I guess I have to wait for a while.
[19:30] <bladernr_> Question: can someone clue me in how to turn OFF this click to launch thing in Unity? If I have to search for an app I installed, and I then Click on that app, I don't think I really need to click a separate Launch button, launching is kind of implied.
[19:34] <trism> bladernr_: there is a gsettings key for it, com.canonical.Unity double-click-activate I believe
[19:39] <bladernr_> trism: thanks! I was looking in the wrong place, that helped a lot :)
[20:27] <hachre> That behavior change is really idiotic in my opinion
[21:37] <taoseeker> hi
[21:37] <taoseeker> I'm being booted from ubuntu-testing
[21:38] <taoseeker> odd
[21:38] <taoseeker> I used to test for ppc
[21:38] <taoseeker> never mind though, I'll stick with the latest
[21:40] <taoseeker> noone here?
[21:42] <ikonia> taoseeker: do you need help with something ?
[21:42] <taoseeker> not anymore
[21:42] <ikonia> ok, I'll return to what I was doing.