[05:12] <OvenWerk1> knome: reading from way back up the back log about ISO size. I sense that there is the idea of making it easy to have everything on a CD where inernet is not available/fast but small for where it is.
[05:13] <OvenWerk1> How hard would it be to make a two cd set? The first is a minimal install and the second is just packages? The first includes a chooser for the second.
[05:14] <OvenWerk1> That way, in places with minimal internet, one cd set could do many computers.
[05:22] <zequence> OvenWerk1: It's done in seeds. I've been meaning to do this for us for next cycle
[05:23] <zequence> OvenWerk1: You can check how others do it. I think Lubuntu has a bunch of different ISOs
[05:25] <Unit193> For arches, not sub-flavors.
[05:58] <zequence> Unit193: They have both a live and an alternate
[05:58] <zequence> Unit193: What do you mean, sub flavors? You starting one in Xubuntu?
[05:58] <Unit193> Right, but the same system.
[06:21] <jhenke> good morning
[08:33] <brainwash> any idea what might be the cause for bug 1313220 ?
[08:34] <knome> OvenWerk1, multiple discs would still mean more testing...
[08:35] <knome> OvenWerk1, and i can't see the extra disc as much more than just an offline software repository
[08:35] <knome> OvenWerk1, people can create such discs already, and choose what they want to include
[08:35] <knome> OvenWerk1, eg. not have to download whole libreoffice if you just wanted a single langpack
[08:56] <zequence> knome: We have a special situation where the live DVD is a great tool and showcase, but too big to be practical for most installations
[08:56] <zequence> So, we will definately have two images
[08:57] <zequence> Either introducing a very basic netinstall, or a much smaller live CD variant
[09:30] <brainwash> knome: please mark bug 1312641 as wishlist, thanks :)
[09:33] <ochosi> brainwash: i suppose you didn't update your ppa with the new patch for powerman?
[09:34] <brainwash> no
[09:34] <ochosi> that would be nice, please remove the sleep though if you can, so we have a patch/test that could be proposed for SRU
[09:35] <brainwash> but which new patch?
[09:36] <ochosi> this, but without line 31: http://lpaste.net/103262
[09:37] <brainwash> what about the briefly visible desktop?
[09:37] <brainwash> xscreensaver even adds a 1 sec sleep before locking
[09:39] <brainwash> so it feels more like a wonky workaround
[09:39] <ochosi> it is
[09:39] <ochosi> it's nothing i'd want to go upstream
[09:39] <brainwash> we need a proper solution
[09:39] <ochosi> but i think it's good enough to send it through some testing
[09:41] <brainwash> mmh, maybe add some logic, so it only locks on wake up if light-locker is running
[09:41] <brainwash> otherwise before suspend
[09:44] <ochosi> yeah, but then you get to the funky part of detecting what locker is running/used
[09:44] <ochosi> what would you do if both xscreensaver and light-locker are installed/running? (typical upgrade case)
[09:44] <brainwash> prefer ll
[09:45] <Gryllida> what is light-locker ?
[09:45] <brainwash> llc already tests if ll is running
[09:45] <ochosi> just trying to make a point, it's not easy to detect what is in use
[09:46] <brainwash> so we can re-use the code
[09:47] <brainwash> but this is getting to hack-ish
[09:51] <ochosi> exactly
[09:51] <ochosi> i think the simple patch should be tested
[09:51] <ochosi> for 14.10 onwards, there'll be a better powerman etc etc
[09:51] <ochosi> bbl
[10:18] <knome> brainwash, done
[10:24] <brainwash> knome: thanks
[10:24] <brainwash> ochosi: bug 1313011
[10:25] <brainwash> maybe you know what's broken here
[11:19] <bluesabre> d'oh!
[11:19] <bluesabre> knome: https://bugs.launchpad.net/menulibre/+bug/1313276
[11:23] <bluesabre> knome: can you verify that the problem goes away if you remove the second Preferences item?
[11:29] <bluesabre> Unit193: I take it back, compton works quite well now
[12:26] <knome> bluesabre, i'll check that at some point
[13:06] <brainwash> ochosi: https://launchpad.net/~thad-fisch/+archive/test now without the 1 sec sleep
[13:43] <knome> GridCube, timem to evaluate -team membership (per strategy document): what kind of contributions did you do for trusty, and do you plan to contribute to the project in the future?
[13:45] <knome> GridCube, asking because you didn't have any work item assigned the last cycle
[13:46] <GridCube> I have not done much really, i've done a few tests when elfy asked me, but not all the ones i would have liked to. I have giving some support on the main channel. As i have not been able to join most of the meeting in the last cycle i could not insert my opinions or take some task works that could have been handed to me if wanted, not that i can do much programing and such, the only project i had that i could take some time to do was the
[13:46] <GridCube> desktop of the week thing, but that was postponed indefinetly and then i could do nothing about it.
[13:47] <knome> right, that's correct. wonder why there isn't no work items for that...
[13:47] <GridCube> I plan to keep being in the channels and doing all what i can to contribute to xubutnu, i still think its one of thebest OS i've ever used and im glad i can do even a little thing to help
[13:47] <knome> so what are your plans in the future?
[13:47] <knome> do you think you can do more testing?
[13:48] <knome> and potentially help organizing the testcases?
[13:48] <GridCube> sure i guess i can do that, i will need guidance to give me an start but i can
[13:48] <knome> there's plenty if you are interested
[13:49] <knome> most of it is in place, but they always need maintaining and improving
[13:49] <GridCube> i was just writing my reply to the mailing list discussion about a new mailing list, and my opinion is that having an external place where people who can not join the meetings to properly read and inform about the cases to vote would be rather usefull, i know it would be to me.
[13:49] <knome> i can most definitely agree to that
[13:50] <GridCube> i understand that i have not beeing of much help lately, and i apologice about that
[13:50] <knome> the problem/workload for that is actually keeping the mailing list updated
[13:50] <GridCube> I know also that I don't always have the best of attitudes and i can be rather obnoxious, and again i apologize about that
[13:50] <knome> that's okay, life happens and comes in the way
[13:50] <knome> i was just checking the situation generally
[13:50] <GridCube> thats good :)
[13:51] <GridCube> again, if theres anything any of you need help with and think i could do a service, please let me know
[13:52] <knome> you should be in touch with elfy mostly, who's running the testing and leading other efforts related to QA
[13:52] <GridCube> very good
[13:56] <knome> humph.
[14:48] <ochosi> thanks brainwash, will check out in a bit
[14:56]  * elfy get's the balrog's whip out ...
[14:57] <ElderDryas> None Shall Pass
[14:57] <elfy> and welcomes GridCube to more testing :p
[15:01] <ElderDryas> Hey elfy, speaking of testing...my Youngest Daughter just gave me a 500gig hdd (replaced it with a SSD in her laptop).  I'm think about dual booting :(, setting up a standard partition setup for use and a seperate partition for testing (no real data, etc). What's a good size for this...10, 15, 20, 25 gig ?
[15:03] <elfy> I tend to use a 20Gb partition in vm for the majority of the basic testing - with that I can also let it do the install alongside testcase
[15:04] <elfy> I'm also this cycle going to be harping on - for those who are in a position to do so - to run unicorn as their main machine to get more testing done with packages/panel changes
[15:05] <ElderDryas> yeah, vm...even worse than dual booting (hang overs from the days when 1) it was not so easy and 2) I was young and stupid.
[15:05] <elfy> also we hope to set up a common ppa for us to use to test things
[15:06] <ElderDryas> and while she gave me a larger hhd, she forgot to give me her ram (2gig and vm's are/were (?) dicey.
[15:06] <elfy> ElderDryas: lol - I find vm testing fine for the basic stuff - I've got 2 unicorn vm's already - one is destined to run with systemd - I've got a trusty vm with that as well
[15:06] <ElderDryas> so a 20 gig partition is good?
[15:06] <elfy> aah yea - can be abit slow ith 2GbRam
[15:07] <elfy> I'd say so - good enough to test installs with :)
[15:07] <ElderDryas> well. I have a birthday coming up...time to start plotting the hints.
[15:07] <elfy> :)
[16:08] <elfy> knome: any reason to hold the QA recap blog thing?
[16:09] <knome> elfy, can't think of any
[16:09] <elfy> ok - I'll publish then
[16:09] <ochosi> knome: what's the status on the css stuff for the lock-article?
[16:10] <knome> ochosi, "meh"
[16:11] <elfy> knome ochosi - I'm happy to wait for that lock article to go first - I just would like to get the recap out before I start calling for unicorn
[16:11] <ochosi> xubuntu project status types: "done", "todo", "inprogress", "blocked", "meh"
[16:11] <knome> elfy, no, just go ahead with the testing article
[16:11] <knome> ochosi, yep...
[16:12] <elfy> ok - done that
[16:13] <knome> can't see it
[16:13] <knome> :P
[16:13] <knome> oh
[16:13] <knome> it's released on april 16
[16:15] <knome> oops!
[16:15] <knome> fixed now.
[16:15] <knome> what the
[16:16] <knome> elfy, did you look at the actual post?
[16:16] <elfy> yea - why?
[16:16] <knome> there was some really odd formatting
[16:16] <elfy> where?
[16:17] <knome> i'm fixing it
[16:17] <elfy> k
[16:18] <knome> should be ok now
[16:18] <knome> tweeting
[16:18] <elfy> thanks :)
[16:19] <knome> and done
[16:19] <elfy> :)
[16:20] <knome> i should go to the grocery store
[16:20] <knome> bu i'm hungry
[16:20] <knome> and no wonder, haven't eaten much today
[16:20] <elfy> so ... did we get anywhere with sorting blueprints for
[16:20] <knome> hmpf, no
[16:20] <elfy> I hate going for food when hungry
[16:20] <knome> hehe
[16:20] <knome> yeah...
[16:21] <knome> i have food at home though, the two issues are unrelated
[16:21] <elfy> :)
[16:22] <knome> ate a banana
[16:22] <knome> but... yeah, we should get organized
[16:22] <knome> i don't want to do too much before the next meeting though
[16:22] <elfy> understand that
[16:22] <elfy> I'm happy to do the 2 QA ones
[16:22] <elfy> when it's time
[16:23] <knome> yep
[16:24] <elfy> QA one will be a lot smaller this time - not a huge list of bugs on it
[16:26] <brainwash> elfy: got some time to test xfpm once again? https://launchpad.net/~thad-fisch/+archive/test
[16:26] <hakermania> Hey there! Can anyone confirm that this is a XUbuntu related bug? Ubuntu's indicators do not seem to have any problem with it.. https://bugs.launchpad.net/ubuntu/+source/wallch/+bug/1313531
[16:27] <elfy> brainwash: yep -
[16:28] <ochosi> hakermania: yes, the icons don't get scaled down correctly currently
[16:28] <ochosi> they changed that in the indicators rather late in the cycle and without warning, so we had on time to fix that
[16:29] <hakermania> ok thanks a lot :) I just wanted to close the bug on Wallch :D
[16:29] <ochosi> meh :)
[16:30] <brainwash> elfy: the lock screen is triggered after waking up the system, so it might reveal the desktop for a brief moment. that's what we need to test and confirm
[16:30] <brainwash> test with light-locker and xscreensaver
[16:31] <brainwash> and maybe other screen lock apps
[16:34] <ochosi> testing that now too... brb (hopefully)
[16:36] <ochosi> brainwash: works fine with light-locker
[16:36] <ochosi> no more seeing the session here, all goes as expected
[16:38] <brainwash> 1 positive test result :)
[16:38] <ochosi> well, better than 0 ;)
[16:39] <elfy> exactly what are you expecting me to do here - in one line - and not forgetting I have and then asking me to do it all again ;)
[16:39] <ochosi> 1) upgrade the xfpm package from brainwash's PPA
[16:39] <ochosi> 2) restart xfpm
[16:40] <ochosi> 3) make sure lock on suspend is set in light-locker-settings
[16:40] <ochosi> 4) close the lid
[16:40] <ochosi> 5) keep your fingers crossed that everything goes fine
[16:40] <ochosi> 6) repeat the test with light-locker removed and xscreensaver installed instead
[16:40] <ochosi> sound about right? ^
[16:41] <brainwash> no need to open the lid? :P
[16:41] <elfy> oh good lord - none of my alias's are set up on this :|
[16:42] <ochosi> hehe, yeah, right, 5.1) open the lid, log in again ;)
[16:42] <elfy> lol
[16:43] <elfy> but you failed at the first hurdle anyway - looks like 6.1 lines to me :D
[16:46] <ochosi> yeah, i know, readability > line-count ;)
[16:47] <elfy> lol
[16:47] <elfy> so that all went pear shaped ...
[16:47] <elfy> just undoing something I did the other day first :p
[16:49] <elfy> mmm
[16:50] <elfy> bah
[16:51] <elfy> so I'll do it after I've reinstalled it
[17:11] <slickymasterWork> elfy: http://iso.qa.ubuntu.com/qatracker/milestones/315/builds <- Xubuntu ones haven't landed yey
[17:11] <slickymasterWork> *yet
[17:15] <elfy> yea I know - I've not seen it build yet
[17:21] <elfy> brainwash ochosi - so - vanilla install, add the ppa - upgraded what it wanted to - killed and restarted xpfm - closed the lid - restart - password - black screen
[17:24] <elfy> purging ppa - readding it and then only upgrading xpfm and not light-locker
[17:34] <elfy> which didn't want to know - so upgraded - no difference - black screen here
[17:36] <ochosi> strange
[17:37] <ochosi> i guess it's no good if it doesn't work always for everyone
[17:37] <elfy> it's still sitting at the dead screen - I left it just in case you wanted me to try anything
[17:37] <elfy> ochosi: +1 this is the intel graphics machine
[17:41] <ochosi> well there's not much to try
[17:41] <elfy> ok
[17:42] <elfy>  so it's all set up to test that now - I just need pinging as and when
[17:43] <ochosi> guess if this sort of patch doesn't work, we'll need to find a good alternative approach first
[18:57] <elfy> GridCube: if you want to get more involved in QA this cycle - and that doesn't just involve testing - let me know, I'm sure I can find something :)
[18:58] <GridCube> elfy, sure, as i said anything i can help im willing to try
[18:58] <elfy> 1st step is to get a trello account then I'm afraid :p
[18:58]  * GridCube googles trello
[18:58] <elfy> that's were we do the backstage stuff
[19:02] <GridCube> done so
[19:02] <elfy> k - what's the account name?
[19:04] <GridCube> GridCube
[19:05] <elfy> k - you should get a mail from trello with the board name
[19:06] <elfy> lderan: re jenkins - excellent - all I've done till now is look rather irregularly :)
[19:06] <lderan> :P
[19:06] <GridCube> elfy, done and done
[19:07] <elfy> GridCube: woohoo
[19:07] <elfy> GridCube: I'll unarchive 14.04 and you can see how we used it during the cycle
[19:08] <GridCube> :)
[19:08] <GridCube> ill check it up later
[19:08] <GridCube> now i gotta go
[19:08] <GridCube> :D
[19:08] <elfy> basically it's just a list that we all write to - you can subscribe to things etc
[19:08] <GridCube> bbl
[19:08] <elfy> yep - well it's there now to look at
[19:08] <GridCube> yes , i think i understand the concept
[19:08] <elfy> 14.10 is quite empty
[19:09] <elfy> yea - it's not hard - I manage :)
[22:26] <ochosi> sergio-br2: ping
[22:28] <sergio-br2> hey
[23:15] <Unit193> < brainwash> 4.2 has been released?  <-- Yep, and with unicorn.  It contains some fixes, one of which is for UTF-8 showing up right.
[23:15] <Unit193> 4.2.1 is even out too, but not in Debian/Ubuntu yet.
[23:17] <ochosi> 4.2 of what?
[23:19] <Unit193> screen.
[23:22] <ochosi> ah
[23:30] <brainwash> ah
[23:31] <Unit193> I pulled the one when it went into experimental and rebuilt for trusty, sweetness.
[23:31] <ochosi> why, what does it do?
[23:33] <ochosi> not even sure what version of screen i have here
[23:34] <brainwash> just a version bump
[23:44] <Unit193> ochosi: 1. Nice to actually have a release after this time. 2. 4.2.1 merges distro patches so that's kind of nice.  3. And last, and the biggest one: http://git.savannah.gnu.org/cgit/screen.git/commit/?id=d94037c08a6dd30845b27cd76d99663e06aaabb2
[23:45] <ochosi> right, i guess that's nice
[23:48] <brainwash> mmh, does not get me hyped
[23:53] <Unit193> Oki, well that's the "new release" info anywho.
[23:54] <brainwash> at least it does not break anything
[23:54] <brainwash> like firefox 29 will :D
[23:54] <brainwash> new "innovative" GUI incoming
[23:56] <Unit193> Yeah, wondering if I should apt-mark hold the current, though not the "best" idea.
[23:58] <brainwash> ah, new dev cycle - same question
[23:59] <brainwash> XMir?
[23:59] <brainwash> or is it dead already (= not an option worth testing anymore)?


