[00:00] <knome> http://www.youtube.com/watch?v=wMSDPLOSHyQ
[00:01] <ochosi> but i guess i need to make room for a precise vm at some point, otherwise i have to try to fix greybird-precise bugs "in the dark"
[00:02] <knome> mmh, right
[00:57] <knome> HA!
[00:58]  * knome just fixed the 404 errors @ xubuntu.org
[00:58] <knome> now to file a RT ticket..
[01:02] <pleia2> \o/
[01:02] <pleia2> you are the winnar
[01:03] <knome> haha
[01:03] <knome> thanks
[01:03]  * knome bites the gold metal and breaks his teeth
[01:03] <knome> OUCH
[01:03] <knome> ;)
[01:03]  * pleia2 passes over a beer instead
[01:03] <knome> http://xubuntu.princessleia.com/i_like_beer <--
[01:03] <knome> hahah...
[01:03] <knome> ;)
[01:03] <knome> exactly!
[01:05]  * knome unmounts sshfs from pleia2's server
[01:07] <pleia2> :)
[01:07] <knome> meh.
[01:07]  * knome might not be able to attend uds even if he wanted
[01:08] <knome> not that i'm too excited to travel to states to hack on a pc
[01:08] <knome> ...
[01:09] <pleia2> but california is lovely
[01:09] <knome> yeah, but indoors?
[01:09] <pleia2> and in oakland
[01:10] <pleia2> but wednesday night we're doing tourist stuff in san francisco! the nice city :)
[01:10] <knome> well, we have bachelor party @ may 12
[01:10] <pleia2> bring your wife, we're having an ubuntu women dinner thursday night at my place
[01:10] <knome> hah :)
[01:11] <knome> she's not really interested in FOSS (sorry! ;)) and not really able to come anyway (three-shift work)
[01:11] <pleia2> it's a nice place for a vacation :D
[01:12] <pleia2> my favorite vacation last year was as a tag-along to a networking conference my fiance went to, in Puerto Rico
[01:12] <knome> heh
[01:12] <knome> well, seriously
[01:12] <knome> it's damn far :/
[01:12] <pleia2> yeah, it is
[01:13] <knome> i'd have loved to attend @ europe
[01:13] <pleia2> it's nice to have it at home, but I was actually looking forward to another europe adventure
[01:14] <pleia2> dunno what they're doing in the fall
[01:14]  * knome is keeping fingers crossed for EU...
[01:14] <knome> why not even finland!
[01:14] <knome> but that's not going to happen.
[01:14] <knome> :)
[01:14] <pleia2> is there snow everywhere in october? :)
[01:14] <knome> depends
[01:14] <pleia2> hehe
[01:14] <knome> you might have none, or you might have 50cm
[01:15] <knome> and polar bears on the streets
[01:15] <knome> and the iglu's on the suburbs
[01:15] <pleia2> lol
[01:15] <knome> hah, not really
[01:16] <knome> the falls have been very non-snowy lately:)
[01:16] <pleia2> I don't actually know what goes into a venue decision
[01:16] <pleia2> seems random
[01:16] <knome> but it snowed today :)
[01:16] <knome> well, a big venue i suppose
[01:16] <knome> and places where to accommodate lots of people
[01:17] <knome> and maybe something interest to show to the sponsored guys and gals
[01:17] <knome> well, we could always show those iglus
[01:17] <pleia2> the brussels one was in the middle of the woods
[01:17]  * knome 's iglu is very humble, but there are nicer ones
[01:17] <madnick> :)
[01:17] <knome> pleia2, that's something to see too...
[01:18] <pleia2> and your pet polar bear!
[01:18] <knome> maybe organize it in lapland
[01:18] <knome> and you can be in the middle of nowhere
[01:18] <pleia2> they had shuttles into the city each night so we could get drunk
[01:18] <pleia2> it was nice :)
[01:18] <knome> haha
[01:18] <pleia2> we got very drunk
[01:18] <knome> i'm sure you did
[01:18] <knome> with all the belgian beer!!
[01:18] <pleia2> yes!
[01:18] <knome> MEH!
[01:18] <madnick> http://en.wikipedia.org/wiki/Icehotel_%28Jukkasj%C3%A4rvi%29
[01:19] <pleia2> I actually took the opportunity to try every lambic I could find (they still aren't hugely common here in the states, when you find them it's always raspberry)
[01:19] <knome> that would work for me...
[01:19] <knome> pleia2, mmh, too bad. there aren't many brands in finland either, but at least we got variety (not always just raspberry)
[01:19] <pleia2> madnick: wow :)
[01:20] <madnick> :P
[01:20] <pleia2> those are some nice igloos!
[01:20] <knome> madnick, do you know which was first, that or http://www.snowcastle.net/en/ ?
[01:20] <knome> i'd say the latter
[01:21] <pleia2> I blogged all my beer too: http://princessleia.com/journal/?p=2996
[01:21] <pleia2> :d
[01:21] <knome> what did you think of delirium tremens?
[01:21] <madnick> "Existing each year between December and April, the Icehotel in the village of Jukkasjärvi, about 17 km from Kiruna, Sweden was the world's first ice hotel."
[01:21] <knome> hah
[01:21] <knome> okay
[01:22] <knome> but the whole complex?
[01:22] <knome> which was first?
[01:22] <madnick> oh
[01:22] <madnick> Dont know
[01:22] <knome> finns or swedes?
[01:22] <madnick> It doesnt say
[01:22] <knome> mmh
[01:22] <pleia2> knome: love delirium tremens, they have it here too, the hotel bar was pretty limited, only had things I already had
[01:22] <knome> okay
[01:22] <knome> that's not my fav
[01:22] <knome> what bout la chouffe?
[01:22] <pleia2> love la chouffe too (have it here)
[01:22] <knome> oh right
[01:22] <knome> you even blogged that :P
[01:22] <knome> there was no mention of DT
[01:23] <knome> or i just missed that...
[01:23] <madnick> "the shakes"?
[01:23] <knome> shakes on the plane?
[01:23] <madnick> oh
[01:23] <madnick> its a beer
[01:23] <knome> ha
[01:23] <madnick> I thought you meant the condition :P
[01:24] <madnick> i figured it was a really bad bar
[01:24] <knome> lol
[01:24] <pleia2> hehe
[01:24] <knome> delirium nocturnum is their other beer
[01:24] <pleia2> nocturnum is ok
[01:24] <knome> not my fav either
[01:24] <knome> other of them is a bit too tangy and the other is a bit too cardboardy
[01:24]  * astraljava emerges when the topic turns to beer
[01:24]  * knome is not the professional beer-rater
[01:25] <knome> astraljava, well of course.
[01:25] <knome> astraljava, have you ever tasted a rye beer?
[01:25] <astraljava> Yes I have.
[01:25] <astraljava> I forget which, but I have.
[01:25] <knome> okay, enjoyed?
[01:25] <knome> i just bought the one by stadin panimo
[01:25] <astraljava> Yeah, for sure.
[01:25] <knome> a small batch in the flagship alko
[01:25]  * astraljava loves rye in pretty much every form
[01:26] <knome> mmh. never tried a rye beer before
[01:26] <knome> pleia2, you?
[01:26] <pleia2> I don't think so
[01:26] <micahg> knome: it's beta, so relatively stable for a power user
[01:26] <knome> i take that as a definite no ;)
[01:26] <knome> micahg, okay
[01:26] <knome> micahg, btw...
[01:27] <knome> micahg, have you heard me complaining about some display issues when switching to an (imaps) inbox folder
[01:27] <GridCube> i did not remembered today's meeting :(
[01:27] <micahg> knome: not sure what you mean by switching
[01:27] <knome> micahg, i mean, changing the account, or sometimes when running TB
[01:28] <knome> micahg, sometimes the initial view is weird
[01:28] <knome> micahg, no idea how to reproduce, but i can take a shot the next time i hit it
[01:28] <knome> pleia2, so have you even tasted rye bread? :)
[01:29] <pleia2> knome: not that I'm aware of
[01:29] <GridCube> knome, i added my opinions to he wiki page about the default window manager shortcuts in its moment, please tell me those are not among the changes that are going to happen
[01:29] <knome> pleia2, okay, so haven't :)
[01:29] <knome> GridCube, the ones under "detailed specification" are what we're pushing, the ones between "obsolete/superseded" not
[01:30] <GridCube> :D oh thats okay then
[01:30] <GridCube> thank you very
[01:30] <GridCube> much
[01:30] <knome> np
[01:31] <micahg> knome: screenshot might help, no idea what you mean
[01:32] <knome> micahg, is there something that would make TB more closed than just closing the window?
[01:32] <knome> is there some daemon or so that needs to be ran on boot, that is left open or so
[01:34] <micahg> knome: no, if it doesn't close in a timely manner, that's a bug (which I think might already be known)
[01:34] <knome> no, that's not it
[01:35] <knome> i was just thinking because i think this might happen more when TB is opened the first time after buut
[01:35] <knome> *boot
[01:35] <knome> but that might be just me...
[01:37] <astraljava> knome: I'm sorry, I havem
[01:37] <astraljava> sorry
[01:37] <knome> hm? :)
[01:37] <astraljava> I haven't followed the whole of the conversation.
[01:37] <knome> no problem
[01:37] <astraljava> But I use TB, so can I double-check anything?
[01:38] <knome> well, i'm wondering how to reproduce...
[01:38] <astraljava> Ahh... the opening view is strange.
[01:38] <knome> AH!
[01:38] <knome> I GET IT I GET IT
[01:38] <knome> IT'S HERE
[01:39] <knome> THE BULL IS HERE!
[01:39] <astraljava> Hahah!
[01:39] <astraljava> "Where is ze bull..."
[01:40] <astraljava> Oh man, this is one of those games for the Bruins... *frown*
[01:42] <knome> micahg, http://temp.knome.fi/other/tb-bug-contentview.png
[01:42] <knome> micahg, FAIL
[01:43]  * micahg isn't sure what he's looking at
[01:43] <knome> micahg, try the message area :)
[01:43] <knome> and the headers area :)
[01:45] <astraljava> knome: Were there some specific steps to reproduce, or is it just the full moon?
[01:45] <knome> astraljava, i think, send a utf8-encoded mail as plaintext, might need to have scands in the title too
[01:45] <micahg> seems like a corrupted index or something, my guess is there's probably a bug for it upstream, but not sure
[01:46] <knome> well yeah, but HOW DO I FIX THIS
[01:46] <knome> :P
[01:46] <knome> it's pretty annoying
[01:49] <knome> and yes, the most annoying part is that when you reload the message (open another and get back to the original one), it's displayed as it should
[01:49] <knome> astraljava, can you repro?
[01:52] <astraljava> knome: I couldn't, but I'm trying to double-check that the message actually leaves as utf-8.
[01:52] <knome> astraljava, i can send you the exact same message
[01:52] <knome> if you want...
[01:54] <astraljava> knome: Yes please<EMAIL_ADDRESS>[01:54] <knome> astraljava, i don't need your permission. sent.
[01:54] <knome> meh
[01:54] <knome> i sent to kapsi
[01:54] <knome> but just a sec
[01:54] <astraljava> Nah, I use mutt on there.
[01:54] <knome> okay, done
[01:55] <knome> comes from knomex@samedomain
[01:55] <knome> boo google for not allowing five-letter mail accts
[01:57] <astraljava> Wow. That's strange.
[01:57] <knome> do you have imaps or just imap
[01:57] <knome> or pop(s)
[01:57] <astraljava> IMAP with SSL/TLS
[01:58] <knome> okay
[01:58] <astraljava> It's not showing up.
[01:58] <knome> at all?
[01:58] <astraljava> Haha. Marked as Junk. :)
[01:58] <knome> congrats
[01:58] <knome> so, when you first click the message
[01:58] <knome> how does it look?
[01:59] <astraljava> It looks totally correct to me.
[02:00] <knome> right...
[02:00] <knome> i need to do some more tests then
[02:00] <knome> it's kind of delicate
[02:01] <knome> but, i'm off to bed now
[02:01] <knome> see you later!
[02:08] <astraljava> Later.
[11:02] <knome> mr_pouit?
[11:30] <mr_pouit> knome: oui ?
[11:44] <knome> mr_pouit, https://wiki.ubuntu.com/Xubuntu/Roadmap/Specifications/Precise/DefaultShortcutKeys
[11:44] <knome> mr_pouit, can you update xubuntu-default-settings with those?
[12:26] <mr_pouit> yeah
[13:11] <knome> mr_pouit, thanks
[13:46] <mr_pouit> Appfinder
[13:46] <mr_pouit> Super R (Run)
[13:46] <knome> yes?
[13:46] <mr_pouit> knome: xfce4-appfinder or xfrun4?
[13:46] <knome> isn't xfrun4 in alt+f2
[13:46] <knome> you should ask ochosi, but i'm relatively sure it means appfinder if it reads appfinder :P
[13:47] <mr_pouit> ok
[13:47] <knome> and yes, that makes sense too :)
[13:49] <mr_pouit> and super1/2/3/4 is a bad idea with non-english layout I'm afraid (let me test)
[13:51] <knome> hmm, really?
[13:51] <knome> not the numpad keys, those, of course :)
[13:53] <mr_pouit> anyway, shortcuts with KP_? numbers don't work
[13:53] <mr_pouit> knome: e.g. with a french layout, to write 1 you have to use <shift>&
[13:54] <ochosi> mr_pouit: what version of appfinder will we have in precise?
[13:54] <mr_pouit> so <super>1 won't launch gmusicbrowser, and <super><shift>& neither
[13:54] <knome> mr_pouit, huh, how is it so??
[13:54] <mr_pouit> ochosi: the 4.8 one
[13:54] <ochosi> same as oneiric or will it include the merged version?
[13:54] <ochosi> gah
[13:54] <ochosi> ok, that sucks a bit
[13:55] <ochosi> then probably super+r should trigger appfinder, as xfrun is already on alt+f2
[13:55] <mr_pouit> yep, I did that
[13:55] <ochosi> ok, ty
[13:55] <ochosi> about the other xfce-components, we'll mainly be staying at 4.8, right?
[13:56] <mr_pouit> knome: because 1 doesn't exist, it's a combination of other keys (just like 'E', you can't use that as a shortcut, it's <shift>e actually)
[13:56] <ochosi> mr_pouit: you mean with a french layout there's no easy way to type "1"?
[13:57] <mr_pouit> ochosi: yeah, I only backported things to xfce4-settings
[13:57] <mr_pouit> ochosi: yeah, you have &é"'(-è_çà in place of<PHONE_NUMBER>
[13:57] <ochosi> that is really wrong :)
[13:57] <knome> yes, that's totally wrong
[13:57] <knome> what if we just forget the french users?
[13:58] <mr_pouit> http://upload.wikimedia.org/wikipedia/commons/b/b9/KB_France.svg
[13:58] <ochosi> about the xfce-cherry-picking. i wanted to ask about the xfwm-tabwin-theming patch
[13:58] <mr_pouit> bah :<
[13:58] <knome> or add the shortcuts for those buttons too
[13:58] <knome> shift+& for gmb
[13:58] <mr_pouit> ochosi: yes, and that
[13:58] <knome> :X
[13:58] <ochosi> phu, we will never know in what other layouts that creates conflucts
[13:58] <knome> ochosi, well yeah but you know, the FRENCH
[13:58] <ochosi> :)
[13:58] <knome> let's just add the numbers
[13:59] <knome> and tell in release notes that they might not work for all layouts
[13:59] <ochosi> mr_pouit: ok, not sure there is much more to cherrypick. if we have a decent version of ristretto (anything above 0.1 should be ok) then that's all i originally intended
[14:00] <ochosi> mr_pouit: i mean the merged appfinder might be nice, cause i think that should work without updating other stuff, no?
[14:00] <ochosi> mr_pouit: but it depends on how much time you have, it's nothing of too much importance i guess
[14:00] <knome> LOL
[14:00] <knome> i typoed my vbox P machine name
[14:00] <knome> "knome-preciese-vbox"
[14:00] <knome> very precise indeed
[14:00] <ochosi> knome: i think the "ochosi to invest cherrypicking from upstream" can be closed in the meeting-agenda
[14:01] <knome> yeah, thanks
[14:01] <knome> i'll just not repost it in the next meeting then
[14:01] <ochosi> yup, that should be fine
[14:01] <ochosi> other than that, i'm afraid we might have to postpone the bluebird-port, now that i have greybird-bugs to fix :(
[14:02] <knome> i'm doing this only because this way, people don't forget their stuff
[14:02] <knome> and we can remind them
[14:02] <ochosi> yeah, makes sense
[14:02] <knome> meh for bluebird
[14:02] <ochosi> well, i'm the only one working on all of this, it's simply not enough time
[14:02] <ochosi> i didn't expect having to fix greybird-bugs at all
[14:02] <knome> i understand, and np :)
[14:03] <ochosi> mr_pouit: what's the deadline for having the greybird-bugs fixed?
[14:03] <mr_pouit> ochosi: I'll see what I can do (as xfrun4 was merged in it, it will conflict with xfce4-utils though)
[14:03] <mr_pouit> ochosi: final freeze, so plenty of time
[14:03] <ochosi> knome: maybe i can improve bluebird so far that it can be shipped with precise, even if it's not great. but no promises there...
[14:03] <knome> ochosi, i postponed your bb work item
[14:03] <ochosi> mr_pouit: ah, good to know.
[14:03] <knome> ochosi, if you get it done, great, then change the status to DONE
[14:04] <ochosi> knome: ok, let's do it this way. at least now the status is more accurate
[14:04] <knome> exactly
[14:04] <knome> and now i'm not worrying about it
[14:04] <ochosi> :)
[14:04] <knome> i only track the BLOCKED-TODO-INPROGESS -progress
[14:05] <ochosi> problem with bluebird is: i have to apply all those fixes i have to do for greybird now to bluebird as well :(
[14:05] <ochosi> which basically means rebasing it
[14:09] <mr_pouit> some work is needed for the icon theme too :)
[14:09] <mr_pouit> (wrt missing icons)
[14:12] <ochosi> mr_pouit: ah, true. mainly the category items are missing now, right?
[14:13] <ochosi> mr_pouit: i mean the keyboard-icons are already in git
[14:19] <mr_pouit> yeah
[14:20] <knome> hmm
[14:20] <knome> mr_pouit,
[14:20] <knome> when i write a message in thunderbird
[14:20] <knome> xubuntu is "misspelled"
[14:20] <GridCube> :P thats normal
[14:21] <knome> when i check the spelling, it suggests to replace it with "Kubuntu", "Ubuntu" or "Edubuntu"
[14:21] <GridCube> D: thats not
[14:21] <knome> how do we add "Xubuntu" to the correctly spelled list?
[14:22] <ochosi> hehe
[14:22] <ochosi> submit a bug in aspell? :)
[14:23] <knome> maybe...
[14:23] <knome> bbl
[14:23] <GridCube> aspell works with thunderbird? isnt it the firefox dictionary?
[15:22] <astraljava> News from the release people: DO NOT UPGRADE TODAY, if you have nVidia hardware. There is an issue between the recent libc and nVidia graphics drivers.
[15:22] <astraljava> More info at eleven. Err... https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/929384
[15:50] <knome> mr_pouit, so, are the shortcuts updated ? ;))
[16:01] <knome> 17:58  tejaswidp: Why are lex and yacc installed by default (along with flex and bison)? Are there applications which use these programs?
[16:02] <knome> mr_pouit, ^
[16:33] <mr_pouit> knome: yes, I'll commit/upload when I'm home
[16:39] <mr_pouit> knome: gthumb
[16:39] <mr_pouit>    * Add runtime dependency (as Recommends) on bison and flex,
[16:39] <mr_pouit>      needed by the webalbums plugin. They're Recommends because they
[16:39] <mr_pouit>      don't harm the core functionality of the program.
[16:40] <mr_pouit> I could demote them to suggests
[16:41] <mr_pouit> (but someone who uses gthumb regularly should confirm that these plugins aren't that useful)
[17:04] <knome> mm
[17:05] <knome> apparently they are for "webalbums"
[17:05] <knome> btw, is there a reason to keep seeding gthumb now that ristretto is fine?
[17:08] <mr_pouit> import from cameras?
[17:08] <mr_pouit> (and the plugin is for static webalbums, apparently there are different plugins for picasa, etc.)
[17:12] <knome>  hmm. isn't most cameras mounted to /media ?
[17:13] <ochosi> depends on what protocol they use
[17:13] <ochosi> but i dunno, i mean xubuntu never supported camera-management by default
[17:16] <mr_pouit> also, there's no use at all of pastebinit byd efault, really
[17:16] <mr_pouit> (if we start cleaning the seeds)
[17:17] <ochosi> +1 :)
[17:21] <mr_pouit> http://bazaar.launchpad.net/~xubuntu-dev/ubuntu-seeds/xubuntu.precise/view/head:/desktop#L89
[17:21] <mr_pouit> and the list of panel plugins installed by default could be cleaned/improved too (it hasn't changed for several years I think)
[17:22] <mr_pouit> (probably cpugraph/systemload/netload have some feature overlap)
[17:23] <ochosi> yeah, i agree on the plugins
[17:24] <ochosi> i think i've asked that a few times before, but vinagre by default?
[17:25] <mr_pouit> remote desktop :>
[17:25] <ochosi> yeah i know
[17:25] <ochosi> but really, i've _never_ used that
[17:25] <ochosi> i once tried, and it didn't work
[17:26] <ochosi> anyhoo, i propose we drop the mount-plugin and the free-space-checker
[17:26] <ochosi> i think that's fsguard, no?
[17:26] <ochosi> aasdf
[17:26] <ochosi> gah, sry
[17:27] <ochosi> i just tried the smartbookmark-plugin
[17:27] <ochosi> that one doesn't even work
[17:27] <mr_pouit> yeah, I propose to drop mailwatch and smartbookmark (too buggy)
[17:27] <ochosi> so those three i
[17:27] <ochosi> hm, mailwatch works ok actually
[17:27] <mr_pouit> we could add xkb-plugin by default, recent versions should have improved
[17:27] <ochosi> at least for my gf
[17:27] <mr_pouit> ok
[17:27] <ochosi> yeah, why not
[17:28] <ochosi> drop: fsguard,mount,smartbookmark
[17:28] <ochosi> add: xkb
[17:28] <ochosi> knome: ^
[17:28] <ochosi> i think that roughly makes sense
[17:28] <mr_pouit> drop: places too, I think
[17:28] <ochosi> yeah, it's still based on thunar-vfs, no?
[17:29] <mr_pouit> no, I included a patch from upstream bugzilla
[17:29] <ochosi> oh ok
[17:29] <ochosi> so it works ok again now?
[17:29] <knome> imo pastebinit is ~okay
[17:29] <mr_pouit> I'm not sure it's that tested/used in xubuntu, since we dropped it from the default panel layout though
[17:29] <ochosi> yeah, well pastebinit is a power-user thing. no "normal" user would ever use that
[17:29] <knome> ochosi, well, it helps when giving support @ #xubuntu
[17:30] <knome> "do 'pastebinit /eat/poop/you/cat'"
[17:30] <ochosi> mr_pouit: mounting etc seems to work in places
[17:30] <ochosi> that
[17:30] <ochosi> so that's nice
[17:30] <ochosi> bbl
[17:31] <knome> ok for me to drop vinagre
[17:31] <knome> i mean, it is clearly a power-user tool
[17:32] <knome> and for the panel plugin changes: OK
[17:32] <knome> going to buy some milk, quark and other stuff
[17:32] <knome> including some beer :P
[17:32] <ochosi> btw, parole has been unmaintained for quite a while now
[17:32] <knome> awwh
[17:32] <knome> i never liked it
[17:32] <ochosi> i talked to the others at fosdem, no-one wants to touch it
[17:32]  * knome hides
[17:33] <ochosi> so we might start to think about alternatives there
[17:33] <ochosi> maybe just use mplayer2? :)
[17:34] <knome> urr
[17:34] <knome> don't know
[17:34] <knome> maybe start by writing a wikipage of the alternatives
[17:35] <knome> and then doing some sort of quick comparison
[17:35] <knome> and discuss that at next meeting
[17:35] <ochosi> hm, maybe
[17:35] <ochosi> totem totally sucks in oneiric btw
[17:35] <knome> could get it changed for precise
[17:35] <ochosi> the icons are completely broken
[17:35] <knome> imo, most video players suck
[17:35] <knome> anyawy, i'm off to the store
[17:35] <knome> bbl
[17:35] <ochosi> m
[17:44] <nanotube> vlc
[18:19] <astraljava> gmb
[18:20] <ochosi> gmb doesn't play videos
[18:21] <micahg> totem is staying on 3.x due to unwanted dependencies for the LTS
[18:21] <micahg> err, 3.0.x
[18:21] <astraljava> Oh. I just thought people were throwing three-letter acronyms up in the air.
[18:21] <ochosi> micahg: is that the same version as in oneiric?
[18:22] <micahg> yes
[18:22] <ochosi> oh, then we're probably better off with parole as it is :)
[18:22] <micahg> parole works fine for me in precise
[18:23] <ochosi> yeah, it just has some serious design-issues imo
[18:58]  * knome is back
[20:53] <knome> somebody been testing the iso's ?
[20:53] <knome> i installed precise in vbox today and maybe-ubiquity looked okay
[20:54] <Unit193> Just synced up, but I hate maybe-ubiquity anyway
[20:54] <knome> :P
[20:54] <knome> get used to it
[20:55] <knome> but is it looking okay?
[20:55] <knome> somebody said it's purple, but i didn't see that
[20:55] <knome> maybe that's fixed?
[20:57] <Unit193> You can skip it if you set your video ram down, but I´m not supposed to do that :/
[20:57] <knome> hmm.
[20:57] <knome> i wonder if i missed it then.
[20:57] <knome> how low do you need to set the video ram?
[20:57] <knome> or, how much do you need to have to get the purple?
[20:59] <Unit193> 36 Seems to pick it up (IIRC)
[20:59] <knome> right
[20:59]  * knome checks
[21:02] <knome> no, in the "Try"/"Install" -screen, i don't have any purple - is that where it should appear?
[21:03] <mr_pouit> gmb 1.1.9 uploaded to precise
[21:03] <knome> mr_pouit, woohoo
[21:03] <micahg> quadrispro got to it first :)
[21:03] <mr_pouit> (that wasn't me)
[21:03] <mr_pouit> yeah
[21:08] <Unit193> 36 I don{t think got it, but 50 sure did. It is a black screen
[21:22] <mr_pouit> knome: new shortcuts committed to bzr (somebody can upload when there are more changes ready, or when he/she's bored)
[21:26] <knome> ha :)
[21:26] <knome> good
[21:26] <knome> and thanks :)
[21:26]  * knome has the 'bad elf' in glass
[23:28] <knome> ochosi, what's the status of the new elementary-fork? it doesn't seem to be in precise yet


[07:24] <arstanj> a
[09:21] <_0mk4r_> how to enable usb2.0 in linux? what is procedure to add a module?
[11:17] <croppa> if i have installed and used automatix2, can i use sudo apt-get cdrom with the edgy alt cd, then sudo apt-get update && sudo apt-get dist-upgrade
[11:18] <croppa> to upgrade dapper to edgy
[11:47] <nalioth> i just saw croppas question
[11:48] <nalioth> the answer (if he returns): if you use automatix, you're probably not gonna be able to upgrade very easily, if at all
[09:33] <nw> ll


[18:03] <jussi01> o/
[19:04] <jussi01> o/
[19:04] <topyli> o/
[19:04] <tsimpson> o/
[19:05] <jussi01> nhandler: ?
[19:05] <jussi01> tsimpson: you are chairing ;)
[19:05] <tsimpson> I guess...
[19:05] <tsimpson> if I can remember how to
[19:06] <tsimpson> #startmeeting
[19:06] <MootBot> Meeting started at 13:06. The chair is tsimpson.
[19:06] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[19:06] <tsimpson> [TOPIC] Discuss what the floodbots are and are not for, why operators should not become reliant on them
[19:06] <MootBot> New Topic:  Discuss what the floodbots are and are not for, why operators should not become reliant on them
[19:06] <jussi01> right. :)
[19:07] <tsimpson> so, this one is really just a "reminder" of what those bots are and are not
[19:07] <tsimpson> I'll probably send an email about this too, but here it goes
[19:07] <tsimpson> the FloodBots are not operators, they are just code with no common-sense
[19:08] <tsimpson> the operators in a channel with the bots should monitor the bots (and be in the monitor channel)
[19:08] <tsimpson> the bots may mute someone for flooding, but you still need to look out for repeat flooders/trolls
[19:09] <tsimpson> and when the bots ban someone on notice, one of the ops should really start a dialogue with the user to see if it was an error
[19:09] <jussi01> Yes, this definately needs to go to email.
[19:09] <jussi01> and probably be added to the op guidelines
[19:10] <tsimpson> basically, the bots are just tools and they do make mistakes, it's the job of the operators to monitor and correct their mistakes when necessary
[19:10] <topyli> agreed, operators must understand this
[19:11] <jussi01> ok, so shall we say bring it to the list and add to the guidelines?
[19:11] <tsimpson> yep, a quick email and something in the guidelines
[19:12] <jussi01> Ok, tsimpson are you going to do it then?
[19:12] <tsimpson> I'll send the email
[19:12] <topyli> tsimpson, maybe you should just say what you just said in mail and throw it to the wiki too
[19:12] <jussi01> should we have a vote here?
[19:12] <tsimpson> on the guidelines update, probably
[19:12] <jussi01> tsimpson: can you make a vote then ? :D
[19:13] <tsimpson> trying to phrase it properly
[19:13] <tsimpson> [VOTE] the operator guidelines should be updated to include information on the floodbots
[19:13] <MootBot> Please vote on:  the operator guidelines should be updated to include information on the floodbots.
[19:13] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[19:13] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[19:13] <tsimpson> +1
[19:13] <MootBot> +1 received from tsimpson. 1 for, 0 against. 0 have abstained. Count is now 1
[19:13] <jussi01> +1
[19:13] <MootBot> +1 received from jussi01. 2 for, 0 against. 0 have abstained. Count is now 2
[19:13] <topyli> +1
[19:13] <MootBot> +1 received from topyli. 3 for, 0 against. 0 have abstained. Count is now 3
[19:13] <jussi01> Excellent. :)
[19:14] <tsimpson> #endvote
[19:14] <jussi01> I wonder where nhandler is...
[19:14] <tsimpson> [endvote]
[19:14] <MootBot> Final result is 3 for, 0 against. 0 abstained. Total: 3
[19:14] <tsimpson> we have 3+, so...
[19:14] <topyli> jussi01, he did say he became uncertain if he'll be back in time from wherever he had to go
[19:14] <tsimpson> [AGREED] the operator guidelines should be updated with information regarding the floodbots
[19:14] <MootBot> AGREED received:  the operator guidelines should be updated with information regarding the floodbots
[19:15] <jussi01> topyli: ok
[19:15] <tsimpson> [AGREED] tsimpson to send an email to the mailing list with information on the floodbots
[19:15] <MootBot> AGREED received:  tsimpson to send an email to the mailing list with information on the floodbots
[19:15] <jussi01> Whats next?
[19:15] <topyli> the core thing
[19:15] <tsimpson> [TOPIC] Define what our core channels are and what makes a channel 'core'
[19:15] <MootBot> New Topic:  Define what our core channels are and what makes a channel 'core'
[19:16] <topyli> so i saw you guys having a good discussion earlier. the email discussion did not amount to an internet-wide debate
[19:16] <jussi01> [19:19:52] <tsimpson> I'm thinking something like: A core channel is defined as an official channel in one of the following categories: * Support for an official Ubuntu derivative; * Main development channel for an official Ubuntu derivative; * Main off-topic/discussion channel for an official Ubuntu derivative; * Official IRC management related channel; The IRCC have the final say as to if a channel is considered a "core channel" and may,
[19:16] <jussi01>  on occasion, add channels t
[19:16] <jussi01> [19:19:53] <tsimpson> o the list that do not fall into the above categories
[19:17] <jussi01> that is pretty close to what I think^^
[19:17] <topyli> i like what that amounts to. we pretty much have the list or core channels now, but we weed to formally define it. we also need the final say
[19:18] <tsimpson> this is what I got, a bit more refined: (flood)
[19:18] <tsimpson> A core channel is defined as an official channel in one of the following categories:
[19:18] <tsimpson>  * Support for an officially supported or officially recognised Ubuntu derivative
[19:18] <tsimpson>  * Main development channel for an officially supported or officially recognised Ubuntu derivative
[19:18] <tsimpson>  * Main off-topic/discussion channel for an officially supported or officially recognised Ubuntu derivative
[19:18] <tsimpson>  * Official IRC management related channel
[19:18] <tsimpson> The IRCC have the final say as to if a channel is considered a "core channel" and may, on occasion, add channels to the list that do not fall into the above categories.
[19:18] <jussi01> We would then need to add the mytbuntu and xubuntu and ubuntustudio devel chans.
[19:18] <Daviey> "The IRCC have the final say as to if a channel is considered a "core channel"" .. what if the channel doesn't *want* to be considered a core channel by the IRCC?
[19:19] <tsimpson> jussi01: that's what I changed it to "officially supported or officially recognised" as xubuntu is recognised
[19:20] <tsimpson> Daviey: why would they not?
[19:20] <ScottK> tsimpson: Does it matter?
[19:21] <topyli> Daviey, i can't see how a core channel can decide to not be core, say #ubuntu. the council must treat it as such
[19:21] <Daviey> tsimpson: it seems somewhat rude for the ircc to just say "it's ours"..without any promiseof discussion or even informing.. and because it's "final say", no grounds to say otherwise.
[19:21] <tsimpson> ScottK: only because I can't think of a reason why it would matter to them
[19:21] <ScottK> tsimpson: Perhaps not everyone is thrilled to have the IRCC take over their channels.
[19:22] <Daviey> tsimpson: #ubuntu-devel is an example of this.
[19:22] <tsimpson> ScottK: you assume the IRCC will take over anything
[19:23] <tsimpson> the IRCC is responsible for Ubuntu's IRC channels, why should we not decide if a channel is core?
[19:26] <jussi01> Daviey: This can be discussed and revised. However, we have been delegated the duty to sort this out, so we are doing this. We havent had any complaint from Ubuntu devel saying otherwise.
[19:26] <Daviey> hah, "we are doing this" .. why even have it in the meeting if it is already decided?
[19:26] <jussi01> Daviey: the meeting is part of doing this...
[19:27] <Daviey> jussi01: it seems it's already done.
[19:27] <topyli> we do need to decide on whether or not to create a definition based on the above musings. this should be done in a meeting
[19:28] <topyli> so let's
[19:28] <guntbert> Daviey: the point of a meeting is to have proposals and to discuss/accept/decline them ...
[19:28] <tsimpson> Daviey: why, specifically, would #ubuntu-devel object to being considered a core channel?
[19:28] <topyli> guntbert, we've provide plenty of time to give feedback and suggestions on the mailing list
[19:28] <topyli> provided
[19:29] <ScottK> tsimpson: What would that be fixing that's broken?
[19:29] <guntbert> topyli: agreed - I wasn't critizing the agenda :)
[19:29] <Daviey> tsimpson: from history, it already has
[19:29] <Tm_T> same
[19:30] <Tm_T> the definition should include " * A channel that IRCC is been asked to include and has decided to include" ?
[19:30] <Tm_T> ah, there
[19:30] <jussi01> Daviey: From my discussions with Colin, there hasnt been an issue. Is there something you would like to bring up?
[19:30] <Tm_T> Daviey: and falls into those defined categories?
[19:30] <Daviey> Tm_T: that solves my issue.
[19:30] <Tm_T> I think the additions outside of those categories needs to ask to be included, or IRCC cannot act
[19:30] <topyli> ScottK, the council has been unable to answer the simple question, "what is a core channel and how to become one?" and we felt that was a problem worth soslving
[19:31] <Daviey> jussi01: no.. i'm saying that from the past, it has been an issue.
[19:31] <Tm_T> Daviey: you mean additions there, not currently considered channels, right?
[19:31] <Tm_T> ScottK: take over?
[19:31] <jussi01> Daviey: and We have a new ircc since then, and things seem to be going fairly smoothly over there.
[19:32] <Tm_T> tsimpson: but if you decide what is core...
[19:32] <Daviey> jussi01: yes.. but the definition isn't limited to #ubuntu-devel
[19:32] <Tm_T> tsimpson: technically you could define it broad enough to contain all ubuntu channels (:
[19:32] <topyli> Tm_T, we define it, we don't make it so
[19:32] <tsimpson> Tm_T: that's why we are defining it here, so we have something to refer to
[19:32] <jussi01> Daviey: Is there an issue we should know about here? has something happened that we have missed?
[19:33] <Daviey> jussi01: no
[19:33] <Tm_T> I think the dialogue is needed when adding new channels yes, especially when they doesn't fall in one of those categories
[19:33] <Tm_T> but for current core channels, no new discussion round to be needed I think
[19:33] <ScottK> Some of you will recall that #kubuntu-devel did not initially react well to the arrival of the IRCC.
[19:34] <tsimpson> and we discussed the issues they had and came to a resolution
[19:35] <Daviey> but the changes which are being done, doesn't mandate a discussion
[19:35] <tsimpson> the main issue, as I recall, was that they thought the IRCC was taking over all management of the channel, which is not the case
[19:35] <Daviey> it's outlining "we own you, if we decide, and there is nothing you can do"
[19:35] <Tm_T> tsimpson: topyli: ye
[19:35] <jussi01> I think the idea here is that there will be core ops available across a certain set of channels. This was asked for by Mark. We understand that devel channels act differently to support channels, so there are 2 groups of core ops.
[19:36] <Tm_T> ScottK: true, mostly because it wasn't discussed beforehand, we are not changing anything for it
[19:36] <ScottK> Sounds like this core channel thing is more of the same.
[19:36] <ScottK> You are one and there's nothing you can do.
[19:36] <Tm_T> Daviey: being a core channel isn't about owning in my mind
[19:37] <topyli> Tm_T, we have called for discussion on the mailing list
[19:37] <topyli> mostly because very long debates are very convenient when the meeting is already on and we should decide
[19:37] <Tm_T> true
[19:38] <ScottK> Just keep in mind that 'the mailing list' only gets you a very narrow slice of the Ubuntu community involved in the discussion.
[19:39] <topyli> it gets the irc team, which is a good population for discussions such as this
[19:40] <ScottK> Just don't expect people not on the IRC team to automatically agree with what you've decided among yourselves.
[19:41] <topyli> all users of ubuntu irc channels are not expected to agree with us
[19:42] <jussi01> Ok, so to the task at hand. Are there any other issues with the idea tsimpson put up?
[19:44] <topyli> no. we can always refine the wording so it's nice and ambiguous, but i'm happy with it
[19:44] <Tm_T> same
[19:45] <tsimpson> so let's vote
[19:45] <tsimpson> [VOTE] add the definition of a "core channel" to the /IRC/IrcTeam/Scope wiki document
[19:45] <MootBot> Please vote on:  add the definition of a "core channel" to the /IRC/IrcTeam/Scope wiki document.
[19:45] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[19:45] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[19:45] <topyli> +1
[19:45] <MootBot> +1 received from topyli. 1 for, 0 against. 0 have abstained. Count is now 1
[19:46] <tsimpson> +1
[19:46] <MootBot> +1 received from tsimpson. 2 for, 0 against. 0 have abstained. Count is now 2
[19:46]  * tsimpson pokes jussi01
[19:46] <jussi01> sorry
[19:46] <jussi01> so thats core channel as specified above?
[19:46] <topyli> yep
[19:46] <jussi01> or just adding it in general?
[19:46] <jussi01> ok
[19:47] <tsimpson> yeah, it can always be modified later
[19:47] <jussi01> +1
[19:47] <MootBot> +1 received from jussi01. 3 for, 0 against. 0 have abstained. Count is now 3
[19:47] <tsimpson> [endvote]
[19:47] <MootBot> Final result is 3 for, 0 against. 0 abstained. Total: 3
[19:47] <tsimpson> [AGREED] add the definition of a "core channel" to the /IRC/IrcTeam/Scope wiki document
[19:47] <MootBot> AGREED received:  add the definition of a "core channel" to the /IRC/IrcTeam/Scope wiki document
[19:48] <jussi01> Just want to say, for Daviey and ScottK and others, Please dont hesitate to bring things up you want to see changed - even if they are written on the wiki. its not a stone wiki :D We promise to have a look at the situation and listen to things that are vbrought up.
[19:48] <tsimpson> I think that's it, unless anyone has any other (short) issues?
[19:48] <jussi01> We may not agree, but we can talk about it.
[19:49] <topyli> shall we action that to someone, or will we fight about it later?
[19:50] <tsimpson> @random jussi01 tsimpson topyli
[19:50] <tsimpson> I guess it's you :)
[19:50] <topyli> brilliang :)
[19:50] <tsimpson> if that's it then, I'll end the meeting
[19:50] <topyli> fair enough, i'll add it. as is, and we go polish as needed
[19:50] <jussi01> thats it from me
[19:51] <tsimpson> #endmeeting
[19:51] <MootBot> Meeting finished at 13:51.
[19:51] <topyli> oh one more thing
[19:51] <topyli> not really of course :)
[19:52] <jussi01> tsimpson: remember to do the minutes and stuff.
[19:52] <Tm_T> thanks tsimpson and others


