[00:00] <jono> good thanks, you?
[00:00] <ScottL> doing well, getting kids dinner then i'm working on some studio stuff
[11:32] <astraljava> ochosi: If you have a little time sometime soon, please have a look at bug #952462, Colin mentions Xfce session handling in https://bugs.launchpad.net/ubuntustudio/+bug/952462/comments/4
[11:54] <mr_pouit> astraljava: you need to do like mythbuntu-live-autostart/xubuntu-live-settings
[13:16] <mr_pouit> micahg: thanks, I hope it'll be ok for the next beta.
[14:07] <astraljava> mr_pouit: Thanks, I also learnt this from a later comment on the bug. I'll look into this tonight, hopefully.
[15:01] <astraljava> Anyone in here using thunderbird as an email app and keeping Indicator plugin in use as well? I find the indicator fails to keep syncronized with the unread mail information from t-bird, thus erratically showing the envelope as blue even when all mail has been marked as read.
[15:13] <micahg> mr_pouit: yeah, next beta should be doable
[15:23] <ochosi> astraljava: i guess lionel's reply is what you want/ed :)
[15:23] <astraljava> ochosi: Sure is, thanks. :)
[18:59]  * knome fires up the desktop pc and we're good to go
[19:02] <Unit193> @ping
[19:02] <meetingology> pong
[19:02] <Unit193> Ready, just not identified.
[19:02] <knome> okay, so who's here for the meeting?
[19:02] <Unit193> I am.
[19:03] <pleia2> \o
[19:03] <mr_pouit> o hai
[19:04] <knome> #startmeeting Xubuntu Community Meeting
[19:04] <meetingology> Meeting started Wed Mar 14 19:04:05 2012 UTC.  The chair is knome. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[19:04] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[19:04] <knome> #topic Team Updates
[19:04] <knome> #subtopic Package and Development
[19:04] <knome> meetingology,
[19:04] <knome> errrh
[19:04] <knome> mr_pouit,
[19:05] <mr_pouit> nothing much apart from bugfixes: xfdesktop4, xfce4-cellmodem-plugin, shimmer-themes, xfce4-settings and xfce4-xkb-plugin
[19:05] <knome> mr_pouit, can you repost with #info? thanks :P
[19:05] <mr_pouit> micahg working on lightdm-gtk-greeter and blueman, should hopefully be ok for beta 2
[19:06] <mr_pouit> I hate you :p
[19:06] <knome> it's mutual
[19:06] <knome> i hate myself too
[19:06] <mr_pouit> #info nothing much apart from bugfixes: xfdesktop4, xfce4-cellmodem-plugin, shimmer-themes, xfce4-settings and xfce4-xkb-plugin
[19:06] <mr_pouit> #info micahg working on lightdm-gtk-greeter and blueman, should hopefully be ok for beta 2
[19:06] <mr_pouit> voila :)
[19:06] <knome> thanks
[19:06] <knome> anything else?
[19:07] <knome> #info PAE kernel is requested for xubuntu precise i386
[19:07] <mr_pouit> yeah, that too
[19:07] <knome> err!!!
[19:07] <knome> #info NON-PAE kernel is requested for xubuntu precise i386
[19:07]  * knome 's brain is a bit numb
[19:07] <knome> #subtopic Bugs, Testing, Docs
[19:07] <micahg> how many users do we expect to need that?
[19:08] <knome> micahg, no idea, but it's easier to install PAE
[19:08] <Unit193> You should be able to go from a mini and install xubuntu-desktop.
[19:08] <knome> Unit193, yes... but in that case, we're offering alternate too
[19:08] <knome> Unit193, so those who need alternate, could go via mini too
[19:09] <knome> there's an item for this on other business, we can continue this later in the meeting :)
[19:09] <knome> anything on bugs, testing, docs?
[19:09] <pleia2> ah, yes
[19:09] <pleia2> #info I'm in the process of improving the testing docs, hopefully a blog post too so we can have more testers for beta2
[19:10] <pleia2> .
[19:11] <knome> something else?
[19:11] <pleia2> that's all from me
[19:11] <knome> ok...
[19:11] <knome> #subtopic Marketing, Art, Web
[19:12] <knome> i suppose there's not yet anything new from the marketing stuff?
[19:12] <pleia2> #info Submitted web form request to confirm we can make Xubuntu products, no response
[19:12] <pleia2> it's been over 2 weeks now
[19:12] <pleia2> so nothing new :(
[19:12] <knome> :/
[19:12] <knome> yeah, let's hope we get forward before precise release
[19:13] <pleia2> I'll try again, maybe it just got lost
[19:13] <knome> btw, if we change our logo, we need new stickers
[19:13] <knome> or at least new sticker sources :)
[19:14] <knome> #subtopic General updates
[19:14] <knome> anything else?
[19:15] <pleia2> I think that's it
[19:15] <knome> me too, it should be quiet after all the freezes...
[19:15] <knome> #topic Other Business
[19:15] <knome> #subtopic Seeding GThumb
[19:16] <knome> okay, so now that ristretto is working again, do we feel like we still should seed gthumb?
[19:17] <mr_pouit> yeah, for importing photos from cameras?
[19:17] <knome> but most of the cameras work as uh, filesystems
[19:17] <knome> there was a term for this
[19:18] <mr_pouit> mass storage?
[19:18] <knome> that
[19:20] <knome> so does most of the cameras support that or not?
[19:20] <mr_pouit> I think we still need gthumb for other cameras that use ptp
[19:20] <mr_pouit> (but I'm not really into that sort of things, so I can be wrong ;-)
[19:21] <knome> okay, it's not too large, is it?
[19:21] <knome> and btw, what's the current iso size status?
[19:21] <mr_pouit> we're not oversized anyway
[19:22] <mr_pouit> amd64: 694M, i386: 679M
[19:22] <mr_pouit> (today)
[19:22] <knome> mmh, so not too tight
[19:22] <knome> (thinking about P+1 too)
[19:22] <knome> so let's still seed gthumb
[19:22] <knome> or does somebody disagree?
[19:23] <knome> no? okay...
[19:23] <knome> #subtopic New logo
[19:23] <knome> so, there's a proposal for a new logo
[19:23] <knome> reasoning is:
[19:23] <knome> it's easier to drop in to various places graphically
[19:23] <knome> it works better on small sizes
[19:24] <knome> it's brighter and more saturated
[19:24] <knome> and it looks good too.
[19:24] <knome> comparisons can be found at: http://temp.knome.fi/xubuntu/precise_logo/
[19:25] <knome> comments?
[19:25] <pleia2> it's good :)
[19:26] <knome> yes, i personally prefer the closed shape very much
[19:28] <knome> is anybody disagreeing? i wanted to bring this to the meeting to raise discussion and to hear if somebody disagrees
[19:29]  * knome just confirmed with skaet that we are okay to do the logo changes after UIFe
[19:29] <mr_pouit> so no exception needed?
[19:30] <knome> mr_pouit, i'm checking with skaet
[19:31] <knome> #action knome, ochosi and mr_pouit to work on getting the new logo everywhere
[19:31] <meetingology> ACTION: knome, ochosi and mr_pouit to work on getting the new logo everywhere
[19:31]  * micahg prefers the old logo
[19:32] <micahg> the new one makes it hard to tell what it is
[19:33] <knome> mmh. i wonder if that's true for those too who doesn't already know the xfce logo
[19:33] <mr_pouit> (I like it on the plymouth theme)
[19:33] <knome> mr_pouit, "probably best to submit a UIFe"
[19:34] <knome> mr_pouit, if you need help with that, just ask me
[19:34] <knome> mr_pouit, or, if you want me to do that :P
[19:35] <micahg> and the whiskers look like a bunny is hiding in the background
[19:35] <knome> mr_pouit, the new or old?
[19:36] <knome> micahg, in the old logo, the whiskers are barely visible
[19:36] <micahg> right :)
[19:36] <knome> except in BIG sizes
[19:36] <mr_pouit> knome: the new one (and yes, please file the UIFe please :P)
[19:37] <knome> but that's not really a problem with the new logo either... there *is* a gap :)
[19:37] <knome> mr_pouit, yeah, skaet ACK'd, now just need to send email to docs team
[19:38] <knome> mr_pouit, okay, we need to upload *this week* :)
[19:38] <micahg> knome: I think the gap makes it look funny
[19:39] <knome> micahg, yeah, but the gap existed on the old logo too
[19:39] <micahg> doesn't look like it
[19:39] <knome> huh?
[19:39] <knome> in http://temp.knome.fi/xubuntu/precise_logo/logo_comparison.png ? :)
[19:40] <micahg> oh, yeah, on that one you can see it
[19:40] <knome> yeah, it's a small one on both, but there is one on both
[19:40] <micahg> was looking at the website logo
[19:40] <knome> ah :)
[19:40] <knome> yeah, the website logo is actually the reason why we decided to change
[19:44] <knome> micahg, so, do you still think there new logo is weird?
[19:44] <micahg> yes
[19:44] <knome> i mean, there's some drawbacks on both ones..
[19:44] <micahg> but I've been using Xubuntu for 4 years and am very familiar with the old look
[19:44] <knome> is it about the whiskers, or the mousehead-shape?
[19:45] <micahg> both
[19:45] <knome> mmh
[19:45] <knome> any suggestions how could we make it less weird?
[19:46] <knome> for the mousehead, i don't think there's much to do except small changes to the shape, since the idea is to have a closed-shape logo
[19:46] <micahg> thinner whiskers, add back legs?
[19:46] <knome> would make the shape inside the circle smaller
[19:47] <knome> also, i suppose it would look weird to have legs but almost no body at all :)
[19:48] <knome> anyhow, do we think we're ready to vote?
[19:48] <knome> small changes are doable before uploading, i'll be working on this tomorrow anyway
[19:48]  * micahg seems to be alone in this view though
[19:48] <Unit193> micahg: I wasn't fond of it either.
[19:49] <knome> i could look about making the gap for whiskers bigger
[19:49] <knome> Unit193, and this is exactly why i asked you to say this earlier
[19:49] <micahg> I don't think the gap should be bigger, rather the whiskers thinned out
[19:50] <knome> mmh.
[19:50] <knome> i can look what i can do without making them disappear again on small sizes :)
[19:50] <knome> or, then we could just have two versions, but that's in a way suboptimal
[19:51] <knome> Unit193, do you want to express what *you* think is not right with the new logo?
[19:51] <Unit193> Not really, that's why I held my fingers, so to say.
[19:51] <knome> micahg, are you completely dissatisfied with the new look?
[19:53] <micahg> knome: idk, I'd probably get used to it over time, I just prefer something closer to the old one
[19:53] <knome> micahg, yeah. it's not that i don't like the old one, it's just a near-nightmare graphically to drop in to various places :)
[19:54] <micahg> knome: can we go the other way and pull the full mouse in?
[19:55] <knome> micahg, that makes it completely unrexognisable on small sizes
[19:55] <knome> micahg, which is why we didn't do that at 10.04, when we changed the logo the last time
[19:55] <micahg> what does upstream do about this?
[19:55] <knome> i suppose xfce uses the X from the logo
[19:55] <knome> and mouse only on bigger sizes
[19:58] <knome> micahg, do you think the whiskers are too fat in the website comparison already?
[19:59] <micahg> yes
[19:59] <knome> what about plymouth?
[19:59] <knome> imo they are quite right there...
[20:00] <knome> but maybe that's because it's inverted :)
[20:01] <knome> the actual sizes are pretty much the smae
[20:01] <knome> #action knome to look the whisker-size
[20:01] <meetingology> ACTION: knome to look the whisker-size
[20:01] <pleia2> that's my favorite action item ever
[20:01] <knome> hehe
[20:02] <knome> if there is nothing new to add to the discussion, let's vote yay/nay
[20:02] <knome> #vote New Xubuntu logo (+1) or the old one, please! (-1)
[20:02] <meetingology> Please vote on: New Xubuntu logo (+1) or the old one, please! (-1)
[20:02] <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me)
[20:02] <knome> +1
[20:02] <meetingology> +1 received from knome
[20:02] <pleia2> +1
[20:02] <meetingology> +1 received from pleia2
[20:03] <knome> mr_pouit, micahg, Unit193
[20:03] <micahg> -1
[20:03] <meetingology> -1 received from micahg
[20:03] <Unit193> -0
[20:04] <knome> Unit193, i suppose -0 isn't +0 :D
[20:04] <knome> but mmh...
[20:04] <Unit193> +0
[20:04] <meetingology> +0 received from Unit193
[20:04] <Unit193> Meany...
[20:05] <knome> mr_pouit, you still lurking around or should we proceed?
[20:05] <knome> #endvote
[20:05] <meetingology> Voting ended on: New Xubuntu logo (+1) or the old one, please! (-1)
[20:05] <meetingology> Votes for:2 Votes against:1 Abstentions:1
[20:05] <meetingology> Motion carried
[20:06] <pleia2> not exactly overwhelming support :) maybe a discussion for the list?
[20:06] <knome> pleia2, we need to push the changes this week, according to skaet, who's now on the chan
[20:06]  * pleia2 nods
[20:06] <knome> mr_pouit said earlier that he likes the new logo on plymouth
[20:06] <pleia2> ok
[20:07] <knome> also, ochosi would have given +1, if he was attending
[20:07] <pleia2> good enough
[20:07] <knome> (that's said at #shimmer though, but it's recorded)
[20:08] <knome> what ochosi also said is probably true; if we're changing the logo, we probably should do that with 12.04
[20:08] <knome> and i have to agree with that. pushing a new logo for LTS+1 is quite bland :)
[20:09] <knome> #info knome promises to work on any suggestions to make the new logo better tomorrow
[20:09] <knome> #subtopic PAE kernel
[20:09] <knome> okay, so non-PAE kernel is requested for xubuntu precise i386
[20:09] <knome> was there some discussion people wanted to have about this?
[20:10] <knome> apparently not anymore... :)
[20:11]  * micahg wonders if Windows 8 supports non-PAE
[20:11] <knome> #subtopic Open action items from previous meeting
[20:11] <knome> ouch
[20:11] <knome> heh
[20:11] <knome> well
[20:11] <knome> ubuntu desktop doesn't
[20:11] <knome> and i agree it makes sense to have a derivative that does
[20:11] <micahg> well, no ubuntu-desktop supports it, just not in the installer :)
[20:12] <knome> mmh, right
[20:12] <knome> but yeah, how do you install the system if the installer is PAE-only
[20:12] <micahg> as do we
[20:12] <micahg> install 11.10 or a netboot install
[20:12] <knome> yeah, but let's say 13.04 is out
[20:12] <knome> you don't want to install 11.10
[20:13] <knome> or even when 12.10 is out
[20:13] <knome> it doesn't make much sense
[20:13] <micahg> 13.04 probably will not have a non-PAE kernell, 12.10 might not either
[20:13] <knome> having non-PAE kernel doesn't do any harm, right?
[20:13] <micahg> knome: you install 11.10 and upgrade to 12.04
[20:13] <knome> i mean, you can always switch to PAE kernel after installation
[20:14] <micahg> 12.04 will probably be end of the line for non-PAE kernels
[20:14] <knome> that's a smaller bad than having to install+upgrade
[20:14] <knome> yeah, but otoh, 12.04 is LTS, so it makes sense to support non-PAE there
[20:14] <knome> if 12.10 is PAE-only, then it is, and we have to live with it
[20:14] <pleia2> it would be nice to have the same support as regular ubuntu in this regard
[20:15] <pleia2> so keep non-pae with lts, then drop it after
[20:15] <micahg> knome: well, if the installer work happens anyways and it won't break anything, I wouldn't mind shipping the non-PAE kernel
[20:15] <micahg> pleia2: the Ubuntu ISOs for 12.04 will ship the PAE kernel for i386
[20:15] <knome> micahg, we've filed a bug today and cjwatson is the assignee, and will work it out
[20:15] <pleia2> micahg: oh, oops
[20:15] <pleia2> maybe we should too :\
[20:16] <micahg> so, if it's not too much work and won't break anything, I don't mind either way
[20:16] <knome> pleia2, except in that case, those users with processors that do not support PAE will need to install 11.0 and upgrade to 12.04
[20:16] <micahg> knome: which is either a 10+ year old desktop or a 5+ year old laptop/netbook
[20:16] <knome> if it's too much work or breaks things, i'm sure we'll hear about this and can rethink
[20:16] <pleia2> knome: as I understand it, the number of users this impacts is on the low side (and it's not like we'll have a fleet of people installing xubuntu servers)
[20:17] <micahg> pleia2: right, that's why I'm ambivalent about the whole thing
[20:17] <knome> micahg, yes, but we say on our website that xubuntu works on older hardware too
[20:17] <knome> pleia2, the number of users who need alternate is on the low side too
[20:18] <micahg> knome: it will work :), just depends what you define as old, you can't run Xubuntu on a P1
[20:18] <pleia2> my p3 laptop won't run pae, but my p3 laptop also kernel panics when I look at it wrong
[20:18] <knome> micahg, but you do agree with me that we can use non-PAE if it just works? :)
[20:18] <knome> mr_pouit +1'd non-PAE
[20:19] <knome> he's going to love me for highlighting him so many times...
[20:19] <micahg> knome: yes, as those installinig 32 bit xubuntu vs 64 bit will probably have less than 3GB RAM
[20:19] <knome> okay, good
[20:20] <knome> #info cjwatson will look at using non-PAE kernel with xubuntu precise i386, knome to follow-up with him if problems arises
[20:21] <knome> so, now the old action items
[20:21] <knome> #action pleia2 and knome to work on t-shirt designs and come up with a proposal on the design and the webstore to plug in
[20:21] <meetingology> ACTION: pleia2 and knome to work on t-shirt designs and come up with a proposal on the design and the webstore to plug in
[20:21] <knome> carried on
[20:21] <knome> #action knome to design flyers
[20:21] <meetingology> ACTION: knome to design flyers
[20:21] <knome> carried on
[20:21] <knome> wallpaper is finalized
[20:21] <knome> madnick provided code
[20:21] <knome> shortcuts are in
[20:21] <knome> wallpaper is in the repo
[20:22] <knome> xfce package revs ok
[20:22] <knome> #action pleia2 to raise publicity on triaging, testing and docs
[20:22] <meetingology> ACTION: pleia2 to raise publicity on triaging, testing and docs
[20:22] <knome> #action pleia2 to gather content for flyers
[20:22] <meetingology> ACTION: pleia2 to gather content for flyers
[20:22] <knome> and wikipage is set
[20:22] <knome> #endmeeting
[20:22] <meetingology> Meeting ended Wed Mar 14 20:22:38 2012 UTC.
[20:22] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/xubuntu-devel/2012/xubuntu-devel.2012-03-14-19.04.moin.txt
[20:22] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/xubuntu-devel/2012/xubuntu-devel.2012-03-14-19.04.html
[20:22] <knome> thanks everybody for attending
[20:23]  * knome needs to lay on the sofa for a while
[20:24] <knome> i'll update the minutes after that
[20:25] <pleia2> thanks knome :)
[20:25] <Unit193> Great, thanks knome.
[20:31] <mr_pouit> (yeah, sorry, that was dinner time, a bit complicated to skip :P)
[20:31] <Unit193> Why would you?
[20:32] <mr_pouit> to vote during the meeting ;D
[20:32]  * mr_pouit hides
[21:10] <knome> minutes are up
[21:10] <knome> bbl
[21:20] <pleia2> tweeted


