[12:16] <gabe> :) thanks :)
[12:16] <mdke_> long journey?
[12:16] <gabe> mmm convoluted, I'd say
[12:17] <gabe> had a little trouble with the old daily builds of feisty
[12:19] <gabe> now, I was hoping that you would be able to give me a little direction. Actually, I wanted to get my mother involved in the documentation effort because she is great at proof reading things. Problem is: do I have to teach here how to use subversion?
[12:19] <gabe> *teach her how to use*
[12:19] <mdke_> no, certainly not
[12:19] <gabe> that's a relief
[12:19] <mdke_> our work in progress documentation is hosted at http://doc.ubuntu.com
[12:19] <gabe> yes...
[12:20] <mdke_> she can just read through and you can point her to the bug filing page, or she can email us
[12:20] <gabe> I was just going to say that I'd followed all kinds of links from there
[12:20] <gabe> thing is, I really think should could make some useful contribution, but getting her to use subversion would be something of a nightmare
[12:21] <gabe> OK, I see
[12:21] <gabe> just to make it crystal clear: I get her to read the documentation at doc.ubuntu.com, particularly  the stuff on the right-hand side
[12:22] <gabe> and when she finds things she thinks need correcting she should...?
[12:23] <mdke_> file a bug or email our mailing list
[12:23] <mdke_> preferably the former, but the latter if the former is too difficult
[12:24] <gabe> ok, and could you give me the address for bug reporting, please
[12:28] <mdke_> https://launchpad.net/ubuntu-doc/+bugs
[12:29] <gabe> aha, thank you
[12:29] <gabe> just one last thing
[12:31] <gabe> what kind of things do you want reported exactly?   I did get my mum to read some pages of this and she pointed out several punction errors. Such as improper use of ":" and ";" etc. Do you care about these, or should she ignore them?
[12:32] <LaserJock> I think those are nice, I personally want stuff to be as polished as possible
[12:32] <LaserJock> but it's nice to sort of so more than one at a time
[12:32] <LaserJock> *do
[12:33] <mdke_> yes, any errors
[12:33] <gabe> LaserJock: you mean report multiple errors in a single bug report?
[12:33] <mdke_> however, be aware that there are lots of different rules for punctuation
[12:33] <mdke_> what is wrong in British English is not necessarily wrong in American English, and vice versa
[12:33] <gabe> mmmm
[12:34] <gabe> mdke_: and which does Ubuntu Doc favour?
[12:34] <mdke_> http://doc.ubuntu.com/ubuntu/styleguide/en/styleguide-grammar.html
[12:34] <gabe> :)
[12:34] <mdke_> american
[12:34] <LaserJock> \o/
[12:34] <mdke_> there are probably lots of failures to comply with our guide though, so pointing those out will be helpful
[12:35] <LaserJock> mdke_: ok, so I believe with the current setup, no docs from edubuntu-docs show up in the Yelp frontpage
[12:36] <LaserJock> mdke_: if you do a search they show up pretty well
[12:36] <mdke_> yes, that's right
[12:36] <LaserJock> now, how is that frontpage determined? is there code involved?
[12:37] <mdke_> yes, it's currently hardcoded
[12:37] <LaserJock> I was wondering if you could do some sort of "if edubuntu-docs; then ...."
[12:37] <mdke_> my idea would be to determine the list according to what is installed in scrollkeeper
[12:37] <mdke_> but Don has not yet got back to me
[12:37] <LaserJock> hardcoded in the yelp source?
[12:37] <mdke_> yes, in Yelp
[12:38] <LaserJock> well, it looks pretty decent as is though
[12:38] <LaserJock> before they were all jumbled together
[12:38] <mdke_> I have the following plan
[12:39] <mdke_> (a) wait for Don to get back, chase him more
[12:39] <mdke_> (b) try and do it myself, see how it goes
[12:39] <mdke_> (c) resign to defeat but think, "hey, it's still better than Edgy"
[12:40] <mdke_> worst case scenario isn't that bad, but hopefully we can do (a) or (b)
[12:40] <LaserJock> well, I think (c) isn't tragic, so that's cool
[12:40] <mdke_> we'll see. (c) would mean doing it without fail in the next release
[12:40] <LaserJock> is it toc.xml?
[12:40] <gabe> could I just ask, what is the easiest way to write docbook? Is there a WSYIWYG editor, or do most ppl just use something like gedit?
[12:40] <mdke_> toc.xml.in, among other files
[12:41] <mdke_> gabe: there isn't a very good wysiwyg editor
[12:41] <mdke_> I use gedit myself
[12:41] <mdke_> I'm off to bed
[12:41] <LaserJock> cya mdke_
[12:41] <gabe> g'night
[12:42] <gabe> LaserJock: do you know if it's hard to get going with subversion?
[12:43] <LaserJock> gabe: I found it pretty easy myself
[12:43] <LaserJock> gabe: our usage is very basic
[12:43] <LaserJock> for subversion
[12:43] <gabe> ah did you follow some instructions for it?
[12:44] <LaserJock> http://people.ubuntu.com/~ogra/rsyncer.sh
[12:44] <LaserJock> doh, that's wrong
[12:45] <LaserJock> https://wiki.ubuntu.com/DocumentationTeam/Repository
[12:45] <LaserJock> gabe: that one ^^
[12:45] <gabe> ok, thanks, I'm looking at it now
[12:45] <gabe> ahh yes, very informative
[12:46] <gabe> I was wondering, I would like to contribute to Ubuntu myself. I am useless at programming, but good with writing. Do you know if there is some documentation I could help to write?
[12:47] <LaserJock> there's always lots of things
[12:48] <LaserJock> the help wiki is a good place to get started
[12:48] <LaserJock> help.ubuntu.com/community/
[12:48] <gabe> mmmm
[12:48] <gabe> I don't quite understand something
[12:48] <gabe> if I can use svn to get the documentation then I can alter it. How does that then get processed in to the proper documentation?
[12:49] <LaserJock> well, you send a patch (you get that from svn diff) and we'll apply it to the repo
[12:50] <gabe> ahh this sounds good
[12:50] <LaserJock> then it gets periodically built into the ubuntu-docs package
[12:50] <gabe> does one submit a patch using svn?
[12:50] <LaserJock> no
[12:50] <LaserJock> you create the patch via svn then send it to the mailing list
[12:50] <gabe> and the patch would be an entire xml document?
[12:51] <LaserJock> once you've shown you know what you're doing and want to continue working with the team you can get svn write access
[12:51] <gabe> LaserJock: sounds good
[12:51] <LaserJock> gabe: it looks something like https://lists.ubuntu.com/archives/ubuntu-doc-commits/2007-March/003409.html
[12:51] <gabe> LaserJock: does the project need any help in translating to Chinese, as I may be able to assist with that also?
[12:52] <LaserJock> there is always a need for translation
[12:52] <LaserJock> translation in Ubuntu is done via Rosetta on Launchpad
[12:52] <gabe> ok
[12:53] <gabe> something else for me to look in to
[12:53] <gabe> but I'm beginning to see the bigger picture with this svn stuff etc
[12:53] <CIA-4> Ubuntu Documentation: nixternal * r3895 kubuntu/hardware/C/hardware.xml: kubuntu hardware section complete - ready for review
[12:54] <LaserJock> the svn is just for docs shipped on the CD
[12:54] <LaserJock> the doc team also has the help wiki with loads more stuff
[12:54] <gabe> i see
[12:55] <gabe> and how is the wiki updated and changed? Does that need special write permission also?
[12:55] <LaserJock> nope
[12:55] <LaserJock> in fact, anybody with a Launchpad account can edit it
[12:55] <gabe> ahhh
[12:55] <gabe> this might be a perfect way to start my mum off
[12:56] <gabe> it means she can read an entire document and make necessary improvements herself
[12:56] <LaserJock> https://translations.launchpad.net/ubuntu/feisty/+translations
[12:56] <gabe> and it has a kind of built-in WSIWYG
[12:59] <gabe> i don't quite understand...
[12:59] <gabe> the translations on rosetta are translations of just one or two words, perhaps just one sentence - is that right?
[01:01] <LaserJock> yep
[01:01] <LaserJock> it's broken up into thousands of chuncks
[01:01] <gabe> yes
[01:01] <LaserJock> *chunks
[01:01] <gabe> but surely that would give poor translations
[01:01] <gabe> it loses context
[01:02] <LaserJock> gabe: that can be a problem yes
[01:02] <gabe> mmm
[01:02] <LaserJock> I honestly don't know anything about the translations
[01:02] <LaserJock> I'm just a poor unilingual American
[01:03] <gabe> LaserJock: that's ok :)
[01:03] <gabe> but do you know how I find a translation that needs doing? All that I look at already have translations
[01:04] <LaserJock> I think you have to look at the status bars
[01:05] <gabe> ahh umm
[01:05] <gabe> purple means...
[01:05] <gabe> green means...
[01:05] <LaserJock> I think there is a #ubuntu-translators channel
[01:05] <LaserJock> they would probably know
[01:05] <LaserJock> I'm just clueless
[01:05] <gabe> aha thanks a lot anyway
[01:05] <gabe> you've helped me so much
[01:07] <LaserJock> no problem
[01:07] <LaserJock> thanks for dropping by
[01:07] <LaserJock> and tell your mum we look forward to seeing her work ;-)
[01:07] <gabe> hehe I will!
[01:07] <gabe> do you also think it's best if she starts with the wiki?
[01:17] <LaserJock> perhaps
[01:17] <LaserJock> the only thing is the wiki is more dynamic
[01:18] <LaserJock> so she might make some minor changes and then have the blown away when somebody changes it around
[01:18] <LaserJock> so for proofreading, in general I think it's better to go with the svn docs
[01:20] <gabe> oh i see
[01:21] <gabe> LaserJock: is there some instructions on how to send patches to the mail list?
[01:24] <LaserJock> gabe: it should be on that wiki page I gave you  DocumentationTeam/Repository
[01:24] <gabe> right
[01:24] <gabe> ok
[01:24] <gabe> thanks a lot
[01:24] <gabe> looking forward to getting started
[01:25] <gabe> only thing is I must learn it all myself first so I can teach ol' ma :)
[01:26] <LaserJock> :-)
[01:31] <nixternal> big transfer
[01:31] <nixternal> I hope CIA doesn't list everyone
[01:32] <LaserJock> muwahahaha
[01:32] <Admiral_Chicago> richard, got time for a question?
[01:32] <nixternal> nope
[01:32] <nixternal> ;p
[01:32] <nixternal> what is it
[01:33] <Admiral_Chicago> okay, so I want to get emails about the changes to any MozillaTeam pages. How can I subscribe that way on the wiki page
[01:33] <nixternal> Transmitting file data .......................................................................
[01:33] <nixternal> you know it is a biggen if it is doing that :)
[01:33] <Admiral_Chicago> I tried MozillaTeam* but that doesn't do it.
[01:33] <nixternal> I think you go to your personal settings on the wiki
[01:33] <nixternal> and then do MozillaTeam/.*
[01:33] <Admiral_Chicago> ah /.*
[01:33] <Admiral_Chicago> okay
[01:34] <nixternal> learn your regex
[01:34] <Admiral_Chicago> regex?
[01:34] <nixternal> #@)*#@
[01:34] <LaserJock> works for shells, should work for wiki pages
[01:34] <nixternal> hehe
[01:34] <LaserJock> Admiral_Chicago: regular expression
[01:34] <Admiral_Chicago> yea, thats why I tried the *
[01:34] <nixternal> sed -e 's/.*: //'
[01:35] <nixternal> oh man, I don't think this is going to be good
[01:35] <CIA-4> Ubuntu Documentation: nixternal * r3896 kubuntu/ (259 files in 3 dirs): cleaning up images (old) and adding k3b.png
[01:35] <nixternal> whew
[01:35] <nixternal> just a lil line, thank goodness
[01:35] <Admiral_Chicago> LaserJock: i know what regular expressions are, not the portmanteau
[01:36] <nixternal> regex == regular expressions
[01:36] <Admiral_Chicago> to be fair, I have been working on getting my *nix skills up (why do RPGs come to mind...)
[01:36] <Admiral_Chicago> i've been trying to level up my *nix ability.
[01:38] <nixternal> I have been trying for years
[02:59] <CIA-4> Ubuntu Documentation: nixternal * r3897 kubuntu/ (libs/kde-menus-C.ent musicvideophotos/C/musicvideophotos.xml): multimedia doc complete - ready for review - added new menu entries
[03:25] <nixternal> getting close now
[03:25] <LaserJock> wahoo
[03:29] <CIA-4> Ubuntu Documentation: nixternal * r3898 kubuntu/about-kubuntu/C/about-kubuntu.xml: fixed for validation
[03:34] <CIA-4> Ubuntu Documentation: nixternal * r3899 kubuntu/musicvideophotos/C/musicvideophotos.xml: added sect ids
[03:35] <CIA-4> Ubuntu Documentation: nixternal * r3900 kubuntu/musicvideophotos/C/musicvideophotos.xml: added caption to image
[03:55] <CIA-4> Ubuntu Documentation: nixternal * r3901 kubuntu/ (libs/kde-menus-C.ent office/C/office.xml): office section complete - ready for review - added new menu items
[03:56] <nixternal> and another one bites the dust
[03:57] <nixternal> LaserJock: it is starting to look like I may have some Handbook time left in me before the week is through :)
[03:59] <Admiral_Chicago> system settings should be done for Kubuntu (mostly)
[03:59] <Admiral_Chicago> i just emailed what I had to ^^
[04:00] <Admiral_Chicago> rock. see ya all later
[04:01] <nixternal> rock on
[04:08] <nixternal> Admiral_Chicago: where is the general settings section?
[04:56] <Admiral_Chicago> nixternal: i sent that to you a while ago
[04:57] <Admiral_Chicago> nixternal: i sent it all in small bits. i'll send a batch again
[05:01] <Admiral_Chicago> nixternal: sent againt
[05:20] <CIA-4> Ubuntu Documentation: nixternal * r3902 kubuntu/hardware/C/hardware.xml: removed nvidia and ati binary info - replaced with links - to dangerous to document in system docs
[10:34] <mdke_> Admiral_Chicago: if you are doing some doc patches, feel free to send them to the list - that way we can see your work and get to know what you are doing
[11:17] <mdke_> anyone know anything about compiz?
[11:22] <mdke_> nixternal: how about just deleting the unused images? we have them in the branches for previous releases if you want to find them again
[11:23] <CIA-4> Ubuntu Documentation: mdke * r3903 /trunk/ (8 files in 6 dirs): adding a document about compiz, needs material
[12:09] <CIA-4> Ubuntu Documentation: mdke * r3904 /trunk/ (21 files in 21 dirs): refreshing pot templates
[05:41] <Admiral_Chicago> mdke: what do you need about compiz
[05:41] <Admiral_Chicago> and my doc work isn't anything major, but i'll keep that in mind
[05:47] <mdke> Admiral_Chicago: see the mailing list
[05:47] <mdke> gtg now
[06:39] <nixternal> mdke: lol, I was thinking about that last night laying in bed. the unused dir that is. I am going to do it today
[06:39] <nixternal> hiya jjesse
[06:39] <jjesse> hiya
[06:40] <jjesse> finally got a temp replacement computer from work
[06:40] <jjesse> need to do some serious doc work this weekend :(
[06:40] <nixternal> you are still working on the bood ey?
[06:40] <nixternal> I am doing serious doc work as well today and tomorrow as well
[06:41] <jjesse> yeah still working on teh book due to the fact my laptop was down all week while i was in utah
[06:42] <jjesse> i was working on reading some of the current docs
[06:42] <Admiral_Chicago> why are you thinking about doc work while lying in bed?
[06:45] <nixternal> yes I think I might
[06:46] <nixternal> my new hobby will be a help system for KDE4
[06:46] <jjesse> maybe you need a hobby that is !ubuntu :)
[06:46] <jjesse> like a life
[06:46] <nixternal> lol
[06:47] <nixternal> see, it goes Life (fam, friends, and school), Linux, KDE, Kubuntu......
[06:47] <nixternal> it all ties in perfectly
[06:49] <nixternal> heh, mdke I am going to borrow your basic-commands
[07:42] <Laser_away> jjesse: nixternal have a life?!? surely you are joking ;-)
[07:43] <somerville32> mdke: Did you get my e-mail? :)
[07:44] <LaserJock> hi somerville32
[07:44] <somerville32> Hi LaserJock :)
[07:45] <LaserJock> somerville32: how are you?
[07:45] <somerville32> I'm doing alright.
[07:45] <somerville32> Still in the hospital, I'm afraid
[07:45] <LaserJock> :(
[07:45] <LaserJock> how long have you been there?
[07:48] <somerville32> A month
[07:48] <LaserJock> yikes!
[07:48] <LaserJock> sounds serious :(
[07:49] <somerville32> hopefully they'll let me out soon :)
[08:10] <nixternal> LaserJock: watch it now ;p
[08:10] <LaserJock> :-)
[08:10] <nixternal> hiya somerville32!
[08:11] <somerville32> Hiya nixternal
[08:11] <nixternal> a month in the hospital!! jeesh, everything OK?
[08:11] <nixternal> heh, and you are on IRC
[08:11] <nixternal> dude, when my mom was just in the hospital, we couldn't even have our cell phones on
[08:12] <somerville32> nixternal: They gave me a little office to work in, haha
[08:14] <nixternal> lol
[08:14] <nixternal> that is sad
[08:16] <somerville32> : )
[09:03] <CIA-4> Ubuntu Documentation: nixternal * r3905 kubuntu/ (6 files in 6 dirs): spring cleaning
[09:10] <somerville32> :)
[09:13] <LaserJock> argg, the always looming String Freeze
[09:13] <LaserJock> somehow I always think of String Theory
[09:13] <LaserJock> maybe Ubuntu documentation is some singularity that's cause a black hole
[09:13] <LaserJock> *causing
[09:14] <nixternal> lol
[09:14] <nixternal> 5 days until freeze
[09:20] <somerville32> Wee :)
[09:27] <somerville32> lo mdke_
[10:17] <CIA-4> Ubuntu Documentation: nixternal * r3906 kubuntu/printing/C/printing.xml: link fixing - thanks Phil
[11:29] <jjesse> nixternal: awesome job on all of the updates that i'm seeing on kubuntu docs
[11:29] <nixternal> why thank you
[11:29] <nixternal> they haven't been easy
[11:29] <jjesse> i now have 62 screenshots for the book to take today :(
[11:29] <nixternal> some have been, but some haven't
[11:29] <jjesse> downloading herd5 as we speak
[11:29] <nixternal> fun
[11:29] <jjesse> your work has been a great help for working on the book
[11:29] <nixternal> it took me 3+ hours yesterday to download herd5
[11:30] <jjesse> d'oh
[11:30] <nixternal> 50+k the entire time
[11:30] <jjesse> yeah i'm at 65k/sec
[11:30] <jjesse> time to go get wife up from her nap :)
[11:30] <jjesse> brb
[11:31] <nixternal> hehe, I need to start a load of laundry
[11:33] <jjesse> i'm doing the laundry that i took to salt lake so i can pack it all back up for 3 weeks in columbus ohio
[11:33] <nixternal> sounds like fun
[11:35] <jjesse> what's not ffun is the drive home and back i'll be making every weekend
[11:36] <nixternal> oh ya, it is a good 6 hour drive for me I think
[11:36] <jjesse> little under 5 for me
[11:36] <jjesse> i'm doing it so i can see my wife isntead of missing her for 3 weeks
[11:37] <nixternal> awwww
[11:38] <Admiral_Chicago> lol
[11:38] <jjesse> no whip cracking
[11:38] <nixternal> jjesse: that's what we always say, but we know the truth
[11:38] <jjesse> comming home cause i want to
[11:38] <jjesse> no seriously try living in a hotel for 3 weeks straight
[11:38] <nixternal> there was a guy in #kubuntu last night from GR
[11:38] <jjesse> yeah?
[11:38] <nixternal> jjesse: I did, for just over a month, I hated it
[11:39] <jjesse> that's why i'm comming home
[11:39] <jjesse> in march and april i have 40 days of hotel book
[11:39] <nixternal> oh wow, that is something I do not miss
[11:39] <jjesse> puts me up to gold in marriot point status
[11:39] <nixternal> lol
[11:39] <jjesse> oooo michigan is still beating ohio state
[11:39] <nixternal> my points are pretty much gone now
[11:40] <jjesse> i'm pushing 75k
[11:40] <jjesse> in under a year
[11:40] <nixternal> I bought a snow blower, cobra golf clubs, 3 iPods, and a digital camera with mine
[11:40] <jjesse> nice
[11:40] <nixternal> holy smokes that is a lot for 1 year
[11:40] <nixternal> someone stole the snowblower
[11:40] <nixternal> lol
[11:40] <jjesse> bummer on that
[11:40] <nixternal> dude, I blew snow, came in for a warm up, went out and it was gone
[11:41] <Admiral_Chicago> hahaha
[11:41] <nixternal> Admiral_Chicago: prolly was your people ;)
[11:41] <nixternal> hahahahaha
[11:41] <Admiral_Chicago> thats why I hide
[11:41] <nixternal> lol
[11:41] <nixternal> your brother would be screaming racist
[11:41] <nixternal> haha
[11:42] <nixternal> laundry is calling
[11:42] <nixternal> back in a few
[11:42] <Admiral_Chicago> speaking of which, I'm going to find him