[00:05] <hatch> huwshimi so besides the var things code review ok?
[00:06] <huwshimi> hatch: I don't really know. I mean there's code there, it does some stuff. I'm not sure I know enough to be reviewing branches like this.
[00:07] <hatch> ahh ok
[00:08] <hatch> huwshimi can you respond with QA OK and then I'll land it, if there are some code issues that others don't like we can fix them in a follow-up
[00:09] <hatch> I just don't want to get held up as there are more changes to be made in this section
[00:12] <huwshimi> hatch: Left a note
[00:12] <hatch> lol, nice passive agressive comment
[00:12] <hatch> if you would like you could fire an email off to design :)
[00:14] <huwshimi> hatch: I'm not sure about landing this without a proper code review though. I can't see if Kyle did one either
[00:15] <rick_h__> huwshimi: hatch what do you need?
[00:15] <rick_h__> hatch: I can do one in the morning before you start if required
[00:15] <hatch> huwshimi ok that's fine if you're not comfortable
[00:15] <rick_h__> no calls until 10 yay!
[00:16] <hatch> rick_h__ that would be awesome thanks
[00:16] <rick_h__> hatch: ok, I've got it on my morning todo.
[00:16] <rick_h__> too shut down to look right now sorry
[00:16] <rick_h__> thanks for looking huw
[00:17] <hatch> np it's well past EOD :)
[00:17] <hatch> rick_h__ https://github.com/juju/juju-gui/pull/437 then https://github.com/juju/juju-gui/pull/439 is branched from it
[00:17] <rick_h__> hatch: rgr
[00:18] <hatch> and now I'm also done :)
[00:18] <rick_h__> night hatch
[00:18] <hatch> night rick_h__ huwshimi
[00:18] <rick_h__> go find your watch :P
[00:18] <hatch> lol
[00:18] <hatch> right!
[08:00] <rogpeppe> urulama: morning!
[08:11] <urulama> rogpeppe: morning
[08:11] <rogpeppe> urulama: how're you feeling today?
[08:12] <urulama> rogpeppe: better, at least i feel hungry now :D
[08:12] <rogpeppe> urulama: always a good sign...
[08:12] <rogpeppe> urulama: do you fancy pairing on moving the charm store apiHandler stuff forward?
[08:13] <urulama> sure. give me 10min to grab something to eat
[08:13] <rogpeppe> urulama: np
[08:42] <urulama> rogpeppe: sorry, that breakfast didn't land well :S
[08:43] <rogpeppe> urulama: oh dear :-\
[08:43] <urulama> rogpeppe: yeah, fats to soon ... nevermind, it'll pass ...
[08:43] <urulama> rogpeppe: gogogo?
[08:43] <rogpeppe> urulama: if you'd prefer to go back to bed, or not interact much, that's fine
[08:43] <rogpeppe> urulama: yup, i'm there
[10:44]  * urulama lunches
[11:27] <rick_h__> morning all
[11:27] <rick_h__> rogpeppe: have you followed the license thread?
[11:27] <rogpeppe> rick_h__: i have
[11:27] <rogpeppe> rick_h__: (g'morning, BTW)
[11:27] <rick_h__> rogpeppe: can you please make sure all our repos, charmstore, charm, etc are ok on that front please?
[11:28] <rick_h__> rogpeppe: it looked like the agreement was lgpl with exception?
[11:28] <rick_h__> for outside libs
[11:28] <rogpeppe> rick_h__: yes
[11:28] <rogpeppe> rick_h__: charmstore is fine
[11:28] <rogpeppe> rick_h__: charm should probably be LGPL but is currently AGPL
[11:29] <rick_h__> ah, since it was pulled from core which is agpl?
[11:30] <rogpeppe> rick_h__: yes
[11:30] <rogpeppe> rick_h__: but it could easily be changed to LGPL
[11:30] <rick_h__> ok
[11:30] <rogpeppe> rick_h__: (with a possible caveat of whether LGPL is compatible with the apache 2 license)
[12:03] <rick_h__> moving to the coffee shop, biab
[12:06] <bac> hola
[12:20] <rick_h__> morning bac
[12:22] <bac> how was swim lessons?  i remember enjoying them until they tried to make us go off the high dive.  didn't go back.
[12:23] <rick_h__> heh, due to scheduling fun we had to go private lessons this round and the boy is loving the personal attention
[12:24] <rick_h__> show off "I can swim under water" and he just throws himself into the lake
[12:24] <rick_h__> then comes up with half the lake being swallowed
[12:24] <rick_h__> but it's fun, hard to not get eager for him to do real swimming so we can trust him to be more indenpendent at water parks/etc
[12:26] <urulama> i need to change place, "feels" too crowdy at home today :D
[12:27] <rick_h__> urulama: yea, coffee shops ftw
[12:28] <urulama> rick_h__: i actually have access to place with net and everything on the other side of town, near woods and more important, no kids singing and dancing around :D
[12:29] <rick_h__> urulama: sounds like a winner
[13:01] <jrwren> morning.
[13:01] <rick_h__> morning jrwren
[13:53] <rick_h__> hatch: sorry, I'm behind on your reviews. Been a busy morning
[13:53] <rick_h__> hatch: looking now and will try to get done asap
[13:53] <hatch> np thx
[14:12] <rick_h__> hatch: one round of comments in
[14:13] <hatch> thx will check
[14:13] <rick_h__> hatch: going to wait on the second one until the diff is one vs both
[14:15] <hatch> ok I'm going to have to fix the markup to enable enter submissions as it uses multiple form elements
[14:15] <hatch> atm you can submit the constraints form, the unit count form, etc which doesn't make any sense
[14:16] <rick_h__> hatch: ah, yea that's ungood. To the user it's all the same form
[14:17] <hatch> I'm guessing huw did that on purpose so I wonder what surprises await me in doing that
[14:17]  * rick_h__ heads back home, coffee shop is getting crowded.
[14:17] <rick_h__> hatch: heh, well that's fine to do it as a follow up
[14:17] <rick_h__> hatch: but your current branch can land without the block
[14:17] <hatch> without the block?
[14:17] <rick_h__> hatch: but take a stab at it, if you end up in css hell, create a card and punt it
[14:18] <rick_h__> without the block on the enter key
[14:18] <rick_h__> saying "if you use the enter key it doesn't work predictably" is a follow on bug/card
[14:18] <hatch> well not really - they can submit the constraints form
[14:18] <hatch> so it falls apart if they hit enter on that
[14:18] <hatch> I'll take a stab, see where it ends up
[14:32] <bac> hi abentley
[14:32] <abentley> bac: otp
[14:33] <bac> abentley: ok, please ping me when you have a few minutes free
[14:55] <hatch> jujugui call in 5
[14:58] <rick_h__> jujugui call in 1 and go
[14:59] <rick_h__> or now ish
[14:59] <rogpeppe> jujugui: hmm, i'm getting "Couldn't start the video call because of an error"
[14:59] <urulama> rick_h__: same here
[14:59] <rick_h__> rogpeppe: urulama another browser?
[15:00] <rick_h__> kadams54: ^
[15:00] <rogpeppe> i'll try incognito
[15:00] <rick_h__> bac: ^
[15:01] <bac> trying
[15:03] <rogpeppe> that didn't work
[15:03] <urulama> me neither
[15:03] <rogpeppe> unfortunately i don't have another browser installed currently
[15:03] <urulama> tried firefox and chrome
[15:03] <urulama> (and safari /me runs away)
[15:04] <rogpeppe> urulama: our previous session seems to have tainted both of us...
[15:04] <urulama> i get the "due to the number of participants ..." error
[15:04] <rogpeppe> i don't get that
[15:04] <rogpeppe> it lets me in (apparently) and then gives me the error
[15:05] <rogpeppe> jujugui: sorry guys
[15:05] <urulama> yes, same here ... see who is there but not able to join :(
[15:06] <rick_h__> sounds like it hates EU folks :/
[15:06] <rick_h__> everyone else is here
[15:06] <rogpeppe> rick_h__: for the record, the "store: start version api responses" card is making good progress. urulama and i should have something to show very soon
[15:07] <rogpeppe> urulama: can you still join gogogo?
[15:07] <urulama> rogpeppe: yes
[15:07] <urulama> rogpeppe: no
[15:07] <urulama> :S
[15:07] <rogpeppe> urulama: i thought it was working for me too...
[15:07] <rogpeppe> urulama: and then not
[15:07] <rogpeppe> urulama: bugger
[15:08] <urulama> rogpeppe: maybe google blocked us due to the usage today :D :D
[15:08] <rogpeppe> urulama: hmm
[15:09] <urulama> rogpeppe: let's give it 10min and retry
[15:09] <rogpeppe> urulama: yeah
[15:11] <rick_h__> rogpeppe: urulama k, reported. Nothing big from the team. I've got a vet appt and will be afk some this afternoon, but that's post your EOD so no worried on your end
[15:12] <jcsackett> rick_h__: re the tagging notion--are we going to be on the hook to do that as proper tagging? e.g. a charm can have multiple tags, and a search should be able to do multiple tags?
[15:12] <jrwren> In go, I know we follow gofmt. do we have style guidelines beyond that?  e.g. prefer multiline string to string with embedded \n after a certain number of newlines?
[15:13] <jcsackett> jrwren: in python, flake8 is your style bible.
[15:13] <jrwren> yes, I flake8 in python.
[15:13] <jcsackett> that's about it, afaik.
[15:13] <jrwren> ok.
[15:13] <jcsackett> and for js in the gui, i have no idea what our style rules are--i just fix what the linter screams at me about. :P
[15:14] <jcsackett> seems to be working so far. :P
[15:15] <rick_h__> jrwren: there's a pull request in juju core for style guide
[15:15] <rick_h__> jrwren: take a peek and see if you can find it in current or recently closed pull requests in /juju/juju
[15:15] <rick_h__> jcsackett: it'll be just like categories now, a list of string. And yes, we'll index those and allow searching on that filter
[15:15] <jcsackett> rick_h__: cool.
[15:15] <urulama> rick_h__: ok, good luck at the vet, maybe see you later
[15:16] <rick_h__> urulama: sure thing, I think we should chat in a bit. just cathing up
[15:16] <urulama> rick_h__: ok, ping when you come back, otherwise, first thing in the morning?
[15:17] <rick_h__> urulama: yep
[15:18] <rick_h__> jrwren: https://github.com/juju/juju/tree/master/doc/contribution
[15:18] <jrwren> thanks rick_h__
[15:19] <rick_h__> np, it's a WIP but something we should get familiar with and support across projects. rogpeppe urulama ^ as well
[15:19] <rick_h__> bac: Makyo ^
[15:19] <urulama> rick_h__: checking
[15:20] <rogpeppe> jrwren: also, this is well worth reading: https://code.google.com/p/go-wiki/wiki/CodeReviewComments
[15:21] <rogpeppe> jrwren: and in general, the go stdlib is very well written and idomatically designed - if it does something a particular way, it's usually a good way to do it
[15:22] <jrwren> Great to know.
[15:22] <rogpeppe> jrwren: there's also this: https://github.com/golang/lint
[15:23]  * urulama brb
[15:23] <jrwren> oooh, golint, lots of messages. I like it.
[15:24] <bac> rick_h__: got a sec? http://<IP_ADDRESS>:8080/job/charmworld-autoland/165/console  -- search for "Selec+" ... it seems the console output abruptly halted, not capturing the actual problem
[15:24] <bac> not a one off
[15:24] <rick_h__> bac: looking
[15:26] <rick_h__> bac: hmm, yea. It was still installing deps and then failed. Mabye a netork issue?
[15:27] <bac> perhaps.  i'll look to see if it failed at the same point previously
[15:27] <rick_h__> network, the jenkins-launchpad-plugin? Maybe a missing dep?
[15:27] <rick_h__> from the download cache?
[15:27] <rick_h__> bac: I'd look at a normal fresh run and see what package it's grabbing after the python-lazr and see if something is up with fetching it?
[15:27] <bac> ok
[15:31] <urulama> rogpeppe: still no gogogog :(
[15:31] <rick_h__> urulama: rogpeppe I'm going to setup a call for the morning. Hopefully the hangouts issues work out by then
[15:31] <urulama> rick_h__: ok
[15:31] <hatch> rick_h__ moving that form stuff is causing issues, I'll land my two branches then do it as a follow-up right away, will be muuuch easier when I don't have to worry about conflicts from my next branch
[15:31] <rogpeppe> urulama: yeah, i'm still having the same problems
[15:31] <rick_h__> hatch: rgr
[15:33] <rogpeppe> urulama: this is what splitId is looking like now, BTW: http://paste.ubuntu.com/7803979/
[15:34] <urulama> rogpeppe: ok, this is muuuch better then the clutter before :D
[15:35] <urulama> rogpeppe: but we do "parse" it twice, right (with the Charm.parse) call?
[15:36] <rogpeppe> urulama: sure. but the first parsing is very lightweight. i doubt it'll take more than a small number of ns
[15:37] <hatch> rick_h__ ok while these things land I'm just going to pick off another bug card from the pile
[15:38] <rick_h__> hatch: rgr
[15:39]  * rick_h__ goes to get some lunch
[15:39] <urulama> rogpeppe: yes, i was just thinking in a way, that this splitId could be part of Charm, so that it is always in sync to all
[15:39] <rogpeppe> urulama: that's a good idea
[15:40] <rogpeppe> urulama: i guess you'd probably want to make the knownSeries an argument to it then
[15:41] <urulama> rogpeppe: that part i don't like :D (but have no alternative atm)
[15:41] <urulama> (as agreed before)
[15:41] <rogpeppe> urulama: yeah, i'm not keen either. i'm tempted to just leave this logic in the charm store for the time being, as we don't really want other people doing the same thing
[15:41] <urulama> rogpeppe: +1
[15:42] <rogpeppe> urulama: after all, we do double-check that the final URL parses ok
[15:42] <rogpeppe> urulama: so if charm urls change, then our tests will break immediately
[15:56] <jrwren> rogpeppe: https://github.com/juju/charm/pull/19 look good?
[15:57] <rogpeppe> jrwren: LGTM
[15:57] <jrwren> ty.
[15:57] <jrwren> now I can bug rick_h__ for moar! :)
[15:58] <rick_h__> ruh roh
[15:58]  * rick_h__ pulls up the board of work item doom
[16:00] <rick_h__> jrwren: side task, can you git pull origin develop from the ci slave machine in the /var/lib/jenkins/jenkins-github-lander directory?
[16:01] <jrwren> oh, to get changes there?  sure.
[16:01] <rick_h__> jrwren: yea, catch it up to latest src
[16:09] <jrwren> I can't status the ci-environment :(    http://pastebin.ubuntu.com/7804136/
[16:10] <rick_h__> jrwren: there's been a bug going around on that, /me looks
[16:11] <rick_h__> jrwren: https://bugs.launchpad.net/juju-core/+bug/1307434
[16:11] <_mup_> Bug #1307434: talking to mongo can fail with "TCP i/o timeout" <cloud-installer> <landscape> <performance> <reliability> <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1307434>
[16:11] <rick_h__> restarting the state server seems to have helped?
[16:12] <rick_h__> jrwren: marked as in progress
[16:12] <rick_h__> jrwren: did you get access to azure?
[16:12] <rick_h__> jrwren: or need me to do the bouncing?
[16:12] <jrwren> i don't have access to the web portal. I could probably use azure cmdline tools to do it.
[16:12] <jrwren> that might be a good exercise for me :)
[16:14] <rick_h__> jrwren: will reboot it here, one sec
[16:16] <rick_h__> jrwren: give it a shot?
[16:17] <jrwren> thanks.
[16:19] <hatch> thanks to all the hard work jcsackett  put into the changes in rendering the inspector my current branch is super trivial to implement :) yay jcsackett
[16:19] <rick_h__> woot yay jcsackett :)
[16:20] <jrwren> rick_h__: just trusty-slave or other slaves too?
[16:20] <rick_h__> jrwren: I can't recall which I updated, please check all three
[16:20] <rick_h__> jenkins machines
[16:22] <hatch> rick_h__ hey I just wanted to point this bug out that my branch will create - I'm not sure what priority you want to put it at https://bugs.launchpad.net/juju-gui/+bug/1342809
[16:22] <_mup_> Bug #1342809: Inspector tabs should route the url <juju-gui:New> <https://launchpad.net/bugs/1342809>
[16:23] <rick_h__> hatch: they can't route because it's too hard to figure out inspector tab vs details/browser tabs
[16:23] <rick_h__> hatch: and we've prioritized the charm details over inspector tabs
[16:24] <hatch> I'm not sure I understand, I don't see why they both can't work?
[16:25] <hatch> http://<IP_ADDRESS>:8888/inspector/wordpress/charm/tab/relations/:flags:/mv/ seems to work just fine
[16:27] <hatch> oh I see a bug in it... showTab() closes the breakout
[16:27] <hatch> so you can't have a tab navigate and the breakout visible
[16:28] <hatch> I'm pretty sure that's the viewlet slot issue and not a routing issue though
[16:30] <bac> rick_h__: the jenkins issues was due to it running out of disk while doing an install inside the lxc, so the error message got swallowed.  cleaned up some old lxc directories and trying again.
[16:30] <bac> s/issues/issue/
[16:30] <rick_h__> bac: ah!
[16:31] <rick_h__> hatch: looking, sorry. in my head tabs in the inspector would be just like the browser as #tabname
[16:31] <rick_h__> and so we have two namespaces living in the one propery
[16:32] <rick_h__> hatch: but it looks like I'm mistaken and the inspector tab is part of the root url?
[16:32] <hatch> it is now :)
[16:32] <rick_h__> hatch: hangout?
[16:32] <hatch> sure
[16:32] <hatch> trying to join the standup one
[16:49] <hatch> rick_h__ does your watch disconnect from the phone a lot? This one dc's like every hour then you have to turn the phone on and hit the button to reconnect
[16:50] <rick_h__> hatch: no, it's been really good
[16:50] <rick_h__> hatch: does your phone do BT LE, 4.0 I think?
[16:50] <hatch> yep, running the latest android and everything - all power saving options turned off
[16:50] <hatch> I can't even find anyone complaining online so this might be an isolated incident
[17:02] <hatch> rick_h__ https://github.com/juju/juju-gui/pull/439 is ready for review - sidenote: I had to pull it down and rebase develop into it to remove the old commits, I kind of assumed the Pr would do that automatically
[17:04] <rick_h__> hatch: rgr, loading
[17:07] <urulama> jujugui night all
[17:07] <rick_h__> urulama: have a good evening
[17:15] <rick_h__> hatch: can I ask you about non machine view uses?
[17:15] <hatch> pourquoi?
[17:15] <rick_h__> qa without :flags:/mv
[17:16] <hatch> oh...
[17:16] <hatch> hmm
[17:16] <rick_h__> it seems to be wanting a bit now
[17:16] <hatch> heh
[17:16] <hatch> ok I guess my removal branch can't land?
[17:16] <rick_h__> not at this time.
[17:17] <hatch> hmm
[17:17] <rick_h__> it can make sure you only get the new UX in MV, but without the flag is still important for 3wks
[17:17] <rick_h__> well, 2 we'll call it
[17:18] <hatch> hmm ok I think I can use those new flag css classes to hide it with mv
[17:18] <hatch> I'll leave this branch for reference, close the PR, and create a new one to hide the old stuff under mv
[17:18] <rick_h__> hatch: k, so I this branch will be a bit diff to land
[17:18] <rick_h__> hatch: ok, sounds good thanks
[17:18] <rick_h__> sorry for the blockage there :/
[17:19] <hatch> s'ok there will be some conflicts in the future but the majority of the code will still be usable so definitely want to keep it around
[17:19] <rick_h__> k
[17:20] <rick_h__> jujugui, just a reminder to QA both with and without the feature flag.
[17:30] <hatch> rick_h__ can you comment about the non mv stuff on #439 PR?
[17:43] <hatch> jujugui looking for a quick review/qa on https://github.com/juju/juju-gui/pull/440
[17:43] <kadams54> hatch: checking
[17:43] <hatch> th
[17:43] <hatch> x
[17:44] <kadams54> welcom
[17:44] <kadams54> e
[17:47] <hatch> :
[17:47] <hatch> P
[17:53] <hatch> LOL airbnb's new logo
[17:53] <hatch> clearly they didn't run that one past the internet lewd machine first
[17:58] <hatch> arosales hey did you see the ghost charm is now promulgated?
[18:29] <hatch> jujugui looking for a review/qa on https://github.com/juju/juju-gui/pull/441
[18:29] <hatch> really trivial css change
[18:30] <hatch> kadams54 did you get lost on #440? The diff isn't that big ;)
[18:33] <kadams54> hatch: sorry, had an important phone call come in.
[18:34] <hatch> those are the worst - getting in the way of the daily activities
[18:35] <kadams54> hatch: all done with review and QA.
[18:35] <hatch> thanks! Can I sucker you into doing #441 too?
[18:35] <hatch> it's really really small :)
[18:35] <kadams54> To make up for it, I'll check out your trivial CSS change.
[18:35] <kadams54> Hah!
[18:35] <kadams54> Great minds.
[18:35] <hatch> lol
[18:40] <kadams54> Trivial thing I just noticed: we don't have proper pluralization in the new scale up UI or in the unit list below… "1 units" and "1 running units".
[18:40] <kadams54> Not in the scope of your work though
[18:41] <rick_h__> it's a simple helper, add it real quick :P
[18:41] <kadams54> OK, #441 is ready to ship
[18:41] <rick_h__> we're getting bad about not catching drive by stuff with that plural stuff. It's getting wrong all over
[18:45] <hatch> kadams54 thanks, I'll add that pluralization in the follow-up
[18:52] <hatch> http://blog.atom.io/2014/07/02/moving-atom-to-react.html
[18:52] <rick_h__> kadams54: how goes your branch?
[18:53] <hatch> it says they are using jquery...I really have no idea what for when they control the environment it operates in
[18:54] <rick_h__> kadams54: I'm heading to the vet, but I'd like to get another set of eyes on your WIP to help move the card of work through. hatch or Makyo can one of you take a peek and see how you can help please?
[18:54] <hatch> sure
[18:54] <hatch> kadams54 what's he talking about?
[18:54] <hatch> ;)
[18:55]  * rick_h__ goes to get the dog poked
[19:01] <bac> yay, my favorite test case now works: https://jujucharms.com/?text=ouch
[19:04] <jcsackett> kadams54: are you leaving friday morning from london?
[19:07] <hatch> jcsackett I am
[19:07] <hatch> well...friday noon i think
[19:08] <hatch> iunno it's in the spreadsheet heh
[19:08] <jcsackett> hatch: i'm pinging kadams54 b/c i think he is on the same flight as me, and mine got modified--i'm leaving the 26th, but the sheet says the 25th. i would imagine kyle is in the same boat, unless he really is leaving friday AM.
[19:08] <hatch> ohhh
[19:09] <jcsackett> yeah, i just emailed sarah to sort it, but kadams54 might need to do the same.
[19:10] <kadams54> jcsackett: Uh oh, yeah, that wouldn't be good
[19:10] <jcsackett> kadams54: you're in the same boat, then?
[19:10] <kadams54> jcsackett: I haven't seen any e-mails about changes yet.
[19:10] <jcsackett> kadams54: are you leaving sat or fri?
[19:10] <kadams54> Last I knew, Friday
[19:11] <jcsackett> kadams54: ok, so you're fine. that's what it says for you. we're both DL-19, just on different days.
[19:11] <kadams54> DL0019, leaving at 9:35 AM
[19:12] <jcsackett> cool, figured there was a chance we were both on the same flight, rather than just flight num, and yours had been goofed too.
[19:12] <kadams54> hatch, Makyo: I'll have a PR shortly for you to look at on that branch.
[19:12] <jcsackett> but it's just the same flight, so i'm the only one goofed. :P
[19:12] <jcsackett> er, flight no. anyway.
[19:20] <kadams54> jcsackett: I'll try not to trash the plane too much on my flight then :-)
[19:20] <jcsackett> kadams54: i would appreciate that. :p
[19:44] <kadams54> guihelp: is there a reason /:flags:/mv/ is 404ing for me on comingsoon?
[19:45] <hatch> bac ^ comingsoon isn't dispatching paths to the guiserver
[19:46] <hatch> kadams54 ^ the app is supposed to be handling the urls but the server isn't passing them through
[19:48] <bac> hatch: ungood
[19:48] <hatch> that's your fault right?
[19:48] <hatch> :)
[19:48] <bac> hatch: yes, it was my mid-afternoon time bomb
[19:48] <hatch> lol
[19:48] <hatch> bac is it something you can take a look at or should someone else?
[19:50] <bac> hatch: i'm looking.
[19:51] <hatch> thank yas!
[19:54] <bac> hatch: [client <IP_ADDRESS>] File does not exist: /var/www/juju-gui/build-prod/:flags:
[19:54] <hatch> bac right, but why is it now thinking that that's a file?
[19:55] <hatch> http://comingsoon.jujucharms.com/machine also fails for example
[19:55] <bac> so apache is attempting to
[19:55] <hatch> bac it should be passing anything that's not in the juju-ui path to the GUI
[19:55] <bac> serve it instead of having the app do it
[19:55] <hatch> yeah...did someone break the charm?
[19:55] <bac> charm or apache config?
[19:56] <hatch> doesn't the charm contain the apache config?
[19:56] <hatch> heh
[19:56] <bac> not charm.  this isn't installed via  charm
[19:56] <hatch> ohhh
[19:56] <bac> it were hand-rolled by me
[19:56] <hatch> I thought this was the charm which was just updated every time
[19:56] <bac> has anyone tried :flags: in the last week or so?
[19:57] <hatch> I thought I used it yesterday tbh
[19:57] <hatch> maybe it was monday?
[19:57] <bac> this config hasn't changed since the 10th
[19:59] <hatch> hmm, well then...
[19:59] <hatch> maybe I didn't use a flag or direct url
[19:59] <hatch> sorry I can't be of more help
[19:59] <hatch> I could look at the config though if you want
[20:02] <bac> hatch: http://bazaar.launchpad.net/~juju-gui-charmers/charms/trusty/juju-gui/trunk/view/head:/config/apache-site.template
[20:02] <bac> that's what the charm does
[20:03] <bac> i didn't think to copy the charm and just manually created an apache config from the nginx config we used on the old site
[20:03] <bac> hatch: FallbackResource looks interesting
[20:03] <hatch> I was just going to say that might be the trick, I was just looking it up heh
[20:04] <hatch> yep that does look like what we need
[20:04] <hatch> wow it's been a long time since I've had to read an apache config
[20:04] <bac> ha
[20:04] <hatch> brings me back to the good ol days of multiple client PHP work on the same server
[20:04] <hatch> oy
[20:05] <hatch> "directive all the things!"
[20:11] <bac> thanks hatch.  kadams54 http://comingsoon.jujucharms.com/:flags:/mv/ works
[20:11] <kadams54> bac: thanks
[20:11] <hatch> bac thanks for doing that so quick! u rock
[20:11] <bac> np
[20:25] <kadams54> Makyo, hatch: WIP PR at https://github.com/juju/juju-gui/pull/442
[20:25] <Makyo> Looking
[20:26] <kadams54> Makyo, hatch: I also ran into something that may have invalidated work today. Need to talk to someone about the supportedContainers attribute on machines.
[20:29] <hatch> oh?
[20:29] <hatch> what's the issue?
[20:34] <rick_h__> and the dog has a high temp right before I leave for a trip. Go pets!
[20:36] <hatch> poor puppy
[20:37] <kadams54> hatch: got a few minutes to chat?
[20:37] <hatch> sure 1min just got to relocate to somewhere cooler
[20:38] <kadams54> You're in Canada already.
[20:38] <hatch> it's like 20c out there...way to hot ;) ( rick_h__ )
[20:39] <hatch> kadams54 ok joining the standup room
[20:44] <jrwren> today, bundles don't have ability to run services on existing machine, does it?
[20:44] <jrwren> I know this is coming as part of charm store api
[20:46] <hatch> jrwren correct
[20:46] <hatch> bundles are just a yaml file
[20:46] <hatch> actually
[20:46] <hatch> that's a deployer file
[20:46] <hatch> :)
[20:46] <hatch> go conflated terminology!
[20:46] <jrwren> a yaml file with no to: machine node :)
[20:49] <jrwren> oh THAT juju-deployer!
[20:49] <jrwren> thanks hatch
[20:49] <hatch> kadams54 your branch will conflict with Makyo's that just landed
[20:50] <kadams54> hatch: Got it.
[20:50] <hatch> jrwren lol np, don't worry it's confusing to people who have been working with it for a long time :)
[20:50] <hatch> the deployer will be moving into juju-core at some point
[20:52] <jcsackett> jujugui: can someone review https://github.com/juju/juju-gui/pull/443 for me?
[20:52] <hatch> yup
[20:52] <hatch> I can
[20:53] <jcsackett> thanks hatch.
[20:53] <Makyo> Totally spaced out lunch.  Sorry kadams54, didn't mean to go awol
[20:53] <kadams54> Makyo: np
[20:53] <hatch> psshhht Colorado.....
[20:53] <kadams54> lol
[20:53] <Makyo> What? D:
[20:55] <hatch> "sorry bro I like..................totally space out.............what was I doing again?.........."
[20:55] <Makyo> Pff.  I just meant I got hungry and realized how late it was :P
[20:56] <hatch> lol suuuure
[20:56] <hatch> ;) ;)
[21:02] <jcsackett> hatch: you've got to get a new joke about colorado.
[21:03] <hatch> "what are you 50 and run in bare feet??"
[21:03] <hatch> how's that?
[21:04] <hatch> that's all the stereotypes I know about CO :P
[21:04] <hatch> jcsackett comments made - maybe if you want to check them out before I do a qa
[21:04] <jcsackett> hatch: looking into switching to a truthier way of doing things now.
[21:05] <jcsackett> changes should be up in a sec.
[21:05] <hatch> cool thanks
[21:05] <jcsackett> hatch: the only "not major" change we've got spec for is containers, unless there's a bug i don't know about.
[21:06] <hatch> jcsackett right, I mean, the rule is that only things that cost money are in the top right?
[21:06] <hatch> config changes don't involve $ changes
[21:06] <jcsackett> hatch: this whole rule is new to me, and like i said, only containers have been mentioned to me.
[21:06] <jcsackett> we can add config if we're told to put config in.
[21:06] <jcsackett> but until that's marching orders, i don't think we should expand this scope.
[21:06] <hatch> ok that's cool - want to reply to that in the PR?
[21:06] <jcsackett> already did.
[21:07] <hatch> :) thanks
[21:07] <hatch> lemme know when changes are up and I'll pull it down for qa
[21:11] <jcsackett> hatch: sure thing. hit one weird thing having changed to truthy
[22:10] <jcsackett> hatch: finally pushed up. had a surprising amount of fallout from badly structured tests.
[22:10] <hatch> ahh, well then!
[22:10] <jcsackett> well, badly is a bit strong--but brittle, anyway. :)
[22:10] <hatch> thanks I'll take a look
[22:10] <hatch> :)
[22:11] <jcsackett> cool. i'm off to get stuff for dinner. if you run into anything QA bad i'll have to deal with it tomorrow morning, otherwise i'll rebase and :shipit: when i return if you qa ok.
[22:12] <hatch> sounds like a plan
[22:12] <hatch> cya
[22:12] <jcsackett> lata
[22:58] <hatch> jcsackett looks good +1, I have some issues with the UI but I sent an email off to design about them
[22:58] <huwshimi> Morning
[23:04] <hatch> mooooooorning
[23:05] <hatch> tonight I'm going to try and convince myself web components make sense
[23:06] <huwshimi> Yay!
[23:08] <hatch> so far it's just seamed like they are going to become the next jquery plugin mess
[23:08] <hatch> but maybe....just maybe I'll find an example which makes sense heh
[23:10] <huwshimi> hatch: What are you looking at exactly?
[23:11] <hatch> huwshimi polymer/web components
[23:12] <hatch> there are still going to end up being 200 different modal dialogue web components each adding different frameworks to the page, each with different css, aria support etc etc etc
[23:13] <hatch> so I'm really not sure how it's going to get us further ahead than we already are right now
[23:13] <hatch> I'm still not going to take some calendar web component which adds jquery to the page and include it in our app for example
[23:14] <hatch> and it moves the configuration into the DOM essentially making html xml :)
[23:18] <huwshimi> yeah, it definitely has an xslt thing going on.
[23:18] <hatch> for people making web pages it's probably really awesome
[23:18] <hatch> web apps...not so much
[23:18] <hatch> at least that's where I'm at now :)