[05:07] <gnomefreak> what is ETA on raring daily builds (chromium, firefox,tbird)?
[05:14] <micahg> umm, I see them for firefox and thunderbird
[05:14] <micahg> chromium will come after we get stable, beta, and dev up to date
[05:15] <gnomefreak> micahg: thanks ill update the dailies


[19:33] <MinSys> anyone watching jono@home?
[19:33] <ColinHarrington> whats that?
[19:34] <MinSys> http://www.ustream.tv/channel/at-home-with-jono-bacon
[19:34] <MinSys> jono is the ubuntu community manager
[19:34] <ColinHarrington> http://en.wikipedia.org/wiki/Jono_Bacon
[19:34] <ColinHarrington> ok
[19:35] <ColinHarrington> Whats the ustream deal about?
[19:35] <MinSys> he does a weekly webcast to answer any questions about ubuntu
[19:35] <MinSys> usually quite interesting
[19:36] <ColinHarrington> Thanks for the link, looks interesting
[19:37] <MinSys> your welcome
[19:58] <ColinHarrington> Hey if you're on this next week send another ping
[19:58] <ColinHarrington> Cool stuff
[23:36] <Takyoji> Heh, didn't know "hotdish" is a term more native to the Minnesota area than other areas. xP
[23:39] <tonyyarusso> Other fools call it a "casserole".  Sillies.
[23:39] <Gulfstream> hotdish is good... :D


[12:41] <Maik> Eickmeyer: mind taking care of Deano59 for once? He's been at it again in main and calls people moron in offtopic
[12:42] <Maik> i had enough of him by now, he had enough chances
[17:30] <Eickmeyer> Maik: That's up to the IRC Council, but I can have a talk with him.
[17:55] <Maik> Eickmeyer: ok thanks, i'd appreciate it a lot if you had a chat with him.  He has something against Blueskai saying hello or good day in #ubuntu and thinks it's offtopic and against the rules. This has been going on for quite some time now and it creates a lot of fuzz in the support channel. But Deano59 himself posts more than enough offtopic or nonrelevant stuff in main.
[22:10] <Noumeno> hi
[22:10] <Noumeno> how can request an Ubuntu cloak ?
[22:48] <krytarik> 1.) I wouldn't know why it'd be a matter for the IRCC rather than for the relevant channel ops (while I also don't know why Eickmeyer was pinged specifically on it, since I'm not in -offtopic)  2.) I'll say that I have a filter set on BluesKaj's greetings, since he's doing it for years and on every channel he is in - so I think Deano59 isn't wrong in feeling it's mildly annoying..
[22:51] <hggdh> Noumeno: you need to be an Ubuntu member -- see https://wiki.ubuntu.com/Membership
[22:52] <Noumeno> hggdh: i am a member
[22:52] <Noumeno> https://launchpad.net/~noumeno
[22:53] <hggdh> jess, jose: could you please add a cloak ubuntu/member/Noumeno for Noumeno?
[22:53] <jess> meow
[22:54] <hggdh> Meow!
[22:54] <jess> let me see
[22:54] <jess> done, but they'll want to log in to their account
[22:55] <hggdh> jess: oops, should have checked on it. I will blame this 9GB kernel memory dump I am trying to analyse...
[22:55] <jose> also, dat capital N
[22:55] <jose> you sure?
[22:56] <hggdh> Noumeno: please login to your freenode account
[22:56] <Noumeno> ok
[22:56] <hggdh> jose: <shrug/> makes no difference to me
[22:57] <jess> the hostnames matched so my dumb brain was like Yeah That's Definitely Their Account, probably should have checked they were logged in :P
[22:57] <jess> different IPs but some ISP, so, probably
[22:57] <hggdh> :-)
[22:58] <launchd> smh my head
[22:58] <hggdh> will wait a bit; if they do not authenticate soon, then we revert
[22:59] <jess> i'll revert it now just to be sure
[22:59] <hggdh> ack. I fully apologise for not having done the check
[22:59] <jess> naw, it's on me too :P
[22:59] <jess> it's such a thursday today
[23:00] <launchd> it feels so much like a friday tho
[23:00] <launchd> and i want it to be a friday really really bad
[23:04] <Noumeno> i have logged in again, but i see no changes ...
[23:04] <Noumeno> thanks
[23:06] <launchd> Noumeno: you still aren't logged in. see /msg nickserv help identify
[23:06] <Unit193> jess: If you do end up re-setting it, can you go lowercase?  Not a problem, but we tend to go lower on member cloaks.
[23:07] <jess> so many group contacfts
[23:07] <jess> contacts
[23:07] <jess> yes, yes i can
[23:07] <launchd> and so many of them are staff/former staff :P
[23:09] <jess> good teamwork guys
[23:11] <Noumeno> is working!!!!!!!! Thanksss!!!!!
[23:11]  * launchd fires confetti into the channel
[23:16] <launchd> Noumeno: you may also want to configure SASL so that your cloak is applied when you connect. see https://userbase.kde.org/Konversation/Configuring_SASL_authentication
[23:16] <launchd> Noumeno: you may also want to configure SASL so that your cloak is applied when you connect. see https://userbase.kde.org/Konversation/Configuring_SASL_authentication
[23:17] <Noumeno> ok
[23:17] <Noumeno> thanks
[23:19] <Noumeno> all ok! thanks
[23:20] <launchd> awesome!