[00:49] <bdx> rick_h: is there special prometheus/telegraf/grafana bundle floating around that works with cmr/juju-2.3beta?
[00:50] <rick_h> bdx: just have to grab my versions in http://jujucharms.com/u/rharding
[00:50] <bdx> Ooooooo
[00:51] <bdx> rick_h: possibly you haven't granted me access?
[00:52] <bdx> oh the charms there
[00:52] <bdx> are the ones I'm looking for
[00:52] <rick_h> bdx: everyone has? https://jujucharms.com/u/rharding/prometheus/2 and https://jujucharms.com/u/rharding/telegraf/0
[00:52] <bdx> IC
[00:52] <rick_h>  bdx right
[00:53] <bdx> you deploy telegraf to the model on which you want to monitor the things on?
[00:53] <bdx> and relate telegraf across to prometheus then?
[00:53] <bdx> or, you offer up the prometheus endpoint
[00:53] <bdx> I see
[00:54] <bdx> offer up the prometheus endpoint
[00:54] <bdx> then the target model telegraf can relate
[00:58] <rick_h> bdx: right, telegraf is the subordinate that goes onto the things you want to watch
[00:58] <bdx> totally
[00:58] <rick_h> bdx: right, should be some blog examples to walk through from the demos if that helps
[00:58] <bdx> already on it
[00:58] <bdx> thx
[00:58] <rick_h> awesome
[00:59] <kwmonroe> not awesome rick_h
[01:00] <rick_h> kwmonroe: :( but but can it please be awesome?
[01:00] <kwmonroe> i hate our monitoring stack, and here's why...
[01:01] <kwmonroe> it's too hard
[01:03] <kwmonroe> rick_h: i want to gather logs and metrics from my deployment.. maybe that's k8s, maybe that's hadoop, etc.  it's hard to figure out whether elastico or prometheus or roll-your-own-rsyslog will serve me best.
[01:04] <rick_h> kwmonroe: yea, I think that getting the data into prometheus is alright as things tend to build that part in
[01:05] <rick_h> kwmonroe: the missing gap is that the relations needs to send sample dashboards over the wire to pre-setup the grafana/visualization bit for that data
[01:05] <rick_h> kwmonroe: imo and all that
[01:07] <kwmonroe> rick_h, yes! we can give peeps a great deployment and functional UI in one shot.  things like "sample dashboards" are what we're lacking.
[01:07] <bdx> https://github.com/jamesbeedy/layer-elasticsearch/issues/10
[01:07] <bdx> I'm on the same track
[01:07] <rick_h> kwmonroe: yea, so in the work we did for monitoring Juju we gave a  downloadable sample dashboard but you have to import it manually
[01:07] <bdx> I figured if I can get the grafana-source relation working there
[01:08] <bdx> that would help pull it all together
[01:08] <rick_h> kwmonroe: I think the thing is that the thing feeding prometheus data knows about the dashboard json, but has to pass that through prometheus, to grafana somehow
[01:08] <rick_h> bdx: yea, but it's a bit different since it's a relation once removed (one link back)
[01:09] <bdx> huh
[01:09] <bdx> "things like "sample dashboards" are what we're lacking" - totaly
[01:09] <bdx> @kwmonroe we need to start a hoard of dashboard json
[01:10] <rick_h> bdx: sorry, I thought you were saying prometheus should do it "I figured if I can get the grafana-source relation working there"
[01:10] <bdx> nah.
[01:10] <bdx> I got it working
[01:10] <bdx> with elasticsearch
[01:10] <bdx> not 100%
[01:10] <rick_h> I'm just saying if you monitor a machine with telegraf the telegraf charm should have sample grafana dashboards and I'm not sure how to get them to grafana through prometheus
[01:10] <bdx> but like working/bronk working
[01:10] <rick_h> bdx: ah, ES in particular
[01:10] <bdx> yeah
[01:10] <rick_h> bdx: gotcha, I read too much into it my bad
[01:10] <bdx> nw
[01:12] <bdx> I prefer grafana over kibana, I think its good to have both options for people (I've a new kibana charm in the works now)
[01:12] <bdx> but for *me*
[01:12] <bdx> I just want it all in one place
[01:12] <bdx> it makes sense to just have the two backends plugged into grafana
[01:13] <bdx> then you can get your elastic beat metrics
[01:13] <bdx> for logs
[01:13] <kwmonroe> i prefer "juju run --all top" for my metrics, but i get that others want this pesky stuff called "data".
[01:13] <bdx> lol
[01:13] <bdx> right
[01:16] <kwmonroe> bdx: let's say i want to propose a visualization engine for metrics/log analysis. your vote is +1 for grafana?
[01:17] <bdx> yeah
[01:17] <bdx> its multi-backend capable
[01:17] <kwmonroe> k, that settles it.  we're doing kibana.
[01:17] <bdx> haha
[01:17] <kwmonroe> ;)
[01:18] <kwmonroe> bdx: you tested so well the first time, let me try another.  prometheus vs elastic.  what say you?
[01:18] <bdx> we need a snap monitor
[01:19] <bdx> to export logs from snaps
[01:19] <bdx> kwmonroe, rick_h: how are you guys getting snap logs exported?
[01:21] <bdx> oh, nm
[01:21] <bdx> Im guessing you just pick them up from syslog
[01:23] <kwmonroe> bdx: i really don't know what you're asking... like a report from "snap list" for installed snaps?
[01:24] <kwmonroe> how in the holy heck this is related to prometheus/grafana/kibana monitors is a mystery to me.  get back in line bdx, one topic at a time.
[01:25] <bdx> lol
[01:25] <bdx> well
[01:25] <bdx> I just snapped our api
[01:25] <bdx> my next goal
[01:25] <bdx> like tomorrow is to get the logs sending through filebeat
[01:26] <bdx> https://forum.snapcraft.io/t/best-practice-for-logging/1210/7?u=jamesbeedy
[01:27] <bdx> so I asked the snapcraft guys what the best practice is there, to get the logs from your snaps
[01:27] <bdx> and the say to log to syslog
[01:27] <bdx> so I did that
[01:28] <bdx> but that doesnt actually mean your same log entries get into the actual system syslog
[01:28] <bdx> all in all
[01:28] <bdx> what I'm saying is
[01:28] <bdx> I don't know how to export the logs of a snap
[01:28] <bdx> and I feel its a difficult task
[01:28] <bdx> that I am extremely pressed to figure out
[01:29] <bdx> and I'm entirely blocked because I dont know how to export the darn logs for my snapped processes
[01:29] <bdx> if everyone is snapping their software, this has to be a common issue
[01:30] <bdx> if there is one thing that is a blocker for the whole logging deal using canonical tech
[01:31] <bdx> its exporting logs from snaps
[01:31] <bdx> for sure
[01:31] <rick_h> bdx: hmm, yea not sure tbh. I think stuff is still early into snaps and gaps like this need some love. I've not tried it out myself so no first hand exp.
[01:31] <bdx> ok
[01:31] <bdx> kwmonroe: your snapping quite a bit
[01:32] <bdx> how are you exporting your snapped process' logs?
[01:36] <bdx> ahh possibly they snap cant be in devmode
[02:00] <bdx> omg
[02:00] <bdx> im so silly
[02:01] <bdx> my logs were never showing up in syslog because I hadnt ever taken my snaps out of devmode
[02:02] <bdx> oh it wsa probably actually the confinement mode confinement
[02:02] <bdx> getting switched to classic
[02:02] <bdx> there we go
[02:03] <bdx> ok glad I figured that out
[02:06] <kwmonroe> bdx: i had to go see a guy about a thing.  i'm sorry i missed the diatribe, but here's the juice.  use the content interface to provide data from one snap to another (or the filessytem as a whole)
[02:06] <kwmonroe> it works wonders with 2.29
[02:07] <kwmonroe> sure, classic mode can save you, but you can enforce all kinds of specialness if you go confined. nothing good, mind you, but all kinds for sure.
[02:07] <bdx> nice
[02:07] <bdx> ok
[02:08] <bdx> Ill look into this immediately
[02:08] <bdx> snapd 2.29?
[02:10] <bdx> is that in zesty or something
[02:11] <bdx> https://packages.ubuntu.com/bionic/snapd
[02:11] <bdx> its not even in bionic
[02:11] <bdx> oooh
[02:11] <bdx> adha
[02:11] <kwmonroe> bdx, stop being a sheeple
[02:11] <bdx> that is a funny joke kwmonroe
[02:11] <kwmonroe> ;)
[02:12] <kwmonroe> snap refresh core --channel candidate will get ya 2.29
[02:12] <kwmonroe> sudo ^^ and what not
[02:14] <kwmonroe> anywho, i really do have to bug out.. point i was trying to make is the new ability to share bits via the content interface.  if you're interested, here's how something like the "pig" snap talks to hadoop, which is only available in 2.29: https://github.com/juju-solutions/snap-pig/blob/master/snap/snapcraft.yaml#L29
[02:14] <bdx> oh beautiful
[02:15] <bdx> thank you
[02:15] <bdx> go bug out now
[02:15] <bdx> ;)
[02:18] <kwmonroe> fwiw bdx, that only works because the 'configure' script of the pig snap makes that directory. it's a fickle time to be alive. i'm happy to chat with you more about how this stuff works -- maybe even headline the juju show this week.
[02:19] <bdx> yeah
[02:19] <bdx> you should
[02:19] <bdx> that would be great
[02:19] <bdx> @rick_h^
[02:19] <bdx> not sure what you agenda is
[02:20] <kwmonroe> oh hell, now you've gone and made it official
[02:20] <bdx> im hungry
[02:20] <bdx> for blood
[02:20] <kwmonroe> heh, see you folks manana
[02:20] <rick_h> Lol on the hook!
[02:20] <rick_h> Night kwmonroe
[05:54] <siraj> I am still looking for some help in this "unable to remove a service using juju remove-service <service-name> or by juju remove-unit or even removing a machine by juju remove-machine command. Even i deleted container still juju show-status display associated machine, application"
[13:51] <ChaoticMind> I'm having trouble provisioning a ceph cluster via juju. I think I got most of it going, but curl'ing the radosgw results in "Empty reply from server" -- can any folks with ceph/openstack experience provide insight?
[14:13] <zeestrat> Hey ChaoticMind, what are you deploying on (MAAS?) and how (bundle?)Å
[14:20] <ChaoticMind> zeestrat: I'm deploying on aws, via my own bundle which includes ceph-mon/ceph-osd/ceph-radosgw/keystone/horizon/percona(mysql) with appropriate relations etc
[14:24] <zeestrat> ChaoticMind: Gotcha. What do the radosgw logs say? Are you using network spaces by any chance?
[14:27] <ChaoticMind> Is there maybe like a minimum viable bundle available somewhere? The logs via juju debug-log aren't super helpful. Nope, not using network spaces.
[14:27] <ChaoticMind> Is there some specific log you're referring to?
[14:29] <ChaoticMind> oh, also, trying to follow https://jujucharms.com/ceph-radosgw/#access results in the command just hanging
[14:42] <zeestrat> Try to `juju ssh ceph-radosgw/0` and look at `/var/log/ceph/radosgw.log`
[14:45] <zeestrat> The guys in #openstack-charms (https://jujucharms.com/u/openstack-charmers/ in the charm store) have a bundle, but that is aimed at maas. You could ask the guys there if they have anything for specific for aws.
[15:01] <ChaoticMind> ah thanks zeestrat - it looks like it didn't initialize properly -- unable to find a keyring on /etc/ceph/keyring.rados.gateway. Have to figure out why
[16:51] <[Kid]> zeestrat, i am trying my new YAML and getting the same thing i was before
[16:51] <[Kid]> ERROR invalid charm or bundle provided at "./k8s-v1.yml"
[16:52] <[Kid]> https://pastebin.com/5XCNwXT3
[16:52] <[Kid]> is there a way to get a more verbose output on where juju is erroring?
[16:52] <[Kid]> like what line, column type debug
[17:50] <kwmonroe> [Kid]: try running 'charm proof' on the directory with your yaml.  you'll need to call it 'bundle.yaml' because i think that's a hard req for proofing bundles.
[17:50] <kwmonroe> [Kid]: when i ran it, it complained on line 28 and 40ish.  looks like you're missing the "to:" directive before your lxd:x entries.
[17:53] <zeestrat> Also, I think you can drop machine definitions 2 to 7 and just add the constraints part to the worker charm
[18:45] <rick_h> Juju show in 15min!!!!
[18:45] <rick_h> woot woot!
[18:51] <rick_h> link for folks that want to join in the chat https://hangouts.google.com/hangouts/_/zxyr3qie45ejfh2x7x7sva5szee
[18:52] <rick_h> kwmonroe: bdx hml tvansteenburgh cory_fu marcoceppi and anyone else that I can talk into it :)
[18:52] <rick_h> ^
[18:52] <rick_h> for watching from the sidelines you'll want the link: https://www.youtube.com/watch?v=YFwE6x6JETY
[18:53] <cory_fu> Cynerva, ryebot: ^
[18:58] <rick_h> bdx: you coming today?
[19:14] <cory_fu> https://github.com/juju-solutions/charms.reactive/pull/123
[19:19] <cory_fu> Also, here is an example interface refactored to use it: https://github.com/juju-solutions/interface-kube-control/blob/6987921aacb7a03c01b635a9465873683a6a54ac/provides.py
[19:21] <cory_fu> bdx: Have you used the --wheelhouse-overrides option for charm build to test some of these in-progress features?
[19:21] <bdx> no
[19:22] <bdx> I can feed that a wheelhouse tarbal?
[19:22] <cory_fu> bdx: Newer versions of charm-build support --wheelhouse-overrides that lets you provide an external wheelhouse.txt file when building a charm that will override items provided by the charm or layers
[19:22] <cory_fu> Not a tarball, alas
[19:22] <cory_fu> Might be worth doing as another feature
[19:23] <cory_fu> But it lets you override items line-by-line
[19:28] <bdx> cory_fu: how is it that I get your branch into the wheelhouse.txt?
[19:29] <kwmonroe> content interface docs: https://forum.snapcraft.io/t/the-content-interface/1074 <-- rick_h
[19:31] <cory_fu> bdx: You can use the VCS URL support: https://pip.readthedocs.io/en/stable/reference/pip_install/#vcs-support
[19:31] <zeestrat> Who's in charge of charmhelpers? The docs situation is a bit of a mess. https://github.com/juju/charm-helpers/issues/27
[19:40] <rick_h> damn, hit done on that and it killed my chrome
[19:41] <rick_h> kwmonroe: :P the last thing I heard before crashing was something about "get it together at the end"
[19:42] <kwmonroe> yeah rick_h, i was trolling on your ability to get your k8stuffv2 deployed.  you did it though.  nice job :)
[19:42] <rick_h> kwmonroe: hah, /me dances harder for the fans
[19:47] <cory_fu> zeestrat: Hrm, yeah, that's probably because pythonhosted.org has been deprecated and uploads all but disabled.  We need to set it up on RTD.io
[19:49] <zeestrat> That would be great :)
[19:51] <cory_fu> tvansteenburgh: Are you admin on the charm-helpers GH repo?
[19:52] <tvansteenburgh> cory_fu: yes, and so are you
[19:52] <tvansteenburgh> oh wait
[19:52] <cory_fu> tvansteenburgh: Nope.
[19:53] <cory_fu> It's probably just jamespage, I suspect
[19:53] <tvansteenburgh> cory_fu: yeah probably, i'm not
[19:55] <cory_fu> tvansteenburgh, zeestrat: Ok, I pinged him on the issue.  Should be pretty straightforward to get done when he's in.
[19:56] <bdx> https://imgur.com/a/4oM40
[19:56] <bdx> all of those ^ machines are right next to eachother in the same subnet
[19:57] <bdx> just because its a cross-model relation shouldn't mean we automatically assume the public ip
[19:57] <bdx> I know I've talked about this with jam and axw (I think)
[19:58] <bdx> but I just want to make it apparent such that its something people think about as they use the new networking functionality
[19:58] <bdx> I absolutely do not want my things to talk over the wan when they are sitting right next to eachother
[19:58] <bdx> hopefully others start to see this, and start yapping about it
[19:59] <bdx> "all of those ^ machines are right next to eachother in the same subnet" - the machine are also right next to prometheus and grafana
[19:59] <bdx> in the same subnet
[19:59] <bdx> not sure if people are aware
[19:59] <bdx> or even care
[20:00] <bdx> I guess we are making the assumption that if things are in a different model, then they dont have rout-ability to eachother
[20:01] <bdx> or possibly, just the wrong endpoint was chosen from network-get
[20:01] <bdx> idk
[20:01] <[Kid]> kwmonroe, thanks! i completely missed that
[20:01] <[Kid]> and that charm proof command is handy!
[20:02] <kwmonroe> np [Kid]
[20:02] <jamespage> cory_fu: hey - what do you need?
[20:03] <cory_fu> jamespage: You're up late.  :)  I was going to set up the charm-helpers repo on readthedocs.org, but I don't have sufficient permissions.  So it's up to you to either set it up there, or give me perms to do so
[20:03] <jamespage> cory_fu: in australia - what's your github handle?
[20:04] <cory_fu> jamespage: johnsca  Then you're up even later than I thought!
[20:04] <jamespage> cory_fu: ok you have admin on that repo now
[20:04]  * jamespage heads for breakfast
[20:04] <[Kid]> kwmonroe, is charm a separate program?
[20:05] <cory_fu> jamespage: Thanks!  Oh, I guess it's early there, then
[20:05] <[Kid]> i.e., do i need to apt-get install charm?
[20:05] <cory_fu> I'm bad at timezones
[20:05] <zeestrat> cory_fu: Great. Would also be handy to redirect the pythonhosted site and update the pypi as it has a decent google rank.
[20:05] <[Kid]> ahh got it
[20:05] <[Kid]> charm-tools
[20:05] <cory_fu> zeestrat: Unfortunately, I haven't found a way that (still) works to do a pythonhosted.org redirect.  Best I can do is delete the docs from there entirely
[20:07] <[Kid]> haha, now i am getting FATAL: Not a Bundle or a Charm, can not proof
[20:07] <[Kid]> and i named it bundle.yaml
[20:09] <[Kid]> haha, but it works anyways
[20:09] <[Kid]> oh well
[20:14] <kwmonroe> [Kid]: charm is a separate program, and while i think you've stumbled onto the ppa that provides charm-tools, the recommended install method is to 'sudo snap install charm'.
[20:15] <kwmonroe> not sure why you're getting a fatal error, but you can pass --debug to the charm command.  perhaps that'll reveal something.
[20:16] <[Kid]> it works
[20:16] <[Kid]> it is deploying, but still only deploying 5 out of the 8 nodes
[20:16] <[Kid]> will it deploy in stages?
[20:16] <[Kid]> i.e., do 5 then the other 3?
[20:17] <[Kid]> this is my new bundle.yaml
[20:17] <[Kid]> https://pastebin.com/GBHKFtzi
[20:17] <[Kid]> and i have the "worker" tag on the nodes in MAAS that are not being deployed
[20:18] <[Kid]> but they are showing "down" in juju status
[20:20] <kwmonroe> [Kid]: juju should do all the machines at once -- maybe maas is just taking a bit of time to fulfil the request.  you could try passing --debug to the juju deploy command to see if that bubbles up any provisioning errors from maas.
[20:21] <kwmonroe> [Kid]: fyi, you can run 'juju deploy' multiple times and it'll reuse existing deployed stuff, so like if easyrsa is already in your model, a subsequent juju deploy will just reuse it.
[20:24] <[Kid]> ahh that is good information
[20:25] <[Kid]> maybe that will kick start MAAS
[20:31] <zeestrat> [Kid]: Just to be clear, how many nodes do you have in maas and how are they tagged? Could ya also pastebin `juju status`?
[20:33] <[Kid]> zeestrat, i have 8 nodes
[20:33] <[Kid]> first two are tagged: master,worker
[20:33] <[Kid]> the rest are tagged: worker
[20:34] <[Kid]> https://pastebin.com/DRAgWsV5
[20:34] <[Kid]> juju status
[20:34] <[Kid]> thing is, MAAS spun up 5 nodes
[20:35] <[Kid]> and not 3
[20:35] <[Kid]> and the 3 it didn't spin up are in a "Ready" state powered off
[20:36] <[Kid]> the two that are labeled master,worker were spun up, but they arent being seen by juju
[20:37] <thumper> [Kid]: are there any errors in the juju log?
[20:37] <[Kid]> just ran deploy again against the same bundle also.
[20:37] <[Kid]> https://pastebin.com/CYbbP8qA
[20:37] <[Kid]> umm in /var/log/juju.log?
[20:38] <[Kid]> i mean /var/log/juju/logsink.log?
[20:38] <thumper> or juju debug-log
[20:38] <zeestrat> [Kid]: Gotcha. Thanks for the info. I see the model shows version 2.0.2. Could you write the output of `juju version`? Just wanna make sure you're on an up to date juju first.
[20:38] <thumper> actually
[20:38]  * thumper thinks of a nice way
[20:39] <[Kid]> juju --version
[20:39] <[Kid]> 2.0.2-xenial-amd64
[20:39] <thumper> oh dear
[20:39] <thumper> you really want to be using newer
[20:39] <thumper> however
[20:39] <[Kid]> i used snap install
[20:39] <[Kid]> that should have pulled latest, right?
[20:39] <thumper> juju debug-log -m controller -l warning --replay
[20:40] <thumper> [Kid]: snap list
[20:40] <thumper> how old is the controller?
[20:40] <[Kid]> snap list
[20:40] <[Kid]> Name  Version    Rev   Developer  Notes
[20:40] <[Kid]> core  16-2.28.5  3247  canonical  core
[20:40] <[Kid]> juju  2.2.6      2739  canonical  classic
[20:41] <thumper> when did you bootstrap the controller?
[20:41] <[Kid]> like a week ago
[20:41] <thumper> juju status -m controller
[20:41] <[Kid]> this is a brand new install
[20:41] <zeestrat> @thumper, might we have a case of mixed snap and ppa install?
[20:41] <[Kid]> juju status -m controller
[20:41] <[Kid]> Model       Controller  Cloud/Region  Version  Notes
[20:41] <[Kid]> controller  dal01-maas  dal01-maas    2.0.2    upgrade available: 2.0.4
[20:41] <[Kid]> App  Version  Status  Scale  Charm  Store  Rev  OS  Notes
[20:41] <[Kid]> Unit  Workload  Agent  Machine  Public address  Ports  Message
[20:42] <[Kid]> Machine  State    DNS          Inst id  Series  AZ
[20:42] <[Kid]> 0        started  <IP_ADDRESS>  6hqhy4   xenial  default
[20:42] <[Kid]> 1        started  <IP_ADDRESS>  n83trc   xenial  default
[20:42] <[Kid]> 2        started  <IP_ADDRESS>  e6qkdm   xenial  default
[20:42] <zeestrat> [Kid]: Could you also do a `sudo dpkg -l | grep juju`
[20:43] <[Kid]> just to be clear the 3 controllers it is showing are VMs
[20:43] <[Kid]> and the machine i am running these commands from is the MAAS server
[20:43] <[Kid]> so i could bootstrap
[20:43] <[Kid]> ii  juju                               2.0.2-0ubuntu<IP_ADDRESS>                     all          next generation service orchestration system
[20:43] <[Kid]> ii  juju-2.0                           2.0.2-0ubuntu<IP_ADDRESS>                     amd64        Juju is devops distilled - client
[20:43] <[Kid]> ii  python-jujubundlelib               0.4.1-0ubuntu1                             all          Python 2 library for working with Juju bundles
[20:46] <zeestrat> Looks like there's an old juju installed. I'd suggest removing the juju and juju-2.0 packages with apt remove etc. Then hopefully you should end up with 2.2.6 from the snap.
[20:48] <zeestrat> Then if it's OK, destroy the controller and do a fresh bootstrap with 2.2.6.
[20:48] <[Kid]> this is wierd
[20:48] <[Kid]> Removing juju (2.0.2-0ubuntu<IP_ADDRESS>) ...
[20:48] <[Kid]> juju --version
[20:49] <[Kid]> Removing juju (2.0.2-0ubuntu<IP_ADDRESS>) ...
[20:49] <[Kid]> 2.0.2-xenial-amd64
[20:50] <zeestrat> You probably need to purge those packages
[20:51] <kwmonroe> [Kid]: might also want to 'export PATH=/snap/bin:$PATH' to make sure the snap executables take precedence
[20:52] <[Kid]> kwmonroe, that did i!
[20:52] <[Kid]> the export now points to the right juju
[20:52] <[Kid]> 2.2.6
[20:54] <[Kid]> another wierd thing is when it destroys the model, it will release all the nodes except for the two that have the dual tags.
[20:54] <[Kid]> the worker,master two
[20:54] <[Kid]> i have to manually release those
[20:54] <[Kid]> trying with 2.2.6 now
[20:57] <[Kid]> well this is stupid. i just rebooted and right back to 2.0.2
[20:58] <[Kid]> ok, its cause it isn't keeping the system variable
[20:59] <[Kid]> how can i make that variable persistant?
[20:59] <zeestrat> Yeah, if purging those packages aint an option, you could fix your path in .bashrc or the like
[21:00] <[Kid]> crap, i have to bootstrap again too
[21:00] <[Kid]> cause the controllers are at 2.0.2
[21:09] <zeestrat> [Kid]: As it's getting late for my brain, here's what I'd do if you still end up with the nodes not deploying. Make sure juju is able to deploy all maas nodes, for example by just deploying a bunch of ubuntu charms `juju deploy ubuntu -n 8`. If all good, remove the worker tags from the master nodes in maas for now just to avoid any confusion and try to deploy something like this: https://pastebin.com/UP3CpdD3
[21:09] <zeestrat> By the way, what version of maas are you running?
[21:10] <[Kid]> 2.2.2
[21:10] <[Kid]> zeestrat, kwmonroe, and thumper. thank you for your help, i really apprciate it
[21:10] <zeestrat> Great. That should work fine.
[21:11] <[Kid]> i see how beneficial juju and maas can be together, just have to get past these bumps. helps me learn though
[21:11] <kwmonroe> w00t, great to here [Kid]
[21:11] <kwmonroe> er, hear
[21:20] <thumper> [Kid]: you probably could have upgraded the controllers
[21:20] <thumper> rather than redeploy
[21:21] <[Kid]> crap. oh well
[21:22] <[Kid]> i am almost done bootstrapping again
[21:22] <[Kid]> also, i meant to mention i am in a HA cluster
[21:22] <[Kid]> for the controllers
[21:22] <thumper> you will find 2.2.6 much better than 2.0.2
[21:22] <thumper> faster
[21:22] <thumper> and more stable
[21:22] <[Kid]> that is good
[21:22] <thumper> better memory footprint
[21:23] <[Kid]> yeah, the ubuntu repos are usually way behind
[21:23] <[Kid]> i don't like bleeding edge, but they are barely trickling blood edge
[21:29] <[Kid]> well, this is interesting
[21:30] <[Kid]> 2.2.6 gives me more detail
[21:30] <[Kid]> cannot run instances: cannot run instance: N
[21:30] <[Kid]> o available machine matches constraints: [('tags', ['master', 'worker']), ('agent_name', ['d71fcd25-e
[21:30] <[Kid]> 11b-4991-8831-1349aca1ad9a']), ('zone', ['default'])] (resolved to "tags=master,worker zone=default")
[21:30] <[Kid]> they are there.
[21:31] <[Kid]> and now the only machines it spun up are the two that have the master,worker tags
[21:31] <[Kid]> ahhh there we go
[21:31] <[Kid]> it is spinning more up now...
[21:32] <[Kid]> so now i think it has something to do with those tags
[21:32] <[Kid]> its like it doesn;t like having two tags as a constraint
[21:40] <zeestrat> [Kid]: I'd try not using multiple tags in constraints like I described above to avoid the issue for now and come back to that later.
[22:00] <[Kid]> ok
[22:01] <[Kid]> and i can just use the to: instead of contraints
[22:37] <thumper> [Kid]: why does the machine need both master and worker tags?


[00:24] <IdleOne> today is the 17th.
[00:25] <IdleOne> time travel is confusing
[00:41] <supachick> hi
[00:41] <supachick> atruechurch.info
[00:41] <supachick> !ops
[00:41] <supachick> yay
[00:42] <supachick> hi idleone
[00:42] <IdleOne> you done?
[00:43] <supachick> ban me and get it done with
[00:43] <supachick> -_-
[00:43] <IdleOne> you can leave on your own
[00:43] <supachick> !ops
[00:44] <supachick> unless you repent you will perish
[00:44] <IdleOne> I'll perish anyway
[00:44] <IdleOne> some day
[00:44] <supachick> why do you want to go to the lake of fire
[00:44] <IdleOne> better view
[00:44] <chu> He's Canadian, obviously sick of the cold.
[00:44] <supachick> http://youtu.be/-5RW_w3wg6E?t=27m18s
[07:42] <DLange> Hi
[07:42] <DLange> every time freenode splits and services are on the other side you send people to #ubuntu-unregged
[07:43] <DLange> that's pretty annoying (and I'm affected by it every week or so depending on how splitty freenode is and how stable services are in a given timeframe)
[07:43] <DLange> (+jf 5:10 #ubuntu-unregged on the channel)
[07:44] <DLange> we've removed that from ##linux quite a long time ago and I'd ask you to do the same for #ubuntu as it only affects your users but doesn't help with anything currently
[07:45] <DLange> if ever botnets like we had a few years ago come back, you can always put a join throttle back on the channel
[07:45] <k1l> DLange: we just had botnets the other day.
[07:46] <k1l> #ubuntu as one of the biggest channels gets regular attention from botnets. but i will forward this suggestion to the team and we will discuss that issue. thanks
[07:49] <DLange> can you point me to the botnet joins? I didn't find anything in #ubuntu logs for the last 48hrs (before I was pinged off and ended back in -unregged as so often)
[07:49] <DLange> the max I'm seeing these days is five joins from one IP and a kiddie with three or so VPNs
[07:50] <DLange> that won't get filtered by +jf 5:10 but the 100s and 1000s of users returning from splits always are
[07:51] <DLange> esp. as freenode's seven has broken the ping handling and re-join burst but that's another story for another day
[07:51] <Unit193> One in my backlog is at 16:40 EST, but yes returning from netsplits into there is annoying.
[07:54] <DLange> can you pastebin?
[07:55] <DLange> idlog -sjoined \#ubuntu.log | grep ":40 " | sort | uniq -c doesn't return any joins of more than one IP for me
[07:56] <DLange> (but then my logs are incomplete as I end up in -unregged every now and then :-))
[07:56] <k1l> http://irclogs.ubuntu.com/2014/07/15/%23ubuntu.html#t18:17
[07:57] <Unit193> The joins/parts/quits/notices were not logged.
[07:58] <k1l> i know
[07:58] <k1l> just to show that there are bots joins.
[07:58] <DLange> neither IPs or *anything* useful for administering the channel :) This is for end users (only)...
[08:01] <DLange> I have it in my logs, thanks for the pointer k1l
[08:01] <DLange> still the join throtteling doesn't help much with such small botnets
[08:03] <DLange> if you don't want to remove the +jf, consider +I *!*@about/linux/staff/* and /freenode/staff
[08:03] <DLange> the cloaks are often still on when the auth is gone due to split services
[08:06] <DLange> have fun discussing, cu around
[09:34] <Pricey> Hmm I thought the ircd kept track of whether you were identified...
[09:39] <k1l> but not in netsplits when all the services go mad etc.
[13:13] <Pricey> k1l: I misread Dlange's lines so my comment is entirely irrelevant.. but I'm pretty sure the ircd does keep track of whether you're identified if it splits from the services side of the network.
[14:17] <k1l_> Pricey: yes. but there was a huge netsplit last days where users were dropped and when reconnecting they could not auth because the services were down. but that is no that common
[15:02] <Pricey> k1l_: Right, I usually only refer to netsplits as servers losing connectivity.
[15:05] <Pricey> Looks like our new "netsplit whenever staffers says 'netsplit'" fantasy commands are working.
[15:12] <k1l_> "it wasnt me" :)
[15:59] <Tm_T> bah
[16:00] <Tm_T> I fail, can someone help me with this? I've basicly without computer this summer so I find this thing bit difficult right now
[16:00] <Tm_T> @login
[16:02] <Tm_T> ah, got it
[16:02] <Tm_T> thanks! (:
[17:57] <Pici> 9.04 :(
[22:03] <popey> I have asked this before, but can never quite get the incantation right, I need #ubuntu-phone to not exist, but fo~
[22:03] <popey> bah
[22:03] <popey> stupid cat walked on keyboard pressing enter then
[22:03] <popey> I need #ubuntu-phone to forward to #ubuntu-touch
[22:03] <popey> can someone tell me the magic?
[22:04] <ikonia> it's it just +f
[22:04] <ikonia> +F #ubuntu-phone #ubuntu-touch
[22:04] <ikonia> I thought it was already done
[22:04] <popey> me too
[22:04] <popey> thought we did it months back
[22:04] <ikonia> it's mode +F #ubuntu-phone #ubuntu-touch from memory
[22:04] <ikonia> but #ubuntu-touch needs to accept forwards
[22:05] <popey> 23:04:46 -!- mode/#ubuntu-phone [+Fb-n #ubuntu-touch!*@*] by popey
[22:05] <ikonia> let me see if I can dig out the sytax if someone doesn't know it
[22:05] <popey> that look okay?
[22:05] <ikonia> don't know what -n is and I don't think you need the !*@*
[22:06] <popey> well that failed
[22:06] <ikonia> ahhh look at that
[22:06] <popey> I just did /mode +F #ubuntu-phone #ubuntu-touch
[22:06] <ikonia> #ubuntu-ops just did it
[22:06] <ikonia> perfect timing net split
[22:06] <popey> eh?
[22:07] <ikonia> 23:06 -!- mode/#ubuntu-ops [+Fcntzf #ubuntu-unregged]
[22:07] <ikonia> una momento
[22:07] <ikonia> let me dig out the docs
[22:07] <ikonia> lets try to get it right
[22:07] <popey> ta
[22:08] <popey> also need to do -tablet and -tv too
[22:08] <ikonia> ok so #ubuntu-touch needs to be +F
[22:09] <ikonia> then #ubuntu-phone needs to be +f #ubuntu-touch
[22:09] <ikonia> and you're +n was also useful
[22:09] <popey> oh
[22:09] <ikonia> (I think thats right)
[22:10] <popey> lets see
[22:10] <popey> nope
[22:10] <ikonia> ughhhh
[22:11] <ikonia> popey: you're an op in both channels ?
[22:11] <popey> yes
[22:12] <ikonia> that seems odd then as +F on #ubuntu-touch allows it to accept forwards
[22:12]  * genii slides k1l_a fresh coffee
[22:12] <ikonia> then +f on #ubuntu-phone should allow it to forward to a channel that is +F
[22:13] <ikonia> popey: try setting it +i too
[22:13] <popey> which?
[22:13] <ikonia> popey: so #ubuntu-phone +if #ubuntu-touch
[22:14] <popey> bingo!
[22:14] <popey> thank you ikonia !
[22:14] <ikonia> ahhh
[22:14] <ikonia> no sweat
[22:14] <ikonia> I was reading it wrong
[22:54] <k1l_> was it Pricey again? :)