[19:28] <Atamira> morning
[19:29] <Atamira> what a damn awesome day here in auckland
[19:29] <Atamira> just awesome
[19:29] <ibeardslee> morning
[19:30] <Atamira> much damage down your way ibeardslee ?
[19:35] <ibeardslee> not for me, I imagine there are a few people trying to get in touch with builders, arbourists etc
[19:53] <snail> morning
[19:53] <snail> 4.5 hours of powercut yesterday in johnsonville
[19:53]  * ibeardslee didn't get that
[19:53] <ibeardslee> although there was plenty of flickering
[20:25] <ajmitch> morning
[20:39] <mwhudson> morning
[21:19] <hads> Lightning is impressive; http://www.stuff.co.nz/timaru-herald/news/9154831/Historic-oak-torn-apart-by-lightning
[21:19] <hads> morning
[21:35] <ibeardslee> wow
[21:49] <snail> hads: what's impressive is how few electrical components get fried in serious electrical stroms
[21:50] <snail> especially since we didn't pull a GB and change our system after WWII
[21:52] <olly> morning
[21:55] <snail> morning
[22:03] <thumper> morning
[23:20] <kcj> Morning.


[06:37] <tsimonq2> cjwatson: @launchpadstatus' Twitter bio says that you can subscribe to updates by email but Launchpad-announce hasn't been posted to for three or four years now. What's up with that?
[13:03] <cjwatson> tsimonq2: Often not the first thing we reach for, but I've posted to it now about this (twice due to a typo :-/)
[19:04] <sergio-br22> hi
[19:04] <sergio-br22> did something happen to the PPA build farm?
[19:05] <wxl> sergio-br22: yep. see topic.
[19:05] <sergio-br22> ahh
[19:05] <sergio-br22> thanks
[19:05] <wxl> np :/