[00:50] <guiverc> looking at #538 : i made the top 5 questions list (askubu; i haven't noticed that before [an answer])  :)
[00:53] <guiverc> progress yaru:  "details the install means and notes" - too difficult?  means could be mis-understood by those not first language english   (though this is me; the pot calling kettle black !)
[00:54] <Bashing-om> guiverc: Feels good all over - I too get a charge when one of my posts (forum)  makes it onto the list .
[00:55] <guiverc> :)
[00:58] <guiverc> planet:open the cosmic: "why it wasn't included in 18.04 are given" i think is change ; s/are given/is given/  (many->singular) ??
[01:01] <Bashing-om> look'n .. you may well be right :) lemme log back in .
[01:02] <guiverc> my thoughts; not @ end yet...
[01:03] <Bashing-om> Yep ! .. agreed .. should be singular . will change .
[01:04] <guiverc> kde plasma 5.14: "Joey apprises though, the"   - this is really petty, but I say ; (not comma)
[01:06] <Bashing-om> guiverc: ack
[01:08] <guiverc> Canonical Donates: "for the Nexus 10; Dalton Durst reports"  I suspect a 'as Dalton Durst" would read better; ie. possibly add a "as"
[01:09] <guiverc> plenty of muscle - you have to have written that; I sure don't use analogy!
[01:11] <guiverc> looks really good in my opinion Bashing-om
[01:12] <Bashing-om> guiverc: guilty . saves listing the specs . // As to the comma in kde plasma 5.14: I kinda want to have that pause because of the length of the sentence and to add emphasis . - I can live with taking the comma out, however .
[01:12] <guiverc> do as you suggest - I barely passed english !  (maybe I should have said that earlier; though is mostly obvious!)
[01:16] <Bashing-om> guiverc: If we add 'as' it changes the meaning of the sentence somewhat . We really want to do that ?
[01:16] <guiverc> it was a suggestion; if you don't like it ignore my suggestion please!
[01:17] <guiverc> (if I read the same thing tomorrow; I'll likely come up with different suggestions - i'm better @ reading cobol & prehistoric computer code!)
[01:17] <Bashing-om> guiverc: Never ignore .. I am the novice here ... rmember, I am the gofer in this enterprise .
[01:18] <guiverc> this relates to ENGLISH - in my opinion you're the master there friend :)
[01:19] <Bashing-om> guiverc: Speaking of gofer, are you able to do the media postings Monday? As that is above my pay-grade .
[01:19] <guiverc> yep - you tell me when, and I'll post...
[01:20] <Bashing-om> Oh say .. long about 8ish GMT to do the media releases ?
[01:21] <Bashing-om> PM !
[01:24] <guiverc_d> i'm looking at clock, may be closer to ~10:00 [UST/UTC/GMT] that I can do it; happy?); but will do when I can in 5+ hours okay?
[01:27] <Bashing-om> guiverc_d: 1000 UTC puts me at 5 AM ... I have not had my coffee at that time ! I shoot for releasing while still a Monday on Greenwitch time .
[01:33] <guiverc> okay - i probably need my coffee; i have it ~2:30 in london; which is why I said 5+ hours (to get close to 8am) from now (making allowances for me in yard & busy on housework i do each monday); doing it later (say 7-9 hours) is actually easier for me..
[01:34] <Bashing-om> guiverc: ' TZ='UTC' date ' We can do it - later - we got wiggle room and still slide under the wire of Greenworch Tuesday .
[01:36] <guiverc> yep; i'm used to it being published 'tuesday' my local (+10) time; but I've always followed directions so am not used to saying when...
[01:38] <Bashing-om> guiverc: 20 hours from now will do me good .. give time for Lyz or Simon to give thier opinion on the 538 issue .
[01:41] <guiverc> tomorrow then; i will potentially need prompting (b/c of brain injury; I can wake with little memory of past; esp. earlier in day & that will be early my local time..)
[01:54] <Bashing-om> guiverc: Understood. I will ping ya here . It only takes me about a half hour to do the mailings and post to the forum .
[03:30] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: How to Schedule Files Backups to Google Drive on Ubuntu @ https://www.omgubuntu.co.uk/?p=133468 (by Joey Sneddon)
[10:36] -SwissBot:#ubuntu-news- ::Softpedia:: Linux Kernel 4.18 Slated for Release on August 5 as Linus Torvalds Outs Last RC @ https://news.softpedia.com/news/linux-kernel-4-18-slated-for-release-on-august-5-as-linus-torvalds-outs-last-rc-522156.shtml (by Marius Nestor)
[13:09] -SwissBot:#ubuntu-news- ::Softpedia:: IPFire Hardened Linux Firewall Distribution Gets Major Update, Here's What's New @ https://news.softpedia.com/news/ipfire-hardened-linux-firewall-distribution-gets-major-update-here-s-what-s-new-522159.shtml (by Marius Nestor)
[14:10] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: The GPD Pocket 2 Crowdfunding Campaign is Now Live @ https://www.omgubuntu.co.uk/?p=133490 (by Joey Sneddon)
[17:06] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: UK Government Publishes List of Ubuntu 18.04 LTS Security Tips @ https://www.omgubuntu.co.uk/?p=133842 (by Joey Sneddon)
[17:50] <Bashing-om> Any recommedations for alterations for UWN538 ?
[18:36] <lotuspsychje> Bashing-om: prep looks good perhaps talk with tsimonq2 for the lubuntu news?
[18:37] <lotuspsychje> or is that pused to 539?
[18:37] <lotuspsychje> pushed
[18:37] <tsimonq2> Pushed.
[18:37] <lotuspsychje> kk tnx
[18:39] <Bashing-om> lotuspsychje: I am undecided on tsimonq2's blog .. the legality as Softpedia exclaimed  as "exclusive" . The Softpedia article has the link to the orininating blog .
[18:39] <tsimonq2> Bashing-om: I went live with Marius at the same exact time.
[18:40] <tsimonq2> Bashing-om: Please include both.
[18:40] <Bashing-om> tsimonq2: can do ! .. I asked that in the ubuntu-discuss channel of you the other day, guess you missed it.
[18:42] <tsimonq2> Bashing-om: I didn't miss it; when I went to respond, you were gone.
[18:42] <tsimonq2> (Get a bouncer. :P)
[18:47] <Bashing-om> tsimonq2: :( .. complicate my life even more :P Lemme work on KISS .
[18:55] <lotuspsychje> lol
[18:55] <lotuspsychje> be here 24/7
[19:54] <Bashing-om> tsimonq2: Done .. see what you think, please.
[22:21] <Wild_Man> Bashing-om, I am here a few minutes if you still need me, you do know why I have not been here right?
[22:22] <tsimonq2> Bashing-om: The official announcement should go in the planet as well.
[22:23] <Wild_Man> guiverc_w, are you taking care of the social media publishing?
[22:23] <guiverc_w> fb, g+, anywhere else you want/need done?
[22:24] <guiverc_w> was there twitter?
[22:25] <Wild_Man> I am not really thinking properly, I had two surgeries in 10 days and the second one still not out of the woods yet
[22:25] <Wild_Man> guiverc_w, yes twitter also but I can do it real quick if you need me too
[22:25] <Bashing-om> tsimonq2: I placed your blog in the Planet .. and the softpedia summary in the Blogosphere . right ?
[22:25] <guiverc_w> don't worry Wild_Man - someone else can 'yell' at me if they discover something else I've forgotten...
[22:25] <tsimonq2> Bashing-om: Yup.
[22:25] <guiverc_w> you get well !!
[22:26] <Bashing-om> tsimonq2: Yours has not been proof read . Are we ready to release ?
[22:26] <Wild_Man> okay, Bashing-om do you need anything else before while I am where
[22:27] <Bashing-om> Wild_Man: Apprciate the effort .. but guiverc_w is here to take up my slack .
[22:27] <Wild_Man> my appendix basted after my first surgery and I gt sepsis
[22:28] <tsimonq2> Bashing-om: Go for it.
[22:28] <Bashing-om> Wild_Man: Ouch ! .. 1st that i have heard . real real bad !
[22:28] <Wild_Man> okay, I did receive your pm that is why I got on
[22:28] <tsimonq2> Wild_Man: :( get better soon
[22:28] <Unit193> I don't even have an appendix.
[22:28] <Bashing-om> All - starting the release at this time . mailings comming up .
[22:30] <Wild_Man> tsimonq2, thanks, I will also miss the board meeting on Thursday, hopefully I will be much better in about two weeks but I may still have to have surgery again, it is a waiting game to see, talk to you later
[22:30] <tsimonq2> OK
[22:30] <tsimonq2> Thanks Wild_Man
[22:36] <Bashing-om> Opps .. got to pull "WIP" !
[22:43] <Bashing-om> mailing sent .. doing the Forum post next .
[22:47] <guiverc> fb g+ & twitter done
[22:48] <Bashing-om> guiverc: No step for steppers ! .. doing the re-direct edits next . Forum is done .
[23:14] <Bashing-om> OK, issue 538 is history .. 539 is set to go :)
[23:18] <Bashing-om> guiverc: I have not seen yet the channel bots to advise that the Fridge has the new issue .. is there a problem ?
[23:18] <guiverc> was I to do the fridge post; I don't see it ?
[23:20] <guiverc> i'll post to fridge .. which goes to ....
[23:20] <Bashing-om> guiverc: Got me .. as I have no account there .. is above my pay grade :)
[23:21] <guiverc> i suspect we're all on the same pay grade :)
[23:21] <Bashing-om> LOL
[23:25] <guiverc> Bashing-om, who ran the python code that copied to wiki - they'll have the source i need for it? (hopefully; will be faster)
[23:27] <Bashing-om> guiverc: Sorry, I do not know anything about the python code for the wiki .
[23:28] <guiverc> who copied it from gdoc to wiki?
[23:29] <Bashing-om> guiverc: I did the copy from Gdoc to the wiki - yes .
[23:29] <guiverc> cut & paste I'm guessing..
[23:30] <Bashing-om> guiverc: Cut and paste to the wiki is the only way I know how to do it :(
[23:31] <guiverc> no probs - how I did it too... just found krytarik's notes on correct way :)
[23:31] <guiverc> (not touching the wiki - the correct way generates a version for fridge - it's what I want; copy & paste doesn't create that...)
[23:34] <Bashing-om> guiverc: yup, I run the script to get the forum version. I do note there is a fridge.post file :)
[23:34] <guiverc> can I please get a copy of it - it's what I'm trying to generate... (haven't got there yet)
[23:35] <Bashing-om> sure ,.. gimme a tic to termbin it .
[23:37] <Bashing-om> guiverc: see: http://termbin.com/2p63 . That look like what you need ?
[23:37] <guiverc> just created it anyway, but thanks; will confirm what I created matches yours, then post...
[23:38] <guiverc> diff same; so we both screwed up the same way, or we both did okay!
[23:38] <Bashing-om> guiverc: That one ^ still has " [B]WORK IN PROGRESS[/B] " . that will require removing when posting .
[23:38] <guiverc> i don't see it in file..
[23:39] <Bashing-om> guiverc: Will not be in a new generation .. I failed to remove the WIP before I ran my scripts .
[23:41] <guiverc> not an issue; the script doesn't copy everything, just titles & links (& must skip wip)
[23:43] <guiverc> links all okay..
[23:44] <guiverc> http://fridge.ubuntu.com/?p=8413 - if you wanna look & please scream @ me if anything is wrong..
[23:45] <Bashing-om> guiverc: I do not know what I can do - but I will look anyway :)
[23:47] <Bashing-om> guiverc: Got me .. I have never looked at the Fridge postings before .. I do not know what to compare to .
[23:48] <guiverc> http://fridge.ubuntu.com/2018/07/23/ubuntu-weekly-newsletter-issue-537/ is prior one; http://fridge.ubuntu.com/2018/07/30/ubuntu-weekly-newsletter-issue-538/ is current one.. i think all is good
[23:49] <Bashing-om> guiverc: However ^ .. the links complete to an expected result :)
[23:49] <Bashing-om> guiverc: Yepper ! .. looks good to me :P
[23:50] <guiverc> my 8413 post may not help you  (my bad) ; i think it assumes you have wpadmin authorities
[23:51] <guiverc> and given some time, the posts should be picked up by SwissBot, Marvin & any other bots here & there :)
[23:52] <guiverc> good pick up fridge was forgotten - thank you... didn't even occur to me...
[23:54] <Bashing-om> guiverc: I just so accustomed to seeing the bots report of the fridge posting .. so I wondered :)
[23:57] <guiverc> :)  at times i remember things, other times I struggle with simple things... i can assist, alas i'm not equipped to lead anything
[23:59] <Bashing-om> guiverc: I do what I can - but I re-affirm - I am the gofer :P .. leastways til we get new blood .