[03:39] <Hilikus> when i do a `systemctrl stop mythbackend` it never exits. is there any way to know why mythbackend is not ending??


[07:36] <jetsaredim> was looking for some help in making some changes to ubiquity
[07:37] <jetsaredim> to add some new dialogs
[07:37] <jetsaredim> is there any documentation on this?
[07:37] <jetsaredim> I've only minimally played with glade, but there is so little documentation out there its hard to know exactly what to change
[09:45] <cjwatson> jetsaredim_: no, I'm afraid there's no documentation at all about that
[09:45] <cjwatson> jetsaredim_: adding new screens is a pain in the arse and still best avoided ;-)
[09:46] <cjwatson> jetsaredim_: what exactly are you trying to do?
[09:47] <cjwatson> jetsaredim_: doc/README in the ubiquity source is a start at explaining how it all hangs together, but makes no pretence at being a "how to add new pages" guide
[02:21] <jetsaredim_> cjwatson: ping
[02:26] <cjwatson> hello
[02:28] <jetsaredim_> h
[02:29] <jetsaredim_> so I offered to help the mythbuntu group with some python, but I'm not so good with glade
[02:29] <jetsaredim_> we'd like to add a couple pages to allow for mythtv setup/installation during install time
[02:29] <jetsaredim_> on a new boutique distro
[02:30] <cjwatson> ok, I have to say that at the moment ubiquity is probably about the hardest possible place to do that ;-)
[02:30] <evand> heh
[02:30] <jetsaredim_> how so?
[02:31] <cjwatson> you'd need to edit ubiquity/frontend/gtkui.py and look for where names beginning with "step" are handled at the moment
[02:31] <cjwatson> you'd need to add pages to the glade file
[02:31] <jetsaredim_> yep
[02:31] <cjwatson> if debconf is involved, you'll need to add ubiquity/components/whatever.py
[02:31] <jetsaredim_> that's about what I figured
[02:31] <cjwatson> but the UI is all totally monolithic
[02:31] <jetsaredim_> i can see that
[02:31] <jetsaredim_> :)
[02:31] <cjwatson> so it's not really well suited for modifications like this yet
[02:32] <cjwatson> I do hope to split it out one day as it would make things easier for me too, but it was kind of like this when I took over the code from guadalinex
[02:32] <jetsaredim_> hm ok
[02:33] <cjwatson> in gtkui.py, you'd need to edit the run, on_next_clicked, and on_back_clicked methods at a minimum
[02:33] <jetsaredim_> do you know of any tools that make it easier to read the glade file, do ya?
[02:33] <cjwatson> possibly random special-case handling elsewhere
[02:33] <cjwatson> in edgy, use glade-2; in feisty, use glade-3
[02:33] <cjwatson> you don't want to edit it by hand
[02:33] <jetsaredim_> yea - I think I got the next and run, but not back
[02:33] <jetsaredim_> I'm having an issue with my glade installation at the moment
[02:33] <cjwatson> fix it first, then ;-)
[02:33] <jetsaredim_> yea
[02:34] <jetsaredim_> so
[02:34] <cjwatson> but the packaged versions should work fine; they're what I've always used
[02:34] <jetsaredim_> how do you map the stuff that you design in glade to actual code?
[02:34] <cjwatson> how do you mean?
[02:34] <jetsaredim_> i guess its more of a glade question
[02:34] <jetsaredim_> but I'm just not 100 familiar with how glade actually works
[02:35] <evand> jetsaredim_: the names of all the objects get imported into the global space, so you can refer to things like self.username_box
[02:35] <jetsaredim_> ok
[02:35] <cjwatson> look around where gtkui.py calls gtk.glade.XML
[02:35] <jetsaredim_> ok
[02:36] <jetsaredim_> where to the settings get stored
[02:36] <cjwatson> that's up to you
[02:36] <jetsaredim_> how do they get translated into install actions
[02:36] <jetsaredim_> like is there a global queue of packages or something
[02:37] <cjwatson> typically you need to write code in scripts/install.py to apply modifications to the installed system
[02:37] <jetsaredim_> like if I put in a screen that says I want to install 10 packages and a couple have customizations
[02:37] <jetsaredim_> ok
[02:37] <jetsaredim_> is there some sort of install chroot?
[02:37] <cjwatson> ideally it's best to avoid installing packages in ubiquity (although sometimes it's necessary)
[02:38] <jetsaredim_> as opposed to?
[02:38] <cjwatson> ubiquity normally just copies the live filesystem over and then removes stuff from it
[02:38] <cjwatson> so normally we try to put everything we need in the live filesystem
[02:38] <jetsaredim_> ic
[02:38] <cjwatson> like I say, it's not always possible, but usually it works out, and it makes the live filesystem a better demo
[02:38] <cjwatson> I assume you've read doc/README? It explains this
[02:39] <jetsaredim_> ... :)
[02:39] <cjwatson> install chroot> yes, /target
[02:39] <cjwatson> does the mythtv stuff you're trying to configure use debconf?
[02:39] <jetsaredim_> some
[02:40] <jetsaredim_> but there is at least one utility that we'd like to be able to run from inside the chroot
[02:40] <jetsaredim_> cause it needs interaction
[02:40] <cjwatson> sure, you can do that, chrex function in scripts/install.py
[02:40] <cjwatson> er, interaction?
[02:40] <cjwatson> as in command-line?
[02:40] <jetsaredim_> no
[02:40] <jetsaredim_> gui
[02:40] <jetsaredim_> mythtv-setup
[02:40] <cjwatson> meh, that'll be fiddly
[02:40] <jetsaredim_> how so
[02:41] <cjwatson> you'd have to set up X authorisation in the chroot and stuff, and it would generally be a mess
[02:41] <cjwatson> also pretty ugly UI-wise; we try to ask all the questions up-front, before the chroot exists
[02:41] <jetsaredim_> there's really no non-interactive way to setup mythtv
[02:42] <jetsaredim_> unfortunately
[02:42] <jetsaredim_> the only other thing I could think of would be something run on first boot
[02:43] <cjwatson> mythtv-setup doesn't ask all that many questions, does it?
[02:43] <cjwatson> and presumably it just blats the answers into a configuration file
[02:43] <cjwatson> it's also a pretty hideous UI
[02:43] <jetsaredim_> yes and no
[02:43] <jetsaredim_> yea
[02:43] <jetsaredim_> for sure
[02:43] <jetsaredim_> but there is stuff about if you have multiple cards
[02:44] <jetsaredim_> and if you have multiple inputs per cards
[02:44] <jetsaredim_> and what channels you want to setup
[02:44] <jetsaredim_> if we didn't run mythtv-setup, we'd essentially have to re-write it in ubiquity pages
[02:45] <cjwatson> so you're doomed to a horrible UI anyway
[02:45] <jetsaredim_> which we've already come up with 2 more pages than are there now as it is
[02:45] <cjwatson> can you at least run it before starting the install and then copy the configuration into /target?
[02:45] <jetsaredim_> interesting thought
[02:45] <jetsaredim_> i suppose that would work
[02:46] <jetsaredim_> though you might not be guaranteed that udev would scan the devices the same way on the install vs the cd
[02:46] <cjwatson> that's how ubiquity does everything else
[02:47] <jetsaredim_> true
[02:47] <cjwatson> if udev doesn't scan the devices the same on the install versus the CD, then it won't necessarily scan them the same way on every boot either
[02:47] <cjwatson> so that would make you screwed anyway
[02:47] <jetsaredim_> so if we wanted to install the mythplugins or something, we should just install them in the livecd and then remove them from if the user didn't want them?
[02:48] <jetsaredim_> err from the install
[02:49] <jetsaredim_> anyway - i have to run - but i'll be back on late
[02:49] <jetsaredim_> r
[02:49] <jetsaredim_> i hope you don't mind me picking your brains
[02:50] <jetsaredim_> o
[02:50] <cjwatson> you can do it either way, it's just generally simpler to have them in the live filesystem
[02:50] <jetsaredim_> ok
[02:51] <cjwatson> just have a shell script call 'apt-install <package>' at some point (yes, apt-install, not apt-get install) and ubiquity will sort out the rest for you
[02:51] <jetsaredim_> in the livecd environment?
[02:51] <cjwatson> if you want a package to be removable, then put it in /casper/filesystem.manifest but not in /casper/filesystem.manifest-desktop
[02:51] <cjwatson> (on the CD)
[02:52] <cjwatson> yes, in the live session
[02:52] <cjwatson> packages listed in both /casper/filesystem.manifest and /casper/filesystem.manifest-desktop will always be installed in /target
[02:52] <cjwatson> packages in just the first one will only be installed in /target if something apt-installs them
[02:52] <jetsaredim_> interesting
[02:52] <cjwatson> this is so that things like ubiquity itself can be removed
[02:53] <jetsaredim_> right
[02:54] <jetsaredim_> wow - I'm going to have to save this session for reference :)
[02:54] <jetsaredim_> ok - i'll def be back to ask more questions
[02:55] <jetsaredim_> thanks again for the help
[02:56] <cjwatson> no problem
[03:15] <evand> jetsaredim_: depending on the question, I may be able to help you as well, if cjwatson is not around.
[05:37] <jetsaredim> evand: any suggestions on tracking down my gtk problems
[05:37] <jetsaredim> I'm running kde and i have the gtk2-engines-qt package installed
[05:41] <cjwatson> whoa, don't use gtkui.py if you're running KDE, use kde-ui.py instead
[05:41] <jetsaredim> no no
[05:41] <jetsaredim> my dev box is kde
[05:41] <jetsaredim> not the livecd environment
[05:42] <jetsaredim> I can't run glade on my dev box since gtk seems all messed up
[05:42] <cjwatson> oh, I suppose that would explain your problems
[05:42] <cjwatson> ask Riddell maybe
[05:42] <jetsaredim> right
[05:42] <jetsaredim> Riddell?
[05:43] <jetsaredim> found
[05:43] <jetsaredim> ok - will do
[05:43] <jetsaredim> thanks


