[01:44] <cmdrqaz> howdy peeps
[01:45] <cmdrqaz> anyone awake willing to give me some help?
[01:45] <cmdrqaz> just did a fresh install on 9.10
[01:45] <cmdrqaz> i have a dual monitor set up, got that working fine
[01:46] <cmdrqaz> but in my old setup when i had a windows on the lets say right monitor, there would be the current window visible in the panel down the bottom
[01:47] <cmdrqaz> but its currents showing in the panel on the left monitor
[01:47] <cmdrqaz> how do i get it back to show on the comprehending monitor
[01:47] <cmdrqaz> ?
[01:47] <cmdrqaz> make sense?
[08:24] <huats> morning
[08:26] <TheMuso> Hey huats.
[08:26] <huats> Hello TheMuso
[08:53] <seb128> hello there
[08:55] <Tm_T> hi hi
[09:03] <pitti> Good morning
[09:03] <chrisccoulson> good morning pitti
[09:05] <seb128> hey pitti chrisccoulson
[09:05] <chrisccoulson> hey seb128
[09:05] <chrisccoulson> how are you today?
[09:05] <seb128> good! you?
[09:06] <chrisccoulson> yeah, not too bad. i had less car drama on the journey to work today, at least
[09:07] <baptistemm> heya
[09:07] <rodrigo_> seb128, pitti: for updates to karmic, I need to do the 'affects distribution' + nomination thing, right?
[09:07] <chrisccoulson> hay baptistemm
[09:07] <chrisccoulson> /s/hay/hey
[09:07] <seb128> rodrigo_, yes
[09:07] <rodrigo_> seb128: ok, thanks
[09:07] <seb128> rodrigo_, you're welcome
[09:07] <seb128> lut baptistemm
[09:07] <rodrigo_> :)
[09:08] <baptistemm> good morning ladies and gentlemen
[09:08] <pitti> rodrigo_: right
[09:30] <didrocks> hey desktopers :)
[09:30] <seb128> lut didrocks
[09:30] <seb128> did you manage to build your cd image?
[09:31] <didrocks> yeah 698 Mb \o/
[09:31] <didrocks> with simplecommeubuntu installed and a symlink on the desktop :)
[09:31] <didrocks> I've now to update simplecommeubuntu package in universe too and ask for a sru
[09:35] <mac_v> chrisccoulson: hi... i noted something similar to the gpm icon > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/397839/comments/46  , but that seems fixed in ATI , it seems more of an xorg issue than a gpm issue
[09:36] <mac_v> chrisccoulson: also, see my comment #49  , if the users are getting the icon that might just mean the bug is hiding and not yet fixed in the xorg
[09:37] <mac_v> hope that helps ;)
[09:39] <chrisccoulson> mac_v - we have carried the X server patch that exposes that bug for some time though
[09:40] <mac_v> chrisccoulson: yeah ,
[09:40] <chrisccoulson> sorry, i meant the patch which fixes that bug
[09:41] <mac_v> chrisccoulson: i got the icon even after the patch , so not sure if the patch was the full fix
[09:41] <chrisccoulson> mac_v - the patch fixes the issue, but i think that the icon is appearing in cases where it shouldn;g
[09:41] <chrisccoulson> in my case, it appears on inactive user sessions where g-p-m is not able to blank the display
[09:42] <chrisccoulson> i'm going to spend some time investigating it anyway, as my girlfriend is quite concerned to read that her display is broken
[09:42] <mac_v> lol... best motivator ;)
[09:42] <chrisccoulson> (which is clearly not very good wording)
[10:09] <seb128> slomo, hey, have you seen crashes similar to http://launchpadlibrarian.net/35086238/gdb-rhythmbox.txt?
[10:10] <seb128> slomo, it's an user saying rhythmbox crashes on volume change
[10:10] <slomo> seb128: yes, which gst-plugins-base version? this should be fixed since some time
[10:11] <seb128> slomo, gstreamer0.10-plugins-base 0.10.25-2ubuntu1
[10:11] <slomo> that's bad :)
[10:11] <slomo> is it reproducible?
[10:11] <seb128> it's bug #472909
[10:11] <seb128> the submitter seems to be able to trigger it easily yes
[10:12] <seb128> I don't get the issue there
[10:15] <seb128> hi kwwii
[10:16] <seb128> kwwii, is anybody working on the new wave theme?
[10:17] <seb128> hi kwwii
[10:17] <seb128> kwwii, is anybody working on the new wave theme?
[10:30] <slomo> seb128: better forward that upstream
[10:30] <seb128> slomo, ok thanks
[10:36] <seb128> kwwii, Tm_T: stop using internet
[10:38] <seb128> kwwii, Tm_T: stop using internet
[10:45] <pitti> seb128: hm, what changed two weeks ago that has made you say everything twice?
[10:47] <seb128> pitti, trying a different mode of focus which made me call previous command in IRC
[10:47] <seb128> I think I will switch back to my click focus now
[10:48] <seb128> focus changing when the mouse pointer moves is not for me
[10:48] <seb128> I keep switching between IRC and command lines
[10:48] <seb128> and when I move the mouse by mistake the focus go where it should not
[10:49] <chrisccoulson> hello everyone (again)
[10:49]  * seb128 kicks touchapd too to move cursor while I'm using the small pointer
[10:49] <seb128> hey chrisccoulson
[10:50] <chrisccoulson> hey seb128
[10:50] <chrisccoulson> having touchpad issues again?
[10:51] <seb128> chrisccoulson, having touchpad moving mouse cursor while I use the trackpoint
[10:51] <seb128> ie I've finger on this round thing in the middle of the keyboard
[10:51] <seb128> and my palm touch the touchpad
[10:51] <didrocks> pitti: thanks for avoiding me creating Quickly blueprints :)
[10:51] <seb128> it's getting annoying
[10:52] <pitti> didrocks: I just create stubs, the bits that came up during the meeting; you still need to provide the flesh :)
[10:53] <didrocks> pitti: and the code then, I guess? ;)
[10:54] <didrocks> *ouch* ;)
[10:54] <pitti> didrocks: you couldn't resist doing that yourself anyway :)
[10:54] <didrocks> haha
[10:54]  * chrisccoulson wishes people would not reply to digest messages without setting an appropriate subject
[10:58] <czajkowski> chrisccoulson: can be very annoying alright
[11:07] <chrisccoulson> downloading a 27MB source tarball over 3G is painful!
[13:00] <seb128> pitti, let me know when you have a minute to look at versions with me
[13:00] <seb128> pitti, I updated the source to lucid rather than karmic but it might need a rename of the apt index and a sources.list change
[13:00] <seb128> pitti, I would like to check that the update runs fine on your server
[13:02] <pitti> seb128: I pulled and removed index/karmic; let me re-run and create the missing dirs
[13:02] <seb128> pitti, thanks
[13:03] <pitti> SystemError: E:You must put some 'source' URIs in your sources.list
[13:03] <pitti> hmm
[13:03] <chrisccoulson> seb128 - i just saw your e-mail to ubuntu-desktop. i was just planning to respond to your e-mail yesterday with a suggestion of cleaning up some of our packages/getting patches upstream, but you beat me to it ;)
[13:03] <seb128> pitti, you will probably need to copy the sources.list manually
[13:04] <seb128> chrisccoulson, I figured that there was maybe too much in the first email since nobody commented
[13:04] <pitti> seb128: ah, it doesn't create index/lucid/etc/apt/sources.list manually?
[13:04] <seb128> so let's start with easy tasks ;-)
[13:04] <seb128> pitti, I don't think it does no
[13:04] <chrisccoulson> seb128 - i was planning to comment, but sometimes it takes me a while ;)
[13:04] <seb128> chrisccoulson, you are still welcome to comment
[13:04] <seb128> chrisccoulson, good work on those SRU btw
[13:05] <seb128> chrisccoulson, on the fixing and on the description the change, impact, etc
[13:05] <chrisccoulson> seb128 - no problem :)
[13:06] <pitti> seb128: running now
[13:06] <seb128> pitti, danke
[13:08] <seb128> pitti, http://piware.de/workitems/desktop/karmic/versions.html, that didn't work apparently
[13:09] <pitti> oops, I should rename it
[13:09] <seb128> pitti, let it there or have both working please, I just sent an email with this url
[13:09] <seb128> ok, clicking on + it has everything
[13:09] <seb128> so small bug
[13:09] <fredp> seb128, pitti: there's an error in devhelp upstream version detection, in that page.
[13:10]  * seb128 looks into the issue
[13:10] <pitti> ok, keeping old symlink then
[13:10] <pitti> but it won't be correct for "karmic"
[13:10] <pitti> seb128: copied back to karmic/
[13:10] <seb128> pitti, right, thanks
[13:10] <pitti> seb128: the + is weird, that didn't happen before
[13:11] <pitti> seb128: the cron job bzr pulls automatically, so just commit and it should sort itself out
[13:11] <seb128> pitti, ok thanks
[13:11] <seb128> fredp, hum right, I will look into that too
[13:12] <seb128> pitti, ok, no http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.lucid/desktop
[13:12] <seb128> pitti, that's what is used to build the default list
[13:12] <pitti> seb128: ah, where does it take its data from then?
[13:13] <seb128> pitti, the list of sources to watch is in the versions.py file
[13:13]  * pitti asks cjwatson
[13:13] <seb128> the germinate list is only used to define the default set
[13:13] <seb128> ie what to show in the default page
[13:13] <seb128> and what in the "+" section
[13:13] <seb128> no germinate = only extra items
[13:14] <pitti> what defines the extra items?
[13:14] <seb128> the things listed in versions.py but not in germinate
[13:14] <seb128> the default list is an intersection of versions.py list and germinate desktop list
[13:15] <seb128> and things out of the intersection are extra items
[13:15] <seb128> ie right now germinate says desktop is empty so everything is in extra
[13:15] <seb128> I will change back to the karmic germinate for now
[13:15] <seb128> shouldn't make a real difference
[13:17] <seb128> change pushed
[13:17] <seb128> it should be ok in the next run
[13:17] <pitti> thanks; I pinged colin about lucid germinate
[13:17] <seb128> thank you
[13:18] <seb128> fredp, it's a vuntz bug
[13:18] <seb128> fredp, we use http://www.gnome.org/~vuntz/tmp/versions/versions-2.28
[13:20] <mac_v> seb128: hi , this is not a theme bug > Bug #472659 , gvfs now does not change icons for the different  states
[13:21] <vuntz> seb128: a vuntz bug? But I have no bug!
[13:21] <seb128> mac_v, ok, I knew that was a duplicate and I figured theme guys would know
[13:21] <seb128> vuntz, hey ;-)
[13:22] <vuntz> what's the bug? :-)
[13:22] <seb128> vuntz, the devhelp versions in your list
[13:23] <seb128> it's outdated
[13:23] <mac_v> seb128: hmm , why the bookmarks in the nautilus sidepane are below the filesystems and the drives... away from the desktop and home... gnome-panel , places menu seems to have a sane order.. is it to keep it similar to the gtk window?
[13:23] <seb128> mac_v, dunno
[13:24] <mac_v> hm...
[13:25] <mac_v> vuntz: ^ any ideas about the nautilus sidepane[ or why gnome-panel is more sensible ] ;)
[13:25] <vuntz> because the code is different? :-)
[13:25] <vuntz> nautilus might try to do something clever
[13:26] <mac_v> ;)
[13:29] <vuntz> seb128: and it wasn't a vuntz bug, nah
[13:30] <seb128> vuntz, which means you fixed it? ;-)
[13:30] <seb128> there is no bug there *jedi wave*
[13:31] <vuntz> yep, it's fixed
[13:31] <seb128> thanks
[13:36] <seb128> pitti, I'm unlock the retracers btw, if they crash don't bother it's my turn to look at those
[13:36] <pitti> seb128: merci
[13:37] <seb128> de rien!
[13:37] <seb128> unlocking
[13:47] <rickspencer3> bonjour desktoppers
[13:47] <pitti> hey rickspencer3
[13:48] <seb128> lut rickspencer3
[13:48] <seb128> how are you?
[13:48] <rickspencer3> bon
[13:48] <rickspencer3> je sui bon
[13:48] <rickspencer3> ?
[13:49] <seb128> je vais bien
[13:49] <seb128> bien
[13:49] <rickspencer3> hehe
[13:49] <rickspencer3> I said "I have beuty" maybe .. oops
[13:49] <seb128> je suis bon = I rock
[13:49] <seb128> or whatever you would say in english to say that you do good job
[13:50] <rickspencer3> hmm
[13:50] <rickspencer3> that's good to know
[13:56] <rickspencer3> seb est bon
[13:56] <rickspencer3> ?
[13:56] <kenvandine> hey guys
[13:56] <seb128> rickspencer3, thanks ;-)
[13:56] <seb128> (yes, correctly written)
[13:56] <seb128> hello kenvandine, how are you?
[13:57] <kenvandine> need more coffee, but good :)
[13:57] <kenvandine> and you ?
[13:57] <seb128> I'm good thanks
[13:57] <rickspencer3> seb128, and also correct
[13:57]  * kenvandine is annoyed with virt-manager atm
[13:57] <rickspencer3> chouette!
[13:57] <seb128> starting to look at cleaning http://piware.de/workitems/desktop/karmic/versions.html
[13:57] <seb128> rickspencer3, ;-)
[13:57] <seb128> or rather http://piware.de/workitems/desktop/lucid/versions.html
[13:58] <seb128> pitti, ^ the list looks fine now
[13:58] <chrisccoulson> excellent, i should start some lucid work now:)
[13:59] <chrisccoulson> unless there is anything else that wants looking at for karmic SRU's?
[14:01] <seb128> chrisccoulson, nothing really on my list no
[14:24] <Laney> op hopping?
[14:24] <seb128> IRC client config for easier op-ing rather ;-)
[14:24] <seb128> working now
[14:25] <seb128> I don't need to stay op btw
[14:27] <seb128> I needed it in the first place to change topic right
[14:27] <seb128> lucid milestone there now
[14:28] <seb128> and updated url for the versions list too
[14:28] <seb128> not to self
[14:28] <seb128> the x in the topic bar in xchat-gnome close the channel
[14:28] <seb128> not the title
[14:28] <istaz> :D
[14:28] <seb128> not -> note
[14:31] <seb128> hum
[14:31] <seb128> pitti,  "HTTP Error 401: Unauthorized" do you know what create such retracer errors usually?
[14:31] <pitti> seb128: no, they started to happen a few days ago, and I didn't try to track it down yet
[14:32] <seb128> ok
[14:32] <seb128> pitti, is there a lpcookie there needed to write comments or something?
[14:32] <seb128> which would be outdated
[14:32] <pitti> I don't think so, since it does work for other bug reports
[14:32] <seb128> ok
[14:32] <pitti> the retracer closed dozens of dupes recently
[14:32]  * seb128 removes lock
[14:33] <seb128> let see if it works on a retry
[14:47] <hggdh> one more bug -- bug 445435 -- this was originally set as a dup of bug 460710, but the problem still exists. Upstream fixed it on gtk+
[14:47] <seb128> hggdh, the probably is neither the theme nor the gtk one?
[14:48] <hggdh> seb128: mbarnes fixed it on gtk itself. I intend to debdiff it against karmic and lucid, but will build a PPA for tests before proposing official changes
[14:48] <hggdh> is this OK?
[14:50] <seb128> hggdh, the change on bug #393534 is the fix from mbarnes
[14:50] <seb128> hggdh, no?
[14:50] <hggdh> let me check
[14:50] <seb128> hggdh, http://launchpadlibrarian.net/34957620/gtk.debdiff
[14:52] <hggdh> yes indeed, they are the same. I will dup against 393534
[14:52] <seb128> hggdh, note that the tif issue was dupped on the gtk one originally I think
[14:53] <mac_v> seb128: is asac on vacation? users to say this Bug 386900 is not fixed
[14:53] <seb128> mac_v, yes for the week he is
[14:53] <hggdh> seb128: no, it was dupped against 460710, this is what confused me
[14:54] <hggdh> heh. It *was* originally dupped against 393534, but then you changed it to 460710 ;-)
[14:54] <seb128> hggdh, see comment #15
[14:54] <mac_v> seb128: hmm , does the notification for you also still display "eth0" ? [i'm not able to check that , i dont use a wired connection]
[14:54] <hggdh> seb128: see https://bugs.edge.launchpad.net/ubuntu/+source/gtk+2.0/+bug/445435/+activity
[14:54] <seb128> mac_v, dunno I'm on wireless right now
[14:54] <mac_v> lol ;)
[14:54] <seb128> hggdh, right, see comment #15
[14:55] <seb128> hggdh, could be yet another bug and none of those two
[14:55] <seb128> hggdh, could be yet another bug and none of those two
[14:56] <hggdh> yes, it could
[14:57] <hggdh> and sounds like it :-(
[14:58] <seb128> or he didn't test correctly the upgrade
[14:59] <hggdh> maybe. I am asking him to send me such an email, and then I will be able to test locally
[15:00] <seb128> thanks
[15:28]  * seb128 does a work break
[15:28] <seb128> be back in a bit
[15:53] <seb128> pitti, robert_ancell has an another totem sru ready to upload
[15:53] <seb128> pitti, what do you prefer to do? put it in the queue now? wait for the current on to move to updates?
[15:55] <pitti> seb128: I think upload it now, with -v
[15:55] <seb128> pitti, ok, doing that
[15:55] <pitti> seb128: the previous one is 6 days old, but has zero verification
[15:56] <seb128> pitti, ok
[15:56] <seb128> pitti, the new one fixes youtube which seems to be something lot of user want to use
[15:56] <seb128> we get a dup a day since karmic
[15:57] <seb128> I would have though most people were browsing it in a web browser
[16:24] <seb128> chrisccoulson, good evening
[16:24] <chrisccoulson> hi seb128
[16:24] <chrisccoulson> how are you?
[16:24] <seb128> good thanks, you?
[16:25] <seb128> did you have some sru changes pending upload?
[16:25] <chrisccoulson> yeah, i'm not too bad - just waiting for the end of the working day now ;)
[16:25] <chrisccoulson> i've still got a g-s-d update pending upload
[16:26] <seb128> chrisccoulson, ok, you didn't subscribe sponsors?
[16:26] <seb128> I don't find it on http://people.canonical.com/~dholbach/sponsoring/index.html
[16:26] <seb128> but I though I had read a bug comment with a debdiff earlier
[16:26]  * seb128 look in his launchpad email box
[16:27] <chrisccoulson> yeah, i subscribed ubuntu-sru, as it hasn't had approval from anybody yet
[16:27] <seb128> it's the other way around
[16:27] <seb128> or I think it should be the other way around
[16:27] <chrisccoulson> yeah, i wasn't sure really
[16:27] <seb128> subscribe sponsors and the sponsor will subscribe the sru team on upload
[16:27] <chrisccoulson> normally i just ping pitti, but it was late last night ;)
[16:28] <seb128> ok, http://launchpadlibrarian.net/35063102/gnome-settings-daemon_2.28.1-0ubuntu2.debdiff gotcha
[16:28] <seb128> chrisccoulson, thanks
[16:29] <seb128> chrisccoulson, btw feel free to commit those changes to bzr normally too
[16:30] <chrisccoulson> seb128 - yeah, i can do that when i get in from work. i wasn't sure how we handled bzr branches with SRU's. do we have separate karmic branches now? (i suppose it doesn't matter in this particular case, as it will just get copied to lucid anyway)
[16:30] <seb128> robert_ancell asked yesterday
[16:30] <seb128> we don't have consistent rule
[16:31] <seb128> if karmic version = lucid one, no question, just commit to bzr
[16:31] <seb128> if karmic version = lucid one, no question, just commit to bzr
[16:31] <chrisccoulson> yeah, that's what confuses me a bit. in this case though, i think it's a bit easier
[16:31] <chrisccoulson> yeah, i'll commit this one when i arrive home
[16:31] <seb128> if that's not the case either create a new bzr and update control
[16:31] <seb128> or don't bother using bzr just add the debdiff to the bug
[16:31] <seb128> I tend to not bother if there is not lot of changes scheduled
[16:32] <seb128> chrisccoulson, don't bother I'm commiting the debdiff now
[16:32] <chrisccoulson> thanks
[16:33] <seb128> chrisccoulson, the crash issue, did you upstream it yet?
[16:35] <mac_v> and471: hey.. you marked Bug 386900 as fix released but users are saying its not fixed... you tested it on a fresh install or upgrade? could you comment on the bug
[16:35] <chrisccoulson> seb128 - not yet. i'll report it upstream later, but i want to think of a better long-term fix really which closes the dialog when the volume is removed. that type of fix would be too intrusive for a SRU though
[16:36] <mac_v> and471: do subscribe to any bug you comment ;)
[16:36] <and471> mac_v: probably not :-)
[16:37] <mac_v> and471: i meant>  *do* subscribe... as in> "always subscribe"
[16:37] <seb128> chrisccoulson, ok, g-s-d uploaded
[16:37] <chrisccoulson> thanks
[16:37] <chrisccoulson> right, time for me to leave work now
[16:37] <seb128> thank you for doing all the work ;-)
[16:37] <seb128> see you later!
[16:37] <chrisccoulson> heh, that's ok ;)
[16:37] <chrisccoulson> bbl
[16:38] <seb128> seems that pitti has been tackling some email backlog today ;-)
[16:38] <and471> mac_v: I cannot test it, I am on wireless :-) However whn I tested it in a virtual machine around mid-way karmic, it was working..
[16:39] <mac_v> seb128: since he responded to your mail? ;p
[16:39] <seb128> not only, also to the bugs I subscribed him too
[16:39] <seb128> but yes ;-)
[16:39] <mac_v> ;)
[16:39] <and471> ANYONE: if you are a wired connection, could you unconnect, then reconnect and take a screenshot of what the notification looks like (the connection notification that is)
[16:40] <mac_v> and471: but did you test earlier , when you marked it released?
[16:40] <and471> mac_v: yes
[16:40] <mac_v> oh , late comment
[16:40] <mvo> and471: I merge the bit you asked me about yesterday btw, was just a odd merge
[16:40] <and471> mac_v: how many papercuts were fixed this cycle?
[16:40] <and471> mvo: okay thanks :-)
[16:41] <mac_v> and471: its a dont ask dont tell policy... ;p
[16:41] <mac_v> and471: so dont ask ;p
[16:41] <and471> mac_v: hehe
[16:47] <seb128> mac_v, and471: http://people.canonical.com/~seb128/notifyosd.png
[16:47] <seb128> mac_v, and471: http://people.canonical.com/~seb128/notifyosd.png
[16:47] <seb128> that's on a karmic iso booted in kvm
[16:47] <and471> seb128: thankyou
[16:47] <seb128> you're welcome
[16:48] <and471> mac_v: so looks like it hasn't been fixed :-(
[16:48] <and471> mac_v: maybe a regression?
[16:48] <mac_v> seb128: thanks... and471 -> argh :/
[16:48] <mac_v> and471: lol , what regression?
[16:48] <and471> mac_v: well when I looked at it, I really think it was solved :-/
[16:48] <and471> mac_v: maybe I was tired ?
[16:49] <mac_v> and471: did you try again in the VW?
[16:49]  * mac_v missing asac :(
[16:49] <and471> mac_v: VW?
[16:49] <and471> mac_v: ^ hehe
[16:49] <mac_v> and471: virtualbox?
[16:49] <mac_v> i i mean VM!
[16:49] <and471> mac_v: I haven't tried again yet
[16:50] <and471> mac_v: don't really have time
[17:05] <rickspencer3> didrocks, people are actually using Quickly!
[17:05] <rickspencer3> I saw we got a good merge proposal today
[17:07] <mac_v> mpt: is Bug 386900 fixed for you?
[17:08] <mpt> mac_v, yes
[17:08] <mac_v> mpt: odd , seb128 and thorwil dont seem to have it fixed
[17:08] <mac_v> aw ,crap! , i just changed the status
[17:09] <mac_v> mpt:  http://people.canonical.com/~seb128/notifyosd.png
[17:09] <seb128> ^ it's a screenshot from a karmic iso booted in kvm
[17:09] <mpt> hm
[17:09] <mpt> brb
[17:11] <mpt> mac_v, ugh, I just got "Auto eth2 Connection Established"
[17:11] <mpt> I guess it's not fixed
[17:11] <mac_v> mpt: yeah , the upstream task hasnt even been touched... :(
[17:15] <didrocks> rickspencer3: yeah, that's a good news  :) (even if my trunk already contained this patch ;)). That's great \o/
[17:19] <hggdh> will packages from multiverse block apport ("not an original Ubuntu package" error)?
[17:19] <seb128> hggdh, should not
[17:19] <seb128> hggdh, but I can confirm the empathy issue
[17:20] <hggdh> oh you looking at the -bugs?
[17:20] <seb128> hggdh, need to ping pitti about that when he will be around, he seems to be away now
[17:20] <seb128> hggdh, yes
[17:20] <hggdh> seb128: will do
[17:20] <hggdh> do you have the bug#?
[17:20] <seb128> hggdh, what bug? no
[17:21] <seb128> hggdh, I just confirm that ubuntu-bug empathy breaks
[17:21] <hggdh> oh, OK
[17:21] <seb128> but it might be because I did built it locally and didn't reinstall the archive version
[17:28] <seb128> hggdh, pitti: sorry for the noise was a local install
[17:45] <pitti> re
[17:45] <pitti> seb128: what's up?
[17:45] <seb128> pitti, nothing
[17:46] <seb128> pitti, an user add apport refusing to report a bug against empathy
[17:46] <seb128> pitti, it's because he used the karmic-proposed version without karmic-proposed source
[17:46] <seb128> I guess apport rely on you having a source providing the deb
[17:46] <seb128> add -> had
[17:46] <pitti> yes, otherwise you can't determine the origin
[17:46] <seb128> right, I figured the issue after pinging
[17:47] <seb128> so basically unping ;-)
[17:57] <hggdh> so the deb-src corresponding to the package has to be active? Is this the default for apt?
[17:57] <hggdh> or only for -proposed?
[17:58] <seb128> hggdh, no, the deb
[17:58] <seb128> not deb-src
[17:58] <seb128> he got the deb manually there or commented the source after installing
[17:59] <hggdh> oh, OK
[17:59]  * hggdh is *very* slow, mentally speaking, today
[18:40] <pitti> good night everyone
[19:05] <chrisccoulson> seb128 - currently, the only effect of the crash in bug 429322 is that a crash report appears (as the crash occurs when seahorse-agent exits). with apport disabled by default, is it worth a SRU? theoretically, we should see this one reported less often now, and there aren't any other side effects
[19:06] <chrisccoulson> obviously, it's not so good if lots of people enable apport
[20:41] <crevette> why debugfs is mounted (/sys/kernel/debug) in my karmic installation, is it a normal behaviour?
[21:18] <cherva> can anyone help me fix my nautilus after the upgrade to 9.10 ? When I try to start it I get this http://pastebin.com/d3c19348
[21:18] <crevette> I guess you didn't upgraded properly
[21:19] <crevette> you have an older glib
[21:22] <cherva> crevette: how to fix it ? I had errors about gnome-themes, gnome-accessibility-themes and gnome-themes-selected - http://pastebin.com/d4d9c8804
[21:22] <crevette> how did you upgrade
[21:23] <seb128> cherva, ldd /usr/bin/nautilus | grep libglib
[21:24] <seb128> cherva, ldd /usr/bin/nautilus | grep libglib
[21:24] <crevette> the missing symbosl is a new one introduces in latest glib
[21:24] <cherva> libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x003f9000)
[21:24] <seb128> there you go
[21:25] <crevette> ouch
[21:25] <cherva> crevette: I upgraded from the update manager
[21:25] <seb128> you did a make install of an old lib
[21:25] <seb128> classic error
[21:25] <seb128> you don't use the distribution version but a copy you installed
[21:25] <seb128> clean it and you should be fine
[21:26] <cherva> seb128: you mean the libglib2.0-0 package ?
[21:26] <seb128> no
[21:26] <seb128> I mean you did build and install a glib version at some point by yourself out of the packaging system
[21:27] <seb128> you might have forgotten about it but it's still in the local dir
[21:27] <seb128> and it's taking over the ubuntu version
[21:27] <seb128> and breaking things for you
[21:28] <cherva> seb128: I'm not sure how to remove it ...
[21:28] <seb128> cherva, you did install it you should know how to remove it
[21:31] <cherva> seb128: I don't remember when I did this .... my machine is upgrading since 6.10
[21:31] <seb128> cherva, sudo rm /usr/local/libglibù
[21:31] <seb128> cherva, sudo rm /usr/local/libglib*
[21:31] <seb128> you probably want to clean other things there too
[21:32] <seb128> I can't advice you to delete everything since I don't know what you installed and why
[21:32] <cherva> seb128: I'll check this
[21:33] <crevette> wow, I've uploaded a package in ppa which will be build in two days :)
[21:33] <lifeless> james_w: thank you. For some reason I don't recall seeing that answer ever.
[21:33] <james_w> lifeless: slightly more in depth this time :-)
[21:34] <james_w> I found my reply to the first mail though
[21:36] <lifeless> james_w: I'll sit and read, I think a howto is needed :P
[21:36] <cherva> seb128: now what ? install libglib from the repo ?
[21:36] <james_w> lifeless: well, it's supposed to be transparent
[21:36] <seb128> cherva, no, just run nautilus
[21:37] <cherva> seb128: same error
[21:37] <james_w> you only want one because you care about the implementation details :-)
[21:37] <seb128> cherva, sudo rm /usr/local/* -r
[21:38] <seb128> just clean everything there
[21:38] <seb128> if you don't have anything installed you use
[21:38] <lifeless> james_w: there is a disconnect here
[21:38] <lifeless> james_w: transparent => dead easy to use is great. Knowing the feature exists and how to make sure it works is a matter of education
[21:41] <cherva> seb128: thanks
[21:42] <seb128> cherva, you're welcome
[22:01] <chrisccoulson> going to the supermarket at this time of the evening is never a good ieda
[22:01] <chrisccoulson> s/ieda/idea
[22:01] <chrisccoulson> i always pick up something really bad
[22:07] <seb128> chrisccoulson, you have supermarked open that late?
[22:07] <seb128> chrisccoulson, where do you live? ;-)
[22:07] <chrisccoulson> seb128 - we have supermarkets open all night ;)
[22:08] <chrisccoulson> i live in birmingham. well, near birmingham...
[22:08] <chrisccoulson> night time is the best time to shop!
[22:08] <Laney> there are a lot of 24 hour supermarkets in the uk
[22:09] <seb128> cultural differences
[22:09] <seb128> there is not a lot of things open after 7pm there
[22:09] <seb128> and I don't think anything after 9pm
[22:10] <chrisccoulson> yeah, most shops on retail parks seem to shut around 8pm here, and high-street shops tend to close around 6pm
[22:10] <rickspencer3> robert_ancell, TheMuso good morning
[22:10] <chrisccoulson> but we have quite a lot of 24 hour supermarkets, which are sometimes useful
[22:10] <robert_ancell> chrisccoulson, night time _is_ the best!
[22:10] <chrisccoulson> robert_ancell - i'm definately a night-time person!
[22:11] <robert_ancell> rickspencer3, hey
[22:11] <seb128> hey robert_ancell
[22:11] <robert_ancell> seb128, hey
[22:11]  * seb128 starts hating bugs again
[22:12] <chrisccoulson> robert_ancell - have you looked any more at bug 429322?
[22:12] <robert_ancell> seb128 - you stopped hating bugs?
[22:12] <seb128> I didn't look at those so much for a few months
[22:12] <robert_ancell> chrisccoulson, it's deep down in gconf/orbit somewhere - something must be assuming the x server is still around.
[22:12] <seb128> I do for a week
[22:13] <seb128> I got some 4300 bug emails in a week
[22:13] <chrisccoulson> robert_ancell - yeah, it seems that way
[22:13] <seb128> I did read those all but I'm saturating now
[22:13] <seb128> I need to do something else tomorrow
[22:13] <robert_ancell> seb128, we need some bots to go around closing stuff...
[22:13] <seb128> what I really want is a "I don't care" button
[22:14] <seb128> I would use it on 80% of bugs
[22:14] <seb128> there is really some 15% interesting ones
[22:14] <seb128> and some feature requests too
[22:14] <seb128> so many "bugs" which are user questions
[22:14] <seb128> or duplicates
[22:14] <seb128> or one time weird issues
[22:14] <seb128> or so minor corner cases
[22:16] <chrisccoulson> robert_ancell - the way it exits is seriously messed up. when it exits, global_client_free() is called, which frees the global GConfClient. Then, seahorse_agent_uninit() is called, which unregisters some gconf notifies, which causes the global GConfClient to get allocated again (after it was already freed), and it does all the gconf_client_add_dir() stuff that it does when it initializes
[22:17] <chrisccoulson> it's really weird :-/
[22:17] <robert_ancell> chrisccoulson, eech
[22:18] <chrisccoulson> robert_ancell - global_client_free() and seahorse_agent_uninit() are registered as exit handlers with atexit()
[22:18] <chrisccoulson> so they always get called when the X connection dies, but they are registered in the wrong order really
[22:19] <chrisccoulson> this orbit stuff is way over my head though
[22:20] <robert_ancell> chrisccoulson, yeah we need the gconf replacement so we don't have to look at it :)
[22:20] <chrisccoulson> yeah, orbit sucks :(
[22:21] <chrisccoulson> do gconf clients need a working X connection to add notifies then?
[22:21] <chrisccoulson> if that's the case, then the fix is to not attempt to do any gconf stuff when the X connection dies, as it's already too late to do anything then
[22:21] <chrisccoulson> or, as mclasen pointed out yesterday, seahorse-agent needs to become a proper session agent
[22:22] <chrisccoulson> and not run from /etc/X11/Xsession.d
[22:52] <robert_ancell> seb128, thanks for putting the debdiffs for the totem changes.  There are too many people changing that bug!
[22:53] <seb128> robert_ancell, you're welcome
[22:53] <seb128> robert_ancell, btw please subscribe sponsors to your bugs that need sponsoring
[22:53] <seb128> that will make things easier to track
[22:53] <seb128> if I stop reading those thousand bug emails I will stop noticing your changes too
[22:53] <robert_ancell> seb128, I subscribed ubuntu-sru - isn't that correct?
[22:53] <seb128> no, ubuntu-sru is those who accept the upload
[22:54] <seb128> subscribe the sponsors
[22:54] <seb128> the sponsor will subscribe sru
[22:54] <seb128> not sure if that's clear ;-)
[22:55] <seb128> the sponsor will decide if that's worth a sru and upload for you
[22:55] <seb128> the sru team will accept things in the queue
[22:55] <robert_ancell> I'm following https://wiki.ubuntu.com/StableReleaseUpdates which says subscribe ubuntu-sru
[22:55] <seb128> btw sru bugs should have testcases and debdiff usually
[22:55] <robert_ancell> seb128, yes, I keep forgetting debdiffs
[22:56] <seb128> robert_ancell, the wikipage seems to not consider sponsoring cases
[22:57] <robert_ancell> seb128, so it's written from the point of view of someone with upload privileges?
[22:57] <seb128> well, steps 3 and 4 go together
[22:58] <robert_ancell> ah, ok
[22:58] <seb128> you can subscribe the sru team but subscribe sponsors too
[22:58] <seb128> sru do review
[22:58] <seb128> they don't do uploads
[22:58] <seb128> ie they will not have something to review and wait for you to upload
[22:59] <robert_ancell> ok
[22:59] <seb128> I've no strong opinion on whether ubuntu-sru should be subscribed before or after upload, ie if you or the sponsor should do it
[22:59] <seb128> I tend to do it after update
[22:59] <seb128> to not make them waste time until things are ready
[23:00] <seb128> ie if you subscribe the sru team they will get sponsor comments about things you did wrong too
[23:00] <seb128> I prefer to get them in the loop when their input is required
[23:00] <seb128> ie after upload
[23:00] <seb128>
[23:00] <seb128> other topic
[23:01] <seb128> robert_ancell, have you seen my new ubuntu-desktop email today?
[23:02] <seb128> the versions page has been updated for lucid
[23:02] <seb128> and merge season has opened ;-)
[23:02] <seb128> I didn't update the gnome version list to 2.30 yet though
[23:02] <seb128> we should maybe do that too
[23:02] <robert_ancell> seb128, yes - lets go!!
[23:03] <seb128> feel free to do changes
[23:03] <seb128> the server side to pull before running updates
[23:03] <seb128> to -> do
[23:03] <seb128> so if you push changes they will be there on the next run
[23:03] <chrisccoulson> i need to start on some merges rather than spending all my time on SRU's!
[23:05] <robert_ancell> seb128, oh good, I can stop bugging you guys to update it :)
[23:06] <seb128> chrisccoulson, no hurry for lucid if you still have things you think should be srued in karmic
[23:07] <seb128> I think we did address the most annoying issues which we can change in srus now
[23:07] <seb128> or rather the annoying one which got user traction
[23:07] <seb128> I've no doubt there is many things annoying some users left
[23:07] <chrisccoulson> yeah, i think a lot of issues are sorted now
[23:08] <chrisccoulson> i'm trying to figure out this seahorse-agent crash at the moment
[23:09] <seb128> is that a logout crash?
[23:09] <seb128> ie something nobody would notice if apport was not running?
[23:09] <seb128> we should try to teach apport to ignore those
[23:10] <seb128> or at least to detect those and note it in the bug
[23:10] <chrisccoulson> seb128 - i'm fairly convinced it's just a logout crash
[23:10] <chrisccoulson> the crash occurs when the X connection dies
[23:10] <seb128> don't waste too much efforts on it
[23:10] <chrisccoulson> so i don't think that users would notice it if apport wasn't running
[23:12] <robert_ancell> seb128, how do I make the sources.list to make version work?  It needs some lucid entries
[23:12] <seb128> robert_ancell, copy the karmic one and change karmic to lucid
[23:13] <robert_ancell> seb128, ah, edit index/lucid/etc/apt/sources.list?
[23:13] <seb128> yes
[23:21] <seb128_> grrrr trackpads
[23:22] <seb128_> robert_ancell, did you fix your sources.list issue?
[23:23] <robert_ancell> seb128_, what is the debian release we are tracking?
[23:23] <seb128_> you didn't read my email!!!
[23:23] <seb128_> unstable
[23:24] <robert_ancell> I mean the URI :)
[23:24] <seb128_> the debian source didn't change
[23:25] <seb128_> deb http://ftp.debian.org/debian/ unstable main
[23:25] <seb128_> deb http://ftp.debian.org/debian/ ../project/experimental main
[23:25] <seb128_> deb-src http://ftp.debian.org/debian/ unstable main
[23:25] <seb128_> deb-src http://ftp.debian.org/debian/ ../project/experimental main
[23:25] <joaopinto> aren't we tracking testing for lucid ?
[23:25] <seb128_> deb http://archive.ubuntu.com/ubuntu/ lucid main restricted universe multiverse
[23:25] <seb128_> deb-src http://archive.ubuntu.com/ubuntu/ lucid main restricted universe multiverse
[23:25] <seb128_> joaopinto, as I wrote in my email today GNOME is maintained enough and uptodate enough in ubuntu that we will use unstable
[23:26] <seb128_> unstable has GNOME 2.28 and we will aim at GNOME 2.30 anyway in lucid
[23:26] <joaopinto> ah ok, did knew there were exceptions :)
[23:26] <joaopinto> didn't
[23:26] <seb128_> well the default is testing
[23:26] <seb128_> but then it's up to anybody to decide for the things he,she is working on
[23:27] <robert_ancell> seb128_, ah, fixed.  Needed to check in the lucid sources.list, forgot the debian one was already checked in
[23:28] <seb128_> robert_ancell, ok good
[23:29] <chrisccoulson> robert_ancell - i think i can see what triggers the seahorse-agent crash now
[23:29] <robert_ancell> seb128_, I'm thinking of making a script that parses gnome FTP and LP updates so we can update versions in near real time
[23:30] <seb128_> robert_ancell, you mean something to run on client side?
[23:30] <chrisccoulson> liborbit calls g_atexit(shutdown_orb) at some point when seahorse-agent starts
[23:30] <robert_ancell> seb128_, server side
[23:30] <robert_ancell> chrisccoulson, cool!
[23:30] <robert_ancell> chrisccoulson, ycuk
[23:30] <robert_ancell> tuck
[23:30] <robert_ancell> yuck
[23:30]  * robert_ancell can type good
[23:31] <chrisccoulson> and shutdown_orb() is called on exit before seahorse_agent_exit() is called
[23:31] <seb128_> robert_ancell, what updates do you want to parse there?
[23:31] <robert_ancell> seb128_, email from gnome-ftp and LP
[23:31] <chrisccoulson> seahorse_agent_exit() tries to do some gconf stuff, which probably fails miserably once shutdown_orb() has been called
[23:31] <seb128_> the rss feeds for gnome updates?
[23:31] <seb128_> hum, why not
[23:32] <robert_ancell> chrisccoulson, I'm sure it doesn't like that :)
[23:37] <chrisccoulson> robert_ancell - so Xorg dying is actually a red-herring. the crash will occur whenever exit() is called from any code path
[23:37] <chrisccoulson> which still probably makes it a non-issue for karmic really
[23:38] <robert_ancell> chrisccoulson, but does it restart?  I got some of the reporters to check if it was running after the problem and they said no
[23:38] <chrisccoulson> robert_ancell - i think it only crashes on shutdown doesn't it?
[23:38] <chrisccoulson> the crash report at the start of the session could be from their previous session
[23:40] <robert_ancell> chrisccoulson, sure


[00:26] <harlowja> smoser https://review.openstack.org/#/c/166201/ fyi
[00:26] <harlowja> useful to look at/over
[10:54] <Odd_Bloke> smoser: Is there any reason for having documentation in /doc that isn't in /doc/rtd/... (and therefore rendered on ReadTheDocs)?
[11:48] <Odd_Bloke> smoser: Does http://bazaar.launchpad.net/~daniel-thewatkins/cloud-init/openstack-vendor-data-doc/revision/1089 look sensible to you?
[11:49] <Odd_Bloke> smoser: (I'm waiting for confirmation from the partner that triggered this investigation that we've solved their problem before opening a MP)
[12:59] <smoser> Odd_Bloke, i think i'd like to have something like:
[12:59] <smoser>  http://bazaar.launchpad.net/~daniel-thewatkins/cloud-init/openstack-vendor-data-doc/revision/1089
[12:59] <smoser> for all vendor-data consumption
[12:59] <smoser> i tihnk we can do this in a backwards compatible mode to if we do it right.
[13:00] <smoser> hm.. well i tihnk we want to do this well.
[13:02] <smoser> sorry.
[13:02] <smoser> bad link above.
[13:02] <smoser> whic his confusing
[13:02] <smoser> https://etherpad.openstack.org/p/cloud-init-vendor-data
[13:02] <smoser> i' dlike to hvae that basic policy in place for all vendor data consumption i think.
[13:50] <ktdreyer> hi folks, I'm wondering about the "#cloud-config" text that I see at the top of cloud-init YAML files. Isn't that a comment in YAML syntax? But cloud-init relies upon its presence?
[13:52] <Odd_Bloke> smoser: OpenStack falls over if vendor-data is just a string; I didn't try with a list.
[13:52] <Odd_Bloke> smoser: But I wouldn't be surprised if OpenStack requires a JSON object.
[13:52] <smoser> Odd_Bloke, well, it does.
[13:52] <smoser> but a string is valid json
[13:53] <smoser> watch:
[13:53] <smoser> $ python -c 'import sys, json; print(json.dumps(sys.argv[1], indent=1))' "Hi Odd_Bloke"
[13:53] <Odd_Bloke> A string is valid JSON; it's not a valid JSON object.
[13:54] <smoser> watch
[13:54] <Odd_Bloke> (As a JSON object is defined as a mapping)
[13:56] <smoser> http://paste.ubuntu.com/10718416/
[13:56] <smoser> you can argue if you want that python's json module is behaving incorrectly
[13:57] <smoser> but that same 'loads' is how openstack is going to check if its valid json
[13:57] <smoser> $ python /tmp/go.py
[13:57] <smoser> contents: "Hi Mom"
[13:57] <smoser> data: Hi Mom
[13:58] <smoser> ktdreyer, yes. cloud-init depends on it in some contexts.
[13:58] <Odd_Bloke> smoser: "foo" is valid JSON, but it's not a JSON object.  A JSON object is a mapping ({"foo": "bar", ...}), and is one of the valid root objects in valid JSON.
[13:58] <Odd_Bloke> As are strings.
[13:58] <smoser> in /etc/cloud/cloud.cfg.d , it probably assumes a default of cloud-config (which is sane).
[13:58] <Odd_Bloke> So I think we're talking past one another here. :)
[13:59] <smoser> ktdreyer, but in other cases, it doens't know what the content of the file is... how to interpret it. so it relies on either data provided to it about the content (such as mime-type) or the content starting with a string.
[14:00] <smoser> well, kyou said openstack will fail if vendor-data is just a string
[14:00] <smoser> but i dont think it would
[14:00] <Odd_Bloke> If it assumes that it will get a mapping and looks for specific keys it might; I'm trying to get back on to that OpenStack cloud to try again.
[14:01] <smoser> i wrote it.
[14:01] <smoser> its a blob
[14:01] <smoser> it makes sense.
[14:01] <smoser> its a contract / data from "vendor" to "guest"
[14:02] <smoser> openstack is not involved.
[14:02] <Odd_Bloke> Ack; I'll try and work out what I was doing wrong.
[14:03] <smoser> Odd_Bloke, i'm not saying that we should use a string.
[14:03] <smoser> i think the dict or list makes more sense.
[14:03] <smoser> and cloud-inti shoudl take the 'cloud-init' entry in that.
[14:04] <smoser> that is what we should make work, and what we should recommend to vendors.
[14:04] <Odd_Bloke> Yeah; that does work.
[14:07] <smoser> Odd_Bloke, fwiw, this whole "string as an object" conversation, I had almost identically with JayF when i first wrote that etherpad.
[14:08] <smoser> :)
[14:10] <Odd_Bloke> smoser: http://json.org/ says that strings categorically are not JSON objects. But JSON objects are not the only valid JSON root type.
[14:10] <Odd_Bloke> So we're just in violent agreement here. :p
[14:12] <smoser> well, just to be snarky, and add more violent agreement
[14:12] <smoser> $ python -c 'import json, sys; print(isinstance(json.loads(sys.argv[1]), object))' '"foo"'
[14:12] <smoser> True
[14:12] <smoser> :)
[14:12] <Odd_Bloke> :D
[14:13] <smoser> openstack expects the VendorData class (which defaults to that thing that reads data from a json file)
[14:13] <smoser> to return data
[14:13] <smoser> it then 'json.dumps()' that to a file-like thing that it shows in the metadata service.
[14:14] <smoser> the VendorData class could return anything, but openstack is going to force that thing to be 'json.dumps'-able.
[14:14] <smoser> which seems sane. as it labels it 'vendordata.json'
[14:23] <Odd_Bloke> Yeah; I think the problem might have been that I just put a regular cloud-config file in there, rather than a JSON document with a string as the root object.
[14:28] <smoser> right.
[14:28] <smoser> err..
[14:28] <smoser> "right."
[14:31] <Odd_Bloke> Yeah.
[14:32] <Odd_Bloke> And JSON strings can't have literal newlines.
[14:33] <Odd_Bloke> So it looks like "#cloud-config\npackages:\n- htop\n".
[14:33] <Odd_Bloke> Uh, plus a space in there.
[14:36] <smoser> so what you want is this:
[14:36] <smoser> cloud_init_data = {'packages': ['htop']}
[14:37] <smoser> with open("file.json", "wb") as fp
[14:38] <smoser>  fp.write('\n'.join("#cloud-init", json.dumps(cloud_init_data))
[14:38] <smoser> somthehign like that.
[14:38] <smoser> bsaically, let tools write it for you
[14:42] <Odd_Bloke> smoser: So have something like http://paste.ubuntu.com/10718633/ as the vendor-data OpenStack reads?
[14:43] <smoser> hm.. wait no. sorry . here.
[14:48] <smoser> http://paste.ubuntu.com/10718667/
[14:48] <smoser> Odd_Bloke, ^
[14:49] <smoser> either of those output formats (list or string) should work for cloud-init in vivid. and are in line with https://etherpad.openstack.org/p/cloud-init-vendor-data
[14:49] <smoser> and i'm saying we should make trusty act like vivid.
[14:50] <Odd_Bloke> smoser: http://paste.ubuntu.com/10718677/ worked on trusty and vivid.
[14:54] <smoser> Odd_Bloke, oh.
[14:54] <smoser> that is odd.
[14:54] <smoser> i dont know whow that works on trusty
[14:54] <smoser> ididn't think it looked in cloud-init
[15:00] <Odd_Bloke> smoser: Yep, it does; line 150 of DataSourceOpenStack.py.
[15:05] <JayF> smoser: Very happy to see cloud-init v2 hit stackforge
[15:08] <smoser> i pointed out, specifically... it is not a openstack project.
[15:08] <smoser> we just want free infrastructure :)
[15:09] <smoser> utlemming, i updated the lp:ubuntu/trusty branch
[15:09] <smoser> by 'dget <link-to-dsc>' (from https://launchpad.net/ubuntu/+source/cloud-init)
[15:09] <utlemming> smoser: ack
[15:09] <smoser> and then 'bzr import-dsc' from that dsc
[15:09] <smoser> and bzr push
[15:09] <smoser> please make sure you update that when you upload
[15:11] <utlemming> smoser: sure, sorry about that
[15:16] <smoser> precise-proposed, trusty, and utopic are now all up to date with archive.
[17:12] <harmw> what would be a fairly decent architecture for a small cloud deployment having compute nodes on multiple locations, each having their own ISP link for connecting with $world and using an ipsec tunnel with $home where keystone lives?
[17:30] <harlowja> claudiupopa whats your openstack email; https://review.openstack.org/#/admin/groups/665,members is up
[17:30] <harlowja> smoser ^
[17:30] <harlowja> u are now cloud-init core
[17:30] <harlowja> feel free to add others
[17:31] <harlowja> also https://review.openstack.org/#/admin/groups/666,members
[17:31] <harlowja> 666 omg
[17:31] <harlowja> lol
[17:32] <smoser> ok thanks.
[17:32] <harlowja> np
[17:32] <claudiupopa><EMAIL_ADDRESS>[17:33] <claudiupopa> So it's finally up.
[17:36] <JayF> 666 the number of the cloud
[17:43] <harlowja> JayF ha
[17:43] <harlowja> alexpilotti whats your email on gerrit?
[17:43] <harlowja> autofill-in not working
[17:44] <alexpilotti> harlowja<EMAIL_ADDRESS>[17:44] <harlowja> k
[17:44] <alexpilotti> autofill has some strange logic
[17:45] <harlowja> k, u are now coreeeee
[17:45] <harlowja> lol
[17:45] <alexpilotti> yeiiii tx :-)
[17:46] <alexpilotti> I found myself swearing a bit about the way it accepts naming ordering and spelling
[17:46] <harlowja> ok first review
[17:46] <harlowja> lol
[17:46] <harlowja> https://review.openstack.org/169854
[17:46] <alexpilotti> d’oh!
[17:46] <harlowja> use all your magic core powers on that one, lol
[17:47] <harlowja> guess we can see if the automated-ci works with that review also
[17:47] <harlowja> or if its broken (or something else)
[17:47] <alexpilotti> quick double check w the format we have in cloudbase-init’s .gitreview
[17:48] <harlowja> thx
[17:48]  * harlowja copied it from taskflow one, ha
[17:49] <alexpilotti> should I +2a or do we leave to smoser the pleasure of his first +a? :-)
[17:49] <harlowja> let's see if the CI breaks first
[17:49] <harlowja> it might be somewhat busted; not sure, ha
[17:50] <harlowja> first commits usually expose that :-P
[17:50] <alexpilotti> yep, we learned it the hard way
[17:50] <alexpilotti> as the first 2-3 post-stackforge patches in cbs-init can testify
[17:50] <harlowja> ya; looks like its busted, lol
[17:50] <harlowja> https://jenkins04.openstack.org/job/gate-cloud-init-pep8/1/
[17:51] <harlowja> ...
[17:51] <harlowja> i'll get all that stuff fixed
[17:51] <harlowja> maybe should turn off the docs build
[17:51] <harlowja> *for now*
[17:51] <alexpilotti> oh… well time to bring the joys of pep8 to cloud-init
[17:52] <JayF> I never start a new project with CI
[17:52] <harlowja> :)
[17:52] <JayF> set it up with noop jobs, then setup things one at a time
[17:52] <JayF> you are braver than me :P
[17:52] <kwadronaut> s/pep8/pdp11/g
[17:53] <harlowja> JayF ha
[17:53] <harlowja> JayF ya; it usually just causes these first commits to be busted
[17:53] <harlowja> then it all goes ok
[17:54] <alexpilotti> docs: https://github.com/stackforge/cloudbase-init/commit/23ddd33fa4a35040f9ab2f84efb54d7244232b8b
[17:54] <alexpilotti> an empty doc/source/conf.py should do
[17:54] <harlowja> kk
[17:54] <harlowja> cool
[17:54] <alexpilotti> and setup.cfg
[17:55] <harlowja> cools
[17:55] <harlowja> thx
[17:55] <alexpilotti> [build_sphinx]
[17:55] <alexpilotti> source-dir = doc/source
[17:56] <alexpilotti> do we have a .testr.conf?
[17:56] <harlowja> will get all that going
[17:58] <claudiub_> I would also suggest updating HACKING.md, since the new method of contributing will be through gerrit. That would mean going a git review instead, when the commit is ready.
[17:58] <harlowja> alexpilotti although seems like we are just gonna stick to nose for a little so i guess no testr.conf needed
[17:58] <harlowja> nose imho is just simpler :-P
[17:58] <harlowja> testr meh
[17:59] <JayF> harlowja: so existing cloud-init stays locked up in bzr?  I have a question about cloudbase-init and this is the closest room I could find so I will ask here hoping either someone can help or someone can direct me to the right room...
[18:11] <jetole> When I start a instance, neither the hard drive is being extended nor is the instance being activated (it has a valid MAK key). The logs say very little. 6 lines regarding attempts to get meta data via <IP_ADDRESS> but I have not added any metadata line to cloudbase-init.conf. Can anyone help me figure out why the plugins I specified aren't running and the meta data lines are being queried when they are not included in the conf?
[18:17] <alexpilotti> jetole: best place for this question is ask.cloudbase.it
[18:17] <alexpilotti> jetole: can you please post also a copy of your cloudbase-init.log and cloudbase-init-unattend.log?
[18:18] <alexpilotti> jetole: also: which Windows version are you using?
[18:18] <jetole> alexpilotti: 2k8r2 standard
[18:18] <jetole> alexpilotti: should I have configured cloudbase-init-unattend.conf as well as cloudbase-init.conf ?
[18:18] <alexpilotti> jetole: if you used the installer, they come preconfigured
[18:19] <jetole> I'm thinking maybe I should have since I'm going the generalize OOB sysprep
[18:19] <alexpilotti> jetole: also a copy of your config files will help in troubleshooting
[18:19] <jetole> some is but not nessicerely how I prefer, for example I don't want to add a user or query the meta servers but I do want to activate windows which can manually be done since the correct MAK key is there and the hard drive doesn't grow to fill the instance size
[18:20] <jetole> OK
[18:20] <jetole> Will do
[18:20] <jetole> thanks
[18:23] <harlowja> ok i think https://review.openstack.org/#/c/169854/ should fix all of it
[18:23] <harlowja> maybe not the pep8 ones though
[18:24] <harlowja> let's see how far that gets
[18:24] <alexpilotti> harlowja: requirements might need sphinx>=1.1.2,<1.1.999
[18:24] <harlowja> kk
[18:24] <claudiub_> harlowja: I have left you a comment on that patchset regarding pep8
[18:24] <harlowja> claudiub_ thx
[18:24] <harlowja> looking
[18:24] <harlowja> alexpilotti i put sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3 into test-requirements
[18:24] <harlowja> it seemed to work in a venv
[18:25] <alexpilotti> pep8: we should do our homework and clean up the entire project
[18:25] <harlowja> when i ran tox -edocs
[18:25] <harlowja> alexpilotti ya
[18:26] <harlowja> ok, updated
[18:26] <harlowja> let's see
[18:26]  * harlowja prefers rst vs markdown also :-P
[18:27] <harlowja> since all that damn sphinx stuff is in rst (might as well just use it all the places)
[18:28] <JayF> harlowja: I have a very recent patchset enabling doc builds on a project if you wanted a template
[18:29] <harlowja> JayF i think this should work; tox -edoc worked for me, let's see if it gets farther
[18:29] <harlowja> then we can make it better
[18:29] <JayF> That's fine, was just offering :)
[18:29] <harlowja> cools
[18:29] <harlowja> thx
[18:32] <alexpilotti> harlowja: tests dont seem to run
[18:32] <harlowja> hmmm
[18:32] <harlowja> Ran 0 tests in 0.006s
[18:32] <harlowja> OK
[18:32] <harlowja> seems to run something :-P
[18:33] <harlowja> although 0 of something
[18:33] <harlowja> ha
[18:33] <harlowja> $ tox -epy27
[18:33] <harlowja> likely cause there aren't any?
[18:33] <alexpilotti> harlowja: https://github.com/stackforge/cloudbase-init/blob/23ddd33fa4a35040f9ab2f84efb54d7244232b8b/.testr.conf
[18:34] <alexpilotti> and testrepository in requirements.txt
[18:34] <harlowja> ya; i think we are sticking with nose + nosetests though for the time being
[18:34] <alexpilotti> not sure if we can get nsoe to do this
[18:34] <harlowja> we can swithc later if we care
[18:34] <alexpilotti> in theory it should be transparent
[18:34] <harlowja> ya; so thats why later switch i think is ok
[18:34] <harlowja> u can commit that one :-P
[18:34] <harlowja> once this goes in
[18:35] <alexpilotti> the fact that we dont have tests is also a good reason why tests dont run :-D
[18:35] <alexpilotti> as in: https://github.com/stackforge/cloud-init/tree/master/cloudinit/tests
[18:35] <harlowja> ;)
[18:35] <harlowja> yup
[18:38] <alexpilotti> I was quite surprise by seeing a green Python 3.4 jenkins run at the first run :-)
[18:40] <harlowja> woot
[18:40] <harlowja> ha
[18:45] <alexpilotti> added https://review.openstack.org/#/c/169880/
[18:46] <alexpilotti> harlowja: hey docs are happy
[18:46] <harlowja> ya; nearly there alexpilotti
[18:46] <harlowja> just a few hacking tweaks/exclusions
[18:46] <alexpilotti> we “only” have pep8 left
[18:47] <harlowja> ok, think latests update should do it
[18:47] <harlowja> let's see
[18:49] <alexpilotti> hacking.rst: what about removing the names and adding a reference to: https://review.openstack.org/#/admin/groups/665,members
[18:49] <harlowja> sureee
[18:49] <alexpilotti> this way we dont have to change the file anytime somedy gets added/removed from the core group :-)
[18:53] <harlowja> ya
[18:54] <harlowja> alexpilotti updated
[18:54] <alexpilotti> merci
[18:55] <harlowja> hopefully that makes it all happy and good to go
[18:55] <alexpilotti> does it makes sense to keep:
[18:55] <alexpilotti> .. _Scott Moser: https://launchpad.net/~smoser
[18:55] <alexpilotti> .. _Joshua Harlow: https://launchpad.net/~harlowja
[18:56] <alexpilotti> in the references sicne they are not accessed?
[18:56] <alexpilotti> I mean they are not referenced
[18:56] <smoser> referenced ?
[18:57] <alexpilotti> https://review.openstack.org/#/c/169854/9/HACKING.rst
[18:58] <alexpilotti> instead of the name list we have: 	* `Core reviewers/maintainers`_
[18:58] <alexpilotti> and at the bottom we have:
[18:58] <alexpilotti> .. _Core reviewers/maintainers: https://review.openstack.org/#/admin/groups/665,members 	38
[18:58] <alexpilotti> .. _Scott Moser: https://launchpad.net/~smoser 	39
[18:58] <alexpilotti> .. _Joshua Harlow: https://launchpad.net/~harlowja 	40
[18:58] <alexpilotti> .. _IRC: irc://chat.freenode.net/cloud-init 	41
[18:58] <alexpilotti> .. _freenode: http://freenode.net/
[18:59] <alexpilotti> I mea, we can add everybody’s launchpad profile there, but I dont see it particularly useful in a dynamic group
[18:59] <smoser> sure. drop that.
[19:00] <alexpilotti> tx. developer’s anti data-duplication professional bias :-)
[19:03] <harlowja> alexpilotti i already dropped it :-P
[19:03] <harlowja> refresh to patch 10
[19:03] <harlowja> ;)
[19:03] <harlowja> to slow, haha
[19:04] <alexpilotti> :-)
[19:08] <jetole> alexpilotti: http://ask.cloudbase.it/question/401/issues-with-meta-activate-serial-and-hdd-extend/ :-)
[19:08] <alexpilotti> jetole: ok tx!
[19:08] <alexpilotti> me or one of my colleagues will look at it asap
[19:09] <jetole> I think I should have used a different blockquote method but I don't post to stackexchange often enough and couldn't recall the syntax
[19:10] <alexpilotti> for logs and long text I usually paste on paste.openstack.org and paste the link in the post
[19:10] <alexpilotti> but yours are not very long so it works inline as well :-)
[19:10] <jetole> I can do the same and add a ref link under the block quote
[19:11] <jetole> ... or nevermind
[19:11] <jetole> ;-)
[19:12] <alexpilotti> jetole: on what cloud are you running this instance?
[19:13] <alexpilotti> plugins are meant to be executed when metadata is present
[19:13] <jetole> alexpilotti: I'm testing on a local qemu-kvm on workstation but I had also uploaded it to openstack and had the same results. I don't need any data from the meta servers at all so I feel it should be fine locally
[19:13] <jetole> well on openstack icehouse, I have the same results
[19:13] <alexpilotti> you can surely reduce the list of plugins
[19:14] <alexpilotti> on icehouse it should definitely pick up metadata from <IP_ADDRESS> or configdrive
[19:16] <jetole> I just updated the post
[19:17] <jetole> from the line @ Update near the bottom
[19:19] <alexpilotti> the unattend part is used only to save one reboot when you set the hostname
[19:20] <jetole> OK. I don't have the logs from icehouse and it will take me a while to get them since I removed the test image and would have to re-upload. I'm using ceph for the stack so uploading raw images only which take a while
[19:20] <jetole> should I do that and get the logs
[19:20] <jetole> ?
[19:20] <alexpilotti> yeah, that would be best
[19:20] <jetole> Ok. It's only the logs though. I know the results are the same
[19:20] <alexpilotti> we can add a “Nil” metadata provider for your Qemu case
[19:21] <jetole> sorry, can you clarify what unattend is used for? I didn't find a good ref on the difference between what the two config files are used for online
[19:22] <alexpilotti> when the image is sysprepped, it uses a file called unattend.xml (rough equivalent of a linux preseed.cfg / ks.cfg)
[19:22] <alexpilotti> thsi contains steps executed during the early first boot during a phase called “specialize”
[19:23] <jetole> I'm familiar with that
[19:23] <alexpilotti> we do a first execution of cloudbase-init at this stage
[19:23] <alexpilotti> to run only a limited set of plugins: NTP, MTU and hostname
[19:23] <jetole> I've used unattend, preseed and occasionally kickstart before but the cloudbase-init-unattend. What does that do differently
[19:23] <jetole> er, I mean that file specifically
[19:23] <alexpilotti> the hostname one requires a reboot
[19:24] <jetole> so the stuff that has to be done prior to the reboot goes into cloudbase-init-unattend?
[19:24] <alexpilotti> yep!
[19:24] <alexpilotti> in short, it’s just the anme of the configuration file used by cloudbase-init when executed during specialize
[19:25] <alexpilotti> there are quite some limitations on what can be executed during that phase, in particular WMI is not available
[19:25] <alexpilotti> in your case, given the requirements you posted, it can be skipped
[19:26] <jetole> ok
[19:27] <jetole> waiting on the upload now. It's at 90% (gbit between wkstn and stack) but than it's theirs the save from local host to ce
[19:27] <jetole> - to ceph (I think via glance)
[19:41] <harlowja> alexpilotti smoser claudiupopa https://review.openstack.org/#/c/169854/
[19:41] <harlowja> we are good to go
[19:41] <harlowja> approve at will
[19:41] <smoser> hooray. tests pass.
[19:41] <smoser> :)
[19:41] <alexpilotti> yeii
[19:42] <harlowja> smoser yaaaa; 0 tests pass 0 times, lol
[19:43] <alexpilotti> smoser: would you fancy +2a it this patch? :-)
[19:44] <smoser> on the above ?
[19:44] <alexpilotti> https://review.openstack.org/#/c/169854/
[19:44] <alexpilotti> yep
[19:45] <smoser> reviewing
[19:45] <harlowja> slacking again apparently, lol
[19:46] <smoser> why is it HACKING.rst ?
[19:47] <harlowja> idk
[19:47] <harlowja> lol
[19:47] <harlowja> seems common to what i've seen
[19:47] <harlowja> https://github.com/openstack/nova/ (HACKIGN.rst)
[19:47] <harlowja> ...
[19:48] <smoser> oh. ok. i didnt'r ealize github would render .rst
[19:48] <smoser> thought .md only
[19:48] <harlowja> ya
[19:48] <harlowja> it handles both
[19:48] <harlowja> and since rst is what sphinx also uses; i like just 1 format
[19:49] <jetole> Something else I wanted to ask, is there a (relatively) easy way for me to create a local metadata server for qemu/kvm for testing images when building them?
[19:49] <jetole> doesn't have to be on the same machine, etc since the KVM images share the LAN adapter of the host
[19:49] <smoser> so the reason i had testenv:docs is so tha tyou could build docs without the rest of the stuff
[19:49] <smoser> due to my general hatred of pypi
[19:50] <harlowja> maybe just get used to running `python setup.py build_sphinx` then :-P
[19:50] <harlowja> its a few more characters, lol
[19:50] <harlowja> but u can do it
[19:50] <harlowja> lol
[19:50] <harlowja> i believe in u
[19:54] <harlowja> we can switch it back; i think its ok if u really want smoser
[19:54] <harlowja> https://github.com/openstack/glance/blob/master/tox.ini#L40 seems to be the common practice
[19:54] <harlowja> although 	deps = {[testenv]deps} i think is fine either way
[19:54] <harlowja> so not sure it matters
[19:55] <harlowja> u sorta need the deps to run that comand anyway
[19:55] <smoser> so you switched it just to have less tox env ?
[19:55] <smoser> ie, less stuff in .tox/
[19:55] <smoser> right?
[19:55] <harlowja> well to install the right dependencies
[19:55] <harlowja> sphinx will crap out if u start including code from cloud-init into docs...
[19:56] <smoser> no.. i had it i thought in its own testenv.
[19:56] <harlowja> ya, well [testenv:docs] will do that
[19:56] <harlowja> afaik that will make a .docs venv
[19:57] <smoser> ah. but the .docs will have all of the requirements in it.
[19:57] <harlowja> smoser the openstack folks mirror pypi afaik so the mirror issues should be less of an issue
[19:57] <harlowja> smoser right
[19:57] <harlowja> and if we have docs that include code snippets; thats probably what we want
[19:57] <harlowja> so those code snippers can be tested as well (which can be done)
[19:57] <harlowja> *snippets
[19:57] <smoser> stop making rational arguments for your side
[19:58] <smoser> its annoying
[19:58] <smoser> :)
[19:58] <smoser> so the code snippets is godo point. and i'm fine with that.
[19:58] <smoser> harlowja, and we officially dropped 2.6 ?
[19:59] <harlowja> ha
[19:59] <smoser> did you mean to remove that ?
[19:59] <harlowja> well it seems like the openstack CI isn't testing it
[19:59] <harlowja> sooo
[19:59] <harlowja> i'm ok with that for now
[19:59] <harlowja> we'll see :)
[19:59] <smoser> istn't that rhel 6 ? didn't you tell me that ?
[19:59] <harlowja> ya
[19:59] <harlowja> it is
[19:59] <harlowja> i can add back later
[19:59] <harlowja> will see
[19:59] <smoser> and they dont have a python3 either.
[20:00] <harlowja> gate-cloud-init-python34
[20:00] <harlowja> ?
[20:00] <harlowja> thats running 34
[20:00] <smoser> ok.
[20:00] <harlowja> but gate-cloud-init-python26 not there right now
[20:00] <smoser> k. good enouh
[20:00] <harlowja> so just chopped 26 from the rest of it for now
[20:01] <harlowja> someone at yahoo will notice that and probably say, whats up
[20:01] <harlowja> but hasn't happened yet :-P
[20:01] <harlowja> also removed 'Environment :: OpenStack'
[20:01] <harlowja> since cloud-init isn't really 'openstack'
[20:01] <harlowja> ...
[20:01] <harlowja> its just cloud...
[20:03] <smoser> yeah, i'm godo wth that.
[20:04] <harlowja> cools
[20:04] <harlowja> merging it then (+a)
[20:04] <harlowja> and merged
[20:04] <harlowja> alexpilotti guess u'll have to rebase
[20:04] <harlowja> https://github.com/stackforge/cloud-init should be all good to code on now :-P
[20:04] <harlowja> world peace to come later, lol
[20:05] <alexpilotti> heh
[20:06] <harlowja> smoser do we want to drop https://github.com/cloud-init/cloud-init ?
[20:06] <harlowja> or link it or mirror it or something?
[20:07] <harlowja> https://review.openstack.org/169904 for those that are bored, ha
[20:07] <smoser> is there any infrastructure to magically keep those in sync ?
[20:07] <harlowja> smoser unsure
[20:07] <harlowja> probably :-/
[20:11] <jetole> alexpilotti: I just posted the updates you asked for via http://ask.cloudbase.it/question/401/issues-with-meta-activate-serial-and-hdd-extend/ - It looks to me like python is not finding the hostname module. I've never done python on Windows and wouldn't know where to look for that plus you may know if it's more than it appears from experience :-)
[20:20] <claudiupopa> jetole: plugins=cloudbaseinit.plugins.windows.sethostname.SetHostNamePlugin,
[20:20] <claudiupopa> That's actually plugins=cloudbaseinit.plugins.common.sethostname.SetHostNamePlugin,
[20:20] <claudiupopa> s/windows/common/ ;-)
[20:21] <claudiupopa> The unattend conf had it right though.
[20:22] <jetole> OK. I actually copied the plugins lines from the stackforge readme
[20:22] <jetole> Is there a more current one?
[20:23] <claudiupopa> Yep.
[20:23] <claudiupopa> Just updated it today.
[20:23] <jetole> on stackforge?
[20:23] <claudiupopa> Yeah.
[20:23] <claudiupopa> In fact, ups, sethostname is still wrong.
[20:24] <jetole> ok...
[20:24] <jetole> s/windows/common/ <- is that for all plugins?
[20:24] <claudiupopa> No, some of them are windows specific.
[20:25] <claudiupopa> The rest are nicely abstracted so that they work on any platform.
[20:25] <jetole> claudiupopa: can you check my whole plugins line there and let me know which other ones I should adjust, please?
[20:25] <claudiupopa> Sure.
[20:25] <jetole> thank you
[20:27] <claudiupopa> networkconfig is common, as well as mtu.
[20:27] <claudiupopa> As well as sethostname.
[20:28] <jetole> claudiupopa: extendvolumes and activate windows still use "windows"?
[20:29] <claudiupopa> Yes, they windows specific.
[20:29] <claudiupopa> Except extendvolumes, which is somewhat a leaky abstraction right now.
[20:29] <claudiupopa> https://github.com/stackforge/cloudbase-init/blob/master/cloudbaseinit/plugins/common/factory.py#L23
[20:29] <claudiupopa> This should give you a fair idea of what is what.
[20:29] <jetole> If I just reboot this instance on the stack, will that test the changes I made to cloudbase-init.conf or do I have to re-sysprep?
[20:30] <claudiupopa> You'll have to resysprep. Or delete a key from the registry.
[20:30] <claudiupopa> There's a key where cloudbaseinit logs the status of the executed plugins.
[20:30] <jetole> do you have the path?
[20:31] <jetole> quicker to test and than I can re-sysprep on my workstation and re-upload once I know I have a working config
[20:32] <claudiupopa> Should be under 'SOFTWARE\\Cloudbase Solutions\\Cloudbase-Init\\'
[20:32] <claudiupopa> HKLM.
[20:33] <harlowja> windows registry
[20:33] <harlowja> eck
[20:33] <harlowja> runs away
[20:34] <jetole> harlowja: I don't have a \\HKLM\SOFTWARE\Cloudbase Solution\
[20:34] <harlowja> i defer to others here
[20:34] <jetole> Do you think the import error may have caused an exit before it was written
[20:34] <harlowja> really will run away ha
[20:34]  * harlowja running to food
[20:34] <harlowja> lol
[20:34] <jetole> ;-/
[20:35] <jetole> :-/
[20:35]  * jetole does the reboot
[20:36] <claudiupopa> jetole: if you don't have any, that's good, no plugin was executed then, so doing a reboot should do it.
[20:36] <jetole> Something else I wanted to ask about. I use a app which provides the initial password, in plain text, in json ['meta']['initialpass'] via http://<IP_ADDRESS>/openstack/2012-08-10/meta_data.json. Can I set a user password via this data?
[20:37] <jetole> I had to write some python code to use this in Linux as I could not find a way to do it natively via cloud-init and a few members of this room (weeks ago) confirmed it could not be done natively
[20:40] <claudiupopa> jetole: in cloudbaseinit it needs to be in ['meta']['admin_pass'].
[20:41] <jetole> so that's a no
[20:41] <claudiupopa> Yes, basically.
[20:42] <jetole> it's ok
[20:42] <jetole> I am getting a terminal prompt for a password via sysprep now and will port the python later
[20:43] <jetole> claudiupopa: Here's the updated console output: http://paste.openstack.org/show/Jf99AeXArfzL3INP4QRi/
[20:44] <jetole> I am seeing the hostname is set but the volumes are not extending and windows is not being activated. It has a valid MAK key and if I click on activate windows than it activates just fine but cloudbase-init isn't extending hdd or activating
[20:45] <jetole> whoa
[20:45] <jetole> wait a second
[20:45] <jetole> the hdd now appears to be extended
[20:46] <jetole> and windows is activated
[20:46]  * jetole does a happy dance
[21:05] <jetole> claudiupopa: If I test this on a local kvm-qemu without the <IP_ADDRESS> meta data, will this run or fail @ hdd-extend and activate?
[21:08] <claudiupopa> jetole: you mean without any metadata service?
[21:09] <jetole> right. This is just for testing on local workstation before uploading to the stack
[21:09] <claudiupopa> Then it will definitely fail. cloudbase-init tries to load the metadata before starting any plugin.
[21:10] <claudiupopa> If it finds no available metadata service, it fails.
[21:10] <jetole> OK
[21:10] <jetole> any recommendation for how I could run a easy to deploy testing meta server on my local net
[21:11] <claudiupopa> Probably we could add some sort of local for-testing service.
[21:11] <jetole> actually I have hit the meta server wall on linux / cloud-init too
[21:11] <jetole> would be better if there is a for testing meta framework
[21:14] <claudiupopa> In the mean time, I guess you could "mock" a metadata service, by starting a local Python / Ruby / Perl server which exports the expected api.
[21:14] <claudiupopa> And then just setting metadata_base_url to point to your mocked service.
[21:14] <claudiupopa> metadata_base_url in config file I mean.
[21:19] <alexpilotti> claudiupopa: we could also just provide a DummyMetadata class
[21:20] <alexpilotti> which implements the base class w/o doing anything else
[22:05] <jetole> claudiupopa, do you want to add a answer to my issue @ http://ask.cloudbase.it/question/401/issues-with-meta-activate-serial-and-hdd-extend/ regarding s/windows/common/ ? I was about to but I wanted to reference you for credit and don't know how since I hardly ever use this service
[22:28] <jetole> alexpilotti and claudiupopa: How do you guys deal with building images? Do you upload every test image to the stack? Isn't that time consuming?
[22:30] <alexpilotti> jetole: it’s ok, it’d be great if you could answer and mark it as an answer :-)
[22:31] <alexpilotti> about images: they get cached on compute nodes, so after the first boot it’s fast even if they are relatively big
[22:33] <jetole> alexpilotti: no I know but I mean when you're building images like, for example, right now I'm building the redeployable win2kr2 image for our stack and I need the meta data to run it which I don't have locally so right now I am doing a lot of dev, upload, test, debug, upload, test, Q&A with you guys (would have been lost without it), upload, test and for me it's pretty time consuming
[22:33] <jetole> I mean if there is no dummy meta server than there still has to be a better way than this
[22:34] <alexpilotti> we use these Powershell cmdlets to automate the process: https://github.com/cloudbase/windows-openstack-imaging-tools
[22:34] <alexpilotti> it’s fully automated, but it takes 1-2 hours per image
[22:35] <alexpilotti> the Windows updates are the time consuming part
[22:35] <alexpilotti> if you dont care about updates, it can be fully done offline
[22:36] <jetole> not bad. I'm on Linux workstation but I could always rdp. There's a bunch of Linux options too for automated builds but for build and test, with the whole upload thing, it just seemed to me like there would have been a less time consuming way. For example, I mean if it wasn't for the meta-data, I could just poweroff the system after a sysprep, qemu-img a backing file for qcow2, boot it up and test in a matter of minutes
[22:36] <jetole> yeah I did the updates on the pre-rollout but that was a one-off task
[22:37] <jetole> for dev & QA, I'm having to re-deploy for every test but oh well
[22:37] <jetole> just hoped the pros had a better path
[22:42] <jetole> Forgot to mention I'm using qcow2 locally for snapshots and backing_files to expedite dev but the stack is using ceph and qcow2 on ceph isn't a good idea so I also have the qemu-img convert time before each upload


[13:50] <meena> Spam? https://github.com/canonical/cloud-init/issues/4280
[13:50] -ubottu:#cloud-init- Issue 4280 in canonical/cloud-init "[docs]:" [Open]


[08:26] <FernandoMiguel> morning
[11:53] <BluesKaj_> Hiyas all
[13:39] <FernandoMiguel> $ yes |killall -9 unity-panel-service
[13:39] <FernandoMiguel> I got to that sad point
[13:41] <jjavaholic> that doesn't help
[13:41] <FernandoMiguel> for a few minutes, it does
[16:36] <FernandoMiguel> don't you hate when logging a bug/trace and nothing happens? :\
[21:00] <penguin42> FernandoMiguel: Thus is the life of hunting a heisenbug
[21:01] <FernandoMiguel> :\
[21:01] <FernandoMiguel> penguin42: you know what's even worse?
[21:01] <FernandoMiguel> it finally happens, and the logs don't get saved
[21:02] <penguin42> FernandoMiguel: Yep, the bug tunnelled out
[21:02] <FernandoMiguel> there seems to be some real problem here, see
[21:02] <FernandoMiguel> WARN  2013-07-17 21:45:27 unity.glib.dbus.proxy GLibDBusProxy.cpp:418 Calling method "SyncGeometries" on object path: "/com/canonical/Unity/Panel/Service" failed: Timeout was reached
[21:02] <FernandoMiguel> I wish anyone here was running unity too :p
[21:02] <FernandoMiguel> seems everyone moved to something else
[21:02] <FernandoMiguel> so I could compare systems
[21:03] <penguin42> if it makes you feel any better I'm debugging a seg in X that just ends up at address 0
[21:04] <FernandoMiguel> ahaha
[21:04] <FernandoMiguel> if you see my bug running by, let it know Im looking for it
[21:05] <penguin42> sure
[21:14] <caravena> other user with bug: https://bugs.launchpad.net/ubuntu/+source/ntfs-3g/+bug/1202021
[21:15] <FernandoMiguel> caravena: try #ubuntu-bug
[21:15] <caravena> Many thanks FernandoMiguel :)
[21:17] <caravena> FernandoMiguel, es #ubuntu-bugs :)
[21:17] <FernandoMiguel> missed and s
[21:17] <FernandoMiguel> darn...
[21:17] <FernandoMiguel> penguin42: chrome gtalk plugin spells everything into an unity strace
[21:17] <FernandoMiguel> mother of god
[21:51] <penguin42> it's taking unity out - it's in a different process?
[21:58] <FernandoMiguel> penguin42: it's on a diff process
[21:59] <FernandoMiguel> fernando  3358  8.6  0.5 1435836 45228 pts/15  Sl+  21:04   9:51          \_ /opt/google/talkplugin/GoogleTalkPlugin
[21:59] <FernandoMiguel> fernando  2803  0.0  0.0   4692   840 pts/15   S    21:03   0:00          |   |   \_ strace -o unitydebug20130717-4-strace.log unity --debug


[00:14] <pwnguin> i wasn't aware mpx was in jaunty
[00:15] <pwnguin> (or xorg main)
[09:44] <bryce> tjaalton: posted debdiff for #308387.  solved the issue for me, but would appreciate if you took a look at it to assure it's the right change
[09:55] <tjaalton> bryce: I'd just modify debian/libdrm-dev.install :)
[09:55] <tjaalton> but the real question is, does -intel build against the kernel headers
[09:56] <tjaalton> the kernel needs db139d606ea25e0590373d5ce6bfc42ce317a61c from drm-next
[09:56] <tjaalton> fdo bug #19132
[09:56] <bryce> well there are some headers which don't conflict (which I left in the makefile).
[09:56] <tjaalton> bah, freedesktop bug 19132
[09:57] <bryce> yeah, I didn't try building anything against it (this is an -ati box)
[09:58] <tjaalton> the goal is to get rid all of them I guess (from libdrm-dev)
[09:58] <tjaalton> only the userspace headers will remain (intel_bufmgr.h, xf86drm.h)
[09:58] <tjaalton> oh well, I'll mail the kernel list
[09:59] <bryce> fair enough; the remainder sounded like maybe obsolete cruft, but didn't want to drop without seeing someone state that explicitly
[09:59] <bryce> ok
[09:59] <tjaalton> btw, the new intel needs newer libdrm, but there are reports where X segfaults on start with it, so.. :/
[10:00] <bryce> dah, such unstable crap
[10:00] <bryce> I'm peeved...  I bought a dell mini 9 for my dad, and after playing with it with him for all of 4 hours, it locked up 3 times
[10:01] <tjaalton> :S
[10:01] <bryce> not sure exactly what is happening, but seems like a kernel lockup
[10:01] <bryce> the dell mini 9 is an i945 hardy setup, with the lpia kernel and a proprietary wireless driver
[10:02] <bryce> was really disappointed - if anything it ought to be a showcase of ubuntu/linux/open-source quality, and to have it locking up so much is really frustrating
[10:03] <tjaalton> yeah that sounds really bad
[10:05] <bryce> anyway
[10:05] <bryce> the system I'm trying to get up to jaunty is one I plan to switch to as my main desktop
[10:07] <bryce> usually I've kept my main desktop to the last released Ubuntu for stability, but I figured I need to dog food more :-)
[10:08] <tjaalton> hehe
[10:08] <tjaalton> my desktop is still intrepid, because of the nvidia blob..
[10:08] <bryce> I had some graphics problems with it before, so was using it just as a build box, but I managed to get those all squared away this week
[10:08] <tjaalton> you probably heard the news about r6/7xx drm stuff?-)
[10:08] <bryce> oh yeah
[10:09] <bryce> and nvidia's new video accel stuff
[10:09] <bryce> vdpau or whatever
[10:09] <tjaalton> so within a month the docs should be out and some sort of a DRI driver too..
[10:10] <tjaalton> I wonder if other drivers will pick vdpau..
[10:10] <bryce> do -ati and -radeonhd both use the same dri driver in mesa?
[10:10] <tjaalton> yes, AIUI
[10:10] <bryce> cool
[10:11] <bryce> tjaalton: vdpau ain't open source
[10:11] <tjaalton> hmm
[10:11] <bryce> and sounds like both Intel and ATI have competing technology solutions for multi-mpeg accel support, so...
[10:12] <bryce> I think again we're going to get into this annoying situation of having a great proprietary solution for -nvidia, and a less great but open source solution from intel
[10:12] <tjaalton> I believe there was an announcement on xorg@ about vdpau
[10:12] <bryce> from nvidia?
[10:13] <tjaalton> yes
[10:14] <tjaalton> a couple of months back
[10:14] <bryce> ah; not spotting it in my mail archive
[10:14] <tjaalton> me neither, but I'll look closer
[10:16] <bryce> anyway, sounds like there'll be fragmentation on the video acceleration front to look forward to this next year or so
[10:16] <tjaalton> here: http://lists.freedesktop.org/archives/xorg/2008-November/040279.html
[10:17] <tjaalton> so the API is free
[10:17] <bryce> heh
[10:18] <tjaalton> yes, too bad that now that nvidia has published vdpau, the other vendors still keep on working on their own stuff..
[10:18] <tjaalton> NIH ftw!
[10:19] <bryce> publishing the API != free
[10:19] <bryce> Microsoft publishes many API's for application developers to use...
[10:20] <tjaalton> well the copyright notice on the headers does sound like it's free..
[10:21] <tjaalton> I'd like to hear what the other vendors think of it..
[10:21] <tjaalton> nothing on the list or IRC so far
[10:21]  * bryce nods
[10:24] <bryce> I guess what I mean is that publishing the API is akin to putting the table of contents of a book on a website
[10:24] <bryce> you couldn't then claim that the book was "available for download from the web"
[10:25] <bryce> similarly, to really call an API "Free", I'd expect the reference implementation to also be published under a free-ish license
[10:25] <pwnguin> more importantly, a set of closed drivers conforming to an API will sustain a far slower the rate of change
[10:27] <bryce> switching systems... bbiab
[10:59] <bryce> erf, I can only get -vesa booted.  wtf
[11:10] <tjaalton> jaunty?
[11:14] <bryce> yep
[11:15] <bryce> retesting -ati, brb
[11:19] <bryce> no go
[11:20] <bryce> ah well, tomorrow's project
[11:24] <tseliot> BTW the id of my NVIDIA card (02E2) is no longer in /usr/share/xserver-xorg/pci/nv.ids or anywhere in /usr/share/xserver-xorg/pci/ (in Intrepid)
[11:25] <tjaalton> so nv doesn't support it
[11:27] <tseliot> tjaalton: but it's a geforce 7300 and it was supported
[11:27] <tseliot> and should be supported by nv too
[11:27] <tjaalton> maybe the .ids parsing code is buggy then
[11:27] <tseliot> yes, that was my 1st guess
[11:28] <tjaalton> improvements welcome :)
[11:29] <tseliot> tjaalton: where's the code? In the source package of nv?
[11:29] <tjaalton> yes
[11:30] <tjaalton> there's a patch which modifies a Makefile
[11:30] <tjaalton> to generate the file
[11:30] <tseliot> ok, I think I've played with something similar before (for nvidia)
[11:31] <tjaalton> -nv is a special case because it lists id's in a couple of functions
[11:32] <tseliot> ok
[11:32] <tjaalton> so it's possible that the parser is buggy
[11:34] <tseliot> the ID is missing from the source file. Other ids for 7300 cards are provided but mine
[11:34] <tseliot> a patch should fix it
[11:35] <tjaalton> so forcing the driver works?
[11:35] <tjaalton> IIRC mvo had a similar case
[11:36] <tjaalton> where the driver didn't list the id, but works if forced
[11:37] <tseliot> it used to work. I'll test it and if it works, I'll give you a patch
[13:52] <marijus> hello, how to check if kms is running properly?
[13:55] <tjaalton> it isn't, period :)
[13:57] <marijus> ok... :) anyway... a happy new year!
[13:58] <tjaalton> unless you're running experimental code from upstream..
[13:58] <marijus> i do...
[13:58] <tjaalton> ok then
[15:00] <tseliot> tjaalton: nv works if I force it in the xorg.conf. Shall I give you debdiffs for intrepid and jaunty? Also I'll contact Aaron Plattner
[15:03] <tjaalton> jaunty is enough, doubt that intrepid will be updated
[15:08] <tseliot> ok
[15:08] <tseliot> BTW did you remove that fedora patch from X? The one which caused corruptions on KDE?
[15:12] <tjaalton> done in git
[15:12] <tjaalton> but I can't build a source package and upload because some xquartz binaries have been changed, and dpkg-buildpackage barfs because of it
[15:18] <tseliot> ouch
[15:21] <tjaalton> so either have to wait for next beta or remove xquartz from the git branch
[15:21] <tjaalton> since it's osx-specific anyway


[15:00] <junka> hello
[15:01] <junka> how can I find cheap hotels/motels in Zaragoza
[15:01] <junka> sorry for the offtopic
[15:36] <DarkPsydeLord> also not proper languaje XD
[17:14] <junka> hello
[17:14] <junka> anyone here?
[19:28] <phablet> 0


[11:11] <AlanBell> hi all
[11:11] <AlanBell> persona sprint weekend
[13:15] <Pendulum> AlanBell: I only just got up so I'll be around in a couple hours once I've fed myself and woken up more
[13:18] <AlanBell> ok
[13:18] <AlanBell> I haven't really got started yet
[20:37] <AlanBell> getting started now
[22:07] <AlanBell> http://www.macworld.com/article/163058/2011/10/up_close_with_ios_5_accessibility_features.html
[22:07] <AlanBell> that is rather cool stuff on the iphone
[23:32] <AlanBell> http://pad.ubuntu-uk.org/simon coming together now


[00:00] <greg-g> +1 from me, I especially love the way your started with your contributions outside of normal work, keep up the rocking work!
[00:00] <boredandblogging> +1 awesome work!
[00:00] <pleia2> +1 from me too, excellent work!
[00:00] <greg-g> s/normal/canonical/ ;)
[00:00] <cr3> greg-g: heh :)
[00:00] <beuno> right, canonical work never qualifies as normal
[00:01] <greg-g> indeed
[00:01] <Ursinha> hehe
[00:01] <Pretto> their employees neither :D
[00:02] <Technoviking> +1 here
[00:02] <pleia2> congrats, welcome cr3!
[00:02] <greg-g> awesome, welcome aboard cr3 !
[00:02] <cr3> Technoviking: now that I have your vote, I can finally suck up to you: love the nick!
[00:02] <Pretto> cr3, Congrats!!!! Welcome aboard!
[00:02] <cr3> thanks folks, my heart just jumped!
[00:02] <Ursinha> congrats cr3 :)
[00:03] <Ursinha> I'm shy to talk after cr3, he's done brilliant stuff
[00:03] <cr3> Ursinha: I'm crossing my fingers for you now
[00:03] <Technoviking> cr3: thanks:)
[00:03] <pleia2> Ursinha: you're up!
[00:03] <Ursinha> hi all
[00:03] <Pretto> hi Ursinha :D
[00:03] <Ursinha> let's go
[00:03] <Ursinha> as some of you may know, my name is Ursula Junque, a.k.a. Ursinha
[00:03] <Ursinha> I've been involved with Open Source since 2003 and working with that since 2006.
[00:04] <Ursinha> my Ubuntu story started when I switched totally from Gentoo to Ubuntu Feisty, when started working with packaging and then advocating Ubuntu to everyone I could (my grandma and mother-in-law use Ubuntu :))
[00:04] <Ursinha> I joined the Ubuntu Brazilian community in about April 2007, and since then, I've been around on irc, always trying to help the beginners - and not letting more experienced people to harass them
[00:04] <Ursinha> after some time on irc, I was given the operator status of the #ubuntu-br channel
[00:04] <Ursinha> I decided to help translations team, then I started doing translations, but realized I could be more helpful doing other stuff
[00:04] <Ursinha> so, talking with Andre Gondim, the leader of translations team in Brazil, I created a script that maintains the brazilian translations wiki, making it reliable for people that want to help translating packages
[00:04] <Ursinha> I've been maintaining it for several months now, and am working now in KDE and GNOME wiki pages, so we can coordinate better how to deal with upstream translations
[00:05] <Ursinha> I've been also helping the ubuntu-br council and official members, supporting them with community stuff and on events such as FISL (Forum Internacional Software Livre), in which I gave a talk about "using Launchpad to help Ubuntu", in the ubuntu-br community track
[00:05] <Ursinha> my spare time has being almost entirely dedicated to Ubuntu
[00:05] <Ursinha> for the future, I intent to keep helping translations team and also docs team, that needs love. I've been also asked by one of the maintainers of APTonCD app to help on its development, so this will be one of my next steps working on helping improve ubuntu
[00:05] <Ursinha> my wiki page is http://wiki.ubuntu.com/UrsulaJunque and my Launchpad page https://launchpad.net/~ursinha
[00:06] <pleia2> impressive work, lots of great testimonials too :)
[00:06] <Ursinha> pleia2, thanks :)
[00:06] <Pretto> just for the record, she lives on IRC!!!! and she is always up to help
[00:06]  * jpds cheers for Ursinha.
[00:06] <Ursinha> :)
[00:06]  * maco cheers for Ursinha too
[00:06] <Ursinha> hey maco!
[00:06] <Ursinha> :)
[00:06] <greg-g> awesome cheering section, Ursinha
[00:07] <Ursinha> :)
[00:08] <greg-g> Ursinha: you say your spare time is spent on Ubuntu, but you also work for Canonical, are you worried about burn out?
[00:08] <beuno> greg-g, Ursinha doesn't sleep, so that shouldn't be a problem
[00:08] <beuno> she's on 24/7
[00:08] <Ursinha> greg-g, actually not, because my job isn't directly related to what I do on free time
[00:08] <Ursinha> lol
[00:09] <greg-g> ahh, ok, that is a good way to stay sane, separating the fields of work
[00:09] <Ursinha> I work on launchpad
[00:10] <bratsche> I'm a fan of Launchpad. :)
[00:10] <Ursinha> :)
[00:10] <maco> oh so you just get annoyed at your dayjob when doing stuff in ubuntu for fun :P
[00:10]  * Pretto is a fan of Ursinha :p
[00:10] <greg-g> maco++
[00:10] <Ursinha> hhahaha
[00:10] <maco> "darn found a bug. will have to fix at work tomorrow"
[00:10] <pleia2> +1 from me, awesome work, and thank you for being so thorough! I couldn't think of any questions to ask :)
[00:10] <JanC> Ursinha: that translation wiki script might be useful for other teams too, I'm not sure how tied to the Brazil situation it is?  (but maybe we better talk about that outside the meeting)
[00:10]  * leleobhz is a fan of Ursinha too
[00:10] <Ursinha> JanC, I have a branch in launchpad, I'll give you the link after the meeting
[00:10] <Legendario> i have been spectating Ursinha`s job on the translation team, just for record too!
[00:11] <greg-g> +1 from me too, awesome work Ursinha.
[00:11] <boredandblogging> +1, rockin'
[00:11] <Ursinha> it's only tied to the way we managed the translations wiki
[00:11] <Technoviking> +1 from me, a fantastic body of work, and maybe the largest cheering section I have seen for a candiate:)
[00:11] <pleia2> woohoo, congrats and welcome Ursinha!
[00:11] <Pretto> Ursinha, you rock!!! Congrats!!!
[00:11] <greg-g> welcome aboard Ursinha
[00:11] <Ursinha> thanks!!!!
[00:11] <Ursinha> I may cry now
[00:11] <cr3> Ursinha: you rock!
[00:11] <leleobhz> wellcome to team Ursinha !
[00:12] <leleobhz> u rock²
[00:12] <Ursinha> :')
[00:12] <jpds> Ursinha: Congrats!
[00:12] <Legendario> ursinha, congrats!!!
[00:12]  * maco hugs Ursinha
[00:12] <Pretto> congrats never ending
[00:12] <Ursinha> thanks all of you!!!
[00:12]  * Ursinha hugs everyone in the room :D
[00:12]  * pleia2 hugs :)
[00:12] <JanC> congrats Ursinha :-)
[00:13] <Ursinha> JanC, thanks!
[00:13]  * greg-g hugs Ursinha
[00:13] <leleobhz> congratulations! im very happy now, because she is a brave girl inside ubuntu brazilian community, help everybody anytime
[00:13] <Pretto> Ursinha, you forgot to talk about #ubuntu-women-br :p
[00:13] <beuno> is that a wrap?
[00:13] <greg-g> I think that's a wrap
[00:13] <Ursinha> what's a wrap?
[00:13] <pleia2> thanks for coming everyone
[00:13] <Technoviking> anyone show up late?
[00:14]  * leleobhz want to congrat publically too Coringao
[00:14] <greg-g> thanks to everyone for coming, and one last round of applause for the new members!
[00:14]  * pleia2 cheers
[00:14]  * cr3 applauds
[00:14]  * beuno waves
[00:14] <Coringao> leleobhz, thanks my friend
[00:14] <Pretto> hey new members, now you have a great responsibility on you
[00:14] <leleobhz> Ubuntugames have a *GREAT* impact into brazilian computer users. i know a lot of people that experimented ubuntu and linux for first time because ubuntugames
[00:15] <leleobhz> CONTRATULATIONS!
[00:15] <Ursinha> beuno, I guess I'm the first female ubuntu member in Brazil
[00:16] <Legendario> Ursinha, I think so...
[00:16]  * leleobhz applauds²
[00:16] <Pretto> time to go now :D
[00:16] <Pretto> home is waiting
[00:16] <beuno> Ursinha, doesn't suprise me that you break new ground
[00:16] <leleobhz> Pretto: good night serenade
[00:18] <Legendario> is the meeting over?
[00:18] <Pretto> Legendario, yes :D
[00:19] <Legendario> so, I am leaving the channel guys
[00:19] <Legendario> congratulations for all the new members, specially the brazilian ones... ;-)
[00:20] <Legendario> bye
[00:24] <Ursinha> I think I'll hang here for a while, just to get used to the idea :)
[14:00] <lbt> Afternoon all - lbt from Mer here :)
[14:01] <lbt> I think lool mentioned a meeting re MID or similar around now-ish?
[14:07] <lbt> persia` GrueMaster lool ....
[14:14] <lool> lbt: hey
[14:14] <lool> lbt: Didn't know we planned a meeting
[14:14] <lbt> hey
[14:14] <lool> But I'm available if needs be
[14:15] <lbt> OK
[14:16] <lbt> let me see if I can dig up who said it...
[14:17] <geirha> Someone should make a bot that sets the next meeting in the topic
[14:17] <nhandler> geirha: There was one. It just never got updated when the Fridge moved to Google Calendar
[14:18] <lbt> [Friday 07 Aug 2009] [17:44:25] <ian_brasil> i will try to make the ubuntu mobile meeting next week and try to find out what is happening with MID
[14:18] <lbt> [Friday 07 Aug 2009] [17:45:59] <ian_brasil> thursday in #ubuntu-meeting @ 13:00 UTC.
[14:18] <lbt> does that help?
[14:19] <Stskeeps> fridge claims it's at 21 i think
[14:20] <lbt> OK be back later then :)
[14:20] <lbt> lool:  thanks - appreciate the offer
[14:20] <lbt> you around later?
[14:23] <lool> lbt: The IRC meetings of the team are usually on Tuesday
[14:23] <lool> Not thursday
[14:23] <lool> If there was a special MID meeting I didn't get the worfd
[14:23] <lbt> there is something on http://fridge.ubuntu.com/calendar
[14:23] <lbt> for 21:00 GMT
[14:24] <lool> That's too late for me   :-/
[14:24] <lool> I'm on holidays starting tonight and am packing; it's 11pm my time and I had to stay up til 1am yesterday
[14:24] <lbt> np - I'll catch you again
[14:25] <lbt> have a good holiday!
[14:48] <blizzkid> lo all. I missed the last regional boards meetings, and won't be able to make it to the next one. Is my only option to become a member to attend one of the meetings?
[14:49] <Ursinha> blizzkid, I think so
[14:50] <blizzkid> that's a pitty
[14:51] <ziroday> blizzkid: you can attend one in another timezone
[14:51] <blizzkid> ziroday: yeah, I've seen that, but unfortunately only one has a date set for the next meeting that isn't in the past, and that one I won't be able to attend :)
[14:52] <blizzkid> the others' next meeting is in the past :)
[14:52] <ziroday> blizzkid: one sec
[14:52] <blizzkid> ok
[14:53] <ziroday> well if I remember correctly Oceania holds a meeting every other tuesday
[14:53] <ziroday> so next meeting being the 25th
[14:54] <ziroday> as for EMEA your best bet is to read the logs from the last meeting, or poke someone on the membership council(?)
[14:55] <blizzkid> yeah, I'll see if I can find it in the logs, or if I can poke someone, thx!
[14:55] <ziroday> blizzkid: good luck
[14:55] <blizzkid> ty
[15:17] <greg-g> blizzkid: the America's board has meetings on the second wednesday of the month at 22:00 UTC, just fyi. We'll also do meetings more frequently if it is needed.
[15:18] <blizzkid> greg-g: ok, so that'd be the second wednesday of September, I'll keep it in mind
[15:19] <greg-g> blizzkid: yeah, we just had one last night :)
[15:20] <blizzkid> greg-g: yeah, I saw it, I was too late :) Oth, I don't think (reading the logs) my wiki page will be considered sufficient
[15:21] <greg-g> blizzkid: gotcha. If you have any questions about areas to improve, let me know.
[15:21] <blizzkid> greg-g: ok if I send you the page url in pm?
[15:21] <greg-g> blizzkid: go ahead
[18:20] <blizzkid> greg-g: you still here?
[18:29] <greg-g> I am
[18:29] <Gnuet> 7wc
[18:30] <blizzkid> greg-g: had time yet to look at the wiki page?
[18:30] <blizzkid> I've been away for a while
[18:32] <greg-g> blizzkid: not yet
[18:32] <blizzkid> k, np :)