[02:13] <catid> well, after i lost data the first time my system crashed using XFS, decided to switch to reiserfs
[05:08] <DudeManJer> I know its not the correct room but I wonder if anybody here knows how to assist about the installation process?
[06:40] <yimmmy> help please
[06:48] <yimmmy> helop
[06:50] <RAOF> !ask | yimmmy
[06:50] <ubotu> yimmmy: Don't ask to ask a question. Just ask your question :)
[07:38] <czarny> hello
[07:38] <czarny> I've updated my g/f's laptop yesterday to partly gutsy
[07:38] <czarny> and after reboot all kernels see ide disks and cdroms as scsi
[07:38] <czarny> instead of hda I get sda
[07:39] <czarny> is it normal?
[07:40] <czarny> I've overcame this problem, nevertheless after all processes in init went OK I'm asked to pass maintainance password
[07:41] <czarny> and when I do, I need to start gdm manually and everything works
[07:41] <czarny> nevertheless I don't get any errors, but the maintanance pswd is needed - why?
[07:42] <crimsun> yes, it's normal.  In fact, that was the movement with edgy, but it got delayed until feity, and bits and pieces ended up being reverted for feisty final
[07:42] <crimsun> feisty, even.
[07:43] <czarny> why the move?
[07:43] <czarny> I'm a PLD (another distro) devleoper and I'd like to hear the reasons
[07:43] <czarny> why everything gets emulated (through sg I'd assume?)
[07:43] <crimsun> because it makes sense.  Upstream (Linux, kernel.org) wants One Interface to Rule Them All.
[07:44] <czarny> and that interface to be is scsii :)
[07:44] <czarny> ok - and about the init problem ??
[07:44] <crimsun> you likely will find a protracted discussion on the libata devel list(s).
[07:44] <czarny> what could cause maintainance passwd ?
[07:44] <czarny> there is no error, all services seem to run normal
[07:45] <crimsun> is this with 2.6.22-[12]  or 2.6.20-15 from feisty?
[07:45] <czarny> 2.6.20
[07:45] <crimsun> I can't comment on the former; it doesn't even boot my machines.
[07:46] <czarny> well the transition wen't bad for me
[07:46] <czarny> UUID's in /etc/fstab got updated to the scsii ones
[07:46] <crimsun> need more context.  Do you have a digital photo or possibly a dump from a serial console?
[07:46] <czarny> but not in /boot/menu.lst
[07:46] <czarny> LOL
[07:46] <czarny> not really
[07:46] <czarny> ok - how could I debug it ??
[07:46] <czarny> is there a ..h m...step by step mode ??
[07:47] <czarny> like every service asks me if it is to be run ?
[07:48] <crimsun> not really.
[07:49] <czarny> well - the strange thing is, that all servicess pass
[07:49] <czarny> in PLD maintance passwd is issued when something breaks
[07:49] <czarny> usually quite early
[07:49] <czarny> and this seems to show after *all* start
[07:49] <crimsun> does starting in recovery mode (the second boot option, which is simply nosplash verbose single) reveal anything?
[07:49] <czarny> because when I start gdm and toy with GNOME it seems all run
[07:50] <czarny> I need to boot in this mode all the time
[07:50] <czarny> but doesn't
[07:50] <czarny> when I boot in the normal mode, when spalsh shows, the computer never reaches GDM
[07:50] <czarny> It's a hardware problem
[07:50] <czarny> some usplash fcked up ati 7500 booting
[07:50] <crimsun> what if you choose the normal mode but remove quiet and splash from the kernel command line?
[07:51] <czarny> didn't try that
[07:51] <czarny> w8
[07:51] <crimsun> we are going through a usplash transition if you haven't kept up with gutsy-changes
[07:52] <czarny> crimsun: I don't use ubuntu :)
[07:52] <czarny> crimsun: I've installed it on my g/f's laptop :)
[07:52] <czarny> crimsun: whoa - works !
[07:52] <czarny> crimsun: THX dude
[07:53] <czarny> so now the rescue mode always will issue passwd at the end ?
[07:53] <crimsun> only if you've configured a root password.
[07:53] <czarny> bout that usplash hung - it's like from...hm...end of edgy?
[07:53] <czarny> crimsun: Yea - I think I maby did??
[07:53] <czarny> crimsun: something needed that
[07:53] <crimsun> certain video cards act weird with usplash and Xorg
[07:53] <crimsun> video's not my strong point (I deal with audio)
[07:53] <czarny> crimsun: well there was a time I was making some splash for PLD
[07:54] <czarny> and I've toyed around usplash and fbsplash
[07:54] <czarny> so usplash doesn't have much options to tweak
[07:54] <czarny> but fbsplash has an option which is told to be used, when during boot something shows on top of the splash
[07:54] <czarny> like changing consoles make splash dissapear
[07:55] <czarny> and when You turn the magical fbsplash option on it forces the splash to stay on top
[07:55] <czarny> since usplashes splash stays on top all the time I'd assume that You use that feature by default
[07:55] <czarny> and both fbsplash with that feature and usplash make my laptop not display anything else then the splash :)
[07:56] <czarny> BTW: NetworkManager 0.6.5 anytime soon ?
[07:56] <czarny> I'd pass You some patches, as I've did it for PLD - it compiles and runs
[07:56] <czarny> but I've got totally no idea how debs are being build and how You ppl develop Your packages
[07:57] <czarny> (and NM 0.6.5 needed some minor patching)
[07:58] <tritium> czarny: what's fixed in 0.6.5?  I still haven't figured out if its a kernel module or network-manager problem that prevents me from using AR5212 on feisty.
[07:58] <czarny> czarny: I totally don't know ;)
[07:59] <czarny> czarny: my friend had problems with his card
[07:59] <czarny> and asked me to try 0.6.5
[07:59] <czarny> and it worked for him
[07:59] <czarny> nevertheless a lot of fuss is out there, especially on Your forums, that 0.6.5 is a magical wand for some ppl who couldn't have used it
[08:00] <czarny> I know that some driver issues were fixed and all the magical conecting modes, like EAP2, WPA2 and other certificate types of connectivity has been revised
[08:01] <czarny> tritium: but to answer Your question - I'd go wit the network-manager helping, as my friends didn't change any drivers, only NM
[08:02] <tritium> hmm, that sounds promising...
[08:02] <tritium> I can only connect to open networks currently
[08:03] <tritium> Was a little surprised to see feisty release with that bug.  I've got to imagine there are a lot of Thinkpad users out there that are affected...
[08:03] <tritium> (among others)
[08:08] <czarny> tritium: thinkpad??
[08:08] <czarny> tritium: I've got a T42
[08:09] <czarny> and I can connect to a WPA2 TKIP network with a certificate and password
[08:09] <tritium> czarny: I've got a T43p with Atheros AR5212
[08:10] <czarny> tritium: aah...so I've got a solution 4 You ;)
[08:10] <czarny> tritium: I'll give You my postal address, You'll give my Yours and we're all set ;)
[08:10] <czarny> just the switch needed ;)
[08:11] <tritium> czarny: ;)
[08:11] <tritium> czarny: it's actually my employer's
[08:12] <czarny> tritium: well - so there's some convincing 4 You to do ;)
[08:12] <czarny> tritium: try "Dir Sir, try to think bout it as an upgrade - it's true You'll get an older model, but the upgrade is, that something that didn't work started to!"
[08:15] <tritium> I'm sure that'll go over really well ;)
[08:20] <czarny> ok - thx dudes
[08:20] <tritium> take care, czarny :)
[08:20] <czarny> crimsun: especially You - easy thing but made me stope
[08:20] <czarny> Yea - I'm going to - I'm going to my g/f graduatation ceremony
[08:20] <czarny> cya
[08:20] <czarny> oh - and fetch my someone who knows bout the usplash thing next time
[08:20] <czarny> cya
[11:40] <gnomefreak> czarny: the usplash issue will be fixed soon now that UDS is over. hopfully sometime in the next 7 days or so but can promise that since its not my package
[11:56] <czarny> gnomefreak: thx
[11:56] <czarny> again bout the hda -> sda stuff
[11:56] <czarny> 2.6.22 detects hda again
[11:56] <czarny> WTF ??
[11:56] <czarny> what makes a kernel detect stuff normally, and what in the scsii way??
[11:56] <czarny> some package ??
[11:57] <czarny> initrmafs ?
[11:58] <czarny> and what is unknown stanza in init scripts?
[12:28] <gnomefreak> czarny: off hand i dont know, its still a bit early here and i havent booted my gutsy sys in a few days because i havent set it up for building packages yet.
[05:36] <czarny> +
[05:38] <czarny> *
[08:14] <Gearman> exterior monitor does not work
[08:29] <Cas> Hi all, A little question about Gutsy. Will the restricted driver manager still be in it?
[08:32] <Toma-> yep
[08:33] <Cas> Toma-: good, I was a little confused by many comments cause of the free approach
[09:32] <venky> hello is anyone on kubuntu gutsy with intel pro wireless 3945?
[09:40] <venky> anyone using kubuntu gutsy?
[12:04] <teethdood> anyone trying firefox 3?


[09:34] <Charbel> who knows what is the address of Beirut time server ?
[09:34] <Charbel> i want to keep time and date synchronized with internet server
[09:59] <Charbel> who knows what is the address of Beirut time server ?
[09:59] <Charbel> i want to keep time and date synchronized with internet server