[00:06] <wallyworld_> sinzui: i don't know mongo very well but those errors could be mongo just refusing to start for whatever reason :-(
[00:14] <sinzui> wallyworld_, that's what I see too. I think something has changed and we might need to adapt juju to it
[00:16] <wwitzel3> perrito666: no luck yet, the problem is nothing in that commit would seem to have a direct impact on backup and restore in this fashion. It is really odd.
[00:16] <sinzui> wallyworld_, the current tip of juju is failing the same test
[00:16] <wallyworld_> sinzui: the other possibility - we set a mongo socket timeout of 21 sec, which is twice the mongo heartbeat interval. those socket connection errors occur about 30 after the sockets are opened. perhaps mongo is closing its client connections because it thinks they areunused
[00:17] <wallyworld_> the socket timeout was recently increaed from 10s
[00:17] <wallyworld_> so if anything that should have made it more tolerant
[00:18] <wallyworld_> but i'm just guessing that the error is due to mongo socket closure, may not be
[00:21] <sinzui> wallyworld_, I don't think recent juju changes are the problem. We know exactly which change the failure happened with https://github.com/juju/juju/commit/635a06380b2df20f829f205e45e2d3a7e9476d0d
[00:21] <sinzui> I don't think that is relevant.
[00:22] <wallyworld_> sinzui: the socket timeout increase happened last week before that change
[00:22] <wallyworld_> i was trying to make sense of what the most relevant culprit may have been
[00:23] <wallyworld_> sinzui: but deploy to other clouds works
[00:24] <sinzui> wallyworld_, only a few intermittent failures caused by timeouts or resources over the last week. This set rarely failed before a few hours ago. It is the only test on aws though that is bootstrapping with juju-monogodb like this
[00:24] <sinzui> wallyworld_, yep all clouds and all the locals love bootstrapping
[00:24] <wallyworld_> so just aws
[00:25] <sinzui> If I could boot utopic there, I bet it would fail the same way
[00:25] <sinzui> precise doesn't fail...it has mongodb-server
[00:28] <wallyworld_> hmmm
[00:28] <sinzui> The ami is two weeks old
[01:31] <wallyworld> sinzui: i just bootstrapped an amazon env on trusty from my local machine
[01:33] <sinzui> wallyworld, CI is still trying. Look at this extraordinary effort http://juju-ci.vapour.ws:8080/job/aws-deploy-trusty-amd64/643/console
[01:33] <wallyworld> wow
[01:33] <sinzui> wallyworld, I could kill the job, see if it restart and complete...if so then I think aws was denfintely doing something bad
[01:34] <wallyworld> sinzui: i wonder if it is region related
[01:34] <sinzui> hmm
[01:34] <wallyworld> 2014-06-20 00:57:20 INFO juju.provider.ec2 ec2.go:643 started instance "i-193ae232" in "us-east-1c"
[01:34] <wallyworld> that is what just worked for me
[01:34] <wallyworld> it picked az c
[01:34] <wallyworld> after it was rejected by a and b as being congested
[01:34] <sinzui> wallyworld, us-east-1a
[01:35] <sinzui> well, that is the on I left alive anyway
[01:35] <wallyworld> 2014-06-20 00:57:17 INFO juju.provider.ec2 ec2.go:627 "us-east-1a" is constrained, trying another availability zone
[01:35] <wallyworld> 2014-06-20 00:57:19 INFO juju.provider.ec2 ec2.go:627 "us-east-1b" is constrained, trying another availability zone
[01:35] <wallyworld> 2014-06-20 00:57:20 INFO juju.provider.ec2 ec2.go:643 started instance "i-193ae232" in "us-east-1c"
[01:35] <wallyworld> so i wasn't allowed to use a or b
[01:35] <sinzui> wallyworld, that one that is taking forever is us-east-1c
[01:36] <wallyworld> hmmm ok, that's the one that worked for me
[01:36] <sinzui> and it just failed. now the other aws jobs will start
[01:36] <wallyworld> not sure what instance type it picked, hw is "hardware: arch=amd64 cpu-cores=1 cpu-power=100 mem=1740M root-disk=8192M"
[01:37] <wallyworld> m1.small maybe
[01:37] <wallyworld> so i wonder why mine worked
[01:37] <sinzui> wallyworld, We get m3.medium by bootstrapping with mem=2G
[01:38] <wallyworld> i just used the default constraints
[01:38] <wallyworld> i can try with mem=2G
[01:38] <sinzui> did I count wrong? I see the test restarting
[01:39] <sinzui> oh this is wrong, CI is only allow to test this 5 times. It is now doing 7
[01:39] <perrito666> wwitzel3: well tomorrow is a holiday here so I wont be here, this is your problem for a day :|, I think we need to find out what is re-writing agents.conf and in which documents is that info stored to see which one we are missing, my guess is that wallyworld's commit fixed something and that the fact that restore was working before was actually a bug
[01:40] <perrito666> we are missing an update somewhee, eiter peergrouper or instancepoller
[01:40] <perrito666> anyway, its late and I am very very tired
[01:40] <wallyworld> perrito666: ok. is there info on the bug, i have not much idea what has been done etc
[01:41] <wallyworld> eg how agents.conf is involved
[01:42] <perrito666> wallyworld: there is not much info, basically, we are doing some stuff in a bash script embedded in restore.go
[01:42] <perrito666> which is being undone
[01:42] <wallyworld> ok, np
[01:42] <perrito666> that is the issue (in few words
[01:42] <wallyworld> and running the exact same steps by hand works?
[01:42] <perrito666> yup
[01:42] <wallyworld> wtf
[01:43] <wallyworld> which line does it fail at?
[01:43] <perrito666> wallyworld: none, that is what makes this wtf of an issue impossible to find
[01:43] <perrito666> the restore ends succesfully
[01:44] <wallyworld> hmmm, ok. i've not even looked at the restore script before so not sure how far i'll get
[01:44] <perrito666> and then when jujud-* starts, it all goes back as it was, courtesy of some worker
[01:44] <wallyworld> i've got some other issues to deal with as well
[01:44] <perrito666> wallyworld: in any case wwitzel3 will be working on that too
[01:44] <wallyworld> ok
[01:44] <sinzui> wallyworld, something interesting is happening here. AWS doesn't see any sign of the two services being deployed
[01:45] <perrito666> wallyworld: this is the script https://github.com/juju/juju/blob/master/cmd/plugins/juju-restore/restore.go#L106 just in case you get inspired
[01:45] <wallyworld> which services, the test ones?
[01:45] <perrito666> now gentlemen, I really need sleep
[01:45] <perrito666> cheers
[01:45] <wallyworld> perrito666: ok,good night
[01:46] <sinzui> did I mention that joyent manta went down for 5 hours yesterday? I had a power cut so it was difficult to report the outage
[01:46] <wwitzel3> perrito666: got it, have a good night
[01:46] <sinzui> ah...
[01:47] <sinzui> wallyworld, let's say the ec2 issue was region. this test suddenlty came to life and may pass http://juju-ci.vapour.ws:8080/job/aws-deploy-trusty-amd64/644/console
[01:48] <wallyworld> sinzui: i just bootstrapped with mem=2G, got same region/zone as before
[01:48] <wallyworld> 2014-06-20 01:43:22 INFO juju.provider.ec2 ec2.go:627 "us-east-1a" is constrained, trying another availability zone
[01:48] <wallyworld> 2014-06-20 01:43:24 INFO juju.provider.ec2 ec2.go:627 "us-east-1b" is constrained, trying another availability zone
[01:48] <wallyworld> 2014-06-20 01:43:25 INFO juju.provider.ec2 ec2.go:643 started instance "i-4a528a61" in "us-east-1c"
[01:48] <wallyworld>  - i-4a528a61
[01:48] <wallyworld> and it worked
[01:48] <sinzui> the test officially passed
[01:49] <sinzui> And I was watching the moment it got unstalled
[01:49] <sinzui> I didn't intervene
[01:49] <wallyworld> so did the failing and passing tests use different regions / zones?
[01:50] <sinzui> wallyworld, no, the test that passed and the one I kept alive were the same region
[01:50] <sinzui> but I think your supposition of region or maybe bad machine were at fault
[01:50] <wallyworld> maybe it is just mongo flakiness
[01:51] <sinzui> wallyworld, the failed bootstraps, the two timeouts, an the pass were all us-east-1c
[01:52] <wallyworld> \o/
[01:52] <sinzui> wallyworld, I don't believe mongo flakiness because there is no prehistory of it in the test
[01:52] <wallyworld> just seems strangethat mongo starts but then has connection errors
[01:53] <sinzui> wallyworld, oh...I lie
[01:53] <sinzui> wallyworld, there are two previous occurrences of this error in the last week. They happened twice in a row, It resolved itself in less than 30 mintutes http://juju-ci.vapour.ws:8080/job/aws-deploy-trusty-amd64/614/console
[01:54] <wallyworld> hmmmm
[01:54] <sinzui> this case though is 4 hours long
[01:54] <sinzui> anyway. Lets close this bug. maybe I need to walk away from CI and let it mind itself
[01:55] <wallyworld> sinzui: would have been interesting to use placement to run the tests on a different region/az when the test fails in us-east-1
[01:56] <sinzui> hmm, well I think I can add such as test after the release, or before if we loose faith that we make juju and CI happy in the next 16 hours
[01:56] <wallyworld> ok
[02:08] <sinzui> wallyworld, new info about joyent: https://bugs.launchpad.net/juju-core/+bug/1329123
[02:08] <_mup_> Bug #1329123: status outage during upgrades in joyent, Juju is broken <joyent-provider> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1329123>
[02:09] <wallyworld> sinzui: looking into that one now
[02:10] <sinzui> I am looking for something like termination protection to keep this instance alive
[02:10] <wallyworld> ok
[02:17] <sinzui> wallyworld, I have an instance. I clobber something on it to keep it alive when the test ended
[02:18] <wallyworld> sinzui: ok, i'm bootstrapping a 1.18.4 env now and will see what the upgrade does
[02:32] <wallyworld> far out joyent is slooooow
[02:39] <sinzui> wallyworld, it is faster than azure
[02:39] <wallyworld> surely you jest
[02:39] <sinzui> as for Hp, it now varies between 9 minutes and 21 minutes
[02:40] <wallyworld> yay cloud
[02:40] <sinzui> azure is consistently 18 to 21 minutes
[02:42] <sinzui> wallyworld, canonistack tests have been passing since I switch the test to pull tools from s3. I suspect swift is the principle cause of speed and out right failures in canonistack
[02:42] <wallyworld> sigh
[02:50] <wallyworld> sinzui: so it seems on joyent the api server does not start again after an upgrade
[02:50] <sinzui> :(
[02:52] <wallyworld> i think mongo is ok, looking into it
[03:59] <wallyworld> sinzui: so it's caused by joyent offering up machine addresses that juju doesn't know how to pick out a mongo replicaset peer from. juju's address processing changed in 1.19 and is not compatible with joyent
[04:00] <sinzui> :(
[04:00] <wallyworld> i'll see if i can figure out a fix
[04:00] <wallyworld> i'm somewhat new to this part of juju
[04:01] <sinzui> wallyworld, I pleased that we know why. I feel relieved that we have really triaged the issue
[04:01] <wallyworld> yeah, me too
[04:02] <wallyworld> sorry i had not enought ime earlier to look
[04:03] <wallyworld> sinzui: sort of argues against that upgrades are generic and can just be tested on one cloud, although i'm confused why a deployment worked as it should have had the same problem
[04:04] <sinzui> wallyworld, yeah. abentley argued a different perspective that we certify upgrade works. We need to do it for each cloud to gather evidence that things work and that upgrade isn't different.
[04:05] <sinzui> wallyworld, well maybe the deploy case works because juju is exploring the possible addresses. upgrade doesn' gather addresses.
[04:05] <wallyworld> sinzui: there's not enough debugging to see the root cause, i'll add some and retest, but first i have to go and pick up my son as he finished school early today
[04:06] <sinzui> wallyworld, All fine with me. I am going to sleep.
[04:06] <wallyworld> ok, i'll send an update
[05:09] <axw> wallyworld: I don't really understand this rsyslog stuff. I can manage to get it to work by changing the default ruleset, but I don't understand why that works... probably going to have to check with wwitzel3 and/or voidspace
[05:10] <wallyworld> axw: fair enough, i don't fully grok it either
[05:10] <wallyworld> maybe add a bug comment and we can ping them later
[05:21] <marcoceppi> where should I be reporting bugs?
[05:21] <axw> marcoceppi: launchpad
[05:22] <marcoceppi> even for things like gomaasapi ?
[05:22] <axw> that's not even on github yet is it?
[05:22] <axw> I think launchpad too
[05:22]  * marcoceppi has no idea
[05:22] <marcoceppi> cool
[05:23] <axw> maybe not when it's on github. matters for juju for integration points, probably doesn't matter for libraries
[05:30] <axw> wallyworld: is there anything else pressing I can look at? or just addresses/azure?
[05:31] <wallyworld> axw: i've made progress with the joyent thing so yeah, just addresses/azure. let's try and wrap up the wip addresses stuff
[05:31] <axw> ok. gonna write some tests now and propose part of it
[05:41] <wallyworld> great
[06:13] <jcw4> clear
[06:13] <jcw4> derp
[06:41] <davecheney> wallyworld: axw https://github.com/juju/juju/pull/135
[06:41] <axw> looking
[06:41] <wallyworld> bah, beat me to it
[06:41] <davecheney> wallyworld: the fix ?
[06:42] <wallyworld> no, looking :-)
[06:46] <wallyworld> axw: davecheney: might explain some of our mongo test issues
[06:47]  * wallyworld handwaves
[06:48] <axw> maybe, not sure. it could cause sockets to not be released
[06:48] <axw> davecheney: reviewed
[06:50] <davecheney> bueno
[06:50] <davecheney> axw: nice review
[06:50] <davecheney> i don't know what the cost of leaking cursors is
[06:50] <davecheney> or the rate we were leaking them
[06:50] <davecheney> but given the usual nonsense we see with mongo
[06:50] <davecheney> i'm confident to bet it wasn't helping
[06:51] <voidspace> morning all
[06:51] <axw> morning voidspace
[06:51] <voidspace> o/
[06:53] <axw> voidspace: when you have a moment, can you please cast your eye over https://bugs.launchpad.net/juju-core/+bug/1332358 and my comment on it?
[06:53] <_mup_> Bug #1332358: creating a local environment stops the syslog (1.19.3) <local-provider> <logging> <juju-core:Triaged> <https://launchpad.net/bugs/1332358>
[06:54] <wallyworld> axw: small one https://github.com/juju/juju/pull/136
[06:54] <axw> looking
[06:55] <wallyworld> fixes last critical for 1.19.4 release
[06:55] <voidspace> axw: ok
[06:56] <voidspace> axw: ouch
[06:56] <axw> voidspace: does that ruleset stuff mean something to you?
[06:56] <voidspace> axw: yep
[06:56] <voidspace> axw: I wrote the rulesets
[06:57] <voidspace> axw: I can switch to looking at this
[06:57] <voidspace> axw: but today is my last day for a week
[06:57] <voidspace> axw: so maybe the best thing I can do is write up a quick explanation of the rulesets to help wayne or someone else debug it
[06:57] <axw> voidspace: sounds good, thank you
[06:57] <voidspace> axw: wayne did the rest of the rsyslog stuff (but not the ruleset)
[06:57] <axw> ok
[06:58] <wallyworld> voidspace: i've moved that bug to 1.19.4 so if there's any way to get it sorted before eod that would be great
[06:58] <wallyworld> either you or wayne
[06:58] <wallyworld> as it would be bad to ship 1.20 with that issue still there
[06:58] <davecheney> axw: wallyworld i THINK i've got all the occurances
[06:58] <axw> wallyworld: what was setting blank addresses?
[06:58] <davecheney> i've searched for them a bunch of different ways
[06:58] <voidspace> axw: is the problem that with local provider, we kill the rsyslog configuration for anything else on the system?
[06:58] <davecheney> i wanted to use the new pointer analysis feature in godoc 1.3
[06:58] <axw> davecheney: oracle? :)
[06:58] <axw> heh
[06:58] <wallyworld> axw: an old version of the instance poller
[06:59] <davecheney> but there isn't enough memory in the world to process juju
[06:59] <axw> wallyworld: ok
[06:59] <wallyworld> i can't recall the exact bug
[06:59] <voidspace> axw: Having a bug description with full sentences would help :-/
[06:59] <davecheney> the stdlib consumes 1.7gb on my machine
[06:59] <wallyworld> but it rings a bell
[06:59] <davecheney> axw: i could try the oracle
[06:59] <axw> voidspace: yes, everything else stops it seems
[07:00] <axw> davecheney: I have 16GB, I'll see if I can run it.
[07:00] <voidspace> axw: and you can reproduce it?
[07:00] <axw> voidspace: yes, trivially
[07:00] <voidspace> axw: what are the repro steps
[07:00] <axw> voidspace: bootstrap local provider, wait for rsyslog worker to kick in, /var/log/syslog stops showing other bits
[07:00] <voidspace> ah
[07:00] <axw> voidspace: I just did what's in the bug
[07:01] <voidspace> hah, there are repro steps
[07:01] <voidspace> axw: it's 8am here and I haven't had coffee :-)
[07:01] <voidspace> so coffee
[07:01] <axw> :)
[07:01] <voidspace> axw: so I guess the problem is that I change the default ruleset to forward all logs to the state server
[07:01] <voidspace> and the state server only logs juju messages and drops everything else
[07:02] <voidspace> and on local provider the state server is "the machine"
[07:02] <voidspace> so all other logs are dropped
[07:02] <axw> it looked like they both do that though?
[07:02] <axw> both rulesets I mean
[07:02] <davecheney> axw: i also have a bunch of junk in my $GOPATH
[07:02] <davecheney> which upset the analyser, it freaks on first error
[07:02] <voidspace> axw: one should just forward messages (local) the other should actually log them (remote)
[07:03] <voidspace> but coffee first
[07:03] <axw> ok
[07:04] <voidspace> (so "remote" ruleset is for logs received by TCP - and they should be logged. The "default ruleset" is "what to do with messages generated locally" and we want to forward those to all state servers - so that's the "local ruleset" which forwards messages.)
[07:04] <voidspace> For local provider we need to be smarter and log messages that aren't juju ones
[07:04] <voidspace> in fact we can do that for all providers
[07:04] <voidspace> so it should be a simple change
[07:05] <wallyworld> thanks davecheney
[07:05] <voidspace> but I/we need to know how to specify "do what you would have done anyway" for the non juju messages
[07:05] <voidspace> the remote ruleset just logs messages - which is why switching to remote by default works
[07:06] <voidspace> but it means that log messages don't get broadcast to other state servers
[07:06] <voidspace> so it isn't correct
[07:06] <axw> voidspace: isn't that just for non-juju log messages?
[07:06] <voidspace> we only want our log file to handle juju messages
[07:06] <axw> wallyworld: why the "" check in bestAddressIndex too?
[07:07] <voidspace> axw: the problem is that it is for non-juju log messages too
[07:07] <voidspace> axw: but yes - we have a tag format for juju messages, so for all *non juju* ones we need to say "just process them as you would have done"
[07:07] <voidspace> I don't know how to specify that
[07:08] <wallyworld> axw: because somehow "" addresses still end up in there and i'm not sure how
[07:08] <axw> nor do I
[07:08] <voidspace> needs digging into
[07:08] <voidspace> probably keeping a reference to the normal "default ruleset" before replacing it
[07:08] <wallyworld> voidspace: axw: there's a ~ syntax i think
[07:08] <voidspace> or something
[07:08] <voidspace> yeah ~ means "stop processing"
[07:08] <wallyworld> or something like that
[07:08] <voidspace> we only want to do that for juju ones
[07:09] <voidspace> but we're also replacing the default ruleset, so the old processing rules might not even be used
[07:09] <voidspace> there must be a way to do it, just needs looking up and trying...
[07:09] <wallyworld> i'm sure between you and wayne you'll figure it out :-)
[07:09] <voidspace> heh, thanks
[07:10] <voidspace> wallyworld: I'll get wwitzel3 up to speed when he comes online if I haven't already fixed it
[07:10] <wallyworld> voidspace: awesome, thanks.
[07:11] <wallyworld> voidspace: i'll mark it as in progress to you so if curtis looks he'll know it's being worked on, and you can assign to wayne to finish off if need be
[07:12] <wallyworld> voidspace: what's you lp id?
[07:14] <wallyworld> never mind
[07:14] <wallyworld> found it
[07:19] <davecheney> ?   	github.com/juju/juju/rpc/rpcreflect	[no test files]
[07:19] <davecheney> ok  	github.com/juju/juju/state	370.446s
[07:19] <davecheney> ok  	github.com/juju/juju/state/api	24.052s
[07:19] <davecheney> what the f has happened to the state package
[07:19] <davecheney> it was 156 seconds a few days ago
[07:19] <axw> hm, I just ran it and it took 115.711s
[07:19] <davecheney> ok, what the f is wrong with the bot ?
[07:22] <axw> wallyworld: the real problem is in the joyent provider
[07:22] <axw> instance.go, Addresses method
[07:22] <axw> it's initialising a slice with len, and then appending to it
[07:22] <wallyworld> let me look
[07:23] <wallyworld> so it is
[07:23] <wallyworld> i'll fix
[07:23] <wallyworld> thanks
[07:23] <axw> np
[07:23] <wallyworld> we did also have that instance poller issue so i jumped to conclusions
[07:32]  * wallyworld taps fingers impatiently waiting for joyent env to start up
[07:32] <axw> I thought it was meant to be fast
[07:33] <wallyworld> not when the instance has to do the apt dance
[07:36] <davecheney> how come you guys rewrite the apt mirrors ?
[07:36] <davecheney> are the ec2 mirrors busted ?
[07:37] <axw> davecheney: dunno, that is inherited from CI I think.
[07:38] <davecheney> it's probably not that important
[07:38] <davecheney> 2mb downloaded
[07:39] <davecheney> the real time is taken writing the data
[07:39] <davecheney> is that using ephemeral storage ?
[07:39] <davecheney> that instance
[07:40] <wallyworld> axw: bollocks, just the provider fix without the other work still fails
[07:40] <wallyworld> so i'll have to add back the other check
[07:41] <axw> wallyworld: :(
[07:41] <axw> davecheney: non capisco. is what using ephemeral storage?
[07:42] <davecheney> the ec2 instance
[07:42] <axw> it has some, it just shows up as /mnt
[07:43] <davecheney> aww crap
[07:43] <davecheney> ok, ignore my suggestion, won't work
[07:43] <axw> davecheney: we use /mnt/tmp as $TMPDIR when running the tests
[07:56] <rogpeppe1> mgz: ping
[07:57] <wallyworld> axw: i added your fix and retained one of mine (and removed the other) and it all works
[07:58] <axw> wallyworld: cool. which one of yours did you have to keep?
[07:58] <wallyworld> the merge addresses one
[07:58] <axw> okey dokey. I guess that needs to be there cos it was buggered before
[07:59] <wallyworld> that's my guess but i don't know 100%
[07:59] <rogpeppe1> because it looks like we're not moving to kr's godep tool that soon, i've just pushed a couple of updates to godeps which should make it a little more pleasant to use
[07:59] <wallyworld> hard to find out for little gain
[07:59] <axw> rogpeppe1: what changes?
[07:59] <axw> wallyworld: no worries, LGTM
[07:59] <wallyworld> ta
[08:00] <rogpeppe1> specifically, there's now a -f flag which, if set and an update fails, tries to fetch new changes from the repo before trying again
[08:00] <davecheney> i did git pull upstream master and the conflicts were horrid
[08:00] <davecheney> how do I undo that ?
[08:00] <davecheney> i have no committed
[08:00] <axw> rogpeppe1: nice, thank you
[08:00] <davecheney> i have not committed
[08:00] <rogpeppe1> axw: also (actually this changes has been around for a while) it tries to do as much work as possible in the face of failure
[08:00] <rogpeppe1> axw: so if one repo is dirty, it doesn't stop others being updated
[08:00] <axw> davecheney: "git reset HEAD" I think?
[08:01] <axw> rogpeppe1: ah excellent
[08:01] <davecheney> axw: nope
[08:01] <davecheney> sorry
[08:01] <axw> davecheney: "git checkout ." in the root. I dunno if there's a better way to do it.
[08:01] <rogpeppe1> axw: i'd appreciate it if you could try it out and tell me if it seems to work ok. i didn't have the energy to write tests :-)
[08:01] <davecheney> axw: thanks
[08:01] <axw> rogpeppe1: will do
[08:01] <davecheney> that worked
[08:02] <davecheney> git totally fucked the change to state/apiserver/root.go
[08:02] <rogpeppe1> davecheney: you might find it useful too FWIW
[08:04] <davecheney> rogpeppe1: will do
[08:04] <davecheney> much love for godeps
[08:05] <rogpeppe1> it's funny, i've been thinking for ages i couldn't make the time to do the auto-fetch stuff, and then it only took 30 mins to do :-)
[08:06] <davecheney> #winning
[08:09] <wallyworld> wtf
[08:09] <wallyworld> Updating juju-core dependencies to the required versions.
[08:09] <wallyworld> launchpad.net/godeps (download)
[08:09] <wallyworld> # cd .; bzr branch https://launchpad.net/godeps /mnt/jenkinshome/jobs/github-merge-juju/workspace/tmp.PFiIQenwfH/RELEASE/src/launchpad.net/godeps
[08:09] <wallyworld> bzr: ERROR: exceptions.RuntimeError: if we move self._source_infos, then we need to change all of the index pointers as well.
[08:09] <wallyworld> Traceback (most recent call last):
[08:09] <wallyworld>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 920, in exception_to_return_code
[08:09] <wallyworld> jenkns is busted
[08:09] <wallyworld> i'll hit the retry button
[08:10] <axw> rogpeppe1: ^^ did you break it? :)
[08:10] <axw> we grab the latest godeps I think...
[08:11] <rogpeppe1> axw: it's quite possible, although i tried to make it so the current behaviour wouldn't change unless explicitly specified
[08:11] <rogpeppe1> axw: specifically, it doesn't try to fetch stuff unless the -f flag is given
[08:11] <axw> okey dokey
[08:12] <axw> hmm actually it looks like it's trying to branch godeps, not run it
[08:12] <wallyworld> axw: i'm off to soccer, if my 2nd retry fails, and there's a fix to anything, can you type $$merge$$ for me again?
[08:12] <axw> wallyworld: sure
[08:12] <wallyworld> ta
[08:13] <wallyworld> i'll be back later anyway, just want to get this sucker landed
[08:13] <davecheney> so lp just had a lie down ?
[08:14] <axw> maybe. I just branched it and it worked fine
[08:14] <axw> on my machine
[08:14] <rogpeppe1> well, jenkins is still thinking about godeps...
[08:17] <rogpeppe1> hmm. *still* thinking. that's not a great sign.
[08:18] <rogpeppe1> same problem again
[08:18] <rogpeppe1> looks like it might be a bzr issue
[08:18] <axw> :(
[08:19] <axw> I'll jump on the machine and take a peek
[08:19] <rogpeppe1> axw: try making sure that the godeps repo dir is deleted
[08:19] <rogpeppe1> axw: that might make a difference, i suppose
[08:19] <axw> it goes to a tempdir
[08:19] <rogpeppe1> axw: hmm
[08:20] <rogpeppe1> axw: it's perhaps indicative of something that it took so long to fail
[08:20] <rogpeppe1> i'll try fetching it from scratch myself
[08:21] <rogpeppe1> worked fine for me
[08:22] <axw> rogpeppe1: works when I do it on the machine too
[08:22] <axw> le sigh
[08:22] <rogpeppe1> axw: hrmph
[08:24] <axw> rogpeppe1: did you do "go get" or "bzr branch"?
[08:24] <rogpeppe1> axw: go get
[08:25] <rogpeppe1> axw: which, i hope, is what the bot is doing too
[08:25] <axw> yeah that works too
[08:25] <rogpeppe1> axw: in fact, i know it is
[08:25] <axw> yep
[08:25] <axw> it is
[08:25] <rogpeppe1> axw: oh yes, the other new feature in godeps is that it now understands package wildcards just like the go tool
[08:26] <axw> rogpeppe1: ah nice, now I don't have to remember how to list the packages :)
[08:26] <rogpeppe1> axw: cudos to github.com/kisielk/gotool - which made it a 2-line change
[08:28] <rogpeppe1> axw: i could uncommit and push -f if we need to
[08:33] <axw> rogpeppe1: just going to see if there are any env vars that are influencing this first
[08:33] <rogpeppe1> axw: good thought
[08:44] <rogpeppe1> fwereade: if you haven't seen it, i think you'll like this proposal: https://docs.google.com/document/d/1e8kOo3r51b2BWtTs_1uADIA5djfXhPT36s6eHVRIvaU/edit
[08:45] <fwereade> rogpeppe1, is that the bundles one? haven't looked at it properly yet I'm afraid
[08:45] <rogpeppe1> fwereade: no, it's a go proposal
[08:45] <rogpeppe1> fwereade: but i'd appreciate your thoughts on the bundles thing too, if poss
[08:46] <rogpeppe1> fwereade: 'cos we're actually implementing it right now :-)
[08:46] <fwereade> rogpeppe1, I read the first sentence and thought "woohoo!"
[08:46] <rogpeppe1> fwereade: :-)
[08:47] <fwereade> rogpeppe1, that's awesome
[08:47] <rogpeppe1> fwereade: i think so too
[08:48] <rogpeppe1> fwereade: it means we can have a clear division in juju-core between internal and external APIs
[08:48] <rogpeppe1> fwereade: i think we could restructure it like that even before the go tool supports it actually
[08:48] <fwereade> rogpeppe1, yeah, and we can make small packages without annoying you *too* much ;)
[08:49] <rogpeppe1> fwereade: :-
[08:49] <rogpeppe1> )
[08:52] <rogpeppe1> axw: any joy?
[08:52] <axw> rogpeppe1: nope :( sticking a "bzr branch" in there to see if it makes a difference
[09:01] <axw> no joy...
[09:04] <rogpeppe1> axw: i've just retracted my latest commit and overwritten godeps/trunk
[09:04] <rogpeppe1> axw: let's see if it works again now...
[09:04] <rogpeppe1> if not, then we're stuffed :-)
[09:04] <axw> rogpeppe1: thanks, I'll give it another kick
[09:06] <axw> rogpeppe1: that did it
[09:06] <rogpeppe1> axw: fuck
[09:07] <axw> :(
[09:07] <rogpeppe1> axw: what the hell was going on there then?
[09:07] <axw> no idea, weird bzr internal badness
[09:07] <rogpeppe1> axw: i will try another time, but with a fresh commit (and slightly different program text, in case it's a weird sha clash or something)
[09:08] <axw> ok
[09:11] <rogpeppe1> axw: pushed, with slightly different changes and commit message.
[09:11] <axw> rogpeppe1: okey dokey. I'll stop the build and try it again
[09:11] <rogpeppe1> axw: great, thanks
[09:16] <axw> does not look promising
[09:19] <rogpeppe1> axw: darn
[09:23] <axw> rogpeppe1: would you mind backing it out for now, and we can take another look at it next week?
[09:23] <rogpeppe1> axw: ok :-\
[09:23] <axw> sorry. kinda need to get this fix in for 1.19.4
[09:24] <rogpeppe1> axw: ok, done
[09:24] <axw> thanks
[09:30] <rogpeppe1> mgz: you around today?
[10:41] <dimitern> fwereade, I've responded to comments and updated most of the networking doc, but there are a few open questions left
[10:42] <dimitern> fwereade, like the ports collection, addresses on the machine doc, port on the address doc, and whether to expose subnet management commands
[10:44] <dimitern> fwereade, also I'm a bit concerned about how to model ipv4 and ipv6 addresses on the same interface - as described we need 2 interface docs with the same name and different subnet ids (for 4 and 6)
[10:44] <dimitern> fwereade, but we might have 2 subnetids on the interface doc instead - IPv4SubnetId and IPv6SubnetId
[10:44] <dimitern> fwereade, thoughts?
[10:51] <dimitern> TheMue, standup?
[10:51] <TheMue> dimitern: so late already? coming
[11:10] <voidspace> axw: wallyworld: ok - I have it so that local messages not originating from juju are no longer dropped
[11:10] <voidspace> axw: wallyworld: now I need to test that juju messages still get through
[11:35] <fwereade> dimitern, cheers, I'll take a look at the doc
[11:36] <fwereade> dimitern, I don't immediately have ideas about 4v6 on the same interface
[11:39] <dimitern> fwereade, right, thanks
[12:05] <wallyworld> voidspace: just got back from soccer, great to see you've figured it out. you're now the juju-core rsyslog expert :-)
[13:45] <bac> hi sinzui, i've been trying to test quickstart on utopic. the gui comes up fine but mediawiki and mysql (the only two i've tried so far) either error or never leave pending.  since bug 1314686 is resolved i would've expected success.
[13:45] <_mup_> Bug #1314686: Please add support for utopic <packaging> <juju-core:Fix Released by wallyworld> <juju-core 1.18:Fix Released by wallyworld> <juju-core (Ubuntu):Fix Committed by racb> <https://launchpad.net/bugs/1314686>
[13:53] <rogpeppe1> dimitern, fwereade, mgz: what do you think about making all the Snippet constants in the names package non-capturing?
[13:54] <rogpeppe1> we just tried to use the snippets to do some parsing, and they're not that useful if they've got capturing groups inside
[13:54] <mgz> rogpeppe1: I'd favour that
[13:54] <mgz> I use non-capturing by default
[13:54] <dimitern> rogpeppe1, then you'll need to change the parsing not to depend on capture groups
[13:54] <bodie_> morning all
[13:55] <rogpeppe1> dimitern: yeah
[13:55] <mgz> rogpeppe1: unrelated, can you push your godeps changes again in a sec when I ask, the bot is getting some bits sorted out
[13:55] <rogpeppe1> mgz: sure
[13:55] <rogpeppe1> mgz: do you know what might've been going on there?
[13:56] <mgz> there seems to be a shared repo across lots of packages, that got a particualr bug tickled, abentley is sorting it now we hope
[13:58] <abentley> mgz: We are just working around the problem.  We hope.
[14:03] <ericsnow> perrito666: would https://github.com/juju/juju/pull/135 have had any impact on the restore (plugin) issue?
[14:03] <natefinch> ericsnow: standup?  Also perrito666 is on holiday
[14:03] <wwitzel3> ericsnow: perrito666 is out today, I'm looking at the backup and restroe stuff
[14:03] <ericsnow> natefinch: coming
[14:07] <voidspace> wwitzel3: https://github.com/voidspace/juju/compare/local-syslog
[14:18] <rogpeppe1> mgz, dimitern: https://github.com/juju/names/pull/9
[14:18] <rogpeppe1> makes snippets non-capturing
[14:19] <rogpeppe1> review appreciated :-)
[14:21] <dimitern> rogpeppe1, reviewed
[14:21] <rogpeppe1> dimitern: you're a star, ta!
[14:22] <dimitern> :)
[14:22] <voidspace> wwitzel3: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/479592
[14:22] <rogpeppe1> merged!
[14:22] <_mup_> Bug #479592: rsyslog doesn't work with property filter 'startswith' <rsyslog (Ubuntu):Confirmed> <https://launchpad.net/bugs/479592>
[14:22] <rogpeppe1> who needs CI anyway :-)
[14:23] <mgz> rogpeppe1: yeah, that looks fine
[14:28] <voidspace> echo 'biggle again' | logger -p local0.notice -t juju-michael-local-
[14:28] <voidspace> wwitzel3: ^^
[14:29] <TheMue> dimitern: your suspicion has been a good one. our infrastructure simply only expects strings
[14:31] <dimitern> TheMue, so if we need to support binary values for service settings that's something to keep in mind :)
[14:39] <TheMue> dimitern: exactly
[14:41] <voidspace> natefinch: so I *think* I've fixed the logging issue, wwitzel3 and I are testing
[14:42] <voidspace> natefinch: the trouble is that we need to verify that logging still works properly with HA and units
[14:43] <voidspace> natefinch: and you can't test that with local
[14:43] <voidspace> natefinch: and it takes a while to check
[14:43] <voidspace> natefinch: with my patch it now works properly again on local
[14:43] <voidspace> I basically just got rid of the local ruleset - we just add the  rules that do the broadcasting and then drop the juju messages
[14:44] <voidspace> no need for a new ruleset
[14:53] <natefinch> voidspace: nice work'
[14:53] <voidspace> natefinch: well, we'll see
[14:53] <voidspace> my machine has now bootstrapped
[15:14] <voidspace> wwitzel3: https://github.com/juju/juju/pull/137
[15:14] <voidspace> axw: wallyworld_ : https://github.com/juju/juju/pull/137
[15:18] <axw> voidspace: cool, thanks. so... those rules at the top go into the default ruleset?
[15:18] <axw> now that there's no "local" one?
[15:20] <alexisb> natefinch, perrito666 : where do we stand on lp 1332110?
[15:21] <wwitzel3> alexisb: perrito666 handed that off to me, he is out today (natl holiday)
[15:22] <alexisb> wwitzel3, ah ok, do you have an update?
[15:22] <wwitzel3> alexisb: not fixed, I think we've isolated it to an issue with peergroup or instancepoller overwriting the conf, but not confirmed anything yet.
[15:23] <alexisb> wwitzel3, ack, getting 1.19.4 out is important so if you need additional help/expertise let me know
[15:24] <wwitzel3> alexisb: thanks, will do
[16:07] <voidspace> I'm off for the week, have fun without me next week
[16:07] <natefinch> voidspace: have fun!
[16:07] <ericsnow> voidspace: \o
[16:07] <voidspace> thanks
[16:07] <voidspace> o/
[16:07] <wwitzel3> voidspace: safe travels
[16:11] <wwitzel3> natefinch: taking my car in
[16:12] <natefinch> wwitzel3: ok
[16:14] <rogpeppe1> mgz: do you want me to push that godeps branch?
[16:16] <mgz> rogpeppe1: yah, lets do it
[16:17] <mgz> so we can undo again if the next one borks
[16:17] <rogpeppe1> mgz: ok, doing. i'll check you've got push rights so you can undo it, cos i'm just off for the w/e
[16:18] <mgz> thanks
[16:20] <rogpeppe1> mgz: ok, you're added and i've pushed it...
[16:20] <rogpeppe1> mgz: now i'm off
[16:20] <rogpeppe1> happy weekends all
[16:49] <sinzui> what version of mongodb does juju require 2.4.6?
[16:50] <sinzui> I see 2.4.9 in ctools, but I have not ported it to juju stable ppa?
[16:50] <sinzui> natefinch, ^
[16:54] <natefinch> sinzui: 2.4.6
[16:55] <sinzui> thank you natefinch
[18:59] <natefinch> wwitzel3: you around?
[19:40] <wwitzel3> natefinch: am now
[19:40] <wwitzel3> natefinch: an oil change and new plugs turned in to $2500 and come get your car next week
[19:42] <alexisb> wwitzel3, sucky
[19:45] <bodie_> 'lo alexisb :)
[19:45] <bodie_> wwitzel3, that is lame
[19:45] <ericsnow> wwitzel3: ouch
[19:46] <wwitzel3> yeah :/
[19:46] <bodie_> anyone have an idea how the canAccess stuff in apiserver works?
[19:47] <bodie_> I'm trying to figure out whether it's necessary to "canAccess" the Unit that Actions are going to, when I query an Action from State
[19:47] <bodie_> jcw4 / mgz / fwereade ?
[19:47] <bodie_> sorry, state/apiserver in case that's too vague
[19:47] <jcw4> bodie_: I don't know but I can investigate also
[19:57] <natefinch> wwitzel3: wow suck
[19:57] <wwitzel3> natefinch: I'm in moonstone
[20:02] <bac> hi cmars
[20:59] <alexisb> alrighty all, I am going to use friday afternoon to take down my system and do some much needed upgrades, if you need me call my cell or send me mail
[20:59] <wwitzel3> alexisb: have a good weekend, will update via the mailing list my progress on the backup and restore when I hit EOD
[21:00] <alexisb> wwitzel3, thank you!
[21:00] <alexisb> have a great weekend yourself
[22:14] <bodie_> oh good, my tests on master are passing again on my workstation
[22:14] <bodie_> wonder what happened


