[00:30] <puff> recon_lap: Back... got a bit of time to kill, thought I'd spend it getting my machine backed up.
[00:36] <recon_lap> hi puff, was chilling.
[00:42] <puff> Cool.
[02:18] <Random833> okay now my default browser setting won't stick at all
[02:18] <Random833> every reboot, and after i pick it and start chromium it complains it's not the default browser
[02:23] <Dinomuffin> Random833: Settings > Preferred Applications?
[02:23] <holstein> Random833: or try sudo update-alternatives --config x-www-browser
[02:25] <Random833> Dinomuffin: i do that, then it's gone again
[02:25] <Random833> holstein: my _xfce_ browser preferences. I don't want to have to do a system-wide thing, and anyway x-www-browser is set to the right thing
[02:25] <Dinomuffin> try holstein's idea
[02:25] <Random833> but when i click the browser icon it complains i haven't set _the xfce setting_
[02:25] <holstein> Random833: i used the commandline setting
[02:26] <Random833> holstein: doing that _won't make it stop using the xfce setting_
[02:26] <Random833> i _did_ set the update-alternatives
[02:26] <Random833> and it works - _when i run x-www-browser from the command line_
[02:26] <Random833> which is not what i want
[02:26] <holstein> Random833: you can try it, because it works for me... did it not work for you?
[02:26] <Random833> ...it WORKS, but WHAT IT DOES it not WHAT I WANT
[02:27] <Random833> since that DOESN'T set the user preference that stuff is looking for
[02:27] <Random833> and I shouldn't have to mess with a systemwide setting anyway
[02:27] <holstein> Random833: cool.. you can just elaborate as to what you want and will see what myself and the other voluteers here can come up with..
[02:27] <Random833> I want to set the xfce preferred application
[02:27] <Random833> and have it stay set
[02:27] <Random833> it goes away when i log off
[02:27] <Random833> and asks me again next time i log in
[02:28] <Random833> and thunderbird doesn't respect x-www-browser, but it respected the desktop environment setting when i was on lxde
[02:28] <holstein> for me, setting it in the commandline worked.. you are saying that its not presistent when you set it from the command line? or you are not getting it?
[02:28] <Random833> ...what.
[02:28] <holstein> Random833: i read a workaround for thunderbird
[02:28] <Random833> I just said, the thing you set in the command line IS NOT THE SAME TIHNG i am trying to set
[02:28] <Random833> it's two different preferences
[02:28] <Random833> ...the command line setting DOES NOT AFFECT what the panel icon does
[02:28] <Random833> they're unrelated
[02:29] <holstein> Random833: for me.. the setting in the terminal was the one that became persistent
[02:29] <Random833> the setting in the terminal IS persistent
[02:29] <Random833> but it DOESN'T APPLY to the situation of clicking the panel icon
[02:29] <holstein> cool.. so the issue is just with thunderbird then? i have a work around...
[02:29] <Random833> it only applies to launching the browser from the terminal
[02:29] <Random833> ...noi
[02:29] <Random833> I JUST SAID
[02:29] <Random833> when i log in
[02:29] <Random833> and click the globe icon on the panel
[02:29] <Random833> it asks me to set my browser. AGAIN. AND AGAIN.
[02:30] <Dinomuffin> why not replace the globe shortcut with a chrome shortcut?
[02:30] <Dinomuffin> this is in your quicklauncher right?
[02:30] <Random833> ......because the globe shortcut is a SYMPTOM
[02:30] <holstein> Random833: for me, it did not only apply to launching it from the terminall it set chrome system wide
[02:31] <Random833> of the fact that the XFCE USER PREFERENCE is not persisting
[02:31] <holstein> change the shortcut then...
[02:31] <Random833> the xfce user preference that also applies to opening links from the terminal
[02:31] <Random833> and I _suspect_ to thunderbird, if it worked, since it worked in lxde
[02:33] <holstein> http://hsmak.wordpress.com/2009/09/03/howto-force-thunderbird-to-open-links-in-firefox/ is what i found and linked for someone recently
[02:33] <Random833> ...dammit, you're not listening. the problem is the xfce user preference
[02:33] <Random833> I don't _CARE_ about the /etc/alternatives setting
[02:34] <Random833> I shouldn't have to - what if two people on my computer prefer different browsers?
[02:34] <Random833> there's a REASON there's a desktop environment preference for it
[02:34] <holstein> Random833: im found that to be true as well.. i couldnt get chrome set as default.. but using the commandline worked for me
[02:34] <holstein> Random833: did you find an existing bug about it?.. i'll go look
[02:35] <Random833> before i report a bug i'll try cleaning my homedir
[02:35] <Random833> i did install xubuntu on top of lubuntu
[02:35] <Random833> it shouldn't make a difference, but just in case
[02:36] <holstein> https://bugs.launchpad.net/xubuntu-default-settings/+bug/893321 is for 11.10
[02:42] <Dinomuffin> arg
[02:42] <Random833> okay... apparently the way chromium sets itself as the default web browser isn't recognized by xfce
[02:42] <Random833> i'll see what happens if i ignore chromium's complaints that it's not the default browser
[02:45] <holstein> i might have said "dont ask again"...
[02:46] <Random833> ok this fixes the issue for the panel
[02:46] <Random833> but thunderbird still doesn't work - which wouldn't bother me except _it worked in LXDE_
[02:47] <Random833> maybe I'll do a fresh install for 12.10
[02:47] <holstein> i read it was a Tbird issue, and found some paes about how to change the default browser.. not sure why it worked for LXDE
[02:47] <holstein> some pages*
[02:47] <Random833> well, it helps that LXDE doesn't install firefox by default
[02:47] <Random833> but that can't be the whole story or it would have just not found a browser
[02:48] <Random833> er, that lubuntu doesn't
[02:48] <holstein> so it was lubuntu? not just ubuntu with lxde added?
[02:48] <Random833> this install started as lubuntu
[02:48] <Random833> then i gutted it and installed xubuntu-desktop on top of it
[02:48] <holstein> not that theres a whole lot of difference, but its helpful to be clear
[02:49] <holstein> if you only had the one browser, and it was chromiume.. thats pluasible
[02:49] <Random833> Honestly my first choice was lubuntu, but 12.04 has some issues with saving other sttings [like my terminal font]
[02:49] <Random833> so I switched
[02:50] <holstein> i think you should go with that.. thunderbird probably has the issue i found when searching the other day, and needs to be "fixed" manually to use chromium.. the gui browser selector may/may not be broken in xubuntu
[02:51] <Random833> there's some bad interaction between the browser selector and chromium
[02:52] <Random833> it doesn't detect chromium as a browser (so i have to type it in, and it saves as a custom-webBrowser.desktop)
[02:52] <Random833> and chromium tries to set itself as the default web browser using its proper .desktop
[02:52] <holstein> xubuntu doesnt ship with chromium though, so its hard to say... its always been "detected" for me
[02:52] <Random833> well, if you set x-www-browser to chromium, then it might be working simply by running sensible-browser
[05:03] <ner0x> Is it possible to change where Thunar/Desktop says the folders are?
[05:03] <ner0x> IE Setting the actual absolute path to the "Desktop" folder?
[05:42] <Random833> holstein: Dinomuffin: I found part of the issue - chromium-browser creates a corrupt .desktop file in ~/.local/share/xfce4/helpers
[05:42] <Random833> since the chromium .desktop file has multiple sections, and it just appends the helper data to the last one
[06:05] <Random833> okay, on further investigation, the blame goes to xdg-utils. I'll add a bug tomorrow once I figure out how to properly fix it
[06:56] <daughain_> What makes xfce different/
[06:56] <bazhang> from what
[06:57] <daughain_> Unity, enlightenment, gnome2/3, etc.
[06:57] <bazhang> different apps, look and feel, etc
[06:58] <bazhang> why not run a live cd and see for yourself
[06:59] <bazhang> http://xubuntu.org/screenshots/
[07:01] <daughain_> been there, came here. still there actually, trying to find out how it differs from someone who uses it because right now i'm just tired.
[07:05] <daughain_> whats the install package for xfce?
[07:05] <bazhang> xubuntu-desktop
[07:06] <daughain_> danke'
[07:07] <bazhang> you want a list of the default apps? its a bit lighter than gnome, but standard install not that much
[07:07] <bazhang> if you have very little ram/slow cpu then lubuntu (lxde + openbox is really the answer
[07:08] <daughain_> can i install temp monitors for cpu and hdd/
[07:08] <bazhang> +)
[07:08] <Mathias> if your system supports it, yes
[07:09] <bazhang> !sensors
[07:09] <daughain_> Thank you both for being more reasonable than the last channel i visited.
[07:09] <bazhang> ?
[07:09] <daughain_> ok, uses standard lm-sensors. cool.
[07:10] <Mathias> you didn't accidentally join #defocus? :P
[07:10] <daughain_> nope.
[07:10] <daughain_> lol
[07:12] <daughain_> as best i can tell, i have a 8-9 yr old dell w/512m ram, and a 1.5ghz centrino processor.
[07:12] <bazhang> that'll be slow
[07:13] <daughain_> ya think?  =)
[07:13] <bazhang> daughain_, yes.
[07:13] <daughain_> it an antique.
[07:14] <Mathias> intel pentium m?
[07:14] <Mathias> should run xubuntu smooth-ish
[07:14] <Mathias> some things takes ages on those :P
[07:14] <bazhang> the ram is the issue
[07:14] <Mathias> yup
[07:14] <daughain_> centrino, i think thats what they called the first gen pent M
[07:14] <Mathias> daughain_: they called all of them that :\
[07:15] <daughain_> i have trouble remembering last month, 8 years ago is a stretch. =)
[07:16] <daughain_> ok, let me reboot, and see what xfce is like. I think the UI installed.
[07:22] <daughain_> Looks a lot like gnome.
[07:24] <daughain_> Is there a difference between adding xfce from ubuntu and using xubuntu?
[07:25] <bazhang> extra apps
[07:25] <bazhang> mroe choices at the login window
[07:25] <koegs> daughain_: if you install xfce, you will get plain xfce, if you install xubuntu-desktop, you will get almost the same as using the xubuntu-cd
[07:26] <daughain_> I used xubuntu-desktop.
[07:27] <daughain_> so, what is it that makes xfce/xubuntu different from gnome? My initial impression is they are exceedingly similar.
[07:28] <bazhang> thats opinion
[07:28] <bazhang> not a support question
[07:30] <Mathias> daughain_: less eyecandy ;P
[07:30] <daughain_> I asked what made the two different, and then added my initial impressions. Is it simply that xubuntu uses 'lighter' apps and a 'lighter' UI? And, where should i ask these questions?
[07:30] <bazhang> not much lighter, no
[07:31] <bazhang> in terms of actual ram usage, if that is the measure
[07:33] <daughain_> So, what channel should I use for non-support questions?
[07:33] <bazhang> !ot
[07:33] <daughain_> Danke.
[07:34] <bazhang> np
[10:17] <Fiona> Bonjour
[10:18] <Fiona> !help
[10:19] <Fiona> Bonjour
[11:19] <jacta> if I download latest 12.10 now and install, will I then be able to update to the full release in a few days when it comes out?
[11:20] <apm1> yup
[11:21] <apm1> just run " sudo apt-get update" and "sudo apt-get dist-upgrade" every day
[11:21] <jacta> I have so many errors in 12.04 - first thing is that I cant mount usb drives, or atleast only one pr reboot :\
[11:21] <jacta> so its kinda annoying ;)
[11:21] <apm1> jacta, what kinda hardware is this ?
[11:21] <jacta> just a dell laptop, think I did to many strange thigns :\
[11:22] <apm1> strange like ?
[11:22] <jacta> so last night I used usb drive 5 times, had to reboot machine after each re-insert
[11:22] <jacta> cant even remember, no things auto mount more
[11:22] <jacta> <- fool
[11:22] <jacta> :D
[11:22] <apm1> run "sudo apt-get install gparted"
[11:23] <jacta> I have gparted - it only let me mount drive once - rest of time its grayed out
[11:24] <apm1> jacta, hmm, have you screwed with this system in any way , i.e installed another OS , changed a config file ?
[11:25] <jacta> I'm not really sure - prolly I had, also can't see files in dvd drive :o
[11:25] <apm1> jacta, if you are not sure what you messed with then my advice is do a clean install (reinstall) of 12.04
[11:26] <jacta> why not 12.10 then?
[11:26] <apm1> because 12.04 has a more stable base than 12.10
[11:26] <jacta> But is it possible to upgrade to 12.10 just like that when it comes in a few days?
[11:27] <jacta> 12.10 should be pretty stable as the new will get out in a few days, or?
[11:27] <apm1> no not if you are currently running 12.04
[11:27] <apm1> why do you think they call 12.04 a LTS because it's freaking semi rock solid
[11:29] <jacta> So you would advice me to reinstall it all with 12.04 again instead of waiting on 12.10 gets more stable?
[11:30] <apm1> yup
[11:30] <jacta> Anyways, can't live with reboots every time I need to usb usb drive :]
[11:32] <apm1> honestly if you were a little more experienced in linux i would have adviced you to move to debian as i did :)
[11:35] <jacta> with xfce?
[11:36] <torax> debian still has gnome2
[11:37] <torax> so if you dont like gnome3/unity and you know your way around linux a bit use debian
[11:38] <jacta> Just need to clarify my preferred interface, right now its xfce
[11:39] <jacta> what I really miss is when using alt+tab - then I miss it to be able to click in the dumps of screen to go to - do you understand? :)
[12:32] <greasegum> hey friends, does anyone know if it's possible to upgrade just ONE package and its dependencies (including shared) to Wheezy if I'm running stable?
[12:35] <koegs> !ot
[12:38] <Pici> greasegum: you want #debian
[12:41] <greasegum> Pici:: thanks, you're totally correct
[14:46] <kristjan_> To which package do graphics that show display brightness (Fn+brightness_up/down) belong?
[14:48] <recon_lap> kristjan_:  would think it's whatever you're using as graphics driver and your actual graphics card
[14:48] <kristjan_> recon_lap, the OSD
[14:48] <recon_lap> kristjan_: any particular reason you asking?
[14:49] <kristjan_> recon_lap, want to bug report
[14:49] <recon_lap> kristjan_: is the bug that you cannot set your brightness ?
[14:50] <kristjan_> recon_lap, no, it's about lag
[14:52] <recon_lap> kristjan_: well, this not related to lag but sure to have some related info https://wiki.ubuntu.com/Kernel/Debugging/Backlight
[14:53] <recon_lap> kristjan_: especially regarding display brightness
[14:56] <kristjan_> recon_lap, my problem is different: http://i.imgur.com/5HS77.jpg < -- this lags sometimes many seconds behind
[14:57] <kristjan_> recon_lap, to which package does this osd graphic belong?
[14:59] <GridCube> !info xfce4-notifyd
[14:59] <GridCube> kristjan_, ^
[15:05] <kristjan_> GridCube, yes, thanks
[18:03] <milen8204> hello, any one could help whit that error massage http://pastie.org/5074437 , that I get after update installing?
[18:04] <baizon> milen8204: sudo apt-get install -f
[18:05] <baizon> try that
[18:05] <milen8204> ok
[18:06] <milen8204> : Sub-process /usr/bin/dpkg returned an error code (1)
[18:07] <GridCube> milen8204, do sudo apt-get update && sudo apt-get autoclean && sudo apt-get autoremove
[18:08] <milen8204> GridCube, ok thanks
[18:08] <milen8204> baizon, thanks for you too
[18:08] <baizon> np
[18:08] <baizon> if you need more help feel free to ask
[18:09] <milen8204> baizon, ok thanks a lot
[18:10] <milen8204> but the problem is still here :
[18:11] <GridCube> do you get any warning while doing the apt-get update?
[18:11] <milen8204> http://pastie.org/5074462
[18:11] <milen8204> that is the report
[18:12] <GridCube> milen8204, run gldaemon by hand
[18:12] <milen8204> i a terminal ?
[18:12] <milen8204> in a terminal?
[18:12] <GridCube> the error report says its not configured yet and thats why its failing to continue
[18:12] <GridCube>   Package g15daemon is not configured yet
[18:13] <GridCube> milen8204, yes
[18:13] <milen8204> said that the package is not found
[18:14] <recon_lap> does that mean 12.10 is out?
[18:14] <GridCube> !info g15daemon
[18:15] <nyRednek> i forget, is there a shell command to display your processor speed/memory?
[18:16] <GridCube> i use top
[18:16] <GridCube> but i guess there might be a better one
[18:16] <nyRednek> GridCube: does top actually display processor speed? or just usage?
[18:17] <GridCube> usage
[18:21] <baizon> i recommend byobu
[18:21] <milen8204> it may done
[18:22] <GridCube> nyRednek, you could use the outputs of lshw
[18:22] <GridCube> lshw -class cpu
[18:42] <agrester> Hello all, got a quick question: how do I change the boot screen in Xubuntu to text?
[18:42] <agrester> I just want to see the text startup process
[18:43] <baizon> agrester: edit /etc/default/grub
[18:43] <agrester> ok
[18:43] <baizon> change this line: GRUB_CMDLINE_LINUX_DEFAULT=""
[18:43] <baizon> from GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
[18:43] <baizon> then run update-grub
[18:45] <agresterer> back
[18:45] <agresterer> Okay, so the login screen will still show up?
[18:46] <baizon> yes it will :)
[18:46] <baizon> agresterer: http://askubuntu.com/questions/120898/removing-the-splash-screen-on-shutdown-an-startup-i-want-to-be-able-to-see-the
[18:47] <agresterer> Thanks
[18:47] <agresterer> Will bookmark that
[18:47] <baizon> np
[18:49] <kcxzero> I don't think the gui login screen will still show up, if that's what you're asking. It will ask you via command line for usrnme and pw.
[18:49] <baizon> kcxzero: yes if you add: GRUB_CMDLINE_LINUX_DEFAULT="text"
[18:50] <agresterer> How do I change the boot splash theme?
[18:50] <baizon> if its empty ("") then it will boot into lightdm
[18:50] <kcxzero> oh ok, cool. Never done that I guess. I must have just removed the content in the quotes entirely in the past.
[18:50] <baizon> agresterer: http://www.noobslab.com/2011/11/install-plymouth-manager-and-change.html
[18:50] <agresterer> baizon: got it so 'quiet' turns of the ESC thingy, 'text' forces text only mode, 'splash' enables splash screen
[18:51] <agresterer> If I hit ESC with just 'splash' it will show the boot processes...
[18:51] <baizon> agresterer: yes
[18:53] <agresterer> I love that Mice theme, the Mac OS 9 style one...
[18:53] <agresterer> could I use that?
[18:53] <baizon> agresterer: from?
[18:53] <agresterer> the sessions and startup admin panel
[18:53] <baizon> yes you can use it :)
[18:55] <agresterer> where is it located?
[18:56] <baizon> agresterer: you have to install the programm from ppa or source
[18:56] <agresterer> it doesn't have one for precise
[19:00] <baizon> agresterer: then use this one: http://sourceforge.net/projects/plymouthmanager/
[19:00] <agresterer> thanks
[19:00] <baizon> np
[19:05] <agresterer> rebooting
[19:19] <wroat> When I download with wubi, it says it's unable to download the metalink. How do I fix it?
[19:27] <puff> Afternoon.
[19:28] <genii-around> I thought xubuntu was dropping wubi
[19:28] <puff> I'm running xubuntu 11.4;  actually I'm running ubuntu 11.4 with the xfce package installed;  I was told (here) that was equivalent to reinstalling from scratch with xubuntu, but I guess not because there's no xfce-panel installed.
[19:28] <puff> So, I use the multiple virtual desktops thing... every now and then when I'm mouse-dragging a window from one virtual desktop to another, I drag too high or something, and the menu bar re-draws itself.  Last night, I'm not sure what I did, but it didn't redraw itself; I mean it disappeared, or at least is empty.  There's a black bar across the top of the screen where the menu bar should be. Any ideas how to get the menu bar to rea
[19:29] <wroat> Really genii-around? Is Lubuntu dropping it too?
[19:31] <recon_lap> puff: I take it you rebooted, is the panel still missing?
[19:31] <genii-around> wroat: No idea. But it looks like your issue is most likely the same as this: http://askubuntu.com/questions/189875/xubuntu-download-error-with-wubi
[19:31] <kcxzero> puff, to run xfce alt-f2 type xfce4-panel. However, that's just to start the panel. Not sure about the black thing.
[19:32] <genii-around> wroat: They suggest there to download the iso and run wubi from that instead of having it try to go grab averything
[19:32] <puff> recon_lap: No, haven't rebooted yet :-).
[19:32] <wroat> Thanks for the link.
[19:33] <puff> Oddly enough, when I try to run it via alt-f2, it finds xfce-panel.
[19:34] <puff> it defaulted to xfce-panel --restart, so I hit enter and now it asks me: "No running instance of xfce-panel was found.\ n\  Do you want to start the panel?  If you do, make sure you save the session on logout, so the panel is automatically started the next time you login."
[19:35] <recon_lap> puff: to many picky details I dont know to help, biggest is that it's a ubuntu install with xfce desktop
[19:36] <puff> recon_lap: Yeah.
[19:36] <puff> Guess I'll go ahead and click "execute", worst that can happen is I need to reboot....
[19:36] <puff> Ah... and that seems to have fixed it.
[19:37] <puff> Just to check... in xfce the menu bar at the top of the screen is called the applet panel?
[19:37] <puff> Also, is there any way for me to prevent that whole drag/redraw thing from happening, other than simply not dragging windows between desktops?
[19:38] <kcxzero> puff,  settings manager.
[19:38] <recon_lap> puff: you should be able to lock the panel
[19:38] <puff> Hm, it appears to be already locked.
[19:39] <puff> Maybe it's different because I restarted it.  I'll make a note about checking the prefs again, next time I see that behavior.
[19:39] <recon_lap> puff: I dont think you restart anything, think you got a whole new panel
[19:40] <puff> Yeah, I guess so.
[19:42] <recon_lap> puff: or maybe the first one crashed and this was a restart
[19:43] <kcxzero> to disable dragging windows to new workspace go to settings manager > window manager>advanced tab then uncheck wrap workspace when dragging a window off the screen.
[19:43] <puff> kcxzero: I don't want to disable dragging windows to new workspaces, I want to disable that weird redraw-the-applet-panel thing.
[19:43] <kcxzero> oh auto hide?
[19:44] <kcxzero> right click panel > panel preference then uncheck auto show and hide panel
[19:44] <recon_lap> more like awol
[19:44] <puff> No, just occasionally when I am dragging a window to a different workspace, something happens - I think the mouse cursor drifts too far upward and his the top edge of the screen - and the applet panel redraws.  Sometimes it redraws incompletely.   This last time it disappeared.
[19:45] <puff> I should clarify, I'm dragging the icons around on the workspace applet, not on the main screen.
[19:45] <kcxzero> oh ok, my bad. never experienced that issue before.
[19:46] <puff> Yeah, I think either I somehow applet panel Preferences Lock Panel got unchecked.
[19:48] <puff> recon_lap: I just figured out, last night I must have typo'd xfce-panel instead of xfce4-panel.
[19:49] <puff> Once again, #freenode to the rescue.  Muchos gracias, gang.
[19:49] <puff> Er, freenode #xubuntu to the rescue :-).
[20:28] <xubuntu177> Hello.  I am want to find out if the xubuntu gui has a common problem with loss of bar controls.
[20:29] <xubuntu177> Is a helper available?
[20:30] <kcxzero> xubuntu177,  the panel? could you expand on what you mean by loss of controls?
[20:31] <xubuntu177> OK. Drop down, and movement of window does not work for any application.  Two clean installations have had this problem after using for several hours of up time.
[20:34] <xubuntu177> For example an open application can't be closed using the dropdown menu and  corner buttons are missing.
[20:35] <kcxzero> oh ok
[20:35] <Sysi> xubuntu177: rm -rf ~/.cache/sessions and log out without saving session
[20:36] <xubuntu177> Then what?
[20:36] <kcxzero> log back in? lol
[20:36] <kcxzero> I've had that issue before too. i stoped using save sessions
[20:37] <kcxzero> just assigned startup applications, instead of saving my sessions.
[20:39] <xubuntu177> OK, I'll give that a whirl.  I am now on my other system with Mint 13 Xfce and it does not seem to have such a problem. I will probably be back.  Thanks for your help.
[20:39] <kcxzero> Yeah, try what he said. It worked for me in the past, hopefully it fixes your issue too.
[20:40] <xubuntu177> You mean there have been other reports of this issue?
[20:40] <kcxzero> I know I've had that issue when saving sessions. But I've never looked to see if anyone else had it.
[20:41] <kcxzero> It seemed to have happened to me when saving a session with applications running on multiple workspaces, but that could have just been a coincidence. I never took the time to mess with it too much. After disabling save sessions I never messed with it again.
[20:43] <xubuntu177> Disabling save.. was a long lasting fix for you kcxzero?
[20:44] <kcxzero> yeah, it should not happen again. By disabling save session you will boot into a new session each time. It only happened because I saved the session, do you know what I mean?
[20:45] <kcxzero> going by what you described, it sounds like exactly what happened to me. Missing borders, can't move windows etc.
[20:46] <xubuntu177> OK. So can this be elevated to the coding guys as a to-do?
[20:48] <kcxzero> I guess, if it's a bug.
[20:48] <xubuntu177> BIG bug IMHO as a dumb user.
[20:48] <Marzatha> what?
[20:49] <kcxzero> I can't seem to find anyone else mentioning it online. So after I fixed it, I never bothered with it again honestly.
[20:49] <Sysi> it's quite common problem but devs haven't really been able to reproduce it
[20:50] <kcxzero> Oh ok, so its known. It seemed to have happened to me when I saved a session on multiple workspaces.
[20:52] <xubuntu177> I usually clear all work spaces of all apps before closing so that would not seem to be a trigger.
[20:52] <xubuntu177> power off I mean
[20:54] <kcxzero> yeah, probably just a coincidence then. The only time it ever worked for me was when I only had a few apps running. Firefox, thunderbird. Then it was fine. Anytime I had enough programs running to utilize multiple workspaces was when I ran into the issue.
[20:56] <xubuntu177> to Sysi:  How do kxczero and I provide clues to help find the origin of this problem?
[20:57] <kcxzero> Is there a bug report?
[20:59] <xubuntu177> I have not submitted a bug report on this.
[20:59] <kcxzero> As I said, I never found anyone else mentioning the issue before. But I'm searching through launchpad now to see.
[21:00] <xubuntu177> OK, waiting for you
[21:01] <kcxzero> I don't see anything about it.
[21:04] <xubuntu177> That is odd if Sysi says it is a common problem
[21:04] <recon_lap> whats the problem?
[21:05] <kcxzero> where the windows manager crashes when you start a saved session. Missing borders etc.
[21:05] <xubuntu177> Right
[21:06] <kcxzero> I'm finding solution of how to restart it and deleting saved session, but no bug report.
[21:08] <recon_lap> never really noticed saved sessions, other than app restarting when i log in if i did not close them when i shutdown
[21:09] <kcxzero> Well actually what I'm finding has nothing to do with saved sessions, simply windows manager crashing. So I correct my statement. No, I don't see anything about saving sessions causing windows manager to crash.
[21:10] <kcxzero> So I should correct*
[21:10] <recon_lap> have you checked you error log?
[21:10] <xubuntu177> If you will excuse me for a minute, I will try kxczeros band aid on the problem system.  I will stay "live" here.
[21:11] <kcxzero> be sure to do what Sysi said. Delete your previous session. Then I would suggest disabling sessions from being saved automatically.
[21:13] <kcxzero> so recon_lap since apps are restarting if you don't close them before logging out, that means you have save sessions enabled?
[21:13] <recon_lap> would appear that is the case, never really paid much attention to it
[21:15] <recon_lap> oddly I dont have "Automatically save session on logout" checked
[21:16] <kcxzero> ok, thanks for the info. When i saved session I windows manager would crash. So I disabled it. I haven't used it in awhile. Were talking about it now because it sounds like the same thing is occurring to xubuntu177.
[21:17] <kcxzero> hmm, do you just have those applications set to startup on boot then, maybe?
[21:18] <recon_lap> let me log out and in again and see what happens , and firefox is the app I normally notice auto starting
[21:18] <kcxzero> What about settings manager > session and startup > general tab. Do you have auto save session on logout checked?
[21:18] <recon_lap> nope
[21:19] <recon_lap> brb
[21:20] <xubuntu177> My rig has the problem even with gedit window. i.e. no window buttons and no ablity to move the window with mouse grab.
[21:20] <kcxzero> yeah, sounds like windows manager has crashed and you can't control any app since the border is gone.
[21:20] <xubuntu177> I tried kcxzero's bandaid but it did not work.
[21:21] <xubuntu177> How do I delete the session on quit?
[21:21] <kcxzero> did you do what Sysi said. Delete the previous sessions?
[21:21] <xubuntu177> see Q
[21:21] <kcxzero> rm -rf ~/.cache/sessions
[21:22] <xubuntu177> OK, I open terminal and put that line in?
[21:22] <kcxzero> yeah
[21:23] <kcxzero> that will delete your previously saved sessions
[21:23] <xubuntu177> OK will do per kxczero
[21:24] <recon_lap> seems sessions getting saved despite not having it selected
[21:25] <kcxzero> recon_lap, you don't just have those application set to autostart in settings manager > application autostart? That's weird.
[21:26] <kcxzero> settings manager > session and startup > application autostart*
[21:28] <recon_lap> kcxzero: no, the not in that application list, firefox is the most likely to autostart. but i was switching between  xfce session and xubuntu session , so i'm a bit vague, but it was doing it in both
[21:29] <kcxzero> ok, thanks.
[21:29] <recon_lap> but pidgin did it as well
[21:29] <xubuntu177> OK tried kcxzero's solution but system reply was "cannot delete ' home/mydirectory'.  So it looks like I almost deleted my home directory
[21:30] <kcxzero> you used this rm -rf ~/.cache/sessions  ?
[21:30] <kcxzero> that should not remove your home directory
[21:30] <kcxzero> don't forget the ~
[21:30] <xubuntu177> yes exactly
[21:30] <xubuntu177> tilde was included
[21:31] <kcxzero> not sure then, have no idea why it would attempt to delete anything in your home directory.
[21:31] <xubuntu177> I will go back and check standby please
[21:32] <recon_lap> I got 10 files in that sessions folder
[21:32] <kcxzero> yeah, bunch of thunar ones?
[21:33] <kcxzero> and session
[21:33] <recon_lap> yep, wonder if it's just stopped saving new ones but still loading old ones
[21:33] <kcxzero> I can't remeber what the session ones are saved as.
[21:35] <recon_lap> xfce-session-username-machine:0 ,  xfce4-longidxxxxxxx.state
[21:35] <xubuntu177> SUCCESS!!
[21:36] <xubuntu177> I put a space between . and cache --- hand copying error.   Now window controls work OK
[21:36] <kcxzero> Great, glad you fixed it. recon_lap yeah that's it. I was just about to save a session just to check, saved me from having to thanks.
[21:38] <xubuntu177> I don't have any reason to save sessions but this should still be in a bug report?
[21:38] <kcxzero> I would think so.
[21:39] <kcxzero> Do you have sessions disabled now? like when you log out do you have save sessions for future login unchecked?
[21:39] <kcxzero> saved sessions* I should say.
[21:40] <kcxzero> Otherwise it may happen again. But since now you have the solution it may not be much of a big deal.. That's if you want to save your session. As for me I just autostart everything I need.
[21:40] <xubuntu177> Yes save sessions is disabled (unchecked)
[21:40] <kcxzero> ok cool
[21:42] <recon_lap> going to see if i can reproduce this behavior
[21:42] <xubuntu177> Xfce is my favorite.  I would like to keep it improving.  Do I have any further actions to help?
[21:43] <kcxzero> looks like recon_lap is going to try and reproduce it, see what he comes up with.
[21:43] <xubuntu177> Standing by
[21:43] <kcxzero> If he comes back you could always provide him with as much info you can to help. I'll stick around. But yeah, I couldn't find an actual bug report about it so...
[21:45] <kcxzero> recon_lap knows what he's talking about so if he can reproduce it he'll probably be the best person to start a bug report. I normally just contribute to things that have already been mentioned haha.
[21:45] <xubuntu177> Why did recon_lap have to leave.  Can't he just switch between computers like I can?
[21:46] <kcxzero> switch between computers? He may not have two computers? I personally would have done it on a virtual machine, but he may be logging out and doing it on his own.
[21:46] <kcxzero> is that what you mean xubuntu177, using two different computers?
[21:47] <xubuntu177> I have 3 boxes w/ 3 OSs on each
[21:49] <recon_lap> hmm, can't seem to get it to save session's at all now. if saved sessions are meant to open app's that where open when you logout
[21:50] <xubuntu177> That is the expected feature, right?
[21:50] <kcxzero> yeah, saved sessions are suppose to open up exactly what you had opened prior to logging out. However, I never got pidgin to ever open when I used it
[21:51] <xubuntu177> more bugs -- bummer
[21:52] <recon_lap> ok, the thunder files in .cache.sessions are all size 0
[21:53] <xubuntu177> Now, if il leave this string, how the h___ do I find out if this will continue to get resoved?
[21:53] <kcxzero> I don't think the thuner files have anything to do with it. I think it's the other ones. The ones all the way on the bottom, one you mentioned previously when I was asking about it
[21:53] <kcxzero> This one >  xfce-session-username-machine:0 ,  xfce4-longidxxxxxxx.state
[21:53] <recon_lap> ok, not seeing those files at all now
[21:54] <recon_lap> must be leftovers from previous bug
[21:55] <enjoyfebruary> Hi there. Does Xubuntu have cpu socket limitation?
[21:56] <kcxzero> xubuntu177, just hope? haha. I guess the best way would be to start a bug report, but I have no experience with that. All I've done is contribute to existing ones.
[21:57] <xubuntu177> One more thing.  There is a precursor behavior of the screen where I have a vertical panel on the left and the column of icons on the left do not shift over  (yes the panel is "locked") This is also cured by not saving the session.
[21:58] <recon_lap> xubuntu177: well if the panel was somewhere else in the saved session and it was loading that session that would move the panel
[22:00] <xubuntu177> What I am implying is that with saving sessions enabled.  The gui seems to degenerate, feature by feature with each use.
[22:00] <livingdaylight> greetings
[22:00] <recon_lap> xubuntu177: from my testing just now i dont think it's save sessions at all atm
[22:01] <kcxzero> no? seemed to happen to me pretty consistently following a saved session
[22:01] <kcxzero> haven't had it happen since I stopped using saved sessions
[22:02] <xubuntu177> I am saying there is some sort of ugly build up after many "saved" sessions.
[22:04] <recon_lap> kcxzero: what i think happened is that the saved session feature was fubar when it was rolled out, appears to do nothing now, but if you had files left over from the fubar release they still load, as the desktop gets updated the saved sessions get more and more out of date and cause more issues, when you remove the old saved sessions they are never loaded or created again
[22:05] <recon_lap> but i could be wrong :)
[22:05] <xubuntu177> If you all know how to elevate this issue.  Please do so.
[22:06] <xubuntu177> It at least should be in the "known bugs" data base
[22:07] <recon_lap> xubuntu177: it's one of those bugs that is hard to reproduce, I tried but cant
[22:10] <xubuntu177> OK thank all of you for your help.  I think I have made all the trouble I can. Carry on X-men!
[22:13] <livingdaylight> hi
[22:13] <xubuntu177> Last thought: maybe the location for storing the last session accumulates to the point that it starts to overwrite the location for the gui program file?
[22:16] <GridCube> !hi | livingdaylight
[22:17] <livingdaylight> Any suggestions how I can change the time/Date?
[22:18] <livingdaylight> http://clip2net.com/s/2piay
[22:18] <livingdaylight> Are there other time apps to install available?
[22:18] <xubuntu177> bye
[22:18] <livingdaylight> I've played with the settings of this clock and its very limited
[22:18] <livingdaylight> as the screenshhot shows the date is on top of Time making it very cramped
[22:20] <livingdaylight> anyone? :/
[22:21] <livingdaylight> I actually quite like how gnome shell 3 has the clock date in the middle of the panel - nice and clear too
[22:21] <recon_lap> livingdaylight: have you tried clicking on it? it should drop down
[22:22] <livingdaylight> ?
[22:22] <livingdaylight> clicking on it drops the calendar down. I'm talking about the default Date/Clock settings
[22:22] <recon_lap> livingdaylight: you can select properties as well and change the font size and format
[22:23] <livingdaylight> as I say, I've played with properties - very limited and I'm still left with either Clock on top fo Date or Date on top of Clock
[22:24] <livingdaylight> just enlarging the fonts makes them collide - its really ugly
[22:26] <livingdaylight> see no option for making it all read in one
[22:28] <livingdaylight> gawd, if I talk crap everyone stops to bother taking the time to tell me that this is a xubuntu support channel and to stay on topic. If, when I ask a xubuntu-related question - no one appears to be around.
[22:32] <livingdaylight> !hi | GridCube