[00:12] <katco> ericsnow: if you're around, looks like review board isn't picking this up? https://github.com/juju/juju/pull/1931
[00:12] <katco> ericsnow: oh shoot and i know why.
[00:12] <katco> ericsnow: i recently changed my github username: katco- to kat-co
[00:13] <ericsnow> katco: that would do it :)
[00:13] <katco> ericsnow: any way to move my account and get that PR up?
[00:13] <ericsnow> katco: I should be able to do that real quick
[00:14] <katco> ericsnow: you are a gentleman and a programmer.
[00:16] <ericsnow> katco: done; hopefully it works ;)
[00:17] <katco> ericsnow: account looks good, but PR still isn't there?
[00:17] <katco> rbt post is asking for a pw
[00:26] <katco> ericsnow: and the instructions you sent out last year aren't working for me =/
[00:28] <katco> axw: wallyworld_: https://github.com/juju/juju/pull/1931 until it gets onto RB. i have to go take care of some things.
[00:28] <wallyworld_> ty
[00:34] <davecheney> boom, gccgo bug is fixed upstream
[00:34] <davecheney> now ... PAPERWORK!
[00:39] <thumper> davecheney: \o/
[00:40] <davecheney> yeah, lynn's patch was submitted this morning
[00:53] <davecheney> ok, that joy was short lived, our other fix that went into gccgo 4.9 needs to be forward ported to 5.0
[00:53] <davecheney> i'll raise another bug
[01:06] <davecheney> win12
[01:22] <thumper> wallyworld_: got a minute?
[01:22] <wallyworld_> sure
[01:22] <thumper> 1:1 hangout?
[02:08] <fwereade> holy crap, that mostly works
[02:09] <fwereade> right, going to bed
[02:22] <ericsnow> katco: if you're still around, try killing that PR, go to RB, log out, log back in, and then re-submit the PR over on github
[04:29] <ericsnow> thumper: ping
[04:38] <axw> wallyworld: FYI, I've proposed the environ-storageprovisioner and dynamic EBS branches -- http://reviews.vapour.ws/r/1258/ and http://reviews.vapour.ws/r/1259/
[04:38] <axw> wallyworld: I guess I'll work on volume-backed filesystems now
[04:41] <axw> wallyworld: FYI, I've proposed the environ-storageprovisioner and dynamic EBS branches -- http://reviews.vapour.ws/r/1258/ and http://reviews.vapour.ws/r/1259/
[04:41] <axw> wallyworld: I guess I'll work on volume-backed filesystems now
[04:42] <wallyworld> axw: great ty, will look soon. volume backed fs sounds good
[05:19] <ericsnow> wallyworld: does this sounds familiar (relative to state log pruning): "failed to retrieve log counts: no such cmd: scale"
[05:47] <bradm> anyone know what the error "juju.rpc server.go:554 error writing response: EOF" in machine-0.log means?  the juju environment isn't very healthy, juju sets aren't triggering the appropriate config-changed hooks
[06:45] <urulama> wallyworld: the sessions added, alexisb notified.
[06:55] <wallyworld> axw: off to soccer for a couple of hours, reviews done
[06:56] <axw> wallyworld: thanks
[06:56] <axw> later
[07:17] <mup> Bug #1436191 was opened: gce: bootstrap instance has no network rule for API <firewall> <gce> <juju-core:New> <https://launchpad.net/bugs/1436191>
[07:24] <mattyw> morning all o/
[08:30] <dimitern> axw, ping
[08:31] <dimitern> axw, I'm +100 on moving replicaset out of the main repo, but will this reduce the tests run time for core?
[08:59] <axw> dimitern: hey sorry, was afk. this change will not. this change is just preparing to move it out of core
[09:00] <axw> and to generate discussion
[09:00] <dimitern> axw, right, so a step in the right direction :)
[09:00] <axw> yup
[09:03] <axw> dimitern: in case I misunderstood - the change on RB atm won't reduce test time, but moving replicaset out of core will
[09:03] <axw> unless of course CI starts running tests for all the github.com/juju packages
[09:04] <dimitern> axw, yep, got it
[09:04] <dimitern> axw, well, that happening at some point certainly won't hurt
[09:05] <axw> it'll hurt the run time ;)  I think we should do it, not sure about as part of the merge gating, maybe just as a voting CI job
[09:05] <dimitern> axw, no no - definitely not part of the merge gating :)
[09:22] <natefinch> wallyworld, dimitern, axw, anyone else: I'm getting a "no reachable servers" trying to connect to state, which then causes all the workers to shut down... but jujud hangs around, and doesn't restart or retry or anything.  Why is that?  Shouldn't it retry?  This is on a machine that I've converted from a regular server to a state server in a replicaset.
[09:22] <natefinch> It's a bummer, because I think it's just that mongo is slow, and if I kill jujud, it restarts and is able to connect.
[09:22] <axw> natefinch: not sure off hand, I'll have a look at the code and see if I can think of a reason...
[09:22] <dimitern> natefinch, I'm not quite sure why, but it should retry
[09:23] <dimitern> natefinch, maybe some worker / runner is hanging instead of exiting
[09:23] <natefinch> dimitern: ahh, hmm, yeah, that's a good point
[09:31] <axw> natefinch: only reason I can see that would explain that is if the state-serving info in the agent config changed
[09:31] <axw> i.e. from having it to not having it
[09:32] <axw> not sure if that's even possible
[09:33] <dimitern> wow that's a first - http://paste.ubuntu.com/10676289/ - build failure in the net-cli branch - anyone seen something like that with the gc compiler?
[09:34] <axw> dimitern: did you update your go compiler?
[09:34] <axw> I've seen that sort of thing when there's version mismatch
[09:34] <dimitern> axw, no - still go 1.2.1 amd64 from trusty
[09:36] <natefinch> try deleteing your gopath/pkg directory and rebuild
[09:36] <dimitern> weird.. so I've wiped out my /tmp and $GOPATH/pkg/* dirs, rebuilt and now it's fine
[09:36] <natefinch> yep
[09:36] <dimitern> natefinch, yep, cheers
[09:37] <natefinch> some weird mismatch.. maybe gccgo or something?
[09:37] <dimitern> I did have both gccgo and gc binaries/object files in pkg
[09:38] <dimitern> in separate subdirs, but still
[09:38] <natefinch> oh right forgot they're in separate dirs...  well, I dunno, I've had it happen once in a blue moon
[09:39] <dimitern> yeah
[09:40] <dimitern> (as they say quite often lately around here - "putin is most likely behind this" :D)
[09:40] <axw> lol
[09:40] <natefinch> haha
[09:42] <dooferlad> Anyone around who could help with a test failure due to an unexpected receive? http://paste.ubuntu.com/10676354/
[09:42] <dooferlad> This seems to happen if I am running the entire suite sometimes, but never if I just run that one test.
[09:42] <dimitern> dooferlad, oh, I know that one
[09:42] <dimitern> dooferlad, it's known to be flaky, esp. under load
[09:43] <dooferlad> dimitern: *sigh*
[09:43] <dimitern> dooferlad, I did try fixing it, but gave up because it wasn't easy without refactoring the way the filter uses watchers
[09:43] <TheMue> I love our tiny logs. ;)
[09:47] <dimitern> dooferlad, our SpaceTag caused quite a stir apparently
[09:47] <dooferlad> dimitern: do you remember what caused the problem? (filter tests)
[09:48] <dooferlad> dimitern: yea, I expect that will be renamed at some point!
[09:48] <dooferlad> network-group maybe
[09:48] <natefinch> is spacetag anything like freeze tag?  sounds like fun ;)
[09:49] <dimitern> dooferlad, the problem is synchronization between the apiserver, api, and state watchers
[09:49] <dimitern> natefinch, it's more like a space cake I guess :D
[10:00] <dimitern> dooferlad, TheMue, standup?
[10:01] <TheMue> dimitern: yes. *lol*
[10:39] <voidspace> dimitern: so I fixed the first test problem (only a new worker sees the broken provider)
[10:40] <voidspace> dimitern: for the second test issue I've pushed a failing test
[10:40] <voidspace> dimitern: when we start the worker we have two dead addresses <IP_ADDRESS> and <IP_ADDRESS>
[10:40] <voidspace> dimitern: I'm expecting to see two ReleaseAddress calls, one for each
[10:40] <voidspace> dimitern: what I *actually* see is *three* calls
[10:40] <voidspace> dimitern: two for the first address and one for the second
[10:40] <voidspace> dimitern: I'm looking into it
[10:40] <dimitern> voidspace, hmm weird
[10:41] <voidspace> dimitern: I have a test that reliably passes asserting those three calls...
[10:42] <dimitern> voidspace, do the first 2 calls have the same args?
[10:42] <voidspace> dimitern: well, the OpReleaseAddress we get is the same
[10:42] <voidspace> so yes
[10:42] <voidspace> same subnetid etc
[10:42] <voidspace> they're the same address
[10:43] <voidspace> dimitern: I'll add some logging to see why
[10:43] <dimitern> voidspace, yeah
[10:43] <dimitern> voidspace, it might be the last call comes from Handle()
[10:43] <dimitern> voidspace, oh, no actually.. if the first 2 are the same maybe the first one does
[10:44] <dimitern> voidspace, make sure you check the addresses you get in Handle are both dead and not gone
[10:46] <voidspace> dimitern: I check that
[10:46] <voidspace> dimitern: I think I found a bug, not sure how it can be the cause
[10:46] <voidspace> dimitern: or how the code worked at all
[10:47] <voidspace> dimitern: I have a select that removes the dead addresses - but it is a single select it doesn't loop
[10:47] <voidspace> dimitern: so it should only do the first address
[10:49] <voidspace> so how I'm seeing three releases is a real mystery...
[10:49] <voidspace> running with logging
[10:49] <dimitern> voidspace, good catch then
[10:49] <voidspace> dimitern: right, I see two attempts for each address
[10:49] <voidspace> from the logging
[10:50] <dimitern> voidspace, I guess one from SetUp and one from Handle ?
[10:50] <voidspace> let me add to Handle to check that
[10:50] <voidspace> dimitern: it's possible that the removal triggers the watcher too - but inside Handle I'm specifically checking if the address exists
[10:50] <wallyworld> fwereade: you around?
[10:50] <voidspace> dimitern: if it's *already* been removed we should fail to fetch it from State
[10:51] <fwereade> wallyworld, heyhey
[10:51] <voidspace> dimitern: it looks like the removal succeeds, triggering the watcher and then we *successfully* pull the address back out of state
[10:51] <voidspace> dimitern: race condition due to transactions?
[10:51] <voidspace> is that possible
[10:51] <dimitern> voidspace, hmm
[10:51] <dimitern> voidspace, it is possible
[10:51] <wallyworld> fwereade: if you had time, i'd love a quick pre-impl chat
[10:51] <voidspace> dimitern: I'm going to confirm that this is the case (one attempt from Handle and one from SetUp)
[10:51] <dimitern> voidspace, that's the thing with JujuConnSuite
[10:51] <fwereade> wallyworld, will be in our hangout in 5 mins
[10:52] <dimitern> voidspace, we have 2 states there - State and BackingState - the latter is the real one used by the apiserver, the former is the state used by the api client
[10:52] <wallyworld> sure
[10:52] <dimitern> voidspace, and they're not synced wrt watchers
[10:53] <dimitern> voidspace, try calling s.BackingState.StartSync() before each assert on the watcher
[10:56] <voidspace> dimitern: what i'm seeing on start is Handle called with every address
[10:56] <dimitern> those were exactly the same issues that lead to flaky tests
[10:56] <voidspace> dimitern: so the initial SetUp is trying to remove them at the same time as Handle
[10:56] <dimitern> voidspace, yeah, that's what I suspected
[10:57] <voidspace> I thought State and BackingState were the same these days, we fixed it by just having one State?
[10:57] <voidspace> I'll try the extra sync anyway
[10:57] <dimitern> voidspace, so you might not need to do the out-of-bound goroutine in setup perhaps?
[10:57] <voidspace> dimitern: maybe not
[10:58] <voidspace> dimitern: I read a docstring saying "Initial" was only the alive entities for a lifecyclewatcher
[10:58] <voidspace> that maybe out of date
[10:58] <voidspace> dimitern: I'll read the lifecycle watcher code
[10:58] <voidspace> I maybe able to just delete the SetUp
[10:58] <voidspace> well, most of it anyway
[10:59] <fwereade> voidspace, I think it has to include dying ones as well and frequently the dead ones
[10:59] <fwereade> voidspace, consider something like a provisioner
[10:59] <fwereade> voidspace, it needs to know about its dead machines so it can remove them
[10:59] <voidspace> fwereade: "frequently"... I'd quite like a deterministic result :-)
[11:00] <voidspace> fwereade: right, I was just going off some docstring that said "initial()" was called with only alive entities
[11:00] <fwereade> voidspace, ok, lifecycle watchers should return everything in their initial results, including dying and dead
[11:00] <dimitern> voidspace, fwereade, so the lifecycle watcher is smarter than I thought :)
[11:00] <voidspace> fwereade: I'll dig it out
[11:00] <voidspace> that's great
[11:00] <voidspace> removes some code
[11:00] <fwereade> voidspace, cool
[11:01] <voidspace>  The first event emitted will contain the ids of all non-Dead  entities
[11:01] <voidspace> state/watcher.go line 136
[11:03] <voidspace> fwereade: so in lifecycleWatcher.initial it fetches the whole collection, *stores* the ids of "non-dead" entities, but returns *all* ids
[11:03] <voidspace> I'll update the docstring
[11:03] <voidspace> dammit, I should no better never to trust a docstring
[11:03] <fwereade> voidspace, yeah, that sounds right
[11:03] <fwereade> voidspace, thanks
[11:03] <voidspace> fwereade: we need to go back to calling them lies...
[11:04] <voidspace> *know better*
[11:06] <voidspace> dimitern: so if I just delete that code in SetUp the test passes...
[11:06] <voidspace> dimitern: which is good
[11:07] <dimitern> voidspace, only one comment on your review
[11:07] <dimitern> voidspace, great!
[11:07] <dimitern> voidspace, I'll wait for the changes around SetUp and will re-review it
[11:08] <voidspace> dimitern: that select is gone
[11:08] <voidspace> dimitern: ah, no it's not
[11:08] <voidspace> dimitern: that's iin the test, fine I'll fix that
[11:08] <voidspace> dimitern: SetUp change pushed
[11:09] <dimitern> voidspace, looks nice and red :)
[11:09] <voidspace> :-)
[11:12]  * dimitern steps out for ~2h
[12:17] <wallyworld_> ericsnow: here's a trivial fix for an intermittent failure on ppc64 http://reviews.vapour.ws/r/1261/
[12:43] <frankban> ocr" could anyone please take a look at http://reviews.vapour.ws/r/1263/ ? thanks!
[12:51]  * dimitern is back
[13:09]  * fwereade omw uk for a bit, will be around again later but was up until 3 last night so might be a bit relaxed about it
[13:39] <dimitern> voidspace, hey
[13:40] <dimitern> voidspace, the releaser looks much better now, thanks!
[13:40] <dimitern> voidspace, you have a review with a provisional "ship it!" and mostly minor changes suggested.
[13:45] <ericsnow> jw4: ping
[13:45] <jw4> ericsnow: ola
[13:46] <ericsnow> jw4: could you take a look at this log from CI: http://data.vapour.ws/juju-ci/products/version-2478/run-unit-tests-vivid-amd64/build-289/consoleText
[13:47] <jw4> ericsnow: that should be fixed?
[13:47] <ericsnow> jw4: it shows a failure that you fixed the other day with the log pruning stuff
[13:47] <jw4> right
[13:47] <jw4> did that error occur recently?
[13:47] <ericsnow> jw4: I'm trying to figure out why
[13:47] <ericsnow> jw4: Tuesday
[13:48] <ericsnow> (yesterday)
[13:48] <jw4> ericsnow: ah, look at the documentation for the mgo http://godoc.org/labix.org/v2/mgo#Database.Run
[13:49] <ericsnow> jw4: right, but I thought you fixed this already
[13:50] <jw4> ericsnow: yeah, I'm looking to see if there's another call to Database.Run
[13:50] <ericsnow> jw4: good point
[13:50] <dimitern> ericsnow, jw4, I did see that patch replacing bson.M with bson.D land, but maybe the dependencies.tsv was not updated after?
[13:51] <jw4> dimitern: there should be no dependencies.tsv update
[13:51] <dimitern> jw4, oh, right - that's in state only
[13:52] <jw4> ericsnow: weird I don't see any other call
[13:53] <jw4> ericsnow: I see that run was testing a version before my fix landed: Testing gitbranch:master:github.com/juju/juju 0752a4bc
[13:54] <ericsnow> jw4: ah, never mind then :)
[13:54] <jw4> :)
[13:54] <ericsnow> (I was just checking that)
[13:54]  * ericsnow promises himself not to try to reason about problems late in the evening
[13:54] <jw4> hehe
[13:55] <jw4> (but aren't you in Mountain Time? 8 AM now?)
[13:58] <natefinch> well, ha --to 1,2 works now, though I have to use a hack to get jujud to restart after the StateWorker errors out from not being able to connect to state.  I gotta figure out why the damn workers aren't shutting down.
[14:02] <voidspace> dimitern: cool, thanks
[14:02] <voidspace> dimitern: you want me to use the  envtesting package in the worker itself?
[14:03] <voidspace> dimitern: in fact, I don't think envtesting.ShortAttempt exists, which is why I was using the other one in the tests
[14:03] <dimitern> voidspace, ah
[14:03] <voidspace> dimitern: I'm pretty sure you've hallucinated its existence
[14:03] <dimitern> voidspace, let me double check
[14:03] <voidspace> dimitern: and I didn't want a dependency on a test package in the production code
[14:04] <dimitern> voidspace, oh, you're right
[14:05] <dimitern> voidspace,  so then use common.ShortAttempt in both the worker and the tests?
[14:06] <voidspace> dimitern: it's in the provider package, but ok
[14:06] <voidspace> well, provider/common
[14:06] <dimitern> voidspace, yeah
[14:06] <voidspace> seems like a weird dependency
[14:06] <voidspace> dimitern: and I dropped one of your issues - you slightly misunderstood the test
[14:06] <voidspace> dimitern: the rest are good and I'll fix them, thanks
[14:07] <voidspace> dimitern: after a break...
[14:08] <dimitern> voidspace, ok, cheers
[14:12] <TheMue> Yeeeeeeeeeeeeeeeeeeeeeeeeeeeeeehaw! Local vMAAS acquiring works. *phew*
[14:13] <dimitern> TheMue, awesome!
[14:13] <TheMue> Needed some patches/changes in their hack, but now the first node started as wanted.
[14:14] <dimitern> TheMue, does it stop as well? :)
[14:14] <TheMue> dimitern: Yeah, will pass this information to the MAAS team. Maybe they are interested in adding it too.
[14:14] <TheMue> dimitern: Oh, good question. one moment.
[14:16] <TheMue> dimitern: Hehe, yeah, it does. *dancingThroughTheRoom*
[14:17] <dimitern> TheMue, great! then you can have a look at that bug 1427814 :)
[14:17] <mup> Bug #1427814: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1427814>
[14:18] <dimitern> TheMue, in order to reproduce it, you'll need to remove the lshw output for a node (or all nodes) from maas db
[14:22] <TheMue> dimitern: shit, I should have been quiet *lol*
[14:22] <dimitern> TheMue, :)
[14:23] <TheMue> dimitern: so, assigned to me and will add a card. but let me provision my fresh nodes first
[14:23] <dimitern> TheMue, sure, np
[14:23] <dimitern> TheMue, there's already a card btw
[14:24] <TheMue> dimitern: ah, ok, then I'll grab it
[14:24] <dimitern> TheMue, cheers, ping me if anything is unclear
[14:24] <TheMue> dimitern: yep, will do
[14:43] <sinzui> ericsnow, I have bug 1435974 into something we can do. In short, the license files don't have copyrights...the owner of the licence is not clear the owner of the code
[14:43] <mup> Bug #1435974: Copyright information is not available for some files <juju-core:Triaged> <juju-core 1.22:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1435974>
[14:45] <ericsnow> sinzui: ah, that makes sense
[14:45] <ericsnow> sinzui: so does that mean we should have a separate top-level COPYRIGHT file?
[14:46] <sinzui> ericsnow, no it means stop cargo-culting licenses. just put the copyright and meaningful paragraph in the LICENCE file. see my comment int the bug
[14:48] <ericsnow> sinzui: got it; I'll take a look
[14:52] <ericsnow> sinzui: should I get someone to write up patches or were you planning on it?
[14:53] <sinzui> ericsnow, I think core staff are best suited to it since they have to change the project, then the juju 1.22.1 dependencies.tsv
[14:53] <ericsnow> sinzui: sounds good
[14:58] <dimitern> ericsnow, hey
[14:59] <ericsnow> dimitern: hi
[15:00] <dimitern> ericsnow, any idea why I'm getting this with GCE ? Bootstrap failed, cleaning up the environment.
[15:00] <dimitern> 2015-03-25 14:58:45 ERROR juju.cmd supercommand.go:430 there was an issue examining the environment: retrieving auth token for <my client email from the json key file>: Invalid Key
[15:00] <ericsnow> dimitern: I'm guessing your key is invalid <wink>
[15:00] <dimitern> ericsnow, I've followed the instructions, registered for a gce free trail, generated a client id as instructed
[15:01] <dimitern> ericsnow, and the gce provider is not liking it for some reason - triple checked I pasted it ok
[15:01] <ericsnow> dimitern: it may be, as axw said, that it's simply not clear what to put into environments.yaml
[15:01] <natefinch> ericsnow, sinzui: yeah, just slapping a copyright line on the license seems to be the easiest way to do it
[15:02] <natefinch> dimitern: you probably have to put it in quotes
[15:02] <dimitern> ericsnow, should the private-key setting be a patch to the json file I downloaded?
[15:02] <ericsnow> natefinch: as sinzui indicates in the bug, we should also simplify the license file
[15:02] <dimitern> ericsnow, s/patch/path/
[15:02] <ericsnow> dimitern: nope, though that is basically what axw suggested (good idea too)
[15:03] <dimitern> ericsnow, ah, so it needs to be the verbatim contents of the file then?
[15:03] <ericsnow> dimitern: you have to copy-and-paste stuff out of that JSON file
[15:03] <sinzui> I think QA can change the tarball scripts to check for copyrights in LICENSE/LICENCE file so we don't get these surprises from Ubuntu
[15:03] <dimitern> ericsnow, oh, well, I'll try this
[15:04] <ericsnow> dimitern: also, I've put better instructions in the 1.23 release notes
[15:05] <dimitern> ericsnow, I'll check there as well then, thanks
[15:05] <natefinch> dimitern: something like this: https://pastebin.canonical.com/128327/
[15:05] <natefinch> (replace <tons of garbage> with your actual key)
[15:05] <ericsnow> dimitern: BTW, where did you get that JSON file?
[15:06] <natefinch> ericsnow: google's site creates it for you
[15:06] <ericsnow> natefinch: right, but at what point?  during the project creation process?  I don't remember
[15:07] <dimitern> ericsnow, from the GCE web ui - API & auth
[15:07] <ericsnow> dimitern: k
[15:07] <ericsnow> dimitern: I remember now, thanks
[15:13] <Muntaner> hi devs
[15:13] <Muntaner> I have a question about charm distros
[15:13] <Muntaner> I need to be free in what distro I launch with my charms: CentOS, Kali, etc... can I actually do that with juju?
[15:13] <ericsnow> dimitern: thanks for looking at the bug, BTW
[15:14] <dimitern> ericsnow, np, looked like a relatively easy fix and a chance for me to try the gce awesomeness :)
[15:14] <ericsnow> dimitern: haha
[15:19] <alexisb> Muntaner, currently juju supports deploying Ubuntu and Windows workloads
[15:19] <alexisb> Muntaner, we will soon have support of Centos
[15:19] <alexisb> but it is not currently available
[15:20] <Muntaner> alexisb, so I'm not able to choose the distro in my charm?
[15:21] <Muntaner> alexisb, maybe by writting my own metadatas?
[15:22] <natefinch> Muntaner: you definitely can create your charm for a specific distro... it just has to be a version of Ubuntu or Windows right now
[15:26] <marcoceppi_> Muntaner: charm distro isn't specified by metadata.yaml, it's defined by where you push the charm to lp or to a local repo. So if you create ~/charms/win2012r2/charm-name then juju deploy --repository ~/charms local:win2012r2/charm-name Juju will attempt to create a VM with Windows Server 2012r2
[15:26] <marcoceppi_> Muntaner: but that series, which defines distro (trusty, precise, win2012r2, etc)
[15:27] <mup> Bug #1436390 was opened: GCE provider config should support extracting auth info from JSON file <gce-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1436390>
[15:27] <mup> Bug #1436397 was opened: map-order sensitive test in md/juju/storage needs to be fixed <map-order> <juju-core:Triaged> <juju-core 1.23:New> <https://launchpad.net/bugs/1436397>
[15:27] <Muntaner> marcoceppi_, there is no way that allows me to use other distros atm?
[15:28] <marcoceppi_> Muntaner: no, because Juju has to know how to handle that distro and that distro needs to have an image spun up with cloudinit running. Juju is doing the machine setup so if it can't speak to that distro it won't work.
[15:29] <dimitern> \o/ gce is bootstrapping now
[15:29] <marcoceppi_> Muntaner: We're adding support for other distros all the time though, the more distros we add support for the easier juju becomes to port to other platforms
[15:29] <Muntaner> marcoceppi_, where can I find a list of the usable distros?
[15:30] <marcoceppi_> Muntaner: right now it's Ubuntu and Windows, with support for CentOS underway
[15:30] <ericsnow> sinzui: FYI, this last run of 1.23 (2482) had only 1 unit test fail :)
[15:30] <natefinch> Muntaner: CentOS support will be submitted pretty soon, in a matter of weeks.    As for current distros, it's just Ubuntu (precise or later) and Windows... I would have ot look to see which versions of windows we support. Just the server versions for the most part, and I think 2012 or later.
[15:32] <sinzui> ericsnow, \0/
[15:34] <aisrael> Does anyone know the status of this critical bug? https://bugs.launchpad.net/juju-deployer/+bug/1421315
[15:34] <mup> Bug #1421315: subordinate service not appearing in watch output <api> <juju-gui> <oil> <regression> <juju-core:Triaged> <juju-core 1.22:Incomplete> <juju-deployer:Triaged> <https://launchpad.net/bugs/1421315>
[15:39] <dimitern> ericsnow, bootstrap fails now -I did  2 attempts, the first one waited for a while, then I stopped it, the second failed right away with RESOURCE_NOT_READY when trying to start the instance
[15:41] <ericsnow> dimitern: do you see an instances or other resources in the GCE [web] console for the project?
[15:41] <dimitern> probably because I'm using region europe-west1
[15:41] <mattyw> folks - is there a way I can open an api connection acting as the state server in JujuConnSuite?
[15:41] <dimitern> ericsnow, I did see a deprecation warning for zone europe-west1-a
[15:41] <mattyw> ^^ seems like there must be a way - but I can't find it
[15:42] <dimitern> ericsnow, now I've switched to us-central1, and so far no errors, it's trying to connect with ssh
[15:42] <dimitern> mattyw, you need to log in as a machine with JobManageEnviron
[15:43] <alexisb> Muntaner, did you get your question answered?
[15:43] <dimitern> ericsnow, it worked this time - bootstrapping is mostly done
[15:43] <mattyw> dimitern, yeah, I'm trying to access an api that is looked to machines with JobManageEnviron
[15:44] <mattyw> dimitern, but I can't create a new machine with OpenAPIasNewMachine because I'm not allowed to start machines with that job
[15:44] <ericsnow> dimitern: oh good :)
[15:44] <dimitern> mattyw, what do you mean not allowed? you're getting an error from state.AddMachine?
[15:45] <mattyw> dimitern, correct
[15:45] <mattyw> dimitern, I can do a quick screen share if you like
[15:45] <Muntaner> alexisb, yes, I don't know what to do now ;(
[15:45] <Muntaner> I should instantiate automatically subnets with different OS
[15:45] <ericsnow> could I get a volunteer to work on lp:1436407?
[15:46] <dimitern> mattyw, hmm, let me look in a few places first
[15:46] <ericsnow> it's a blocker for 1.23
[15:46] <Muntaner> connected between them... and I wanted to use juju bundles
[15:46] <dimitern> #1436407
[15:46] <mup> Bug #1436407: certSuite.TestNewDefaultServer failed on vivid <ci> <juju-core:Invalid> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1436407>
[15:46] <alexisb> cmars, if you sill have someone available ^^
[15:46] <dimitern> ericsnow, I do believe one of the patches you've reviewed should fix that - I've left a comment
[15:47] <ericsnow> dimitern: ah, cool
[15:47] <dimitern> mattyw, so is the machine you're adding the first one?
[15:48] <mattyw> dimitern, I tried s.OpenAPIAsNewMachine(c, state.JobManageEnviron)
[15:48] <ericsnow> dimitern: yep, http://reviews.vapour.ws/r/1261/
[15:48] <mattyw> dimitern, but that fails because I'm not allowed
[15:48] <dimitern> mattyw, ok, let me have a look at your code?
[15:48] <dimitern> ericsnow, that's the one
[15:49] <voidspace> dimitern: ah, can't use worker.AssertStop as worker.Worker doesn't implement Stop
[15:49] <ericsnow> dimitern: thanks for remembering :)
[15:49] <dimitern> ericsnow, lucky catch I guess :)
[15:49] <voidspace> statetesting.AssertStop I mean
[15:49] <dimitern> voidspace, well, how about defer worker.Stop(w) then ?
[15:51] <voidspace> dimitern: don't need the func call around it as it's a single liner I guess
[15:51] <ericsnow> all, we also need someone to work on #1435974, which should be pretty simple but will involve patches to most of our repos
[15:51] <mup> Bug #1435974: Copyright information is not available for some files <juju-core:Triaged> <juju-core 1.22:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1435974>
[15:51] <alexisb> cherylj, are you working anything critical??
[15:51] <ericsnow> that one is needed before Ubuntu will take 1.22, so it is pretty important
[15:52] <alexisb> if not can you take a look at 1435974
[15:57] <frankban> dimitern: what's the goal of the revision updater? is it just for juju status?
[15:59] <voidspace> dimitern: nope, needs wrapping
[15:59] <voidspace> dimitern: http://play.golang.org/p/4N_ydeMKEB
[15:59] <voidspace> dimitern: the *first* panic is triggered inside the defer - never get to the second
[15:59] <voidspace> dimitern: which is why we wrap in a function call!
[16:02] <dimitern> voidspace, sorry, will get back to you in a bit
[16:03] <voidspace> dimitern: no problem, just an interesting observation
[16:03] <voidspace> dimitern: I can't change the defers as you suggested
[16:03] <mup> Bug #1436415 was opened: vivid local template container "juju-vivid-lxc-template" did not stop' <ci> <lxc> <vivid> <juju-core:In Progress by ericsnowcurrently> <juju-core 1.23:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1436415>
[16:03] <voidspace> dimitern: I made all the other changes and now one test is failing for no discernable reason [yet]
[16:03] <mup> Bug #1436421 was opened: juju panics after upgrade from 1.18.4 to 1.20.11 <juju-core:New> <https://launchpad.net/bugs/1436421>
[16:03] <voidspace> dimitern: will fix and ship
[16:15] <dimitern> voidspace, I guess you're not looking your PMs :)
[16:32] <ericsnow> dimitern: do you know if wallyworld's cert expiry patch needed to be forward-ported to master?
[16:35] <dimitern> ericsnow, no, I don't off hand, but check if the bug is
[16:35] <dimitern> ..affecting both master and 1.23
[16:37] <ericsnow> dimitern: I'm pretty sure it either doesn't apply to master or was already fixed :)
[16:37] <ericsnow> dimitern: I'll ask wallyworld when he's around
[16:37] <ericsnow> dimitern: I do have a question about networking, if you have a minute
[16:38] <dimitern> ericsnow, shoot
[16:39] <ericsnow> dimitern: for the vmware provider (from alteros) it looks like the low-level API does not support managing much networking details for instances (in this case virtual machines)
[16:40] <dimitern> ericsnow, really? that's a bit surprising
[16:40] <dimitern> ericsnow, but shouldn't matter much anyway - networking features are optional
[16:40] <ericsnow> dimitern: so opening/closing ports and assigning internal/external IP addresses is not supported and must be handle manually
[16:40] <ericsnow> dimitern: I'm talking about for the core firewall functionality of a provider
[16:41] <ericsnow> dimitern: for supporting juju expose/unexpose
[16:41] <ericsnow> dimitern: though that is certainly related
[16:41] <dimitern> ericsnow, right, ok
[16:42] <ericsnow> dimitern: I'm going off the information I have about the capability of the "vSphere" API that we're using
[16:42] <dimitern> ericsnow, so you're saying the provider will need to do some manual steps to open/close ports on each instance
[16:42] <ericsnow> dimitern: so I wanted to get your thoughts on what might be the best approach to take in this situation
[16:42] <ericsnow> dimitern: right
[16:43] <ericsnow> dimitern: and to manage internal/external IP of an instance
[16:43] <dimitern> ericsnow, what sort of management?
[16:43] <ericsnow> dimitern: (just for the sake of juju's networking needs)
[16:43] <ericsnow> dimitern: not talking about the juju networking API
[16:43] <TheMue> aaargh, shitty yaml again, disliking a tab :(
[16:45] <dimitern> ericsnow, well, not having support for open/close port is not uncommon - the provider can just return an error
[16:45] <ericsnow> dimitern: so what might be the most sensible approach for the provider to manually set these things
[16:45] <dimitern> ericsnow, but I need to understand a bit better the issue around internal/external IPs you mention
[16:46] <ericsnow> dimitern: really?  how does juju handle that when handling an expose call?
[16:46] <dimitern> ericsnow, expose triggers calling OpenPort on the environ via the firewaller
[16:46] <ericsnow> dimitern: right
[16:47] <ericsnow> dimitern: so what happens when OpenPort returns an error saying it isn't supported?
[16:48] <dimitern> ericsnow, the firewaller logs an error/warning and that's it
[16:49] <ericsnow> dimitern: but then the unit doesn't get exposed, right?
[16:49] <ericsnow> dimitern: that seems like a show-stopper for any provider
[16:50] <dimitern> ericsnow, no
[16:51] <dimitern> ericsnow, so first, the service is exposed or not, not its units
[16:51] <ericsnow> dimitern: right
[16:51] <dimitern> ericsnow, then, "exposed" is just a flag, it doesn't guarantee access, it declares intent
[16:52] <ericsnow> dimitern: got it
[16:52] <dimitern> ericsnow, whether a given unit is accessible after exposing the service - that's where the firewaller comes into play
[16:52] <dimitern> ericsnow, so if it fails to open the port - too bad; however this is not an issue for *some* providers
[16:53] <dimitern> ericsnow, e.g. local doesn't have (or assume) restrictive firewall rules so even without exposing a service, once it's running you can access it
[16:54] <dimitern> ericsnow, now, if the provider does not allow you to control access (egress/ingress), I'm not sure you can do much about it
[16:57] <mbruzek> wwitzel3: Can I get a review of this go code? https://github.com/mbruzek/virtualservices/blob/master/parse_endpoint.go
[16:57] <mup> Bug #1436407 was opened: certSuite.TestNewDefaultServer failed on vivid <ci> <juju-core:Incomplete by wallyworld> <juju-core 1.23:Fix Committed by ericsnowcurrently> <https://launchpad.net/bugs/1436407>
[16:57] <mbruzek> wwitzel3: https://github.com/mbruzek/virtualservices
[17:05] <ericsnow> dimitern: so to summarize: OpenPort/ClosePort isn't critical as long as there is still external access to the port on the instance
[17:08] <ericsnow> dimitern: what specifically does juju require regarding internal IP addresses?
[17:24] <dimitern> ericsnow, that's correct
[17:30] <TheMue> dimitern: any idea why bootstrapping fails with "You may want to use the 'agent-metadata-url' configuration setting to specify the tools location." even if the configuration setting is done?
[17:49] <dimitern> ericsnow, sorry, got in another call
[17:49] <ericsnow> dimitern: no worries :)
[17:49] <dimitern> ericsnow, re internal IP addresses
[17:50] <dimitern> ericsnow, there's no special requirement - just that an instance can talk to the apiserver
[17:50] <dimitern> ericsnow, on its published cloud-local address
[17:50] <ericsnow> dimitern: k
[17:50] <dimitern> TheMue, have you imported the boot images?
[17:51] <ericsnow> dimitern: it seems like communication between charms via the cloud-local address is pretty common, so that should be a factor, right?
[17:52] <TheMue> dimitern: you mean "--sync-tools" into a local directory?
[17:52] <dimitern> ericsnow, yes, all charms inside the environment use the private address of the unit (which in turn comes from the unit's assigned machine)
[17:52] <dimitern> TheMue, no, I mean does your maas have any images you can see in the web ui?
[17:53] <ericsnow> dimitern: got it; thanks for all the clarification :)
[17:53] <TheMue> dimitern: yes, 14.04 and 14.10
[17:53] <dimitern> ericsnow, np, I hope I was helpful :)
[17:53] <ericsnow> dimitern: totally
[17:53] <TheMue> dimitern: but I get an error when doing juju bootstrap
[17:54] <dimitern> TheMue, and you're bootstrapping with --upload-tools --debug?
[17:54] <TheMue> dimitern: so far w/o debug, will try again
[17:55] <dimitern> TheMue, might be helpful, yeah
[17:56] <TheMue> dimitern: hmm, currently not directly. but will ping you tomorrow morning
[17:56] <cherylj> alexisb, ericsnow, I can take bug 1435974
[17:56] <mup> Bug #1435974: Copyright information is not available for some files <juju-core:Triaged> <juju-core 1.22:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1435974>
[17:57] <dimitern> TheMue, ok, paste a dump of the bootstrap log along with it
[17:57] <alexisb> cherylj, thank you!
[17:57] <ericsnow> cherylj: awesome, thanks!
[17:57]  * dimitern steps out
[18:00]  * TheMue too
[18:24] <ericsnow> cherylj: make sure to assign the bug to yourself and mark it as in progress
[18:25] <cherylj> ericsnow: done
[18:25] <ericsnow> cherylj: thanks :)
[18:27] <mup> Bug #1434437 changed: juju restore failed with "error: cannot update machines: machine update failed: ssh command failed: " <backup-restore> <maas-provider> <juju-core:Invalid> <juju-core 1.22:Incomplete by ericsnowcurrently> <https://launchpad.net/bugs/1434437>
[18:31] <natefinch> I think turning up logging to show DEBUG logs fixed my problem...
[18:41] <cherylj> ericsnow, sinzui:  Just to sanity check:  http://reviews.vapour.ws/r/1264/
[18:42] <cherylj> I'll modify that text to reflect which license is used in the other packages.
[18:44] <sinzui> cherylj, perfect, and the diff shows the comedy that happened
[18:44] <cherylj> ah, yeah
[18:45] <cherylj> sinzui: should I go back in and add that one line package description too?
[18:46] <ericsnow> cherylj: a friendly reminder that the patch will also need to be applied to 1.22 and 1.23 :)
[18:50] <cherylj> ericsnow: I haven't had to apply changes to a non-master branch yet.  Is there an easy way to do it?
[18:51] <ericsnow> cherylj: you should probably be able to just create a new pull request with a different target branch (I expect it will apply cleanly on all branches)
[18:52] <ericsnow> cherylj: but you *may* need to rebase your branch to the target and force-push it before the new PR will apply cleanly
[18:52] <cherylj> ericsnow: yeah, I think I do
[18:52] <ericsnow> cherylj: not the funnest dance
[18:52] <cherylj> hehe
[18:53] <ericsnow> cherylj: be sure to land it in each branch before moving on to the next branch
[18:54] <ericsnow> cherylj: to be honest, I think we could make this easier by null-merging older branches up the chain and then strictly forward-porting from there
[18:55] <ericsnow> cherylj: if I understand it right that would eliminate the need to rebase for each PR
[18:55] <ericsnow> cherylj: it would also mean the forward port would be accomplished by merging the older branch into the newer one (e.g. 1.22 -> 1.23 -> master)
[18:56] <ericsnow> cherylj: however, that isn't the state of things at the moment so you'll have to go the rebase-then-PR route :)
[18:57] <cherylj> ericsnow: now that you've gotten me really confused, I should just go back and do the first thing?  ;)
[18:57] <ericsnow> cherylj: sorry, I was afraid of that :)
[18:57] <mup> Bug #1436495 was opened: sporadic test failure: storeManagerStateSuite.TestStateWatcher <ci> <juju-core:New> <https://launchpad.net/bugs/1436495>
[18:59] <ericsnow> cherylj: do what you were doing 1. land your PR against master, 2. rebase your branch against 1.23  3. force-push it 4. create a new pull requrest from your branch to 1.23 5. repeat 2-4 for 1.22
[18:59] <cherylj> ericsnow: that I can do :)  Thanks
[19:00] <ericsnow> cherylj: (and land the PR from 4 before moving on to 5)
[19:01] <ericsnow> cherylj: there are other ways to do this too, perhaps even simpler, but I've already muddied the waters a bit :)
[19:03] <cherylj> ericsnow: for a package description (from your RB comment), should I add something like "This package contains the core functionality for juju"?
[19:04] <ericsnow> cherylj: that sounds fine to me
[19:04] <ericsnow> sinzui: ^^^
[19:06] <ericsnow> cmars: intermittent(?) test failure possibly related to your team's work:  #1436507
[19:06] <mup> Bug #1436507: sporadic test failure: FilterSuite.TestMeterStatusEvents <ci> <juju-core:New> <https://launchpad.net/bugs/1436507>
[19:07] <cmars> ericsnow, will take a look
[19:07] <ericsnow> cmars: thanks
[19:07] <ericsnow> cmars: I'm trying to get the vivid unit tests passing in CI :)
[19:07] <cmars> ericsnow, it just so happens I have a vivid instance ready for action
[19:10] <mup> Bug #1436507 was opened: sporadic test failure: FilterSuite.TestMeterStatusEvents <ci> <juju-core:New> <https://launchpad.net/bugs/1436507>
[19:12] <ericsnow> sinzui: looks like run-unit-tests-vivid-amd64 just passed on vivid :)
[19:12] <ericsnow> sinzui: on 1.23
[19:14] <sinzui> ericsnow, yeah
[19:15] <ericsnow> sinzui: master is close (maybe just intermittent failures)
[19:15] <sinzui> ericsnow, I am whipping the precise aws upgrade job. I think aws + precise is experiencing unreliability this week and it is hurting the test results
[19:16] <ericsnow> sinzui: I've opened bugs for recent failures and noted all related bugs in #1433577
[19:16] <mup> Bug #1433577: Vivid unit tests need to pass <ci> <test-failure> <vivid> <juju-core:In Progress by ericsnowcurrently> <juju-core 1.23:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1433577>
[19:17] <sinzui> ericsnow, I saw :)
[19:18] <ericsnow> sinzui: now if only I could get the vivid deploy test to pass :(
[19:19] <mup> Bug #1436507 changed: sporadic test failure: FilterSuite.TestMeterStatusEvents <ci> <juju-core:New> <https://launchpad.net/bugs/1436507>
[19:21] <ericsnow> what changed, mup?  are you just making this up?
[19:22] <ericsnow> natefinch: were you going to be able to give me a review on http://reviews.vapour.ws/r/1234/?
[19:22] <natefinch> lol:   return newStorageWorker("", api, api, api, api)
[19:23] <ericsnow> natefinch: obviously :)
[19:23] <natefinch> ericsnow: yeah, sorry, got distracted by getting my HA stuff working
[19:23] <ericsnow> natefinch: hey, I'm okay with that
[19:27] <natefinch> api/converter/converter.go: needs merge
[19:27] <natefinch> apiserver/converter/converter.go: needs merge
[19:27] <natefinch> worker/converter/converter.go: needs merge
[19:27] <natefinch> You must edit all merge conflicts and then
[19:27] <natefinch> mark them as resolved using git add
[19:27] <natefinch> $ git mergetool
[19:27] <natefinch> No files need merging
[19:27] <natefinch> ffffff.....
[19:28] <mup> Bug #1436507 was opened: sporadic test failure: FilterSuite.TestMeterStatusEvents <ci> <juju-core:New> <https://launchpad.net/bugs/1436507>
[19:38] <sinzui> ericsnow, I paused CI. I am going to restart vivid-slave-b and give it one more try with 1.23
[19:56] <ericsnow> cherylj: looks like godeps (really a flaky code hosting service) is making your merge fail :(
[19:57] <cherylj> ericsnow:  I was wondering what was causing that.  Is there anything I can do other than keep retrying?
[19:57] <ericsnow> cherylj: I just ran godeps on my local host and it took a looooong time (and CI is less patient)
[19:58] <natefinch> ericsnow: weird, what host is being slow?
[19:58] <ericsnow> cherylj: wait for launchpad (or whoever) to speed back up
[19:58] <ericsnow> natefinch: not sure
[19:59] <ericsnow> natefinch: it wasn't clear which, though it *seemed* to correspond to gopkg.in
[19:59] <ericsnow> natefinch: which doesn't tell me much
[20:10] <ericsnow> cherylj: also, keep in mind that I enabled the reviewboard webhook on a number of our github repos the other day but not all of them
[20:11] <ericsnow> cherylj: so if no review request shows up it probably means there's no hook and it will have to be reviewed on github
[20:12] <ericsnow> cherylj: if you bump into that please let me know so I can double-check the webhook is set up right
[20:14] <cherylj> ericsnow: will do
[20:33] <cherylj> davecheney: If you could take a look today :)  http://reviews.vapour.ws/r/1239/
[20:39] <davecheney> cherylj: sure thing
[20:48] <dpb1> rick_h_: how do I download a bundle from the store from the command line?
[20:48] <rick_h_> dpb1: curl https://api.jujucharms.com/v4/mongodb-cluster/archive/bundle.yaml ?
[20:48] <dpb1> ok
[20:49] <rick_h_> dpb1: though that's the new format, so you'll need a not-yet-released deployer to use it
[20:49] <rick_h_> dpb1: or quickstart I think will do that
[20:49] <dpb1> rick_h_: https://jujucharms.com/u/landscape/landscape-dense-maas/
[20:49] <dpb1> rick_h_: why is that preview blank?
[20:49] <dpb1> rick_h_: (sorry for the rapid fire questions). :)
[20:49] <rick_h_> dpb1: looking
[20:50] <rick_h_> dpb1: no gui annotations for positions
[20:50] <rick_h_> dpb1: we've got a todo to add a default layout algo to the svg generator
[20:51] <dpb1> rick_h_: OK, I'll export something from the GUI and see if I can figure it out.  Thanks, that is probably enough to go on
[20:53] <dpb1> rick_h_, Makyo, I'm giving the branch a final test now, things looking much better test coverage wise.  Thanks.
[20:53] <rick_h_> dpb1: awesome, ty for bearing through us with it.
[20:53] <Makyo> dpb1, seconded, thanks a ton
[20:53] <rick_h_> dpb1: big chunk of work to move forward the new bundle story and such
[20:54] <dpb1> np, sorry it's taken a while, other prios came up.
[20:54] <rick_h_> and hopefully we can iterate on it to smooth it out as a nice useful feature
[20:54] <dpb1> rick_h_: agreed
[20:54] <rick_h_> dpb1: understand, unfortunately it's not really anyone's day job :)
[20:54] <ericsnow> natefinch: so about that review :)
[21:34] <ericsnow> cmars: did that bug end up being related to your stuff?
[21:34] <ericsnow> cherylj: would you mind targeting 1.22 first?  It's the key one we need to get fixed first.
[21:37] <alexisb> cherylj, thumper, the bug cherylj is working is very time sensitive, so we will want to pass that off to another team member at eod for cherylj
[21:37] <cherylj> ericsnow: yes, I can do that
[21:38] <ericsnow> cherylj: thanks
[21:40] <thumper> alexisb: ack
[21:40] <alexisb> thumper, cherylj thank you!
[21:42] <cmars> ericsnow, i seriously doubt it. nothing is stable on vivid afaik on my instance
[21:44] <cmars> ericsnow, mongo sockets left open, all kinds of timeouts, etc.
[21:56] <ericsnow> cmars: lovely
[21:56] <cmars> ericsnow, still poking at it
[21:57] <ericsnow> cmars: please keep a list of everything you notice needs fixing on vivid :)
[21:57] <cmars> ericsnow, will do
[21:57] <ericsnow> cmars: thanks!
[22:09] <cmars> wallyworld, could this be related to storage? what might cause this timeout? https://bugs.launchpad.net/juju-core/+bug/1436507/comments/1
[22:09] <mup> Bug #1436507: sporadic test failure: FilterSuite.TestMeterStatusEvents <ci> <intermittent-failure> <juju-core:In Progress by cmars> <https://launchpad.net/bugs/1436507>
[22:12] <cherylj> ericsnow, sinzui:  For the juju/cmd case, there is an exception to the license noted, so I just added the copyright information and left the rest of the LICENSE file intact:  http://reviews.vapour.ws/r/1269/
[22:13] <ericsnow> cherylj: sounds good
[22:13] <cherylj> ericsnow: can you merge the juju/cmd PR?
[22:13] <ericsnow> cherylj: sure
[22:13] <cherylj> thanks
[22:14] <wallyworld> cmars: not the new storage feature - the storage in the error is the environment blob store where charms and tools are saved (instead of cloud storage)
[22:14] <cmars> wallyworld, ok, got it
[22:14] <wallyworld> cmars: for whatever reason, the mongo db used for that storage became disconnected - i/o timeout
[22:15] <wallyworld> it attempts to rollbacl failed operations, but the rollback failed too
[22:15] <cmars> wallyworld, ah, that's *very* consistent with other errors i'm seeing
[22:15] <cmars> wallyworld, i'm running mgo tests now
[22:15] <ericsnow> cherylj: did you try adding a merge comment?  the landing bot was added to a number of repos recently and I believe cmd is one of them
[22:16] <wallyworld> cmars: maybe on a busy system things can't keep up? not sure
[22:16] <wallyworld> but for whatever reason, juju->mongo is not happy
[22:18] <cmars> so i decided to run mgo.v2's tests. http://paste.ubuntu.com/10680888/
[22:19] <cmars> this is on canonistack. i'll try a kvm locally for a second opinion
[22:36] <ericsnow> cmars: yikes
[22:41] <cmars> ericsnow, that might be a red herring.. i get the same error on trusty
[22:42] <cmars> ericsnow, which is a different sort of yikes
[22:42] <ericsnow> cmars: :)
[22:42] <ericsnow> cmars: at least that package isn't important to juju <wink>
[22:45] <cmars> yeah, i mean, close enough, right? http://paste.ubuntu.com/10680988/
[22:46] <cmars> that's an mgo.v2/txn test, which I just ran on trusty
[22:47] <ericsnow> cmars: bank error *not* in your favor :)
[22:52] <cmars> ericsnow, just curious, does the vivid torrent work for you? i'm getting a tracker error
[22:53] <cmars> ericsnow, http://cdimage.ubuntu.com/ubuntu-gnome/releases/vivid/alpha-1/
[22:53] <cmars> oh, i should probably get beta-1
[22:53] <cmars> nevermind
[22:53] <ericsnow> cmars: don't know
[22:53] <cmars> beta-1 works
[23:00] <ericsnow> cmars: lesson learned :)
[23:05] <cherylj> ericsnow: no, I hadn't, the last time I made changes to cmd it was still a manual merge repo
[23:05] <ericsnow> cherylj: well, I tried it and nothing happened :)
[23:05] <cherylj> ericsnow: I also see that charm doesn't trigger RB
[23:05] <ericsnow> cherylj: charm is one for which I did not add the hook
[23:06] <ericsnow> cherylj: I'll push the merge button on cmd
[23:06] <cherylj> ericsnow:   thanks :)
[23:06] <cherylj> Can you also review the 1.22 change?  http://reviews.vapour.ws/r/1268/
[23:07] <ericsnow> cherylj: be sure to target 1.22 with your PRs (you have to manually change the target brach from master)
[23:07] <ericsnow> cherylj: you bet
[23:07] <ericsnow> cherylj: I see you're a step ahead of me :)
[23:08] <cherylj> hehe :)  It took me a little bit of time to figure out how to actually do the changes / PR for 1.22
[23:10] <cherylj> I haven't contributed to most of these repos before, so I have to so all the initial steps to get things set up first
[23:25] <ericsnow> cherylj: sorry about that; I really appreciate that you are working on this :)
[23:26] <cherylj> ericsnow:  It's no problem at all.
[23:35] <davecheney> alexisb: oh shit, sorry i'm late
[23:35] <alexisb> davecheney, nws
[23:35] <alexisb> I am on the hangout when you are ready
[23:35] <davecheney> alexisb: jumping in the hangout now
[23:47] <axw> wallyworld: can you please create github.com/juju/replicaset when you have a moment. I can't do that, but I'll do the rest
[23:48] <wallyworld> sure
[23:48] <wallyworld> axw: mongo-replicaset perhaps?
[23:48] <wallyworld> or is that too wordy
[23:49] <wallyworld> or tautological
[23:49] <axw> I'd rather just go with replicaset as that's what it's called now, we can rename it later if we need to
[23:50] <axw> wallyworld: ^
[23:50] <wallyworld> ok, i was thinking replicaset on its own was ambiguous
[23:50] <wallyworld> but we can rename if needed
[23:54] <wallyworld> axw: that's done, i've also added the bots as collaborators so we can automate landings if needed
[23:54] <wallyworld> s/automate/gate
[23:55] <axw> wallyworld: thanks