[04:56] <bigjools> jtv: just landing a packaging fix now
[04:56] <jtv> Thanks
[05:07] <bigjools> jtv: it's in
[05:13] <jtv> bigjools: sent you my draft reply.
[05:15] <bigjools> jtv: looking
[05:46] <jtv> bigjools: could I bother you for a review?  https://code.launchpad.net/~jtv/maas/bug-1379568/+merge/237893
[05:47] <bigjools> jtv: doing one already but I'll take a look
[05:50] <jtv> Thanks.
[06:01] <bigjools> gmb: instead of the red error banner, do you think a separate oops page would be better?
[06:01] <bigjools> it confused me until I realised what was going on
[07:59] <gmb> bigjools: If the red error banner is confusing, then yes, we should do something different. I think we have a chunk of work to do on error reporting, actually: at the moment errors that happen in bulk actions are barely reported at all (just "couldn't be executed on N nodes:").
[09:37] <jtv> Any reviewers available?
[09:37] <jtv> rvba: I'll also need landing approval, but I'm going to run some local Q/A first.
[09:51] <allenap> jtv: I want to get my branches on the way to landingdom, then I’ll get stuck into your reviews.
[09:51] <jtv> Thanks!
[10:11] <jtv> allenap: thanks for the swarm of reviews.
[10:13] <allenap> jtv: You’re welcome. The code was good so it was easy.
[10:16] <jtv> Thanks.  Really making a point of facilitating reviews.
[10:35] <gmb> allenap, jtv, (rvba): Review needed when you have chance gents: https://code.launchpad.net/~gmb/maas/bug-1379154/+merge/237936
[10:35] <jtv> I'll take it.
[10:35] <gmb> Thanks
[10:37]  * gmb -> moar tea
[10:53] <gmb> jtv: Gah, I missed the ", you"! But yay, made you look :)
[10:54] <gmb> Thanks for the review :)
[11:22] <zezom> I'm currently running proxmox at home on a single server + NAS but I'm quite impressed with what I've seen MASS + JUJU do. Unfortunately I am unable to tell if I can run MAAS, JUJU and my virtuals all on a single server. I would like the ability to add more servers in the future but for now one server is all I have. I've read through the MAAS install doco on ubuntu.com but it doesn't say if the MASS controller install can run any virtual's on i
[11:22] <zezom> t's self or if it's only used to bootstrap other nodes to run virtual's.
[11:24] <zezom> I also have a Ubuntu desktop but I shut it down when not in use.
[11:28] <rbasak> zezom: no need for MAAS at all if you only have one server. You can just use Juju on it directly, and Juju can create VMs or containers as needed.
[11:29] <rbasak> zezom: you can use the "manual" Juju provider for this. Or the "local" provider if you never want to go beyond one server (it's a bit easier).
[11:29] <zezom> rbasak, that's great. and in the future I can install maas when required?
[11:29] <rbasak> For just a small handful of servers, the "manual" provider should be fine.
[11:30] <rbasak> Beyond that, to switch to MAAS, you'll need to redeploy to a new MAAS environment.
[11:30] <zezom> should I install the cloud version of the Ubuntu server image then? Or just the standard server image?
[11:30] <rbasak> For the manual or local providers, just the standard server image will be fine.
[11:30] <rbasak> If local, bootstrap Juju from the server itself. If manual, I think you can bootstrap it from your desktop.
[11:31] <rbasak> Hmm.
[11:31] <zezom> when you say redeploy will that mean I'll have to recreate the setup? or I can just move the setup to the new hardware after presenting it to the existing juju?
[11:31] <rbasak> If you want to manage the deployment from your desktop, the manual provider might be easier in that case.
[11:31] <rbasak> Anyway, #juju would probably be more relevant for this conversation. People there know more than I do about this.
[11:31] <rbasak> You'll have to recreate.
[11:32] <rbasak> Juju has functionality that makes this easier though, with backup/restore stuff (I'm not familiar with it though)
[11:32] <zezom> thank you for the info. it's appreciated.
[11:45] <gmb> rvba, https://code.launchpad.net/~gmb/maas/bug-1379154/+merge/237936 needs approval for landing when you have a moment.
[11:50] <jtv> And a bunch of mine as well...
[12:08] <rvba> gmb: just reviewed your branch.
[12:08] <gmb> rvba: thx
[12:09] <jtv> rvba: could you review landing-approval-review mine as well?
[12:09] <rvba> jtv: doing it now
[12:09] <jtv> I've got 4 up, but they're not big.
[12:09] <jtv> Thanks.
[13:29] <gmb> jtv, rvba: https://code.launchpad.net/~gmb/maas/fix-register_event_and_event_type-bug-1379401 needs reviewing if you have the time and bandwidth.
[13:29] <gmb> allenap: ^^
[13:30] <allenap> gmb: I have spare girth in my band.
[13:54] <jtv> Simple documentation review: https://code.launchpad.net/~jtv/maas/update-ipv6-limitations/+merge/237982
[14:02]  * gmb -> out; errands. Back later
[14:44] <th3rt> I'm trying to use MaaS to setup some super micro nodes with the IPMI on a separate maas network.  I can't seem to get MaaS to associate the IPMI interfaces with the correct host (I think because they are on a different network in MaaS).  Can anyone tell me what I'm doing wrong?
[14:46] <jtv> th3rt: having them on a separate network should be fine.  No idea what could be going wrong there.
[14:47] <th3rt> If I delete all the nodes from MaaS,  how can I get MaaS to re-discover the nodes?
[14:48] <th3rt> ... or is that the wrong thing to do.  I didn't set this MaaS server up originally (and have never used MaaS before) so I'm not sure how the discovery process works once a node has been deleted.
[14:48] <jtv> th3rt: as long as they're set to netboot, just turn them on.
[14:49] <jtv> Assuming you're letting MAAS manage DHCP, and letting the nodes netboot,
[14:49] <jtv> turning a node on will netboot it off the maas server.
[14:49] <jtv> It will boot into an ephemeral image that registers the node with the server.
[14:51] <th3rt> jtv,  thanks much.  That helps.  I am letting MaaS manage DHCP.
[14:51] <jtv> np
[22:57] <DominiKiD> can anyone help me with my maas configuration?
[22:57] <DominiKiD> i beent ryign to do this for weeks and i have no clue of what im doung..
[22:57] <DominiKiD> doing
[22:58] <DominiKiD> i been  trying to make my own home server and add a node
[22:58] <DominiKiD> i installed mass on one of the computers
[22:58] <DominiKiD> and eveyrthign seems to be working..
[22:58] <DominiKiD> now i dont have a blue how to configure the dhcp
[22:58] <DominiKiD> the clusters
[22:59] <DominiKiD> help enyone?