[01:38] <niemeyer> thumper: Yo
[01:39] <thumper> niemeyer: oh hai
[01:39] <thumper> I had a go question...
[01:40] <thumper> if you have a select and each of the cases are waiting on a channel
[01:40] <thumper> what is happening under the covers?
[01:40] <thumper> and that select is inside a for { }
[01:40] <thumper> like the provisioner
[01:40] <niemeyer> thumper: An epoll
[01:41] <niemeyer> thumper: Not sure if that's your question, though?
[01:41] <thumper> niemeyer: I was just wanting to make sure it wasn't doing stupid looping when nothing is happening
[01:42] <thumper> I considered wrting a test app to check, but got busy thinking of something real
[01:42] <niemeyer> thumper: Ah, no, it will block
[01:42] <niemeyer> thumper: Unless you have a default in the select loop.. then it would spin like crazy
[01:42]  * thumper nods
[01:43] <niemeyer> s/select loop/select clause/
[02:19] <wallyworld_> thumper: if you have a moment at some point, https://code.launchpad.net/~wallyworld/juju-core/create-machine-command/+merge/165518
[02:19] <thumper> wallyworld_: sure
[02:20] <wallyworld_> thumper: i didn't update machine state to include a Clean attribute. still not sure if we want that or not
[02:20] <thumper> wallyworld_: I'm about to email the group about my proposed machine state changes as there are a lot of them
[02:21] <wallyworld_> i'm thinking if we do add it, we can change the default assignment policy
[02:21] <wallyworld_> from AssignNew to AssignUnused
[02:22] <wallyworld_> since we can look for a "clean" machine
[02:22] <thumper> right...
[02:22] <thumper> there is more to it though :)
[02:22] <thumper> which I'll be putting in the email
[02:22] <wallyworld_> sure, containers complicate things
[02:23] <wallyworld_> what i say above gives us the same thing as we have now
[02:23] <wallyworld_> since without it, create-machine just wastes resources
[02:23] <thumper> wallyworld_: well, you sould be able to use --force-machine
[02:23] <thumper> wallyworld_: does that work?
[02:23] <wallyworld_> ah,true
[02:24] <wallyworld_> should work
[02:24] <wallyworld_> the machine is created, spun up, and is just sitting there
[02:24] <wallyworld_> with no principal units or anything running
[02:24] <wallyworld_> i'll check it out
[02:34] <wallyworld_> thumper: all works as expected :-)
[02:46] <thumper> wallyworld_: good
[02:48] <wallyworld_> thumper: i think juju status should print out the constraints for the machine
[02:48] <wallyworld_> right now it doesn't seem to do that
[02:48] <thumper> perhaps a flag
[02:48] <thumper> we are getting too much info by default
[02:49] <thumper> much more than is usually useful
[02:49] <wallyworld_> you think?
[02:49] <wallyworld_> i sorta like what's there now
[02:50] <wallyworld_> there's only 5 lines for eacdfh machine
[02:50] <wallyworld_> adding one more for constraints doesn't seem too bad
[05:25] <thumper> well, that is me about done for the day
[06:32] <rogpeppe1> mornin' all
[06:34] <kyhwana> evening
[06:51] <dimitern> morning
[06:51] <rogpeppe1> kyhwana: :-)
[06:51] <rogpeppe1> dimitern: hiya
[06:53] <dimitern> rogpeppe1: hey
[06:54] <dimitern> rogpeppe1: i couldn't finish yesterday because just as i was nearing the end and only a few more test cases were needed, i started getting test failures or panics when running the apiserver tests; but not all the time, like 1 in 10 cases
[06:54] <rogpeppe1> dimitern: hmm, that's not entirely surprising for that kind of logic.
[06:55] <rogpeppe1> dimitern: have you run it with race detection on?
[06:55] <dimitern> rogpeppe1: yes, multiple times - no races
[06:56] <rogpeppe1> dimitern: well, not a memory race anyway, eh? :-)
[06:56] <dimitern> rogpeppe1: so there are 2 kinds of failures - timeouts for the watchers (always the same - next() returns a stopped error before stopping either the server or the watcher - and in the logs i can see it is indeed getting stopped somehow)
[06:58] <rogpeppe1> dimitern: is that one kind of failure or two?
[06:58] <dimitern> rogpeppe1: another issue is the pretty long and somehow not very legible panic, usually mentioning PutCharm some 50 frames down and having mgo stuff close to the top
[06:58] <rogpeppe1> dimitern: could you paste the panic here?
[06:59] <dimitern> rogpeppe1: running them again
[07:01] <dimitern> rogpeppe1: http://paste.ubuntu.com/5696111/
[07:01] <rogpeppe1> dimitern: interesting, looks like a runtime bug
[07:01] <rogpeppe1> dimitern: you can reproduce this ok?
[07:02] <dimitern> rogpeppe1: trying more times
[07:03] <dimitern> rogpeppe1: how can you tell is likely a runtime bug?
[07:03] <rogpeppe1> dimitern: it's dying during garbage collection
[07:04] <dimitern> rogpeppe1: wow :) these kind of things always happen to me :D
[07:04] <rogpeppe1> dimitern: so it seems.
[07:05] <rogpeppe1> dimitern: please could you try and see if you can reproduce the behaviour using gustavo's new Go-only yaml implementation
[07:05] <dimitern> rogpeppe1: it happened again - almost the same, but trace order is changed a bit
[07:06] <dimitern> rogpeppe1: http://paste.ubuntu.com/5696122/
[07:06] <dimitern> rogpeppe1: so how to get it?
[07:08] <rogpeppe1> dimitern: i'm just looking for it
[07:10] <dimitern> rogpeppe1: hmm now it happens on every run - yesterday happened less often.. also it doesn't happen if I run individual tests
[07:10] <rogpeppe1> dimitern: https://code.launchpad.net/~niemeyer/goyaml/go-port
[07:11] <dimitern> rogpeppe1: so what - delete the goyaml in gopath and get this instead?
[07:12] <rogpeppe1> dimitern: yeah - although you'll need to manually branch it into launchpad.net/goyaml
[07:12] <dimitern> rogpeppe1: or just remove the files and replace them
[07:12] <rogpeppe1> dimitern: yeah, that's probably easier
[07:14] <TheMue> morning
[07:14] <rogpeppe1> dimitern: fairly trivial CL: https://codereview.appspot.com/9681045
[07:14] <rogpeppe1> TheMue:  hiya
[07:15] <dimitern> TheMue: hey
[07:15] <dimitern> rogpeppe1: looking
[07:17] <dimitern> rogpeppe1: LGTM
[07:17] <rogpeppe1> dimitern: ta
[07:18] <dimitern> rogpeppe: ha! i happened at first with goyaml-go, but wasn't sure it's clean, so I went in pkg/linux_*/launchpad.net/ and deleted goyaml.a
[07:18] <dimitern> rogpeppe: now there's no panic, just some failures
[07:19] <rogpeppe> dimitern: hmm. keep trying
[07:19] <dimitern> rogpeppe: http://paste.ubuntu.com/5696153/
[07:20] <rogpeppe> dimitern: it may still be a runtime bug
[07:20] <rogpeppe> dimitern: just that you're not triggering it any more for some reason
[07:20] <dimitern> rogpeppe: oops there is it again: http://paste.ubuntu.com/5696157/
[07:20] <rogpeppe> dimitern: because i'm not sure the code path you're testing uses yaml much
[07:21] <rogpeppe> dimitern: ah, good. (well, kinda :-])
[07:21] <rogpeppe> dimitern: could you push the branch - i'll see if i can reproduce
[07:22] <dimitern> rogpeppe: sure
[07:22] <dimitern> rogpeppe: ha! now all passed
[07:22] <rogpeppe> dimitern: run it in a loop
[07:23] <TheMue> *: any probs with the current goyaml?
[07:23] <dimitern> rogpeppe: lp:~dimitern/juju-core/041-provisioner-api-calls
[07:23] <dimitern> rogpeppe: how do you mean in a loop?
[07:25] <dimitern> rogpeppe: it seems it happens in the TestOperationPerm ... except now it happened later + a failure: http://paste.ubuntu.com/5696171/
[07:26] <rogpeppe> dimitern: while true; do go test; done
[07:28] <dimitern> rogpeppe: running
[07:31] <rogpeppe> dimitern: i've just reproduced it
[07:31] <dimitern> rogpeppe: cool
[07:32] <dimitern> rogpeppe: w/o goyaml-go?
[07:33] <rogpeppe> dimitern: no - i'll just try with non-cgo goyaml
[07:34] <dimitern> rogpeppe: ok, if it's indeed a runtime bug now begins the tedious hunting for a minimal case to reproduce i guess..
[07:34] <rogpeppe> dimitern: yeah.
[07:41] <dimitern> rogpeppe: while you're looking at this, i'll finish the rest of the tests, so hopefully if there's a way around the panic it'll be ready for proposing
[07:41] <dimitern> rogpeppe: if you don't mind
[07:42] <rogpeppe> dimitern: you could work against 1.0.3 for the time being
[07:42] <dimitern> rogpeppe: does it work like that?
[07:42] <rogpeppe> dimitern: it certainly should do
[07:43] <rogpeppe> dimitern: we're trying to keep 1.0.3 compatibility after all
[07:43] <rogpeppe> dimitern: if it doesn't, it's a bug
[07:43] <dimitern> rogpeppe: i'm getting 1.0.3 again to try
[07:43] <rogpeppe> dimitern: if you're using go from source, you can just do hg update go1.0.3
[07:44] <rogpeppe> dimitern: then run all.bash
[07:45] <dimitern> rogpeppe: I'll put it in a separate dir and just wipe out the gopath/pkg/*, i messed it up last time i tried to setup multiple go versions + gopaths so i can switch between them easily, i'll be more careful this time
[07:45] <rogpeppe> dimitern: i have an entirely separate tree for working with separate go versions
[07:46] <rogpeppe> dimitern: (which is actually very useful because i can be testing against one branch while developing another)
[07:46] <dimitern> rogpeppe: well, I tried having ~/go/<ver> for goroot, and ~/work/go/<ver> for gopath, but then it didn't work with emacs somehow after the raring upgrade
[07:47] <dimitern> rogpeppe: (come to think about it, it still doesn't work - i need to run emacs from a terminal rather than from the launcher, otherwise the gopath/root i set in .bashrc are not visible
[07:47] <rogpeppe> dimitern: that's not surprising. emacs won't run .bashrc
[07:48] <rogpeppe> dimitern: did you try putting the settings in your .profile ?
[07:48] <dimitern> rogpeppe: but it worked in quantal! now it cannot find gofmt etc. unless run from the shell
[07:48] <dimitern> rogpeppe: i tried .profile, .Xsessionrc, /etc/profile, everything.. no joy
[07:49] <rogpeppe> dimitern: try removing it from your .bashrc, adding it to your .profile, logging out and logging in again
[07:50] <rogpeppe> dimitern: .bash_profile might work too
[07:50] <dimitern> rogpeppe: tried that as well, just emacs somehow defies all known ways it should cooperate with my environment :)
[07:50] <rogpeppe> dimitern: i'd be surprised. this is an environment-variable/shell issue, not emacs, i think
[07:51] <dimitern> rogpeppe: well, that very well maybe, but haven't seen a problem with another app so far
[07:51] <rogpeppe> dimitern: that's probably because no other app needs $GOPATH and $GOROOT
[07:52] <rogpeppe> dimitern: or relies on any setting in your .bashrc, i suspect
[07:52] <dimitern> rogpeppe: btw - if i just rm -fr $GOPATH/pkg/ and then run should work, or I should leave pkg empty?
[07:52] <rogpeppe> dimitern: that should work fine.
[07:52] <rogpeppe> dimitern: directories are created on demand
[07:55] <dimitern> rogpeppe: hmm apparently goyaml-go uses go1.1 features (function ends without a return statement)
[07:55] <dimitern> rogpeppe: switching to goyaml-c
[07:55] <rogpeppe> dimitern: ha
[07:59] <dimitern> wallyworld_: ping
[07:59] <wallyworld_> hi
[08:00] <dimitern> wallyworld_: hey, looking at create-machine
[08:00] <wallyworld_> thanjs
[08:00] <dimitern> wallyworld_: why do we need this at all? why not have an argument to deploy instead? don't we want it to be atomic?
[08:00] <wallyworld_> it's part of the containerisation work
[08:01] <wallyworld_> maybe read tim's email
[08:01] <dimitern> wallyworld_: i know; i read it
[08:01] <dimitern> wallyworld_: but still now convinced it's a good idea to have a separate command
[08:01] <wallyworld_> the next step is to allow containers to be created inside a machine
[08:02] <dimitern> wallyworld_: i see that, ok, but still - using 2 steps to deploy inside a container seems wrong
[08:04] <wallyworld_> ultimately the common operation ie deploy will be atomic. this is a step along the way
[08:04] <dimitern> rogpeppe: with go 1.0.3 i see no panics so far, but still some tests failures with the watchers (again, not on every run)
[08:04] <wallyworld_> just constructing the jigsaw peices
[08:04] <dimitern> wallyworld_: so you're saying create-machine isn't there to stay?
[08:04] <wallyworld_> not sure yet
[08:05] <wallyworld_> all up for prototyping and discussion
[08:05] <wallyworld_> will aid in testing during the development etc
[08:05] <wallyworld_> plus it ma turn out to be useful longer term, not sure yet
[08:06] <dimitern> wallyworld_: yeah, that's just the thing - adding stuff we're not sure we need right now will surely bend the direction in the future to finding ways to use them
[08:07] <dimitern> wallyworld_: anyway, just thinking out loud - will take my concerns to tim's email :)
[08:08] <wallyworld_> fair questions. i started this work before the email. it's all very much in a state of flux
[08:08] <wallyworld_> but as a developer, the ability of create machines/containers will be very usrful
[08:08] <dimitern> wallyworld_: sure when starting on a big new feature there's always uncertainty where to begin
[08:09] <wallyworld_> eg may want to spin up a few containers ahead of time
[08:09] <dimitern> wallyworld_: i agree, but i doubt a command is the necessary for that
[08:09] <wallyworld_> and then scale out later
[08:09] <wallyworld_> how else would it be done if there were no command to so it
[08:10] <dimitern> wallyworld_: you see "juju's way" of doing things afaiui is telling it what you need and letting it do it for you
[08:10] <dimitern> wallyworld_: what mark (sabdfl) said scaling out a service + containers could be automated
[08:11] <wallyworld_> sure. but having some manual control would be nice too
[08:11] <dimitern> wallyworld_: having a service deployed on 1 machine + some containers and this is 1 unit, adding a unit could replicate that and the containers
[08:12] <dimitern> wallyworld_: could be, not sure yet, i think it's worth some careful consideration
[08:12] <wallyworld_> think of it like being able to add an existing running machine/vm to the env
[08:13] <wallyworld_> it's just another tool in the kit
[08:13] <dimitern> wallyworld_: you could do that with manual provisioning (eventually), but this is just a special case - why complicate things adding more special cases like that?
[08:14] <rogpeppe> dimitern: https://code.google.com/p/go/issues/detail?id=5554
[08:16] <wallyworld_> dimitern: for me it's a useful tool. ymmv. the command bit is a small portion of the logic. i like having manual control
[08:17] <dimitern> rogpeppe: cool! thanks for filing a bug
[08:18] <rogpeppe> dimitern: i'm currently testing against tip. it's possible the problem is already fixed.
[08:18] <dimitern> rogpeppe: so with go 1.0.3 more often than not tests pass (1 in 5 failure so far)
[08:19] <rogpeppe> dimitern: i'm sure there's a problem you need to fix too :-)
[08:19] <rogpeppe> dimitern: i'm not looking into it any further for the moment, because there's lots of stuff i want to get proposed today before i go away next week
[08:19] <dimitern> rogpeppe: it'll be helpful if i manage somehow to reproduce it consistently
[08:19] <dimitern> rogpeppe: sure
[08:20] <dimitern> rogpeppe: but I want to propose a split of apiserver.go into multiple submodules
[08:20] <rogpeppe> dimitern: different packages?
[08:21] <rogpeppe> dimitern: if you're just talking about splitting the file, +1
[08:21] <dimitern> rogpeppe: the same package state/apiserver/ but having things like root.go, client.go, machine.go, etc.
[08:21] <dimitern> rogpeppe: ok, i'll do it after i finish this
[08:21] <rogpeppe> dimitern: i'd name all the ones implementing the actual api to start with "api"
[08:22] <rogpeppe> dimitern: e.g. apiroot.go, apiclient.go, apimachine.go
[08:22] <rogpeppe> dimitern: so it's easy to see which files implement the core logic
[08:22] <dimitern> rogpeppe: also i'd like to split api_test.go into perm_test.go, machine_test.go, client_test.go, etc.
[08:23] <rogpeppe> dimitern: seems reasonable
[08:23] <dimitern> rogpeppe: i'm fine with api*.go
[08:23] <dimitern> rogpeppe: cool
[08:23] <rogpeppe> dimitern: if you do it, make it a branch which is entirely mechanical - no code changes at all, please.
[08:24] <rogpeppe> dimitern: i'm not seeing any panics against tip, BTW
[08:24] <dimitern> rogpeppe: sure, but after i'm done with this; don't want to make it harder for me to merge later
[08:24] <rogpeppe> dimitern: yeah
[08:25] <dimitern> rogpeppe: will it impede the run time too much if we split agent and client perm tests into 2 files and 2 tables?
[08:26] <rogpeppe> dimitern: i'm not sure i see the point
[08:27] <rogpeppe> dimitern: the point of those tests is to test permissions against the entire API surface area
[08:28] <rogpeppe> dimitern: you could split the table, i suppose
[08:28] <dimitern> rogpeppe: hmm, ok - but only perm checks should be in there; error conversion tests, bad logins, etc should be separate
[08:28] <rogpeppe> dimitern: agreed
[08:28] <rogpeppe> dimitern: i have some vaguely formed thoughts about how we can make the perm checks much smaller and faster
[08:30] <dimitern> rogpeppe: oh?
[08:30] <dimitern> rogpeppe: (while i'm at splitting stuff i might as well split apiclient to multiple files as well)
[08:32] <rogpeppe> dimitern: that's a fair bit smaller - i wonder if it might be better just as two files - one for the client api and one for the agent api
[08:32] <rogpeppe> dimitern: or actually
[08:32] <rogpeppe> dimitern: it's perhaps good to have a 1-1 file mapping between apiserver and api
[08:32] <dimitern> rogpeppe: exactly my point
[08:32] <rogpeppe> dimitern: for the pieces implementing the api
[08:32] <dimitern> rogpeppe: good, will do then
[08:35] <rogpeppe> dimitern: i've run the apiserver tests 17 times so far against tip and no panic
[08:36] <dimitern> rogpeppe: good! so it seems fixed
[08:36] <rogpeppe> dimitern: or the bug just isn't being tickled any more
[08:37] <dimitern> rogpeppe: well, it might also mean someone will recognize it and say it's fixed
[08:38] <rogpeppe> dimitern: yeah. i'm hoping someone will say "ah, we fixed it then", and then they'll issue a new point release
[08:38] <rogpeppe> wallyworld_: ping
[08:39] <wallyworld_> rogpeppe: hi, i'm just about to leave for soccer
[08:39] <rogpeppe> wallyworld_: v quick question
[08:39] <wallyworld_> ok
[08:39] <rogpeppe> wallyworld_: in environs/cloudinit, you did syslogConfigRenderer, right?
[08:39] <wallyworld_> i think so, let me check
[08:40] <rogpeppe> wallyworld_: is there a particular reason why the config is rendered after bootstrap-state is called?
[08:40] <rogpeppe> wallyworld_: because i'm thinking about moving it earlier in the script
[08:41] <wallyworld_> rogpeppe: i think it will be ok to move. i think it was put where it is because that's where some previous logging stuff was initialised
[08:41] <wallyworld_> but i'm not entirely sure
[08:41] <rogpeppe> wallyworld_: ok, cool
[08:41] <wallyworld_> all it does anyway is write a conf file
[08:41] <wallyworld_> so that can go anywhere really
[08:42] <rogpeppe> wallyworld_: that's what i thought; just wanted to check there wasn't anything subtle going on.
[08:42] <rogpeppe> wallyworld_: thanks
[08:42] <wallyworld_> np.
[09:12] <dimitern> rogpeppe:
[09:12] <rogpeppe> dimitern:
[09:12] <dimitern> rogpeppe: oops, I have a question :)
[09:13] <rogpeppe> dimitern: go on
[09:13] <dimitern> rogpeppe: in this log: http://paste.ubuntu.com/5696381/
[09:14] <dimitern> rogpeppe: is it normal to have an Error response to the Stop request?
[09:15] <rogpeppe> dimitern: i don't see that you are
[09:15] <rogpeppe> dimitern: which line are you thinking is an error response to the stop request?
[09:16] <rogpeppe> dimitern: i am seeing that i need to sort out the rpc logging - it's logging each message twice
[09:16] <dimitern> rogpeppe: ah, right - [LOG] 94.86663 DEBUG rpc/jsoncodec: -> {"RequestId":4,"Error":"watcher has been stopped","ErrorCode":"stopped","Response":{}}
[09:16] <dimitern> this is the Next response
[09:16] <rogpeppe> dimitern: (i know why)
[09:17] <rogpeppe> dimitern: that's a response to a Next
[09:17] <rogpeppe> dimitern: note the RequestId
[09:17] <dimitern> rogpeppe: yeah
[09:18] <dimitern> rogpeppe: i think we have a problem with the current watcher implementation in the client, but only the environ config one fails because it needs to do extra work on marshaling/unmarshaling the AllAttrs when receiving a response
[09:18] <dimitern> rogpeppe: it seems next should quit as soon as stop was called
[09:18] <dimitern> rogpeppe: (the next goroutine in the client, that is)
[09:18] <rogpeppe> dimitern: on the server side?
[09:19] <rogpeppe> dimitern: why's that?
[09:19] <dimitern> rogpeppe: because otherwise we have this issue
[09:19] <dimitern> rogpeppe: and arguably it's an error to try reading a stopped watcher anyway
[09:19] <rogpeppe> dimitern: perhaps you could try describing the issue and why it's happening
[09:20] <dimitern> rogpeppe: well, i *think* as soon as stop is called the next goroutine does not exit immediately and tries to read, getting the error, and then exits, but the error is dispatcher to the client outside
[09:21] <dimitern> rogpeppe: but really it shouldn't report that error if it knows for sure the server-side watcher was stopped
[09:22] <rogpeppe> dimitern: isn't that what the ErrStillAlive check is about?
[09:23] <dimitern> rogpeppe: if it worked i shouldn't have received anything on the in channel, right?
[09:23] <dimitern> rogpeppe: when next encounters a stopped state
[09:23] <rogpeppe> dimitern: ha, yes
[09:24] <rogpeppe> dimitern: it should return after the Kill
[09:24] <dimitern> rogpeppe: ah, I think I see the error - after w.tomb.Kill(err) i should return rather than trying the select
[09:24] <dimitern> :)
[09:24] <dimitern> yeah
[09:26] <dimitern> rogpeppe: that fixed it
[09:26] <rogpeppe> dimitern: cool
[09:28] <dimitern> rogpeppe: only one things bothers me - i think it's maybe worth panicking when i cannot unmarshal the environ config i got on the in channel, rather than logging an error
[09:28] <rogpeppe> dimitern: i think the watcher should die if that happens
[09:29] <dimitern> rogpeppe: it does, but if we got that far something is very wrong, hence a panic is in order i think
[09:29] <rogpeppe> dimitern: can't that happen if the server sends some dubious data back?
[09:30] <dimitern> rogpeppe: and where did it get it from? state - so it think it's still worth panicking
[09:30] <rogpeppe> dimitern: definitely not
[09:30] <dimitern> rogpeppe: explain?
[09:30] <rogpeppe> dimitern: in general we don't panic when an external data source produces something unexpected
[09:30] <dimitern> rogpeppe: hmm
[09:30] <rogpeppe> dimitern: it might be talking to a version of the API with a subtly different interface
[09:31] <dimitern> rogpeppe: ok then, i'll leave just the error log
[09:31] <dimitern> rogpeppe: fair point
[09:31] <rogpeppe> dimitern: you don't need to log the error - you can kill the watcher with an appropriate error
[09:31] <rogpeppe> dimitern: then it will be picked up as usual by the rest of the logic
[09:31] <rogpeppe> dimitern: causing the agent to die, or whatever
[09:31] <dimitern> rogpeppe: i'm killing it, and logging the error
[09:32] <rogpeppe> dimitern: i'm not sure that the log is necessary, but i guess
[09:32] <dimitern> rogpeppe: it won't hurt when debugging incompatible api server/client connections, i think
[09:33] <dimitern> rogpeppe: btw you copied my branch when you filed the golang issue, right?
[09:36] <rogpeppe> dimitern: yes
[09:36] <dimitern> rogpeppe: cool, i'm proposing it soon
[09:46] <dimitern> rogpeppe: so with the newly gained understanding of the api internals hopefully, i'll be able to help the other guys next week while you're gone
[09:46] <rogpeppe> dimitern: that would be great, thanks
[09:47] <rogpeppe> dimitern: another small CL: https://codereview.appspot.com/9710044
[09:47]  * dimitern looking
[09:50] <dimitern> rogpeppe: what's "bootstrap-state" ?
[09:50] <rogpeppe> dimitern: jujud bootstrap-state
[09:50] <rogpeppe> dimitern: the thing that initialises the mongo state
[09:50] <rogpeppe> dimitern: and sets the initial password for the machine agent
[09:50] <dimitern> rogpeppe: i see (never heard of it before)
[09:52] <dimitern> rogpeppe: LGTM
[09:59] <dimitern> rogpeppe: do you think you'd manage adding the agent API connection stuff today?
[09:59] <rogpeppe> dimitern: that's the aim
[10:00] <rogpeppe> dimitern: i have a branch that does it
[10:00] <rogpeppe> dimitern: but there are one or two branches that need to go in first
[10:00] <dimitern> rogpeppe: that will be awesome
[10:00] <rogpeppe> dimitern: well, let's sat i have a branch that does it *in theory* :-)
[10:01] <dimitern> rogpeppe: i was thinking once i started the api stuff i might as well do most (if not all of it), so others can concentrate on replacing state calls with api calls next week, once we have the connection
[10:01] <rogpeppe> dimitern: that sounds like a good plan
[10:01] <rogpeppe> dimitern: BTW the API connection stuff involved refactoring the machine agent, and it's turned out really quite nice
[10:02] <dimitern> rogpeppe: good to hear
[10:05] <rogpeppe> dimitern: did you look at the Runner CL?
[10:06] <rogpeppe> dimitern: i don't think you reviewed it, which was a bit surprising :-)
[10:17] <dimitern> rogpeppe: this one? https://codereview.appspot.com/9643043/
[10:18] <rogpeppe> dimitern: yeah
[10:18] <dimitern> rogpeppe: I looked at it briefly, but by the time I got the time to review it it already landed :)
[10:18] <dimitern> rogpeppe: https://codereview.appspot.com/9721043/ is ready
[10:19] <dimitern> rogpeppe: will look at yours once more more carefully
[10:19] <rogpeppe> dimitern: np. more eyes always appreciated - it's a moderately complex piece of code.
[10:20] <rogpeppe> dimitern: i'm slightly surprised you've done all those api calls in one CL. i thought they might work well as many separate ones.
[10:20] <rogpeppe> dimitern: it's not a particular problem, but i might not get it reviewed today
[10:21] <dimitern> rogpeppe: they're closely related - all needed by the provisioner and really most are trivial
[10:21] <dimitern> rogpeppe: np, go as far as you can
[10:22] <rogpeppe> dimitern: i guess i just prefer separable changes to be separate :-)
[10:22] <dimitern> rogpeppe: i guess watchers and machine calls can be separated
[10:22] <rogpeppe> dimitern: that might be good, if you don't mind too much.
[10:23] <dimitern> rogpeppe: uhh.. you're right actually - just now glanced at the diff - it's in excess of 1000 lines
[10:23] <rogpeppe> dimitern: yeah, it's pretty big
[10:24] <dimitern> rogpeppe: didn't look like that when i was doing it :) anyway - will try bzr pipes to see if i can split it easily
[10:24] <rogpeppe> dimitern: you might not need pipes too much
[10:24] <rogpeppe> dimitern: most of the changes are orthogonal
[10:25] <rogpeppe> dimitern: if you do the commonWatcher thing first (making the EntityWatcher use it only) then all the rest are likely to be independent
[10:26] <dimitern> rogpeppe: good point, will do
[10:27] <dimitern> rogpeppe: ok, disregard that CL then, I'll propose it after splitting
[10:28] <rogpeppe> dimitern: thanks
[10:34]  * dimitern hates bzr diff!!!!
[10:35] <mgz> ?
[10:35] <mgz> you know it takes arguments, right?
[10:35] <dimitern> mgz: so i've been in this situation before
[10:35] <dimitern> mgz: i have trunk and a branch off it
[10:36] <dimitern> mgz: i need to see changes in a particular path between the two branches
[10:36] <dimitern> mgz: but none of the suggested args help
[10:36] <dimitern> mgz: tried --old trunk while on the new branch; tried -r-2, but i need a path as well, not the changes in the whole tree
[10:37] <dimitern> mgz: tried --old trunk --new feature-branch - still frustratingly no results!
[10:38] <dimitern> mgz: please help :)
[10:39] <dimitern> mgz: (if it makes a difference - both branches are clean - no uncommitted changes)
[10:39] <mgz> hm, I'd expect --old to work
[10:40] <mgz> have you got qbzr intalled?
[10:40] <dimitern> mgz: well it doesn't; yes I have qbzr
[10:41] <dimitern> mgz: with qdiff is still the same (No changes)
[10:41] <dimitern> mgz: all i need here is diff trunk:tip and feature:tip and show me the changes in state/api/ only
[10:42] <mgz> so, it works for me with standalone branches
[10:42] <dimitern> mgz: so i can cherry pick some of them and split the feature into multiple smaller ones
[10:42] <mgz> but something seems to be unhappy with native colo
[10:43] <mgz> but, I'd expect if you cd ~ then do `bzr diff --old .../src/real/branch/location/trunk --new .../src/.../feature state/api` it'll work
[10:43] <dimitern> mgz: here's what bzr reports: http://paste.ubuntu.com/5696558/
[10:43] <dimitern> mgz: ah, i'll try that
[10:44] <mgz> right, so try --old ~/src/juju-core/trunk --new ~//src/juju-core/041-provisioner-api-calls
[10:45] <mgz> there might be an issue with checkouts, I'll see if we have a bug filed
[10:45] <dimitern> mgz: hallelujah! it works like that
[10:46] <dimitern> mgz: although i'd expect it to work in a LW checkout as well..
[10:47] <mgz> looks like bug 596785 plus bad location resolution code in the diff command
[10:47] <_mup_> Bug #596785: 'bzr diff --old|new PATH' does silently exists if arg does not exist <diff> <patch-needswork> <Bazaar:Confirmed> <https://launchpad.net/bugs/596785>
[10:48] <mgz> can you file a new bug with your symptoms please dimitern?
[10:48] <dimitern> mgz: a new one or amend this
[10:48] <mgz> a new one
[10:48] <dimitern> mgz: sure
[10:49] <mgz> the location code being wrong I don't see any entry for, can do both issues in one merge possibly, but might make sense to do them seperately
[10:51] <dimitern> mgz: bzr diff --old/--new does not report and changes with a lightweight checkout of a native repo?
[10:51] <dimitern> mgz: as summary
[10:51] <mgz> s/and/any/ and seems reasonable
[10:52] <mgz> and just end after "checkout"
[10:52] <dimitern> mgz: not sure i get you - where's the "and" ?
[10:52] <dimitern> mgz: ah
[10:53] <mgz> :)
[11:01] <dimitern> mgz: bug 1183776
[11:01] <_mup_> Bug #1183776: bzr diff --old/--new does not report and changes with a lightweight checkout of a native repo <amd64> <apport-bug> <bzr> <diff> <raring> <bzr (Ubuntu):New> <https://launchpad.net/bugs/1183776>
[11:01] <mgz> thanks!
[11:04] <dimitern> mgz: any idea how to make my life easier and cherry pick interactively what to merge? rather than having to manually edit the diff and run patch with it
[11:09] <danilos> dimitern, mgz: I need to step out to sign some documentation in the court, likely to not make it for the stand-up
[11:09] <dimitern> danilos: ok
[11:19] <rogpeppe> dimitern, TheMue: another small CL: https://codereview.appspot.com/9723043
[11:20] <mgz> dimitern: use shelve
[11:21] <dimitern> rogpeppe: LGTM
[11:21] <rogpeppe> dimitern: ta!
[11:21] <dimitern> mgz: i'll try
[11:22] <dimitern> mgz: how will shelve help with committed trees?
[11:22] <mgz> cherrypick the feature branch across to your new integration branch
[11:23] <mgz> then set EDITOR and use shelve interactive to edit out the bits you don't want
[11:24] <dimitern> mgz: it seems way too complicated.. i'll just branch the old feature and vistually merge into the new one with directory comparison
[11:24] <mgz> it's two commands...
[11:25] <mgz> but depending on how hard the changes are to unpick, interactive mode may be useful or not
[11:26] <mgz> oh, and I'm not actually sure what `bzr merge -i` does
[11:26] <mgz> what you want, it seems
[11:27] <mgz> so, you have feature, which you want to split out
[11:27] <mgz> dimitern: so, in your checkout, on trunk, `bzr switch -b prefeature` then `bzr merge -i .../feature`
[11:29] <dimitern> mgz: i'll try next time, thanks; spent too much time already fiddling around with tools, so i'm back to good old manual methods + meld for visual merging
[11:29] <TheMue> rogpeppe: done
[11:34] <dimitern> mgz, wallyworld_: are we doing the standup?
[11:34] <mgz> lets
[11:34] <mgz> can just say hi at least :)
[11:48] <dimitern> rogpeppe, mgz: https://codereview.appspot.com/9667048 first part
[11:48] <rogpeppe> dimitern: that's more like it :-) :-)
[11:52] <dimitern> TheMue: ^^ reviews appreciated
[11:52] <dimitern> there are 3 more CLs coming in this pipeline
[11:58] <TheMue> dimitern: done
[11:58] <dimitern> TheMue: cheers
[11:59] <dimitern> TheMue: actually making them arguments to init() will make the code less readable
[12:00] <dimitern> TheMue: and I don't see an advantage in doing that
[12:00] <dimitern> TheMue: could you explain your reasoning?
[12:04] <TheMue> dimitern: having them as arguments would let you check if they are set. that's the only reason.
[12:04] <dimitern> TheMue: it won't compile anyway if they're not set
[12:07] <dimitern> TheMue: i'll add a check in init() to ensure they are set, but not as arguments
[12:07] <TheMue> dimitern: it won't compile?
[12:09] <dimitern> TheMue: no, you're right - it will compile, but panic at runtime
[12:09] <dimitern> TheMue: i'll add a check, thanks
[12:09] <TheMue> dimitern: you set them after init(), so a check there would fail.
[12:12] <dimitern> TheMue: i moved init after setting the,
[12:13] <TheMue> dimitern: so please also comment that those values have to be set before calling init().
[12:13] <dimitern> TheMue: sure
[12:14] <TheMue> dimitern: great, thx
[12:19] <dimitern> thanks guys, submitting with the changes
[12:51] <dimitern> rogpeppe, mgz, TheMue: next in line: https://codereview.appspot.com/9714044
[13:12] <dimitern> danilos: you as well? ^^
[13:35] <rogpeppe> dimitern: you have a review
[13:35] <dimitern> rogpeppe: tyvm
[13:35] <rogpeppe> dimitern: much better split into bits like this!
[13:36] <dimitern> TheMue: calling init() in commonLoop() is not quite the same, because it's needs to be called before the go routine spins up
[13:38] <TheMue> dimitern: due to the created channel?
[13:39] <dimitern> TheMue: yeah, that as well
[13:41] <TheMue> dimitern: ok, could lead to a race otherwise. what else?
[13:42] <dimitern> TheMue: actually I think this is it - couldn't find other reason
[13:46] <TheMue> dimitern: ok, fine
[14:00] <dimitern> thanks for the reviews, submitting soon; 2 more to go
[14:05] <dimitern> rogpeppe: kanban
[14:51] <dimitern> rogpeppe, TheMue: last one about the provisioner: https://codereview.appspot.com/9708044/
[14:54] <TheMue> *click*
[15:05] <TheMue> dimitern: done
[15:05] <dimitern> TheMue: thanks!
[15:18] <rogpeppe> dimitern: reviewed
[15:18] <dimitern> rogpeppe: cheers
[15:19] <dimitern> rogpeppe: we you're saying the agent shouldn't use SetMongoPassword at all, and use SetPassword instead?
[15:20] <rogpeppe>  dimitern: yes
[15:20] <dimitern> rogpeppe: ok, even better
[15:20] <rogpeppe> dimitern: the API server knows when SetMongoPassword is appropriate, and does it
[15:21] <dimitern> rogpeppe: it's getting smarter then :)
[15:21] <rogpeppe> dimitern: that's kinda the idea of the API :-)
[15:22] <dimitern> rogpeppe: indeed
[15:37] <dimitern> rogpeppe: does the same apply for unit.SetMongoPassword?
[15:37] <rogpeppe> dimitern: yes. hmm, that's an interesting point actually
[15:37] <rogpeppe> dimitern: currently SetPassword should be doing SetMongoPassword for all agents
[15:38] <dimitern> rogpeppe: so for unit.SetMP i'll use the same logic  as for a machine
[15:39] <rogpeppe> dimitern: yeah - i.e. it should always be set.
[15:39] <rogpeppe> dimitern: presumably you've merge trunk?
[15:39] <mramm> anybody know how sync-tools works
[15:39] <dimitern> rogpeppe: ok
[15:39] <rogpeppe> merged?
[15:39] <dimitern> yeah
[15:39] <rogpeppe> mramm: i've never used it
[15:39] <dimitern> rogpeppe: it's used to sync ec2 public tools to your private bucket
[15:39] <mramm> and have a minute to walk danwest through getting tools into MAAS?
[15:40] <rogpeppe> dimitern: yeah i know roughly what it does
[15:41] <rogpeppe> dimitern: but i've never actually *used* it
[15:41] <dimitern> rogpeppe: ops, sorry - that was for mramm actually
[15:41] <dimitern> rogpeppe: got too used to addressing you lately :)
[15:41] <rogpeppe> dimitern: np - i do that too sometimes
[15:43] <mramm> can you use sync-tools as an argument to bootstrap
[15:44] <mramm> and IIRC you need to put your EC2 credentials somewhere to make it work
[15:44] <mramm> is this documented anywhere that we can just point danwest too?
[15:44] <dimitern> mramm: no
[15:44] <mramm> :(
[15:44] <dimitern> ramit's a separate command
[15:44] <mramm> ok
[15:45] <dimitern> mramm: there was a mail from jam about how it works
[15:45] <mramm> so bootstrap and then sync tools?
[15:45] <mramm> ok, will search for that
[15:46] <dimitern> rogpeppe: do you think unit tests for agents/workers in general should also only use the api?
[15:46] <rogpeppe> dimitern: that's an interesting question.
[15:46] <rogpeppe> dimitern: i'm not entirely sure it's possible
[15:47] <rogpeppe> dimitern: you'd need to juggle at least two API connections and send the right commands to the right one
[15:47] <dimitern> rogpeppe: yeah
[15:47] <dimitern> rogpeppe: and if we leave them using state directly how bad will it be?
[15:47] <rogpeppe> dimitern: i'm not sure that's bad at all
[15:47] <rogpeppe> dimitern: the actual code being tested will need to use the API
[15:48] <rogpeppe> dimitern: it's just the setup code which will talk directly to mongo (and probably some verification code too)
[15:48] <dimitern> rogpeppe: yeah, exactly, the tests can still access it directly
[15:48] <rogpeppe> dimitern: yup
[15:48] <dimitern> rogpeppe: and btw this will save a *huge* amount of work
[15:48] <rogpeppe> dimitern: yeah
[15:54] <rogpeppe> i hadn't seen this error before: cannot make S3 control bucket: A conflicting conditional operation is currently in progress against this resource. Please try again.
[15:54] <dimitern> rogpeppe: it seems like an ec2 error
[15:55] <rogpeppe> dimitern: yeah it is. just another one i hadn't seen before
[15:55] <rogpeppe> dimitern: to join the collection of sporadic live test failures.
[15:55] <rogpeppe> dimitern: getting live tests to pass reliably is gonna be really hard
[15:55] <dimitern> rogpeppe: yup, unfortunately
[15:56] <danwest> dimitern: mramm pointed me your way for juju-core/MAAS bootstrap issues
[15:58] <dimitern> danwest: hm, ok - what do you need?
[15:59] <danwest> dimitern: new raring install with apt-get juju-core
[16:00] <danwest> trying to bootstrap against MAAS provider and get the following:
[16:00] <danwest> ~$ juju -v bootstrap
[16:00] <danwest> 2013/05/24 11:27:45 INFO environs: reading tools with major version 1
[16:00] <danwest> 2013/05/24 11:27:45 INFO environs: falling back to public bucket
[16:00] <danwest> 2013/05/24 11:27:45 ERROR command failed: no tools available
[16:00] <danwest> error: no tools available
[16:01] <dimitern> danwest: can you try juju-core from source and see if it helps?
[16:02] <mramm> I expect that nobody has tested the sync tools path with MAAS
[16:02] <mramm> it landed at the very last second for the raring cycle
[16:02] <mramm> I know I have not tested it myself :/
[16:02] <dimitern> mramm: me too, and maas landed at the last moment as well, so it might not work from the released version
[16:03] <danwest> dimitern: mramm: I can try from source but that might take me a couple to get setup
[16:03] <mramm> dimitern: dan is working on the "cloud installer" and any help we can give him would be good
[16:03] <danwest> thanks mramm
[16:03] <mramm> dimitern: we want to keep him unblocked ;)
[16:04] <dimitern> mramm: sure, i'll help if i can, but have never tried the maas provider
[16:04] <mramm> yea, but william is out
[16:05] <dimitern> danwest: we fixed a bunch of issues with tools and bootstrapping after the raring release, hence my suggestion to run from source
[16:05] <danwest> dimitern: k
[16:05] <mramm> danwest: once you have a working source install
[16:05] <mramm> the upload tools thing you were pointed at a while ago will probably work
[16:07] <danwest> dimitern: mramm: grabbing source now
[16:07] <mramm> danwest: sorry this is not a better path yet
[16:07] <mramm> I have to run out and get some food, back in a few
[16:08] <danwest> same here - just grabbing source first
[16:08] <mramm> william will also be back on monday, and I know he has tested this
[16:09] <danwest> k
[16:37] <Makyo> I'm seeing http://pastebin.ubuntu.com/5697229/ in trunk, running in a precise lxc.  Is this a known thing?
[16:37] <dimitern> Makyo: don't tell me you never updated from lucid? :)
[16:38] <Makyo> dimitern, Haha, nah, running raring, but tests were failing there, thus the precise lxc dev setup
[16:38] <dimitern> Makyo: well, lucid is definitely not among the expected series iirc
[16:39] <dimitern> Makyo: can you reproduce it consistently?
[16:39] <Makyo> dimitern, Every time.
[16:39] <Makyo> Let me run with -gocheck.v
[16:40] <Makyo> No more info.
[16:41] <dimitern> Makyo: running with -gocheck.v in environs/imagemetadata/
[16:43] <Makyo> dimitern, Yeah, no extra info on the failure, others pass.
[16:43] <Makyo> dimitern, lucid is specified in the test, environs/imagemetadata/simplestreams_test.go:463
[16:44] <dimitern> Makyo: file a bug; maybe they decided to drop lucid from the cloud archive just today
[16:44] <Makyo> dimitern, got it.  Thanks.
[16:44] <dimitern> Makyo: thanks
[16:45] <dimitern> rogpeppe: ping
[16:45] <rogpeppe> dimitern: pong
[16:45] <dimitern> rogpeppe: actually why do you insist on having api prefix to filenames when split?
[16:46] <rogpeppe> dimitern: because i like having error.go and server.go stand out as files related to core api server functionality, not the actual API methods
[16:47] <dimitern> rogpeppe: hmm
[16:47] <dimitern> rogpeppe: well, ok
[16:48] <dimitern> rogpeppe: so apiserver.go will be gone, to be replaced by apiroot.go, apistate, apiclient, apimachine, etc, right?
[16:48] <rogpeppe> dimitern: there is actually a possibility that the api* files could be moved into their own package actually (in the api server anyway)
[16:48] <rogpeppe> dimitern: yeah
[16:48] <dimitern> rogpeppe: that sounds better - so apiserver/api/*
[16:49] <rogpeppe> dimitern: yeah, but it's only a possibility - i'd prefer not to do it for now
[16:50] <dimitern> rogpeppe: what are your concerns about it?
[16:50] <rogpeppe> dimitern: it feels unnecessary
[16:51] <dimitern> rogpeppe: why not rename server to apiserver, errors to apierrors and leave the rest uprefixed?
[16:51] <dimitern> rogpeppe: they's stand out even more
[16:51] <rogpeppe> dimitern: that's not a bad idea
[16:52] <dimitern> rogpeppe: cool, i'll make it so then
[16:52] <rogpeppe> dimitern: sgtm
[16:52] <dimitern> rogpeppe: and the same for the client?
[16:52] <rogpeppe> dimitern: yeah
[16:52] <dimitern> rogpeppe: nice
[17:50] <danwest> dimitern: any tricks to building juju-core from source?
[17:51] <dimitern> danwest: so if you do go get -v -u launchpad.net/juju-core/... (note the ...)
[17:51] <dimitern> danwest: once done, you'll just need to do go install launchpad.net/juju-core/cmd/juju
[17:52] <danwest> k
[17:52] <dimitern> danwest: and then use juju <command> as usual
[18:16] <dimitern> rogpeppe: still there?
[18:17] <rogpeppe> dimitern: aye
[18:18] <dimitern> rogpeppe: i'm done with the splitting, proposing in 5m, and i'd like if you take a look
[18:18] <rogpeppe> dimitern: ok. i'm gonna be gone quite soon though, and i'm really trying to get this branch proposed
[18:21] <dimitern> rogpeppe: if you can; it's mechanical, but mostly if it seems ok as an arrangement https://codereview.appspot.com/9746043
[18:23] <rogpeppe> dimitern: well remembered about the copyright notices :-)
[18:23] <dimitern> rogpeppe: oh yeah :)
[18:24] <rogpeppe> dimitern: i get "upload in progress" at https://codereview.appspot.com/9746043/diff/1/state/apiserver/apiserver.go?column_width=90
[18:24] <rogpeppe> dimitern: i think that's because codereview is confused though.
[18:25] <dimitern> rogpeppe: hmm.. well it's just what server.go used to be
[18:25] <dimitern> rogpeppe: probably the rename + modify somehow confuses rietveld
[18:25] <rogpeppe> dimitern: utils.go rather than helpers.go ?
[18:26] <dimitern> rogpeppe: np
[18:26] <rogpeppe> dimitern: i'm wondering if each test file should have its own suite
[18:27] <dimitern> rogpeppe: we can do that, but let it be a follow up
[18:27] <rogpeppe> dimitern: but i don't mind that much
[18:27] <rogpeppe> dimitern: yeah, definitely
[18:27] <dimitern> rogpeppe: i think it should be considered a trivial CL
[18:28] <dimitern> rogpeppe: and would really want to land it today, to save me some trouble tracking moving trunk
[18:29] <rogpeppe> dimitern: where have the auth* functions ended up?
[18:29] <dimitern> rogpeppe: in root.go
[18:30] <rogpeppe> dimitern: ah, that seems goo
[18:30] <rogpeppe> d
[18:30] <rogpeppe> dimitern: it all seems great actually
[18:30] <dimitern> rogpeppe: cool enough to land?
[18:31] <rogpeppe> dimitern: LGTM trivial
[18:31] <dimitern> rogpeppe: great, tyvm!
[18:31] <rogpeppe> dimitern: i think that's the largest "trivial" change ever :-)
[18:31] <dimitern> rogpeppe: yeah :)
[19:14] <rogpeppe> dimitern: in case you're still around, you might want to take a look at this: https://codereview.appspot.com/9738043
[19:16] <dimitern> rogpeppe: will do
[19:30] <dimitern> rogpeppe: LGTM
[19:30] <rogpeppe> dimitern: thanks. i won't submit until the next one's ready though
[19:30] <dimitern> rogpeppe: ok
[19:30] <dimitern> rogpeppe: btw "biggest diff ever": Diff against target:	7640 lines (+3825/-3612) 26 files modified
[19:32] <rogpeppe> dimitern: what's that in?
[19:32] <dimitern> rogpeppe: the one I just landed
[19:32] <rogpeppe> dimitern: :-)
[19:33] <rogpeppe> dimitern: not as big as the error one which may happen sometime, probably
[19:33] <dimitern> rogpeppe: in lp - doesn't show the full diff, just the first 5000 lines, but the summary at the top shows the info above
[19:33] <dimitern> rogpeppe: oh, yeah - we should do that
[19:34] <rogpeppe> dimitern: i didn't get it working yet - i was spending too much time on it, so put it on hold
[19:35] <dimitern> rogpeppe: yeah, it'll come to that
[19:35]  * dimitern is still not quite sure i didn't screw up trunk with that rename
[19:36] <dimitern> I pulled and run all tests pass
[19:36] <dimitern> now i'm doing the same in a fresh clone of trunk, just to be shure
[19:36] <dimitern> *sure
[19:44]  * dimitern is relieved.. all tests pass on trunk.. *whew*
[19:46] <dimitern> time to go
[19:46] <dimitern> rogpeppe: good night and have a nice holiday!