[14:26] <frankban> uiteam I need two reviews for https://codereview.appspot.com/195690043 (quickstart/python)
[14:26] <frankban> thanks!
[14:36] <hatch> on it frankban
[14:37] <frankban> hatch: thanks
[14:37] <frankban> hatch: have you seen my email re juju connect stuff?
[14:38] <hatch> not yet
[14:38] <hatch> i will
[15:34] <hatch> frankban: review and qa done
[15:34] <hatch> looks good
[15:35] <hatch> frankban: I am interested to know why you wrapped those two methods?
[16:26] <hatch> frankban: so why did you wrap those functions in a functools.wrap decorator? can you not return a function in python normally?
[16:28] <frankban> hatch: functools.wrap preserves the original name and documentation of the decorated function
[16:29] <hatch> frankban: ahh
[16:31] <frankban> hatch: FYI those values are stored in func.__name__ and func.__doc__
[16:39] <hatch> interesting that those aren't included by default
[17:12] <hatch> any idea why the gui charm needs firefox in its sysdeps?
[17:16]  * hatch cry's "I just want to run the linter"
[17:16] <mbruzek> hatch ping
[17:16] <hatch> sup
[17:17] <hatch> uiteam, anyone know why I wouldn't have the correct version of pip for the guicharm linter?
[17:17] <frankban> hatch: firefox is required by functional tests using selenium
[17:17] <frankban> hatch: not sure if I understand your second question
[17:18] <hatch> # Ensure the correct version of pip has been installed
[17:18] <hatch> tests/.venv/bin/pip --version | grep "pip 1.[4-9]" || exit 1
[17:18] <hatch> make: *** [setup] Error 1
[17:18] <hatch> ^ frankban
[17:18] <mbruzek> hatch: I am trying to figure out the charm store uris
[17:18] <frankban> hatch: what pip version do you have?
[17:18] <hatch> 1.5.4
[17:19] <hatch> pip 1.5.4 from /usr/lib/python2.7/dist-packages (python 2.7)
[17:19] <mbruzek> hatch: Kapil has a launchpad url lp:~hazmat/charms/bundles/kubernetes/bundle
[17:19]  * hazmat ears are ringing
[17:19] <frankban> hatch: tests/.venv/bin/pip --version
[17:19] <mbruzek> hatch: and quickstart maps to that  juju quickstart bundle:~hazmat/kubernetes/kubernetes
[17:19] <mbruzek> hello haz
[17:20] <mbruzek> hello hazmat
[17:20] <hazmat> greetings
[17:20] <hatch> frankban: ummm 6.0.7?
[17:20] <frankban> hatch: really?
[17:20] <hatch> mbruzek: if you want to deploy a bundle using quickstart or the depployer then you'll have to use the old yaml format
[17:20] <mbruzek> hatch: trying to figure out how quickstart maps bundle:~hazmat/kubernetes/kubernetes to lp:~hazmat/charms/bundles/kuberentes/bundles
[17:21] <hatch> pip 6.0.7 from ......../develop-trunk/tests/.venv/local/lib/python2.7/site-packages (python 2.7)
[17:21] <hatch> mbruzek: it guesses
[17:21] <hazmat> mbruzek: on lp distro is charms, series is bundle is the nutshell
[17:21] <mbruzek> hatch trying to figure out the mapping so I can write readmes for other bundles
[17:21] <frankban> hatch: I am rebuilding the devenv for the char, and checking again
[17:22] <hatch> mbruzek: all of that is changing soon - makyo_ is working on updating the deployer to support the new syntax
[17:23] <hazmat> hatch: thats not url syntax is it? i thought it was mostly just syntatic incompatible format changes
[17:23] <hazmat> in the bundle itself
[17:23] <mbruzek> hatch So I am writing a readme for how quickstart works now.  I just want to know what format will work with our bundle here:  p:~kubernetes/charms/trusty/kubernetes-bundle/trunk
[17:23] <hatch> no the url changed as well
[17:23] <hatch> mbruzek: if you want to use that you'll have to point to the old yaml file directly
[17:24] <hatch> the new bundle yaml format is not supported by the deployer
[17:24] <mbruzek> hatch: I don't want to point to that url, I like the bundle: uri, I just need to know how it works.
[17:24] <frankban> mbruzek: quickstart still uses the old charmworld for bundles, and the supported syntax is described in quickstart --help
[17:24] <mbruzek> frankban: thank you.  Will read up on that
[17:24] <hatch> for some reason the deployer wasn't updated before the bundle syntax was
[17:24] <frankban> mbruzek: it will be updated soon to support the new bundle URLs
[17:25] <hatch> frankban: why do we want to use such an old version of pip? 5 major versions older?
[17:27] <mbruzek> hatch: frankban: I see the help text now, it seems that quickstart supports 5 formats.  Which one would you recommend?  I see things are changing, what would be the format that would be recommended that works now and in to the future?
[17:27] <hatch> I think those two are mutually exclusive :)
[17:27] <mbruzek> doh
[17:28] <hatch> juju quickstart bundle:mediawiki/single
[17:28] <hatch> we want this format to work
[17:28] <hatch> but currently it doesn't
[17:29] <frankban> hatch: I think in the future we want "juju quickstart bundle/mediawiki-single"
[17:29] <frankban> mbruzek: ^^^
[17:29] <hatch> oh jeeze that's a new format to me
[17:29] <mbruzek> hatch: frankban:  Our bundle currently lives here:  lp:~kubernetes/charms/trusty/kubernetes-bundle/trunk
[17:29] <hatch> I think I'll just write code - give up on what format is what lol
[17:29] <frankban> hatch: in the new charm store, the "bundle" string is not a schema, is a series
[17:29] <mbruzek> It is not yet promulgated.  Is that in a wrong spot?  Should we change that?
[17:31] <frankban> hatch: it seems that pip quickly switched from version 1.5.6 to 6.0 :-|
[17:31] <hatch> lol
[17:31] <frankban> hatch: so yes that check should be changed, feel free to do that as part of your branch
[17:31] <hatch> frankban: what was it there for?
[17:32] <hatch> There must be a reason why we checked at all
[17:32] <frankban> hatch: I did not add that code, so not sure, perhaps some backward incompatible changes with previous pip versions
[17:32] <hatch> so think I can just remove the check entirely?
[17:34] <frankban> hatch: I'd suggest to keep the check, just make it more permissive
[17:34] <hatch> so just greater than 1.4?
[17:34] <frankban> hatch: +1
[17:51] <hatch> frankban: do you know of a way to structure the grep for that? I am having a heck of a time nesting the conditionals in the makefile
[17:52] <hatch> ifndef apparently doesn't work for me
[17:52] <hatch> oh makefiles
[17:54] <frankban> hatch: grep -E "pip (1.[4-9]|6)" ?
[17:55] <hatch> negative, tried that :)
[17:56] <hatch> here is what I am attempting to do in the makefile (and failing) https://gist.github.com/hatched/83544f1c201ee1a71a6e
[17:56] <hatch> for some reason ifndef is not found?
[18:00] <frankban> hatch: what I suggested works here
[18:00] <frankban> % echo "pip 6.3" | grep -E "pip (1.[4-9]|6)"                                                                                (trunk) ubuntu
[18:00] <frankban> pip 6.3
[18:01] <hatch> yeah it works from the echo but not in practice
[18:15] <hatch>  tests/.venv/bin/pip --version | grep -E '1\.[4-9]\.|6\.[0-9]\.[0-9]' || exit 1
[18:15] <hatch> bleh lol
[18:17] <mbruzek> hatch: I tried to deploy using quickstart using a raw html bundle, but none of the charm store charms showed up.  I ran this with --debug and the pastebin is here. http://paste.ubuntu.com/10076915/  Can you help me
[18:17] <mbruzek> ?
[18:18] <hatch> looking
[18:18] <hatch> what was the command you used?
[18:19] <hatch> btw thanks for writing these docs :)
[18:25] <hatch> mbruzek: still there?
[18:25] <mbruzek> yes
[18:25] <hatch> what was the command you used?
[18:25] <mbruzek> juju quickstart https://raw.githubusercontent.com/whitmo/bundle-kubernetes/master/bundles.yaml --debug 2>&1 | tee quickstart_problem.txt
[18:26] <mbruzek> The bundle is legit, it works with deployer and references Charm store uris
[18:26] <mbruzek> I am trying to figure out why none of the charms are loaded
[18:29] <hatch> hmm yeah you're right it looks good
[18:29] <frankban> mbruzek: quickstart states that the bundle deployment request has been accepted
[18:29] <mbruzek> fankban I can show you the juju status that tells me otherwise
[18:29] <mbruzek> or the gui if you don't believe status
[18:29]  * mbruzek *grins*
[18:29] <hatch> mbruzek: have you tried deploying those services directly?
[18:29] <frankban> mbruzek: what's the content of https://<IP_ADDRESS>/gui-server-info
[18:29] <frankban> ?
[18:30] <mbruzek> {"uptime": 3435, "deployer": [{"Status": "started", "Queue": 0, "DeploymentId": 0, "Time":<PHONE_NUMBER>}, {"Status": "scheduled", "Queue": 1, "DeploymentId": 1, "Time":<PHONE_NUMBER>}, {"Status": "scheduled", "Queue": 2, "DeploymentId": 2, "Time":<PHONE_NUMBER>}, {"Status": "scheduled", "Queue": 3, "DeploymentId": 3, "Time":<PHONE_NUMBER>}], "apiversion": "go", "sandbox": false, "version": "0.4.2", "debug": false, "apiurl": "wss://<IP_ADDRESS>:17070"}
[18:31] <frankban> mbruzek: so you have pending bundle deployments in the queue, they are executed in order
[18:31] <mbruzek> frankban: I guess I tried this bundle several times now.
[18:31] <mbruzek> I can destroy and start over again, but I don't think I would get a different result.
[18:32] <mbruzek> hatch: I have deployed this bundle through juju-deployer when have the bundle on my local machine.
[18:32] <frankban> mbruzek: let's check the guiserver logs: they are stored in the gui unit in /var/log/upstart/guiserver.log
[18:33] <mbruzek> on machine 1?
[18:33] <frankban> mbruzek: wherever the gui unit is placed: juju ssh juju-gui/0
[18:34] <mbruzek> frankban: OK found it, is that safe to pastebin?  It does not show my keys or other stuff?
[18:35] <frankban> mbruzek: I think so, but let's use the canonical pastebin
[18:40] <mbruzek> frankban: working on it
[18:40] <frankban> mbruzek: ty
[18:45] <mbruzek> frankban: had to paste it by hand, no upload feature on pastebin.canonical.com
[18:45] <mbruzek> https://pastebin.canonical.com/125051/
[18:49] <frankban> mbruzek: uhm... I don't see any errors in the logs. it seems that the deployer is still working on your first bundle as usual, except it's not deploying anything
[18:50] <frankban> mbruzek: you can try, from that machine, "sudo service guiserver restart", then "juju set juju-gui builtin-server-logging=debug" and then try to deploy the bundle again (once) and see if the logs show something
[18:50] <mbruzek> I see a python exception in queues.py is that nothing?
[18:53] <frankban> mbruzek: not sure if that's related to the bundle deployment
[18:54] <frankban> mbruzek: but it's well over my EOD now and I have to go, so could you please try what I described and file a bug against the GUI charm with the info attached?
[18:55] <mbruzek> will do,  thanks for your assistance frankban.
[18:55] <mbruzek> Have a good day
[18:55] <mbruzek> night
[18:55] <frankban> night and ty
[20:31] <hatch> uiteam do we know which branch I should push my guicharm changes to? lp:charms/trusty/juju-gui  or  lp:~juju-gui/charms/trusty/juju-gui/trunk
[20:31] <hatch> and by push I mean propose
[20:46] <hatch> uiteam lf a review for a smallish diff https://code.launchpad.net/~hatch/charms/trusty/juju-gui/add-uuid-configjs/+merge/248826
[22:22] <rick_h_> hatch: juju-gui/charms/trusty/juju-gui/trunk
[22:23] <hatch> oh hai!
[22:23] <hatch> yeah I have it up for review
[22:23] <hatch> :)
[22:24] <rick_h_> ah cool
[22:25] <hatch> tornado is bonkers
[22:25] <hatch> just so you  know :P
[22:25] <rick_h_> :)
[22:25] <rick_h_> async python ftw
[22:25] <rick_h_> hatch: just think of it like nodejs
[22:25] <hatch> ehh I'm still thinking an async language might be better :)
[22:26] <hatch> makyo_ and I are going to have to get schooled by frankban tomorrow :)
[22:27] <rick_h_> heh, docs aren't bad
[22:27] <hatch> nah it's just trying to find the correct spot to put things in the guiserver is the issue
[22:27] <rick_h_> gotcha
[22:28] <hatch> having a yeild in the middle of a function then never returning to it really threw me for a loop
[22:32] <huwshimi> Morning
[22:32] <hatch> morning huwshimi
[22:32] <rick_h_> morn
[22:32] <hatch> I fixed some of the rendering performance issues in leankit by modifying their stylesheets :)
[22:33] <hatch> there are cascading shadows and transparencies so it's no wonder you get screen tearing on slower machines
[22:43] <hatch> I found this cool site that shows benchmark comparisons for various languages. http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=dart&lang2=go


[13:10] <mup> Bug #1777443 opened: Got 500 http error when using MAAS Api <MAAS:New> <https://launchpad.net/bugs/1777443>
[18:46] <PatrickD_> Hi, trying to get MAAS HA working, with SSL. But it looks like the address is converted to ipv6 and used in the URL (https://[::ffff:<IP_ADDRESS>]/MAAS/) which fails because the cert is not valid. Any idea ?
[18:48] <roaksoax> PatrickD_: https://docs.maas.io/2.4/en/installconfig-network-ssl
[18:51] <PatrickD_> yes, I did that. But when accessing the interface, rackd tries to connect to the API using https://[ipv6]/MAAS/rpc and fails the cert check.
[18:51] <roaksoax> PatrickD_: what's maas_url on rackd.conf ?
[18:52] <PatrickD_> https://domain.name/MAAS
[18:53] <roaksoax> PatrickD_: that's probably because domain.name is resolving to the IPv6?
[18:54] <PatrickD_> no it doesn't. It resolves to ipv4 only. in rpc/clusterservice.py it looks like it transfers the name to IP (v6). ~line 1043
[18:56] <roaksoax> PatrickD_: does the region have any IPv6 address ?
[18:57] <PatrickD_> link local
[18:57] <PatrickD_> no, only loopback
[18:59] <roaksoax> PatrickD_: oh so maas uses: [::ffff:<IP_ADDRESS>]
[18:59] <roaksoax> PatrickD_: that's fine
[18:59] <roaksoax> PatrickD_: that's expected
[18:59] <roaksoax> that doesn't mean we are using ipv6, but for maas to support Ipv6 we need to do that
[19:00] <PatrickD_> So how it is supposed to check the cert validity using https://[::::ffff:<IP_ADDRESS>]/MAAS/rpc ?
[19:01] <roaksoax> PatrickD_: you are welcome to file a bug on that, although, we currently only support ssl for front-facing users and not inter-controller communication
[19:01] <roaksoax> PatrickD_: but please do file abug
[19:04] <PatrickD_> Ah, I see :) Makes sense now. We will file a bug. It means we will need 2 IPs for API. 1 for inter-controller and 1 for front-facing, with redirection of 80 to 443.
[19:10] <roaksoax> PatrickD_: yeah, so for inter-rack communication it would seem we would just have to use the domain instead of changing as you described
[19:12] <PatrickD_> We will file the bug tomorrow :) Thanks for your help ! (And thanks for MAAS too ;)


[08:19] <Rhonda> http://archive.ubuntu.com/ubuntu/project/ doesn't seem to get updated with the current keyring file, has that moved?
[08:20] <Rhonda> (tried to create me some chroots and noticed that it only works for xenial with that file)
[08:27] <Unit193> FWIW, ubuntu-archive-keyring is a package in Debian.
[08:28] <Rhonda> That would be cheating.  (darn, you're obviously right)
[08:28] <Unit193> Someone even put the cloud and dbgsym keys in there.


[02:20] <tsimonq2> balloons: About the Ubutnu Font Testing I have seen in the MLs, how can I be of assistance? I run Lubuntu Xenial.
[02:23] <balloons> You should have the font then. Give things a work
[02:23] <balloons> whirl*
[02:23] <tsimonq2> balloons: uhh what exactly should I be doing?
[02:23] <tsimonq2> :)
[02:24] <tsimonq2> and how do I make sure I am using the new one?
[02:24]  * tsimonq2 wishes there were test cases so he didn't have to bother balloons :P
[14:09] <balloons> It should be on the wiki. I guess it's not and that's why you are asking questions?
[16:42] <flocculant> balloons: given that there's been no apparent change in ubuntu font version - I'll just carry on pinning the old version until the bugs I reported get fixed
[16:43] <flocculant> seems a bit daft for them to ask you to ask people to test things if bugs reported when it changed don't get fixed first *shrug*
[16:43] <balloons> flocculant, yes, no new updates. I just never really mentioned it's existance to people
[16:44] <flocculant> ok - then bug 1520772 and bug 1525150 :)
[16:44] <balloons> you were one of like a handful of people who ever gave feedback. They are really really looking for Arabic and non-western feedback as they have the biggest changes. But the font stuff happens differently, so it'll be a bit before we see another update
[16:44] <flocculant> yea I assumed as much
[16:45] <flocculant> I know it's meh so pinned it :D
[16:45] <balloons> You can blame me for not getting more eyeballs on it sooner, heh
[16:45] <flocculant> ha ha ha
[16:48] <flocculant> balloons: posted to the qa list re the bugs I saw mid-Dec with that font
[16:48] <balloons> yes, I remember
[16:49] <balloons> it landed just after thanksgiving, and I knew about it early dec
[16:49] <balloons> well.. everything was in place early dev
[16:49] <flocculant> weirdest one I saw was it refusing to let me use ubuntu light - forced thin on me
[16:50] <flocculant> anyway now it's on the qa list we can see if we get more eyes
[22:37] <flocculant> balloons: so I found something that needs to be addressed somehow - nothing broken, kind of wishlisty
[22:38] <flocculant> if a bug becomes invalid - still shows in tracker, if we have a 'half good' test result listing that invalid bug an admin can remove the bug from the result
[22:39] <flocculant> but if someone has written 'sum stuff' and reported that invalid one - but not actually reported the issue which remains - admin fiddling about makes it a good result
[22:40] <flocculant> perhaps - looking at how useful gold was for fixed - make an invalid bug icon black ?
[22:40] <flocculant> thoughts on that last point?
[22:44] <tsimonq2> +1 flocculant
[22:47] <flocculant> I always +1 flocculant
[22:47] <flocculant> works for me
[22:50] <tsimonq2> lol