[01:38] <papertiger> When i use "kcmshell4 icons " it takes about 20-30 minutes to apply a change to icon theme =P
[01:39] <papertiger> got any idea how i fix this?
[01:48] <BluesKaj> howdy all
[01:57] <papertiger> hi BluesKaj
[01:57] <BluesKaj> hey papertiger
[01:58] <papertiger> i am trying to figure out why it "kcmshell4 icons" can not apply my icon theme..
[01:59] <papertiger> or any theme...
[04:55] <Doyle> Hey. 12.10 - Setting screensaver threshold has no effect. Always activates at the default 15m
[04:56] <Doyle> Changes are reflected in the conf.
[04:56] <Doyle> Ideas?
[04:58] <Doyle> Apparently it's only affecting the fishtank
[05:03] <heoyea> apply changes
[05:24] <Doyle> Nope. Affects all screensavers.
[05:24] <Doyle> I can set the threshold to 1m or anything under 15, but above that and it activates at 15
[06:22] <arbir> Hello
[06:23] <arbir> test
[06:25] <arbir> Hello
[06:26] <arbir> test
[06:27] <arbir> can anybody get the Dejavu font condensed working ?
[06:33] <papertiger> huh?
[06:34] <papertiger> By doing exactly what?
[06:35] <arbir> papertiger:  i am trying to use dejavu condensed and it keeps switching back to book
[06:58] <papertiger> rename book to a later alpabet letter... that should work.. it picks the one at the top if errors occurs for some reason... name it zook instead =P
[06:58] <papertiger> sorry i am tired, but it should work
[06:58] <papertiger> or you could just remove the fonts you do not use or want to use
[07:14] <papertiger> im trying out razorqt, but i have not figured out how to alter screensaver and screen dimming settings yet.
[07:19] <papertiger> hehe on a small storage system razorqt could really come in handy. But compared to the entire KDE Sc it falls a little short....
[07:19] <papertiger> hehe
[07:30] <heoyea> o
[10:14] <R33D3M33R> hello, so i wanted to try out the 13.04 alpha and it doesn't fit on a GB USB stick O_o ... ok, it's development release, but does this mean the final version will be the same?
[10:15] <nine_> no
[10:16] <nine_> not even close at this stage
[10:19] <R33D3M33R> ok
[10:48] <R33D3M33R> so I just logged out of the live mode, to relogin it asks me for a password. I tried "", ubuntu, kubuntu, password, but nothing works ... any ideas?
[10:49] <Peace-> R33D3M33R: mmm where did you download the image?
[10:49] <R33D3M33R> from the daily live page
[10:49] <R33D3M33R> http://cdimage.ubuntu.com/kubuntu/daily-live/current/
[10:49] <R33D3M33R> i386 version
[10:49] <R33D3M33R> i'm running in virtualbox
[10:50] <R33D3M33R> installation of programs worked without pass, but now it's asking for it
[10:50] <Peace-> R33D3M33R: this is strange no password should be required
[10:50] <Peace-> R33D3M33R:  try to ask here #kubuntu-devel
[10:51] <R33D3M33R> ok
[10:51] <Peace-> R33D3M33R: have you tried to leave password emty?
[10:51] <Peace-> empty
[10:51] <R33D3M33R> yes
[10:52] <R33D3M33R> i'll post a screenshot
[10:54] <R33D3M33R> any ideas where to i can save, imageshack suddenly wants me to register :(
[10:54] <Peace-> R33D3M33R: there is a widget called pastebin just drag and drop the file into
[10:55] <R33D3M33R> http://picpaste.com/posnetek1-7DQZOfFo.png
[10:55] <R33D3M33R> so i tried to enter blank password but it does nothing
[10:56] <R33D3M33R> also ubuntu, kubuntu, password and so on
[10:56] <Peace-> R33D3M33R: ask to riddel he should know on #kubuntu-devel
[10:56] <Peace-> i have to go (eat)
[10:56] <R33D3M33R> ok
[10:56] <R33D3M33R> bon apetite and thanks
[12:51] <BluesKaj> HI folks
[13:15] <monkeyjuice> morning BluesKaj
[13:15] <monkeyjuice> snow coming tonite
[13:15] <BluesKaj> "morning monkeyjuice
[13:16] <BluesKaj> we have a half inch or so
[13:17] <Peace-> BluesKaj: Here too
[13:18] <monkeyjuice> were are you Peace-
[13:18] <BluesKaj> Peace-, snow in Italy ...you must be near the mountains
[13:31] <Peace-> BluesKaj: nope verona
[13:34] <the_ant> just join this room. hai everyone.
[13:35] <_Adrod> hi guys
[13:36] <Peace-> hi
[13:36] <_Adrod> hi peace
[14:19] <carl3399> Hello
[14:19] <carl3399> hello
[14:22] <justben> hi
[14:22] <carl3399> hi
[14:22] <justben> where are you from?
[14:22] <carl3399> me?
[14:23] <justben> ofcourse
[14:23] <carl3399> Austria :D
[14:23] <justben> i come from china.
[14:23] <justben> haha, i am new here
[14:24] <carl3399> :)
[14:25] <justben> i am excited when i talk with foreigner
[14:25] <Tm_T> hi justben and carl3399, welcome to the support channel, we have a chit chat channel at #kubuntu-offtopic (:
[14:26] <justben> thanks, i have been there yesterday.
[14:27] <carl3399> oh hello Tm_T
[14:28] <carl3399> hello
[15:00] <dmatt> I attempted install of K12.10 and both times installer crashed. how to troubleshoot this? is there a log file or something i can examine?
[15:02] <dmatt> booting into live worked and usb install medium was checked
[15:05] <Tm_T> dmatt: /var/log/ should install related log files, atleast I recall it had something
[15:14] <dmatt> thanks, there seems to be a /var/log/installer/ directory
[15:15] <dmatt> some io error...
[16:38] <rfirmin> hello, i just upgraded to kubuntu 12.10. for some reason resolve.conf is not being initialized with any name servers. i see a nameserver come in via the dhcp config in syslog, but it never makes it to resolv.conf
[16:38] <rfirmin> any ideas?
[16:43] <rfirmin> nobody around?
[16:44] <BluesKaj> rfirmin, open /etc/resolvconf/resolv.conf.d/head, ignore the warning and paste your nameservers there
[16:45] <rfirmin> thanks! will cisco anyconnect vpn still be able to work with that hardcoding (once i set it up; it's not yet installed)?
[16:47] <rfirmin> guess i'll find out :)
[16:47] <BluesKaj> rfirmin, I imagine it will , not sure ..I gather you're not using network manager , or if so you've had vpn setup in the options
[16:48] <BluesKaj> previously that is , rfirmin
[16:48] <rfirmin> BluesKaj - yeah anyconnect circumvents the network manager. however currently this is a stock kubuntu install, so there is a bug somewhere
[16:48] <rfirmin> i.e. it is out of the box networking setup which is not generating resolv.conf
[16:50] <BluesKaj> rf  normally i just purge network manager and use the /etc/network/interfaces, the new resolvconf , and hosts.allow
[16:51] <BluesKaj> if you keep network manager , it will keep rewriting the resolvconf/resolv,conf file and wipe any edits you've added there
[16:51] <rfirmin> fair enough. surprises me because i thought network manager was finally relatively stable
[16:51] <BluesKaj> rfirmin,^
[16:51] <rfirmin> i had issues with it way back in 2008/2009, but since then it seems to have been functional
[16:51] <rfirmin> until now
[16:52] <BluesKaj> ok , I have no experience with vpn so i can't tell whether network manager is buggy or not
[16:52] <rfirmin> thanks for the resolv.conf.d/head trick, it works well. i'll file a bug and see if anyone bites
[16:53] <BluesKaj> right
[17:10] <blazemore> Can I make the Kickoff menu launch when I press the Super key?
[17:22] <xixor> blazemore: don't think so, super key is registered as just a modifier, so I don't think it can be used on it's own
[17:25] <blazemore> xixor: I swear I've used distros where that was the default behaviour, although they might not have been KDE
[17:28] <xixor> It's a possibility.  That isn't default on KDE, and I'm not sure it would be possible.  Maybe, I'm no expert in these matters.  Default keybinding for the KDE klicker menu is ALT+F1, ALT+F2 brings up the krunner launcher
[17:28] <blazemore> ty for alt+f1
[17:29] <xixor> blazemore: right click on the klicker menu->Application Launcher Settings->Keyboard Shortcut, it will tell you what the keyboard shortcut is, and will let you change it
[17:30] <xixor> blazemore: Klicker menu->System Settings->Shortcuts and Gestures.  In there almost any existing KDE keyboard shortcut can be seen and customized
[17:31] <xixor> blazemore: lots of good ones are in Global Keyboard Shortcuts, select KDE component KWin and there are lots of good ones there
[18:05] <Tygart> xixor: blazemore:  You can edit the Kickoff menu launch shortcut by right clicking on the "Kickoff Launch" icon and choose "Application Launch Setting" Then on the left Choose "Keyboard shortcut"
[19:54] <moroveno> what do I need to install to get GL_EXT_texture_sRGB_decode support
[19:59] <jeltsch> Hi, I’m using Kubuntu 12.10. If I go to the “Touchpad” entry in KDE’s systems settings, I’m told that no touchpad could be found.
[20:00] <jeltsch> Any ideas about how to debug this problem?
[20:00] <jeltsch> I’m using a Dell Latitude 6430.
[20:05] <[Raiden]> hi
[20:05] <[Raiden]> how to apply changes after manual editing of kdeglobals file?
[20:25] <moroveno> anyone in here to help?
[20:27] <BinaryCortex> hello
[20:27] <BinaryCortex> is anyone awake for a question
[20:28] <moroveno> lol
[20:28] <moroveno> guess everyone is watching football
[20:34] <BluesKaj> moroveno: just ask your question
[20:35] <BinaryCortex> i found an answer, not one i like but ill remember that BluesKaj
[20:54] <P_Walker> I must say i'm impressed of Kubuntu. +1 to all devs
[20:59] <invariant> Where do I have to put xrdb -load "${HOME}"/.Xdefaults such that it is applied? I put it in ~/.kde/env/a.sh, but this had no effect.
[21:17] <oneadvent> hi. I have a problem with dragging and dropping in dolphin. This is both with dragging inside dolphin and dragging to a browser or another program. copy/paste works fine...any ideas
[21:51] <Guest5780> hallo
[21:53] <Guest5780> ist jemand noch wach heute abend?
[21:55] <oneadvent> hmph started working..that was weird. i didn't do anything to make it work....
[22:22] <T___> hei, i wanna switch off the status-updates from kopete to the other chatpartner "blabla closed the chat". But how can i do this in telepathy?
[22:25] <holyguyver> what is the terminal code for launching konqueror?
[22:26] <tsimpson> holyguyver: what do you mean "terminal code"? just launching konqueror from a terminal?
[22:27] <holyguyver> tsimpson: Yes
[22:27] <tsimpson> just type "konqueror" (without quotes) and press enter
[22:27] <tsimpson> make sure you have it installed
[22:28] <holyguyver> tsimpson: That is not working & yes it is installed
[22:28] <tsimpson> holyguyver: what happens when you try?
[22:28] <holyguyver> It syas it is not isntalled, but it is
[22:29] <holyguyver> tsimpson:
[22:29] <tsimpson> what does "apt-cache policy konqueror" show?
[22:30] <Plagiating> hey, studiert jemand zufällig geschichte?
[22:30] <holyguyver> tsimpson:  apt-cache policy konqueror-trinity konqueror-trinity:  Installed: 4:3.5.13-1ubuntu0+ax3~precise  Candidate: 4:3.5.13-1ubuntu0+ax3~precise  Version table: *** 4:3.5.13-1ubuntu0+ax3~precise 0        500 http://ppa.quickbuild.pearsoncomputing.net/trinity/trinity-v3.5.13/ubuntu/ precise/main i386 Packages        100 /var/lib/dpkg/status
[22:31] <tsimpson> I didn't say konqueror-trinity, I said konqueror
[22:31] <tsimpson> it likely is installed as a different binary
[22:32] <holyguyver> tsimpson: Konqueror trinity is the only konqueror I wish to use
[22:32] <holyguyver> tsimpson: So how do I launch it?
[22:33] <Plagiating> is it possible to get in quakenet?
[22:33] <tsimpson> holyguyver: look at the output of "dpkg -L konqueror-trinity|grep /bin, see what it shows
[22:34] <holyguyver> tsimpson: Thanks, that answered a lot
[22:34] <holyguyver> tsimpson: dpkg -L konqueror-trinity|grep /bin /opt/trinity/bin /opt/trinity/bin/kbookmarkmerger /opt/trinity/bin/keditbookmarks /opt/trinity/bin/kfmclient /opt/trinity/bin/konqueror
[22:35] <holyguyver> tsimpson: I think that answered my question :D
[22:35] <tsimpson> holyguyver: so you can either run "/opt/trinity/bin/konqueror" directly, or add  /opt/trinity/bin to your PATH environment variable (by editing ~/.profile)
[22:36] <Plagiating> is it possible to get into qnet?
[22:36] <holyguyver> tsimpson: I will just run it directly, that is what I am used to, thanks for helping me find it
[22:37] <tsimpson> holyguyver: you're welcome
[22:37] <unheeding> what's the best theme for window decorations?
[22:37] <tsimpson> whichever you like best
[22:38] <unheeding> oxygen is pretty sweet, it has the blue outline... i like that
[22:40] <[Raiden]> bespin and skulpture  also good
[22:40] <[Raiden]> kwin themes
[22:43] <[Raiden]> and some qtcurve presets
[22:59] <STiAT> hey guys, I got a little problem here for grub2 recognizing my win7 installation on this computer
[23:00] <STiAT> setup: uefi, win7 (two "system" disks, two normal disks)
[23:00] <STiAT> and linux (swap, / and /home)
[23:00] <STiAT> but for some reason, grub does not configure the win7 installation, any ideas?
[23:01] <STiAT> oh, and using gpt ofc
[23:01] <STiAT> to make it even more complicated
[23:02] <STiAT> i already changed /etc/default/grub accordingly, but it only shows the ubuntu installation, no windows.
[23:52] <girnaar> hello
[23:52] <girnaar> how to  install java on kubuntu


[02:18] <mbruzek> waigani on a scale of 1 to 10 how hard was Ubuntu to install on a Mac?
[02:20] <waigani> hmmm, not too bad actually. I'd give it a 7
[02:20] <waigani> the trackpad sucks though
[02:21] <waigani> selecting, dragging and dropping - I have not sworn sworn so much in a long time!
[02:23] <waigani> I found this very helpful for the install https://help.ubuntu.com/community/MacBookPro11-1/Saucy
[07:58] <dimitern> jam, ping
[07:59] <dimitern> jam, if you haven't yet started working on bug 1268471 i'd like to pick it up
[07:59] <_mup_> Bug #1268471: cache bootstrap address <bootstrap> <juju-core:Triaged by dimitern> <https://launchpad.net/bugs/1268471>
[08:00]  * dimitern is away for 1h
[08:56] <rogpeppe> anyone have an idea why my /boot partition might have filled up recently?
[09:01] <axw> rogpeppe: usually for me that's because of kernel upgrades, and the old ones being kept around
[09:01] <rogpeppe> axw: yeah, i'd just figured that out, thanks
[09:01] <axw> are there lots of vmlinuz files?
[09:02] <axw> ok
[09:02] <jam> dimitern: I haven't started it yet
[09:02] <rogpeppe> axw: i've just removed some old vmlinuz and initrd.img files
[09:02] <rogpeppe> axw: hopefully no crucial ones
[09:02] <rogpeppe> axw: i'm assuming that old versions will never be used again
[09:02] <axw> rogpeppe: you should probably apt-get remove the packages
[09:02] <rogpeppe> axw: ah
[09:03] <axw> removing the packages updates grub too
[09:03] <axw> rogpeppe: linux-image-<version>-generic
[09:03] <axw> remove them for whichever ones you deleted :)
[09:05] <rogpeppe> axw: how can i list all the packages i've got installed?
[09:06] <rogpeppe> axw: i'd like to do <list all packages> | grep linux-image, just to make sure i'm doing the right thing
[09:06] <axw> rogpeppe: dpkg --get-selections
[09:06] <rogpeppe> axw: ha ha
[09:07] <rogpeppe> axw: you can't do it with apt-get?
[09:07] <rogpeppe> axw: fair enough
[09:07] <axw> not sure actually
[09:10] <rogpeppe> axw: much better! /boot down from 100% to 30%
[09:10] <axw> :)
[09:11] <rogpeppe> axw: one might think that the usual upgrade procedure would garbage collect every now and again
[09:12] <rogpeppe> axw: thanks a lot BTW
[09:12] <axw> rogpeppe: yeah, though you wouldn't want to upgrade and lose your old kernel if the new one is busted
[09:12] <axw> rogpeppe: nps
[09:14] <rogpeppe> axw: yeah, but keeping around 8 versions is probably slightly overkill...
[09:14] <axw> I won't argue with that :)
[09:59] <jam> axw: did something change with the test suite that it is trying to read /home/ubuntu/.ssh/authorized_keys ?
[10:00] <jam> axw: https://code.launchpad.net/~rogpeppe/juju-core/479-desired-peer-group/+merge/201245 for the traceback
[10:00] <jam> it happens that the machine has an ubuntu user
[10:00] <jam> but the test suite is run as "tarmac"
[10:00] <jam> so doesn't have rights
[10:00] <axw> jam: that'd be the authenticationworker I think
[10:00] <jam> and *IMO* shouldn't need them
[10:00] <dimitern> jam, rogpeppe, wallyworld_, any idea how to work around this error while bootstrapping? bootstrap failed: cannot find bootstrap tools: XML syntax error on line 9: element <hr> closed by </body>
[10:01] <jam> dimitern: wallyworld_ has a patch up for it, but also just "juju bootstrap --upload-tools" which I think you need anyway ?
[10:01] <dimitern> jam, oh, silly me, ofc
[10:01] <dimitern> thanks
[10:01] <axw> jam: so, I'm pretty sure the error there is not due to the lack of access
[10:02] <axw> it is very spammy though
[10:02] <jam> axw: [LOG] 31.15149 ERROR juju.worker.authenticationworker reading ssh authorized keys for "machine-0": reading ssh authorised keys file: open /home/ubuntu/.ssh/authorized_keys: permission denied
[10:02] <jam> that may not be why the test suite failed, true
[10:02] <jam> but it does look like something is broken in our test infrastructure
[10:02] <jam> which hides realstuff
[10:10] <axw> jam: I don't suppose I can do multiple prereqs on a proposal, can I?
[10:10] <jam> axw: just one
[10:10] <axw> rats
[10:10] <jam> you could merge them into another branch and use that as the prereq
[10:11] <axw> doesn't matter, I'll just wait for the others to be approved
[10:11] <axw> anyway: hooray, Windows can now bootstrap again (in my sandbox)
[10:42] <rogpeppe> jam: i just saw that
[10:42] <rogpeppe> jam: i suspect that something's not setting up things for the fake home correctly
[10:43] <jam> rogpeppe: well the tests are run as Tarmac, so it should be reading a different home dir
[10:43] <rogpeppe> jam: nothing should be trying to read from /home/ubuntu
[10:43] <jam> I have the feeling authentication worker has hard-coded "ubuntu" user's .ssh/authorized-keys
[10:43] <rogpeppe> jam: yeah
[10:44] <axw> jam: it could be changed, but I wonder if it should be run at all in tests. I don't think it's a good idea for the test user's authorized_keys to be updated...
[10:46] <rogpeppe> jam: it doesn't seem to hard code /home/ubuntu actually
[10:46] <rogpeppe> jam: but even so, it shouldn't be looking at the real home directory
[10:47] <axw> that's a good point
[10:48] <jam> standup
[10:48] <jam> fwereade: ^^
[11:26] <mattyw> fwereade, hi there - the id meeting - I could move it one hour earlier - would that be better?
[11:32] <mgz> wallyworld: lp:~gz/juju-core/1.16_ssl_verification_bootstrap_state_1268913 as an idea. would really like to write a test for it, but have few ideas.
[11:32] <natefinch> jam, rogpeppe: this might be the problem: 6.8G	./test-mgo172948267
[11:32] <rogpeppe> natefinch: probably
[11:32] <rogpeppe> natefinch: but why is it so big?
[11:32] <wallyworld_> mgz: let's see if it works first :-)
[11:33] <natefinch> rogpeppe: I don't know. I'm going to try passing --oplog-size and see if I can trim it down. The help says the oplog defaults to 5% of disk space
[11:33] <jam> rogpeppe, natefinch: note that I cleaned all of /tmp before we restarted the tarmac bot a couple of hours ago, so that is a 'new' run
[11:33] <jam> natefinch: did you submit that one yourself
[11:33] <jam> ?
[11:33] <rogpeppe> natefinch: oh wow
[11:33] <natefinch> jam: that's on my local machine
[11:33] <rogpeppe> natefinch: perhaps we could make it zero...
[11:33] <jam> rogpeppe: natefinch: mongo defaults are very much about "this will be a mongo machine"
[11:33] <jam> which is very much against a test suite :)
[11:34] <jam> natefinch: ah, good. I just checked the bot and I swapped the "used" and "available". The bot currently has6.9GBfree
[11:35] <natefinch> jam: there's no reason why that can't be plenty.  I'll do some tests locally to see if the op log thing helps.
[11:38] <natefinch> jam, rogpeppe: that did it.  oplogSize 100   (100MB) gets the directories down to 387M on my machine
[11:39] <rogpeppe> natefinch: cool
[11:39] <jam> natefinch: even 100 is rather large for the test suite. I don't know what we want in practice
[11:39] <rogpeppe> natefinch: even 10 would seem like plenty
[11:39] <jam> my understanding is you can't resize it
[11:39] <natefinch> I'll try 10 and see if anything blows up
[11:40] <jam> "The oplog exists internally as a capped collection, so you cannot modify its size in the course of normal operations. "
[11:40] <jam> http://docs.mongodb.org/manual/tutorial/change-oplog-size/
[11:40] <jam> so you can restart mongo to change the size (with some real hacks from what I can see)
[11:40] <jam> but you can't just a
[11:40] <jam> adjust it on the fly
[11:41] <jam> anyway, 10MB should work, but will mean we have to do full syncs more often if a slave gets out of date
[11:41] <jam> (more entries in the oplog than it can keep up with)
[11:41] <natefinch> this is just for the tests.... and it seems to run fine with 10
[12:03] <natefinch> I feel somewhat morbid with all these error messages about waiting for sockets to die
[12:06] <mgz> natefinch: the poor sockets... :)
[12:18] <nate_finch> oh USB ethernet adapter.... why do you hate me so?
[12:44] <frankban> hi juju-core devs, trying to bootstrap an azure env i get this: http://pastebin.ubuntu.com/6750245/ . It might be related to bug 1250007
[12:44] <_mup_> Bug #1250007: Bootstrapping azure causes memory to fill <amd64> <apport-bug> <saucy> <juju-core:Incomplete> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1250007>
[12:55] <mgz> frankban: looks like it could be, a recursive error or something
[12:56] <mgz> frankban: you have the stack there, so add some printing and de-incomplete the bug
[12:56] <mgz> hm, actually writing config, not printing an error
[12:57] <frankban> mgz: an encoding error writing the jenv?
[12:57] <mgz> frankban: add some debug stuff on top of a local 1.16.5 and find out
[13:18] <natefinch> mgz: wonder if azure is bootstrapping a machine that's too small?  512mb RAM or something?
[13:22] <mgz> natefinch: the OOM is on the local machine, no?
[13:22] <natefinch> mgz: duh.  yeah.  That's weird
[13:24] <mgz> as frankban can reproduce it, should be pretty trivial for him to narrow down the issue
[13:26] <frankban> mgz: it seems to affect trunk too: data, err := goyaml.Marshal(info) in configstore/disk/Write seems to never return
[13:26] <dimitern> fwereade, ping
[13:27] <mgz> frankban: good, being a branch-only issue would be more annoying
[13:31] <dimitern> fwereade, sorry, never mind
[14:00] <frankban> mgz: it seems a failure marshalling  the azure management-certificate
[14:01] <dimitern>  rogpeppe, jam, fwereade: a quick review? https://codereview.appspot.com/52050043 fixes bug 1268471
[14:01] <_mup_> Bug #1268471: cache bootstrap address <bootstrap> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1268471>
[14:01] <rogpeppe> dimitern: will look in a mo
[14:01] <dimitern> rogpeppe, ta
[14:12] <frankban> mzg, so maybe the bug is in the documentation: https://juju.ubuntu.com/docs/config-azure.html : the management-certificate-path is the pem file, not the cer one.
[14:12] <frankban> mgz: the bootstrap node has been successfully created, but status fails: 2014-01-14 14:10:30 DEBUG juju.state open.go:88 connection failed, will retry: dial tcp <IP_ADDRESS>:37017: connection refused
[14:13] <frankban> mgz: and now it works... it has taken several minutes. thanks for your help mgz
[14:13] <mgz> frankban: presumably because the client OOMed before actually finishing up everything
[14:14] <mgz> or... okay, what did you change?
[14:16] <frankban> mgz: nothing, it just takes a lot more time than I was used to with ec2. anyway, the problem I see here are two:1) the documentation is ambiguous and 2) juju explodes very badly if you set up your azure environment with the wrong certificate file
[14:17] <mgz> okay, so what did you actually change? the management-certificate setting?
[14:17] <mgz> having any value that OOMs on serialisation just needs fixing
[14:18] <frankban> mgz: the management-certificate-path setting
[14:18] <mgz> frankban: can you record that in the bug?
[14:18] <frankban> mgz: sure
[14:19] <sinzui> hi natefinch. I have some go+win questions that you might help me answer
[14:22] <natefinch> sinzui: sure
[14:22] <rogpeppe> dimitern: argh, i've just discovered that this CL, which should have gone in a month ago, never made it in: https://codereview.appspot.com/37650048/
[14:23] <sinzui> natefinch, I have setup a windows instance to build juju and the installer. There is a arch mismatch though
[14:23] <dimitern> rogpeppe, looking
[14:23] <dimitern> rogpeppe, ah yes
[14:23] <rogpeppe> dimitern: i'm sorry, it probably means that the logic in your branch will need looking at again, but i'd like to get it in, if that's ok
[14:23] <sinzui> natefinch, do we need 386? If so can I choose go 1.2 or go 1.1rc3?
[14:24] <smoser> hey. is streams.canonical.com supposed to have some data ?
[14:24] <sinzui> smoser, not yet
[14:24] <dimitern> rogpeppe, get it in, I'll merge the changes and fix mine
[14:24] <rogpeppe> dimitern: thanks.
[14:24] <sinzui> smoser, http://streams.canonical.com/juju will have something soon though
[14:24] <rogpeppe> dimitern: i was looking at the code and thinking "i'm sure i made this a bit simpler"..
[14:24] <natefinch> sinzui: we build 386 for go because it's compatible with both x86 and x64  but the OS bitness doesn't matter
[14:24] <dimitern> rogpeppe,  :)
[14:25] <natefinch> sinzui: 1.2 should be fine
[14:25] <sinzui> fab, thank you natefinch.
[14:25] <smoser> k. thanks, sinzui . jamespage ^.
[14:25] <natefinch> sinzui: np
[14:25] <smoser> jamespage noticeds that it was being hit from his juju.
[14:26] <jamespage> sinzui, yeah - I was trying to deploy a saucy charm under the local provider (running on trusty)
[14:26] <jamespage> #fail
[14:27] <sinzui> jamespage, 1.6.x always checks streams, then fails over to aws. But also note that many charms wont deploy on saucy because they rely on a package from a ppa that doesn't exist.
[14:27] <jamespage> sinzui, thats 1.17
[14:27] <jamespage> sinzui, this charm should work on saucy
[14:27] <frankban> mgz: commented on bug 1250007
[14:27] <_mup_> Bug #1250007: Bootstrapping azure causes memory to fill <amd64> <apport-bug> <saucy> <juju-core:Incomplete> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1250007>
[14:28] <sinzui> jamespage, you can always set the tools-metadata-url to the location you expect tools to be found
[14:28] <sinzui> jamespage, which cloud? your own?
[14:28] <jamespage> sinzui, local provider so yes
[14:29] <dimitern> rogpeppe, but you can review mine anyway, at least as it is now maybe?
[14:29] <rogpeppe> dimitern: yeah, i will
[15:24] <rogpeppe> dimitern: i am still looking at your CL BTW, and trying to work out how to avoid apiConfigConnect calling prepareAPIInfo. i'm thinking that it's perhaps not quite right that prepareAPIInfo calls Environ.StateInfo, but i haven't quite worked out what it *should* do
[15:27] <dimitern> rogpeppe, why avoid calling it?
[15:27] <rogpeppe> dimitern: firstly, because it's really slow
[15:28] <rogpeppe> dimitern: secondly, because if we've got an API connection, we can get the most up to date API server addresses by asking the API
[15:28] <dimitern> rogpeppe, well, apiConfigConnect calls NewAPIConn, which does the same
[15:29] <rogpeppe> dimitern: your code is invoking Environ.StateInfo twice, AFAICS
[15:30] <dimitern> rogpeppe, yes
[15:30] <dimitern> rogpeppe, but it's not really slow if we have the cache
[15:30] <dimitern> rogpeppe, it's slow only once initially
[15:30] <rogpeppe> dimitern: isn't this happening when we *don't* have the cache?
[15:30] <dimitern> rogpeppe, I was thinking how to avoid calling it twice but couldn't find a way
[15:31] <rogpeppe> dimitern: i don't see why apiConfigConnect needs to call NewAPIConn at all
[15:31] <rogpeppe> dimitern: can't it just call apiOpen directly?
[15:32] <rogpeppe> dimitern: we're discarding the APIConn type anyway
[15:33] <dimitern> rogpeppe, ah, that's a good point
[15:35] <rogpeppe> dimitern: that old branch of mine has landed, BTW
[15:36] <dimitern> rogpeppe, ok, will merge mine
[15:40] <dimitern> another small review anyone? https://codereview.appspot.com/52130043/ - fixes bug 1259925
[15:40] <_mup_> Bug #1259925: juju destroy-environment does not delete the local charm cache <destroy-environment> <local-provider> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1259925>
[15:43] <mgz> dimitern: do you need the prereq reviewed first?
[15:43] <dimitern> mgz, they're not really related
[15:43] <dimitern> mgz, just in the same pipeline, and rogpeppe is already reviewing the prereq
[15:43] <mgz> k
[15:43] <mgz> I shall assume sanity then
[15:44] <dimitern> :) ta
[15:48] <mgz> dimitern: revie
[15:48] <mgz> -wed
[15:48] <dimitern> mgz, cheers!
[15:49] <rogpeppe> dimitern: reviewed
[15:49] <dimitern> rogpeppe, thanks
[15:51] <natefinch> rogpeppe: are there tests besides the ones involving git that *always* fail on trusty?
[15:52] <rogpeppe> natefinch: i don't *think* so, but i'll just check again.
[16:13] <natefinch> rogpeppe: FYI, QA just ran the test suite on trusty and it passed, so you don't have to bend over backwards trying to figure out if it's possible to pass on trusty
[16:25] <rogpeppe> natefinch: i'm running the test suite continuously now. so far i've had 2/2 failures
[16:26] <natefinch> rogpeppe: that's about the ratio I get on saucy :/
[16:26] <rogpeppe> natefinch: one with the juju package failing with "Waiting for sockets to die", the other with that and minunits tests failing with "no reachable servers"
[16:27] <natefinch> rogpeppe: yeah, I get those fairly often
[16:48] <marcoceppi> Hey guys, maas question, where does juju sync-tools put the files on the maas master?
[16:49] <mgz> marcoceppi: in the filestorage thing, which I think boils down to postgres blobs
[16:50] <marcoceppi> mgz: ack, thanks!
[16:50] <mgz> you can get at them using the maas cli thing... I think the bug with that got fixed
[17:16] <rogpeppe> natefinch: 6/6 test failures so far
[17:16] <rogpeppe> natefinch: test run times varying between 9 and 20 minutes
[17:17] <natefinch> rogpeppe:  yeesh
[17:19] <TheMue> Tschakka, it passes. *phew* Some more details tomorrow morning and I can push it again. *happy*
[17:19] <rogpeppe> natefinch: the juju package fails every time. other packages i've seen fail: worker/minunitsworker state/apiserver/upgrader	worker/provisioner
[17:30] <arges> hi. Are there simple instructions for 'seeding' a juju maas provider with juju tools? I'm imaginging first i need to mirror the tools directory, then 'juju sync-tools --source <path to tools>'. is there a better way to do this? and how do I mirror the tools easily?
[17:32] <natefinch>  juju bootstrap --upload-tools should work: http://maas.ubuntu.com/docs/juju-quick-start.html
[17:32] <natefinch> arges: ^
[17:33] <arges> natefinch: well what i'm asking is, imagine i'm using juju from a machine that has s3 access blocked. how would i get tools on that machine so I can use juju
[17:33] <arges> and its a maas enviornment
[17:34] <mgz> args, no there should be simple instructions, but that sort of thing with sync-tools is the right idea
[17:35] <mgz> *arges
[17:35] <mgz> **kwarges
[17:35] <arges> heh
[17:35] <natefinch> lol
[17:35] <arges> mgz: now the question is. how do I easily mirror juju tools
[17:36] <arges> wget -m on the s3 url doesn't work. and I can download specific files, but i don't want to miss anything
[17:36] <arges> i also thought of 'juju sync-tools -e lxc' and downloading tools locally, then syncing that to maas (which seems like a hack)
[17:39] <mgz> arges: I think --local-dir, then rsync or whatever that to somewhere with maas access, then --source from there should work... but the streams.canonical.com being broken bug prevents me from actually testing that
[17:39] <arges> mgz: --local-dir is an argument to which command?
[17:39] <mgz> both to sync-tools
[17:39] <arges> oh ok
[17:40] <arges> mgz: i think --local-dir is in newer version of juju
[17:41] <arges> its not in 1.16.5
[17:41] <mgz> arges: that seems likely then...
[17:44] <mgz> your trick with the local provider seems worth trying, or just getting the tar bits you need from the ec2 bucket and generating the metadata files, which then requires several more commands and is also not well documented, and probably only nice and usable on trunk...
[17:44] <mgz> this stuff has been semi-broken for too long
[17:44] <arges> mgz: yea the local provider trick works for now. I'll check out trunk when I have time
[18:20] <rogpeppe> natefinch: 10/10 failures so far
[18:27] <natefinch> rogpeppe: dang.  I'm 100% fail as well..... trying to figure out what's going on.  Given that a lot of it seems to have to do with the test mongo server, I wonder if I managed to break it in some odd way
[18:30] <natefinch> rogpeppe: seems like it's probably one specific problem that is cascading across tests
[18:31] <rogpeppe> natefinch: yeah, i think so
[18:31] <rogpeppe> natefinch: i suspect some kind of race in mgo, but i dunno really
[18:31] <rogpeppe> natefinch: i need to muster up the energy to dive in again, now that i can repro it on my machine for the first time reliably
[18:42] <rogpeppe> i'm done for the day though
[18:42] <rogpeppe> g'night all!
[18:47] <natefinch> heh, running go test -race somehow froze my computer
[18:49] <natefinch> ....twice
[18:49] <natefinch> maybe I'll stop doing that
[18:57] <sinzui> ha ha. The windows client for 1.17.1 gives up on the public address and attempts to connect on the private address
[18:59] <natefinch> good luck with that
[19:03] <sinzui> I think this is another day to hit the sauce
[19:03] <natefinch> hot sauce?
[19:03] <sinzui> natefinch, beer
[19:03] <sinzui> Before developing in Windows, I drank 1 beer a month
[19:04] <sinzui> Except for yesterday's hacking via python and ssh, I drink to numb the pain
[19:04] <natefinch> sinzui: yeah, windows is pretty terrible.
[19:05] <natefinch> So, I went to upgrade to trusty, and it runs through the whole huge thing.  At the end it says:
[19:05] <natefinch> Upgrade complete
[19:05] <natefinch> The upgrade has completed but there were errors during the upgrade
[19:05] <natefinch> process.
[19:06] <sinzui> natefinch, The good news is that CI can build the windows installer along with the release tarball. Running the client tests looks like an exercise in adapting bash and *ix=isms
[19:06] <sinzui> natefinch, don't remove any packages
[19:06] <natefinch> ..... so... am I on trusty?  did it work?  Were the errors fatal?  Do I need to do somtehign to fix them?
[19:07] <sinzui> natefinch, I have found that re-enabling the disabled archives (most still using saucy), then updating again fixes the issues
[19:07] <natefinch> sinzui: cool, I'll give that a try.   They do it to ensure only the tested/compatible are installed, but as developers, we are crippled. I one let upgrade remove the packages that came from other archives and that caused a chain of breakages.
[19:09]  * sinzui wont do that again
[19:11] <natefinch> brb rebooting
[19:12] <marcoceppi> did you guys change the default behavior of destroy-environment from using the -e flag to a list of environments as parameters? Or has that how it's been?
[19:13] <natefinch> well great, now I can't open "software & updates" :/
[19:51] <_thumper_> morning
[19:53]  * thumper sighs
[19:53] <thumper> big email backlog...
[20:25] <natefinch> sinzui: lsb_release -a says trusty, but the "About This Computer" window still says 13.04.... is that normal for being on the release branch, or did my mucked up upgrade screw things up?
[20:25] <natefinch> sinzui: s/release branch/development branch/
[20:25] <sinzui> natefinch, yes
[20:26] <natefinch> sinzui: ok, phew
[20:27] <thumper> natefinch: the about computer package gets updated later
[20:28] <thumper> sometimes the login screen will show old version number too
[20:28] <thumper> until that is updated
[20:28] <natefinch> thumper: yeah, it does.  boo.
[20:28] <thumper> natefinch: tests passing?
[20:29] <natefinch> .....and that answers the question of whether go test -race still crashes my laptop
[20:32] <thumper> haha
[21:29] <sinzui> natefinch, do you have any incites into this error. I can run the script from powershell over  rdp, but ssh errors on bootstrap command (but not the version command) http://pastebin.ubuntu.com/6752700/
[21:34] <natefinch> sinzui: looks like it's looking for the juju home directory, which doesn't exist for some reason
[21:35] <sinzui> JUJU_HOME is defined (at least is in powershell)
[21:35]  * sinzui looks in ssh env
[21:35] <natefinch> C:\Users\Administrator\AppData\Roaming\Juju  would be the default
[21:37] <sinzui> natefinch, thank for the clue. It isn't defined when I execute the script via ssh
[21:37] <natefinch> sinzui: welcome
[21:48] <natefinch> thumper, wallyworld_:  This test consistently fails for me: TestStartInstanceWithDefaultSecurityGroup  (in provider/openstack/live_test.go)
[21:57] <thumper> natefinch: is this run normally with make check?
[21:57] <thumper> natefinch: if so, just passed for m,e
[21:58] <natefinch> thumper: not sure what you mean about make check, I just did go test in that directory (also fails when running the full test suite)
[21:59] <thumper> ok, works for me then
[22:03] <natefinch> thumper: weird.  Fails for me every single time
[22:03] <natefinch> live_test.go:248:
[22:03] <natefinch>     c.Assert(defaultGroupFound, gc.Equals, useDefault)
[22:03] <natefinch> ... obtained bool = false
[22:03] <natefinch> ... expected bool = true
[22:04] <natefinch> gotta go
[22:58] <davecheney> sinzui: hold on, imma coming


[00:03] <tsimonq2> Cool :)
 Welcome!
 😀
 Hoping the Lubuntu dev team is having a good weekend
 😎😎😎


[08:16] <arapgodsmack> anyone here know of a linux third party app to adjust mouse scroll speed?
[08:30] <theShirbiny> arapgodsmack: i don't think you need a third party app for this
[08:32] <theShirbiny> oh, i thought you said mouse speed :|
[08:32] <theShirbiny> arapgodsmack: take a look at this https://wiki.archlinux.org/index.php/Imwheel


[00:56] <Unit193> Well crap, seems final freeze, so if something is seeded it's boned.  https://packages.qa.debian.org/s/sgt-puzzles/news/20230417T000358Z.html seems kinda like it'd be good to have. :3
[01:06] <jbicha> Unit193: you're a Xubuntu developer right? since it's only seeded in Xubuntu, you could still get that upload in before release if you're willing to respin the Xubuntu ISOs
[01:41] <Unit193> Figured the rule was "if it's seeded, that's a nogo."
[01:56] <jbicha> if that were 100% enforced, then there wouldn't be any ISO respins because we wouldn't fix any bugs after Final Freeze 😉
[10:53] <nkshirsa_> sil2100, eric will bump up the lunar dev version i think this week to be 4.5-1ubuntu1
[10:53] <nkshirsa_> the debian sos package is way behind, its on 4.2 still i believe
[10:54] <nkshirsa_> 4.0.2 even
[10:54] <nkshirsa_> https://packages.debian.org/search?keywords=sosreport
[10:59] <sil2100> nkshirsa_: ok, thanks! Yeah, in such cases, when debian is lagging (and there's no such version in Debian), remember to use VERSION-0ubuntu1
[10:59] <sil2100> 0 meaning 'not-in-debian' and ubuntu1 meaning 'first version in ubuntu'
[11:00] <sil2100> In general ubuntu0 is reserved only for cases like ubuntu0.1 or ubuntu0.22.04 etc.
[19:00] <rbasak-mobile> !dmb-ping
[19:01] <teward> poor timing for me needing a biobreak :P
[19:01] <teward> there but via phone so slow


[08:54] <kalikiana_> zsombi: review? https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/realLayoutDirectionChange/+merge/318359
[08:54] <zsombi> kalikiana_: sure
[08:55] <kalikiana_> zsombi: Also https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/ellipticSubTitles/+merge/318390 has been sitting a while
[08:55] <zsombi> kalikiana_: I had once a fix for the Mainview not dispatching the layout direction change properly, prehaps we should reload that work again...
[08:59] <kalikiana_> zsombi: The problem here first of all is that the gallery is cheating by not actually changing it. I suspect there's buglets that will surface only now. daker is the one who actually triaged several RTL/ direction-related issues more recently
[08:59] <zsombi> k
[09:00] <kalikiana_> zsombi: Do you have any pointers to the dispatching issue? Old code, bug or a piece of code?
[09:00] <zsombi> kalikiana_: should be on the staging, in between some working branch, having some words about MainView rtl crap :D
[09:00] <zsombi> it was long ago
[09:01] <kalikiana_> zsombi: So it was committed?
[09:01] <zsombi> not completed afair
[09:02] <kalikiana_> Hmmm
[09:03] <zsombi> kalikiana_: https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/mainview-rtl/+merge/251420
[09:03] <zsombi> I even made an MR, but we got redirected to some other things
[09:07] <kalikiana_> zsombi: Ah, thanks, I remember we were talking about that. So that may still be needed to get the right out of the box behavior
[09:08] <zsombi> yep
[09:10] <kalikiana_> I'll provide an updated MR for it (that branch even predates our version split, so weird to look at it now :-D)
[09:11] <zsombi> kalikiana_: I know :)
[09:11] <zsombi> it was abandoned, and never had time to return to it
[09:49] <kalikiana_> zsombi: It seems we have LayoutMirroring settings in several components in staging, but not in the MainView... I'm wondering if there was a reason not to do it in MainView for everything
[10:03] <kalikiana_> zsombi: daker: https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/rtlBackButtonIconName/+merge/319668
[10:06] <kalikiana_> Also: https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/layoutMirroringEnabledInMainView/+merge/319669
[10:56] <daker> zsombi: does your last MR fixes bug 1667165 too ?
[10:56] <daker> sorry it's for you kalikiana_
[11:50] <kalikiana_> daker: It's related but not the same. So, right now apps have to enable RTL, like the gallery does, to get full layout mirroring out of the box - the MR changes that. Although, as said above, I am wondering if there was any reason to do it on a per-component basis...
[11:55] <daker> kalikiana_: i see, i am not sure about the second part :D
[17:31] <bluss> is there a thumbnailer I can call from Python to get or generate thumbs for example for PDFs
[17:43] <daker> kalikiana_, zsombi i want try to write some components using QCC2 but there are some packages not available in 16.04, not sure how to deal with that
[17:45] <kalikiana_> daker: That's work in progress. The new qtbase is now building in the silo, and qtdeclarative/quickcontrols2 are coming soon
[17:45] <kalikiana_> There were some issues with the build configuration
[17:46] <daker> kalikiana_: ok
[17:46] <kalikiana_> daker: For now you can have a go in a Zesty lxd container if you want. Otherwise you'll have to wait a couple weeks or so
[17:46] <kalikiana_> (Maybe longer, it depends if there's more build issues or if what was done in qtbase is enough)
[17:47] <daker> kalikiana_: i can use the lxd container, but i am not sure how to launch it...
[17:49] <daker> not sure how to tell lxd to use my X server as a display
[19:43] <zsombi> [11:49:04] <kalikiana_> zsombi: It seems we have LayoutMirroring settings in several components in staging, but not in the MainView... I'm wondering if there was a reason not to do it in MainView for everything
[19:43] <zsombi> there was no reason
[19:43] <zsombi> my IRC client died... and I did not notice it...
[19:44] <zsombi> daker: what components do you want to write?
[19:56] <kalikiana_> zsombi: Hmm okay. Well, my MR is there, moving the code to the MainView was simple enough. One thing occurs to me after I prepared it, if those components are used outside a MainView, including a MainWindow, this wouldn't suffice... so maybe we actually want to retain the default in all of those respective components
[19:57] <kalikiana_> Or rephrased more simply: MainView and MainWindow should probably have the LayoutDirection in addition to individual components, not instead of
[19:58] <zsombi> kalikiana_: the fun is that it's an attached property after all...
[19:59] <kalikiana_> Not sure how that's related
[20:02] <zsombi> kalikiana_: well, every component's layotu can be driven through the attached props, it's only that we need to react and take them into account properly
[20:03] <kalikiana_> zsombi: I don't see what that has to do with anything. I'm concerned where we need to enable the defaults. It would be the same if it was a regular property
[20:04] <daker> zsombi: i don't know maybe start with a simple one :)
[20:04] <zsombi> kalikiana_: right... I was just thinking loud :)
[20:04] <zsombi> the feature I added to MainViewBase was defaulted to local's layout direction
[20:05] <kalikiana_> Right
[20:05] <zsombi> kalikiana_: so something like that needs to be set, and perhaps we shoudl add that to be automatically set for all components...
[20:07] <kalikiana_> zsombi: I feel we'd want want that to apply to any component... it seems odd to me that it's not the default for Item to be honest
[20:07] <zsombi> kalikiana_: I do get that why
[20:08] <zsombi> for instance you want to give the possibility to the component implementation to drive when they take the layout direction into use, so you don;t default anything on those
[20:09] <zsombi> the layout direction handling is after all implemented in the Item, the LayoutDirection attached object si just an interface to drive that
[20:22] <kalikiana_> zsombi: Maybe then it should only be added to AdaptivePageLayout and nowhere else
[20:23] <kalikiana_> Since MainView (or MainWindow) has no use for it


[11:32] <foophi> i clicked the link above to read wiki re faq i got random nothing about faq wiki though
[11:35] <foophi> i have a laptop that keeps crashing any suggestions on tools or live cd to test for hardware faults people please =)
[11:42] <verterok> foophi: you should ask in #ubuntu
[11:43] <verterok> this was the channel for the ubuntuone project, which is closed


[01:48] <davecheney> niemeyer: testing/mgo_test.go wasn't being run
[01:48] <davecheney> i'll roll that fix into my next proposal
[02:14] <niemeyer> davecheney: Oops.. thanks!
[02:19] <davecheney> niemeyer: https://code.launchpad.net/~niemeyer/goetveld/trunk/+merge/126136
[02:20] <davecheney> ^ not propsed with lbox, sorry
[02:22] <davecheney> urgh, change list is empty as well ...
[02:24] <davecheney> ahh, because i did it ass backawards
[02:25] <davecheney> niemeyer: https://code.launchpad.net/~dave-cheney/goetveld/001-add-darwin-termios-support/+merge/126137
[03:16] <niemeyer> davecheney: LGTM
[03:16] <niemeyer> davecheney: I've just changed the project so it's trunk is owned by the gophers team
[03:16] <niemeyer> s/it's/its/
[03:16] <niemeyer> davecheney: Please feel free to repropose against the new trunk and submit it straihgt
[03:16] <niemeyer> straight
[03:24]  * niemeyer => bed
[07:52] <fwereade> ha! my first Refresh-related bug with a long-lived-entity
[07:52] <rogpeppe> fwereade: morning!
[07:52] <rogpeppe> fwereade: it was bound to happen
[07:52] <fwereade> rogpeppe, what would you think about putting Refresh in at the start of Watch on Unit and Service?
[07:53] <fwereade> rogpeppe, that way the initial event actually is the current state, rather than potentially being whatever aged rubbish you started to watch?
[07:53] <rogpeppe> fwereade: what are the events that those watchers produce?
[07:54] <fwereade> rogpeppe, something-changed
[07:54] <fwereade> rogpeppe, send fresh units back
[07:54] <rogpeppe> fwereade: so won't the initial event be a fresh unit?
[07:54] <rogpeppe> fwereade: and hence have all the currently correct settings?
[07:54] <fwereade> rogpeppe, AFAICT it'll correspond to *some* transaction more recent than the revno of the old document
[07:55] <fwereade> rogpeppe, hey wait that makes no sense
[07:55] <rogpeppe> fwereade: hmm, that seems wrong
[07:55] <fwereade> rogpeppe, ok, time seemed to be flowing in reverse, and a Refresh fixed it, but clearlymore thought is required
[07:55] <rogpeppe> fwereade: the initial event should be the most recent revno
[07:56] <fwereade> rogpeppe, ah, no, the initial event is just the unit yu originally watched
[07:56] <rogpeppe> fwereade: that seems wrong to me
[07:56] <fwereade> rogpeppe, yeah, agreed
[07:56] <rogpeppe> fwereade: then there's no point in having the initial event
[07:57] <fwereade> rogpeppe, well, yeah; we could either Refresh it or reconstruct a new one and send that back
[07:57] <rogpeppe> fwereade: i'd incline towards the latter
[07:57] <rogpeppe> fwereade: we don't do any implict Refresh anywhere else
[07:58] <rogpeppe> TheMue: yo!
[07:58] <fwereade> rogpeppe, ok, sgtm
[07:58] <rogpeppe> fwereade: and every other event on the channel is a fresh object
[07:58] <fwereade> TheMue, heyhey
[07:58] <fwereade> rogpeppe, yeah, feels neat
[07:58] <TheMue> morniing rogpeppe and fwereade
[08:32] <fwereade> rogpeppe, TheMue: should be trivial: https://codereview.appspot.com/6571047
[08:35] <rogpeppe> fwereade: LGTM
[08:36] <fwereade> rogpeppe, cheers; trivial enough to submit directly, do you think?
[08:37] <rogpeppe> fwereade: i *think* so, but it is a significant change in one sense.
[08:37] <rogpeppe> fwereade: even though the code is trivial
[08:38] <fwereade> rogpeppe, in the sense that it causes the uniter to work properly, it is significant ;p
[08:39] <fwereade> rogpeppe, and I think it is unambiguously (1) correct, because watches should send current state and then deltas; and (2) safer, because we don't ever send the originating entity over to some unknown client over a channel
[08:39] <rogpeppe> fwereade: it's that last thing that i think is the killer argument
[08:39] <fwereade> rogpeppe, indeed, it is only secondary in my mind because it wasn't the thing that bit me
[08:40] <rogpeppe> fwereade: i'd say go for it
[08:40]  * fwereade cheers
[09:41] <Aram> moin.
[09:42] <davecheney> hello and goodbye
[09:42] <davecheney> time to make the dinner
[09:42] <davecheney> then i'll see ya'll for the hangout
[09:46] <fwereade> ok  	launchpad.net/juju-core/worker/uniter	117.284s
[09:46] <fwereade> ok  	launchpad.net/juju-core/worker/uniter/charm	7.835s
[09:46] <fwereade> ok  	launchpad.net/juju-core/worker/uniter/hook	0.007s
[09:46] <fwereade> ok  	launchpad.net/juju-core/worker/uniter/relation	8.826s
[09:46] <davecheney> fwereade: did you see my comment to the list about i/o usage
[09:46] <davecheney> that might explain your excessive test times
[09:46] <fwereade> davecheney, I did, makes a lot of sense
[09:46] <fwereade> davecheney, thanks
[09:46] <davecheney> fwereade: maybe aram can help
[09:46] <davecheney> i had a look today, but I wasn't much chop for anything
[09:47] <davecheney> invoking mgo the way the tests do, doesn't make it create that big _tmp
[09:47] <davecheney> flie
[09:47] <davecheney> but then again, I never connected a client to the manually invoked one
[09:47] <Aram> 20MB
[09:47] <Aram> make it smaller
[09:47] <Aram> 1MB
[09:47] <davecheney> on my machine _tmp was 256mb
[09:47] <Aram> hmm?
[09:47] <Aram> perhaps testing/mgo had leaked?
[09:48] <Aram> or was this only from one test?
[09:48] <Aram> aaah
[09:48] <Aram> I know
[09:48] <Aram> niemeyer made the capped collection 20MB
[09:48] <Aram> 200
[09:48] <davecheney> aram what is _tmp ?
[09:48] <Aram> and it needs contiguous space for that
[09:48] <davecheney> (see email)
[09:48] <fwereade> Aram, aaaahhh, and it's only made little in *some* tests
[09:48] <Aram> ok, let me read the email
[09:48] <fwereade> Aram, right?
[09:49] <davecheney> fwereade: only made little in cloudinit -> deploy to ec2
[09:50] <davecheney> oh, that explains why my had started version didn't use any disk space
[09:50] <davecheney> it won't do that until someone connects to it and does ensure index ...
[09:53] <fwereade> davecheney, StartMgoServer specifies everything that addMongoToBoot does, doesn't it?
[09:54] <Aram> fwereade: make the capped collection 1MB and see if tests take less.
[09:54] <Aram> in open.go
[09:55] <Aram> wtf is wrong with launchpad today, so slow.
[09:56] <Aram> actually, my internet is slow.
[09:56]  * Aram reboots router
[10:15] <TheMue> lunchtime, see you in the hangout
[10:59] <TheMue> hmm, my build complains about an undefined bson.SetZero. i already update mgo. or is it a different problem?
[10:59] <Aram> bzr pull
[10:59] <Aram> go get -u is not enough
[11:00] <TheMue> Aram: thx, will try
[11:01] <TheMue> Aram: it pulled nothing, but i'm still using 1.0.2. may this be the problem?
[11:01] <Aram> no
[11:01] <Aram> you pulled mgo, right?
[11:02] <TheMue> yes
[11:02] <Aram> what does bzr log --line -r -1 say?
[11:03] <davecheney> so, how about that meeting ...
[11:04] <TheMue> funny, 172 with the added SetZero
[11:04] <davecheney> TheMue: maybe a fast path is to
[11:04] <davecheney> rm -rf .../v2/mgo
[11:04] <davecheney> go get ...
[11:04] <davecheney> the cd v2/mgo
[11:05] <davecheney> bzr pull
[11:05] <davecheney> that is what I did
[11:05] <davecheney> i'm pretty sure it will work
[11:05] <TheMue> will try that too
[11:05] <davecheney> please double check you don't have another mgo snuck away somewhere else
[11:05] <Aram> davecheney: but it's always funny to find new bzr misfeatures and broken behaviors to complain about them.
[11:06]  * davecheney smiles at Aram
[11:06] <davecheney> its like bzr has set the revision to a revision in a branch
[11:07] <fwereade> hm, should we be meeting now?
[11:08] <davecheney> indeed
[11:08] <davecheney> we should
[11:12] <Aram> we should have a meeting about the lack of the meeting.
[11:13] <davecheney> Aram: please propose an agenda first
[11:13] <Aram> a user story.
[11:13] <Aram> which we have to send to a program manager.
[11:13] <TheMue> shall i sent out the invite?
[11:14]  * davecheney is texting mrarmm
[11:15] <fwereade> TheMue, please do
[11:16] <TheMue> done
[11:17] <mramm> sorry I was late to the meeting
[11:17] <davecheney> s'ok
[11:17] <davecheney> lets get going
[11:20] <mramm> I'm in the meeting, called by frank
[11:20] <davecheney> err, nobody else is
[11:21] <Aram> we are
[11:21] <Aram> :)
[11:21] <Aram> davecheney: https://plus.google.com/hangouts/_/74ad471b07ee1c4e3215133bbf54c62e79ff5c7b?authuser=1&hl=en
[11:21] <davecheney> ta
[11:23] <Aram> rogpeppe: ^ ^
[11:24] <rogpeppe> oops, didn't see it
[11:24] <rogpeppe> will be there in a moment
[11:29] <mramm> 16:06 niemeyer: Woah
[11:29] <mramm> 16:06 niemeyer: services:
[11:29] <mramm> 16:06 niemeyer:  builddb:
[11:29] <mramm> 16:06 niemeyer:    charm: builddb
[11:29] <mramm> 16:06 niemeyer:    exposed: false
[11:29] <mramm> 16:06 niemeyer:    units:
[11:29] <mramm> 16:06 niemeyer:      builddb/0:
[11:29] <mramm> 16:06 niemeyer:        agent-version: 0.0.0
[11:29] <mramm> 16:06 niemeyer:        machine: 1
[11:29] <mramm> 16:06 niemeyer:        public-address: ec2-204-236-223-223.compute-1.amazonaws.com
[11:29] <mramm> 16:06 niemeyer:        status: started
[11:33] <fwereade> davecheney, sorry, did you paste it somewhere I missed?
[11:33] <davecheney> sorry, email
[11:33] <davecheney> irc is on another machine, sorry
[11:35] <fwereade> davecheney, np, ty
[11:59] <fwereade> lunch bbl
[12:48] <niemeyer> Morning juju masters!
[13:06] <davecheney> niemeyer: hello
[13:06] <niemeyer> davecheney: Heya!
[13:06] <davecheney> sleep it would seem, eludes me
[13:10] <TheMue> niemeyer: hi
[13:14] <niemeyer> davecheney: Wow, yeah, you've been here for a while :)
[13:14] <niemeyer> TheMue: Yo
[13:30] <fwereade> niemeyer, heyhey
[13:30] <niemeyer> fwereade: Heya
[13:30] <niemeyer> fwereade: Just reviewing the relation units stuff
[13:30] <niemeyer> fwereade: Superb so far
[13:31] <fwereade> niemeyer, for some reason I made the make-uniter-work branch depend on that one
[13:31] <fwereade> niemeyer, jolly good, hopefully I won't need to reparent the followup ;)
[13:31] <fwereade> niemeyer, I submitted one trivial this morning btw that was necessary
[13:32] <niemeyer> fwereade: No, certainly not.. I think there were a few opportunities to have split the branches, as you noted yourself in the description, but it's alright.. happy to have it in whatever form.
[13:33] <fwereade> niemeyer, cheers
[13:33] <niemeyer> fwereade: Super, thanks re. trivial
[13:34] <fwereade> niemeyer, now I come to think of it, the timeout bumps in the followup are surely only necessary because I wasn't using a tmpfs
[13:34] <fwereade> niemeyer, I will adjust them down as seems fit
[13:35] <niemeyer> fwereade: Hmm
[13:35] <niemeyer> fwereade: The timeouts on the sad cases may be high
[13:35] <fwereade> niemeyer, I was thinking "conservatively", at first, anyway -- just to what they were originally
[13:35] <niemeyer> fwereade: Those prevent spurious breaks when the machine happens to get some load or when tests are running on a slow machine
[13:36] <niemeyer> fwereade: I haven't seen the branch
[13:36] <niemeyer> fwereade: What were they?
[13:36] <fwereade> niemeyer, 5s to 10s is the notable one, in a couple of places
[13:36] <fwereade> niemeyer, and I really don't think it deserves that long
[13:36] <niemeyer> fwereade: wow
[13:36] <niemeyer> fwereade: Yeah, that's a lot
[13:37] <niemeyer> fwereade: How come we're getting such long timeouts? Are we missing a resync?
[13:37] <fwereade> niemeyer, that was pessimistic, in practive it only missed the 5s mark by a few milliseconds even under load
[13:37] <fwereade> niemeyer, but I was in no mood to mess around ;)
[13:37] <fwereade> niemeyer, almost certainly it is because the mongo tests stress the hell out of my machine unless I have a tmpfs
[13:37] <niemeyer> fwereade: Hmm
[13:38] <niemeyer> fwereade: I wonder why
[13:38] <niemeyer> Well, I do have an SSD
[13:38] <fwereade> niemeyer, I think Aram and davecheney have a better developed understanding of it -- the stuff I've been working on has not generally been affected enough to get really worked up about when you're running a few tests at a time
[13:39] <fwereade> niemeyer, that said, it feels *much* nicer now than it ever did before, not sure is this is psychosomatic
[13:39] <fwereade> niemeyer, is anyone working on jujud btw?
[13:39] <niemeyer> fwereade: not that I know of
[13:40] <niemeyer> fwereade: I was about to ask what else has broken tests atm
[13:40] <fwereade> niemeyer, that seems to be the one remaining eyesore in the test output
[13:40] <niemeyer> fwereade: Anything obvious there?
[13:40] <fwereade> niemeyer, barely looked tbh
[13:40] <fwereade> niemeyer, focus has been elsewhere
[13:41] <fwereade> niemeyer, schema error in bootstrap_test is the first
[13:41] <fwereade> niemeyer, the remaining failures can probably be mostly attributed to collateral damage
[13:42] <niemeyer> fwereade: That rings a bell somehow
[13:57] <niemeyer> fwereade: Review sent
[13:57] <fwereade> niemeyer, cheers
[14:00] <niemeyer> Aram: ping
[14:00] <Aram> pong
[14:01] <niemeyer> Aram: Heya
[14:01] <niemeyer> Aram: How're things going there?
[14:02] <fwereade> niemeyer, the resyncing is to pick up Alive changes, without which Unit.Status will report "down" regardless of content
[14:02] <Aram> niemeyer: yesterday I've taken a swap day and today I'm working on the missing watchers and lifecycle in watchers. but a little bit later, ATM I'm running some rrands.
[14:02] <Aram> errand
[14:02] <Aram> s
[14:03] <niemeyer> fwereade: Sorry, I'm still slow today.. can you cover it a bit more piecemeal?
[14:03] <niemeyer> Aram: Okay, let's please talk once you're back
[14:04] <fwereade> niemeyer, ah, sorry, ok: I'm actually on crack, that's a different piece of code
[14:04] <fwereade> niemeyer, no reason for the resyncing you correctly complain about
[14:04] <niemeyer> fwereade: Is it just a matter of refreshing the unit itself?
[14:04] <fwereade> niemeyer, yeah, that is the sane and easy way
[14:05] <niemeyer> fwereade: Super.. I'm really just trying to understand these new patterns and see where/whether they fall short
[14:05] <fwereade> niemeyer, that was almost certainly an unremoved attempt at working around the weirdness in the entity watchers
[14:11] <rogpeppe> niemeyer, fwereade: just checking, do you think the provisioner is currently working in trunk?
[14:11] <fwereade> rogpeppe, STM to be, just deployed a unit
[14:12] <fwereade> rogpeppe, not from trunk, but I haven't touched the provisioner
[14:12] <rogpeppe> fwereade: hmm, my live tests aren't working
[14:12] <niemeyer> rogpeppe: It was yesterday
[14:12] <rogpeppe> niemeyer: the live test?
[14:12] <niemeyer> rogpeppe: The provisioner
[14:14] <rogpeppe> niemeyer: the provisioner test suite runs fine for me locally - just not live
[14:14] <niemeyer> rogpeppe: I've used the provisioner live yesterday
[14:15] <niemeyer> rogpeppe: Multiple times
[14:15] <rogpeppe> niemeyer: i've probably broken the live tests somehow then
[14:15] <niemeyer> rogpeppe: Or they are just not working after the state migration
[14:16] <rogpeppe> niemeyer: entirely possible. but it's not relying on watchers, so i *thought* it should work ok
[14:19] <rogpeppe> niemeyer: did juju status report you the correct agent version for the bootstrap machine?
[14:20] <niemeyer> rogpeppe: Yep
[14:21] <niemeyer> rogpeppe: I have a paste somewhere, hold on
[14:23] <niemeyer> rogpeppe: Sorry, can't find it
[14:23] <niemeyer> rogpeppe: I can easily fire a new env, though
[14:23] <rogpeppe> niemeyer: i think i saw it actually
[14:23] <rogpeppe> niemeyer: i'm trying again, but not in the test this time
[14:27] <niemeyer> fwereade: I think we'd benefit from adding back service.CharmURL, btw
[14:27] <niemeyer> fwereade: We can probably just revert it from somewhere in history
[14:28] <fwereade> niemeyer, I can only think of one place it's be a real boon... quite often we want the charm itself as well
[14:28] <niemeyer> fwereade: In hindsight, it was the SetCharmURL bit that was ill-conceived.. CharmURL is fine
[14:28] <fwereade> niemeyer, but yeah no actual objections
[14:28] <niemeyer> fwereade: Yeah, but often we grab the charm and throw it away.. we might grab the charm only if
[14:29] <fwereade> niemeyer, fair enough
[14:29] <niemeyer> fwereade: Not an issue by any means.. just sharing brain state :)
[14:36] <fwereade> niemeyer, ok, re MachineUnitsWatcher: what is the mechanism by which it guarantees it does not send events with the same unit both Added and Removed?
[14:37] <niemeyer> fwereade: I think there isn't any right now..
[14:38] <niemeyer> fwereade: I've pondered about the same thing in the context of the MachinesWatcher
[14:38] <fwereade> niemeyer, I guess that was true both before and after the loop change
[14:38] <niemeyer> fwereade: Right
[14:38] <niemeyer> fwereade: I've actually made a comment regarding this in the CL
[14:38] <niemeyer> fwereade: Dave suggested it wasn't an issue, but I'm not yet sure
[14:39] <niemeyer> fwereade: I'm tempted to drop them too
[14:39] <fwereade> niemeyer, it feels to me like it is
[14:39] <niemeyer> fwereade: If nothing else, we must handle the situation where it doesn't show up correctly
[14:39] <niemeyer> fwereade: Because it is just a perspective of timing
[14:39] <niemeyer> fwereade: If we made the same query moments afterwards, we'd see nothing
[14:40] <fwereade> niemeyer, yeah, indeed
[14:40] <fwereade> niemeyer, I guess it's best to use that style though, and fix the watchers so that mergeChanges always does the Right Thing
[14:41] <niemeyer> fwereade: +1
[14:41] <fwereade> niemeyer, the advantage of the double-loop style in RUW is that I think it *did* allow me to make useful guarantees of that nature
[14:41] <fwereade> niemeyer, anyway, shouldn't be too tricky :)
[14:41] <niemeyer> fwereade: I've been doing a few changes, btw: renaming mergeChanges to merge; getInitialEvent to initial, and pass the change itself onto initial; plus the w.out change I've mentioned
[14:42] <niemeyer> fwereade: Hmm
[14:42] <fwereade> niemeyer, those all sgtm
[14:42] <niemeyer> fwereade: I don't think so
[14:42] <niemeyer> fwereade: I mean, I don't think there were any guarantees before either
[14:42] <niemeyer> fwereade: Because events were aggregated regardless
[14:43] <fwereade> niemeyer, I *think* that because the loops in which I send and the loops in which I get scope changes are different, it all Just Works
[14:43] <fwereade> niemeyer, I don;t pick up a new scope event until I've sent the change derived from the first one
[14:43] <niemeyer> fwereade: I don't see why it makes a difference.. the code that may be executed or not is exactly the same, with the new convention or with the old one
[14:43] <fwereade> niemeyer, that change may have had any number of settings changes merged in but those are safe
[14:43] <niemeyer> fwereade: The second loop is exactly a copy with the first one with the send disabled
[14:43] <fwereade> niemeyer, not in RUW
[14:44] <niemeyer> fwereade: Which is exactly what we do in the new convention, but with less code
[14:44] <niemeyer> fwereade: Oh?
[14:44] <niemeyer> fwereade: /me looks again
[14:44] <fwereade> niemeyer, although it is just one more var to track really
[14:47] <niemeyer> fwereade: I see.. I think it's actually preferable to teach merge about how to handle the situation
[14:47] <niemeyer> fwereade: Otherwise it's unnecessarily buffering changes arbitrarily
[14:47] <fwereade> niemeyer, yeah, sounds sane
[14:48] <rogpeppe> niemeyer: ah, i think i *may* have discovered the reason why live tests are failing
[14:48] <niemeyer> rogpeppe: Sweet!
[14:48] <rogpeppe> niemeyer: just a hunch as yet
[14:49] <rogpeppe> niemeyer: but...
[14:49] <rogpeppe> niemeyer: what's the name of the public bucket containing the mongo binaries?
[14:49] <niemeyer> rogpeppe: juju-dist.. why does it matter?
[14:50] <rogpeppe> niemeyer: is it hard-coded?
[14:50] <niemeyer> rogpeppe: yes
[14:50] <rogpeppe> drat
[14:50] <niemeyer> rogpeppe: As of today
[14:50] <niemeyer> rogpeppe: It shouldn't be, but this avoids yet another refactoring without all tests green
[14:50] <rogpeppe> niemeyer: that's fine. hrmph.
[14:52] <niemeyer> fwereade: Follow up reviewed too
[14:52] <TheMue> niemeyer: test of removals in firewaller always showed an effect. the fw dislikes the service removal when it is stopped. stopping the service watcher returns an error then.
[14:52] <fwereade> niemeyer, ta
[14:53] <niemeyer> TheMue: More details please?
[14:54] <niemeyer> TheMue: If the firewaller is stopped, how can it dislike anything?
[14:54] <fwereade> niemeyer, ok, so *that* was the bit with a weird StartSync that I think is justified
[14:54] <niemeyer> fwereade: Yeah, I imagined it when reading
[14:54] <fwereade> niemeyer, Unit.Status does an alive check on the UA
[14:54] <niemeyer> fwereade: I'm just curious about how it unrolls into it
[14:54] <niemeyer> fwereade: Aha, ok.. is that all?
[14:55] <fwereade> niemeyer, Status returns "down" when the pinger is not there
[14:55] <fwereade> niemeyer, yeah, that's it
[14:55] <niemeyer> fwereade: So a suggestion: let's move the sync down to right before Status, and call Sync rather than StartSync
[14:55] <fwereade> niemeyer, ah, yeah, sounds sensible
[14:55] <fwereade> niemeyer, cheers
[14:56] <niemeyer> fwereade: Thanks!
[14:56] <niemeyer> TheMue?
[15:02] <TheMue> niemeyer: sorry, my wife called me ;)
[15:02] <TheMue> niemeyer: fw.Stop() is expected to return no error
[15:02] <TheMue> niemeyer: but if a service is removed it returns a service not found
[15:03] <TheMue> niemeyer: because during the stop all internal go routines are stopped, and there the service watchers
[15:03] <TheMue> niemeyer: and this stopping does state.Service(name) for the non-existing service
[15:03] <niemeyer> TheMue: This is a bug that should be fixed
[15:04] <TheMue> niemeyer: indeed
[15:04] <TheMue> niemeyer: so you had the right feeling about testing it
[15:05] <niemeyer> TheMue: Would you mind to review all fw call sites that grab objects, and consider the appropriate action when the respective entity isn't found?
[15:06] <niemeyer> TheMue: Happy to have that done in tiny branches that follow each other so that we have a good way to coordinate as we go
[15:06] <TheMue> niemeyer: could you please rephase "fw call sites"? thx.
[15:06] <niemeyer> TheMue: call site == a point in the code that calls something
[15:07] <TheMue> niemeyer: ah, yes. ok, will do.
[15:07] <niemeyer> TheMue: Once you have that first issue fixed, please push for review so we can talk a bit about it with more concrete logic
[15:08] <TheMue> niemeyer: ok
[15:26] <rogpeppe> niemeyer: hmm, live tests fail even though bootstrapping and deploying live work ok. looks like the provisioner never sees the new machine.
[15:27] <niemeyer> rogpeppe: How can the provisioner never see the new machine if it is the one firing off new machines
[15:28] <rogpeppe> niemeyer: it's not the one that creates the new Machine though
[15:28] <niemeyer> rogpeppe: Exactly.. and if it didn't see that machine, it wouldn't fire an instance fo rit
[15:29] <niemeyer> rogpeppe: Also, tests pass
[15:29] <rogpeppe> niemeyer: the live deploy tests are currently disabled
[15:29] <niemeyer> rogpeppe: Provisioner tests pass
[15:30] <rogpeppe> niemeyer: sure. i'm just saying what i see.
[15:30] <niemeyer> rogpeppe: Of course, and I'm just explaining that "provisioner never sees the new machine" can't be true on its own
[15:30] <niemeyer> rogpeppe: The builddb charm works
[15:30] <niemeyer> rogpeppe: Firing new machine
[15:30] <niemeyer> rogpeppe: With machiner, uniter, etc
[15:30] <rogpeppe> niemeyer: absolutely. i see that working too.
[15:30] <niemeyer> rogpeppe: That doesn't happen with a provisioner that never sees a new machine
[15:31] <rogpeppe> niemeyer: but my live test that used to work no longer works. so *something* is up.
[15:31] <rogpeppe> niemeyer: it might be the fact that the second machine is added before the provisioner comes up
[15:31] <niemeyer> rogpeppe: I'm sure..
[15:32] <niemeyer> rogpeppe: Again, tests pass..
[15:32] <niemeyer> rogpeppe: You seem to argue that the provisioner is completely broken.. I doubt it's as simple as that
[15:32] <rogpeppe> niemeyer: i'm not arguing that at all
[15:32] <rogpeppe> niemeyer: i'm saying that live tests fail that used to pass, that's all
[15:33] <rogpeppe> niemeyer: and i don't see the provisioner see the new machine, which seems to be a symptom
[15:33] <niemeyer> rogpeppe: Sorry, okay.. I don't know how to help then
[15:33] <rogpeppe> niemeyer: i'm not asking for help, just giving a status update
[15:33] <niemeyer> rogpeppe: That live tests are broken, ok :)
[15:34] <rogpeppe> niemeyer: yeah, it's weird
[15:35] <niemeyer> fwereade, rogpeppe: Regarding https://codereview.appspot.com/6571047, I really want to stop sending entities down the pipe at all
[15:36] <niemeyer> Everything is a lot simpler and more correct if we just sent the entity identification
[15:36] <rogpeppe> niemeyer: just send a change notification?
[15:36] <niemeyer> rogpeppe: Yeah, with the id/name
[15:36] <rogpeppe> niemeyer: i tend to agree.
[15:36] <niemeyer> The machines watcher was significantly simpler and more obvious to handle correctly on the other side with it
[15:37] <niemeyer> That said, I've been resisting suggesting this for now, just so we can get it all working as it used to
[15:37] <niemeyer> After we're comfortable again, I think we should change
[15:37] <fwereade> niemeyer, no strong feelings myself
[15:38] <niemeyer> This also avoids the spurious reads we have nowadays within the watcher itself
[15:38] <niemeyer> when the entity changes repeatedly without being consumed
[15:38] <niemeyer> and it also simplifies the Dead-handling logic..
[15:38] <niemeyer> Anyway, lunch time here
[15:39] <niemeyer> rogpeppe: If you're still struggling by the time I'm back, let's try to pair on it
[15:39] <rogpeppe> niemeyer: i think i might be getting somewhere now. just expressing the problem was helpful.
[15:39] <rogpeppe> niemeyer: aaargh!
[15:39] <rogpeppe> niemeyer: found it
[15:41] <rogpeppe> so frickin simple
[16:02] <platypusfriend> Greets
[16:03] <platypusfriend> I'd like to suggest that, on the https://juju.ubuntu.com/ page, under the "Try it for yourself" heading, the instructions to install Juju from the PPA don't work out of the box with Ubuntu 12.04.1
[16:04] <platypusfriend> gregkrsak@brewmaster:~$ add-apt-repository ppa:juju/pkgs
[16:04] <platypusfriend> The program 'add-apt-repository' is currently not installed.  You can install it by typing: sudo apt-get install python-software-properties
[16:04] <platypusfriend> (thanks!)
[16:18] <niemeyer> platypusfriend: kthxbye
[16:19] <niemeyer> rogpeppe: What was it?
[16:19] <rogpeppe> niemeyer: well, one problem was that i was assuming that the machine received from the machine watcher had no information content, so was reading agent tools from the original.
[16:20] <rogpeppe> niemeyer: but... that doesn't appear to have fixed the problem. we will see.
[16:20] <rogpeppe> niemeyer: am currently running a live test again
[16:24] <rogpeppe> niemeyer: hmm, looks like the machine watcher might not be sending an initial event.
[16:25] <niemeyer> rogpeppe: Indeed, I don't think it is
[16:25] <rogpeppe> niemeyer: i thought we tested for that
[16:27] <niemeyer> rogpeppe: I can fix that.. what else is using it?
[16:28] <niemeyer> Hmm
[16:28]  * rogpeppe checks
[16:28] <niemeyer> Apparently only used in tests
[16:28] <niemeyer> In two places only, one of them being the live tests
[16:28] <rogpeppe> niemeyer: that sounds about right
[16:29] <niemeyer> rogpeppe: I'm on it.. will take the chance to simplify the watcher according to the latest conventions
[16:29] <rogpeppe> niemeyer: sounds good
[16:30] <niemeyer> rogpeppe: Hah, curious
[16:30] <niemeyer> rogpeppe: If we send just the id, the initial event becomes a bit silly
[16:31] <rogpeppe> niemeyer: i'm not sure
[16:31] <rogpeppe> niemeyer: it's actually still useful, even though it carries no info content
[16:32] <rogpeppe> niemeyer: because it for a very simple pattern inside various watcher clients
[16:32] <rogpeppe> s/it/it makes/
[16:32] <niemeyer> rogpeppe: Cool, I'm not suggesting we change the convention right now either way, since we're in the middle of a huge transition
[16:32] <rogpeppe> niemeyer: +1
[16:32] <niemeyer> rogpeppe: Let's just observe the changed sites and see how they look once we do this
[16:32] <rogpeppe> niemeyer: sounds good
[16:33] <rogpeppe> niemeyer: my observation was that in quite a few places, the initial event is not acted upon any differently from a changed event, so it makes sense to handle them both in the same branch of the select statement.
[16:34] <niemeyer> rogpeppe: If that's generally the case for the entity watchers, +1
[16:34] <rogpeppe> niemeyer: so it's nice to guarantee that we get at least one event
[16:34] <niemeyer> rogpeppe: It perhaps also conveys useful information, although I'm not entirely sure:
[16:34] <niemeyer> rogpeppe: When we get the watch fired, we know we're subscribed
[16:35] <rogpeppe> niemeyer: interesting. i wonder if that's ever actually useful to know.
[16:35] <niemeyer> rogpeppe: Ah, no, sorry, it doesn't matter
[16:35] <niemeyer> rogpeppe: We provide the machine revno when watching, so there are no holes
[16:36] <rogpeppe> niemeyer: ah, so in that case the initial event *does* carry useful info
[16:36] <niemeyer> rogpeppe: ?
[16:36] <rogpeppe> niemeyer: oh, sorry, other way around
[16:36] <niemeyer> Yeah
[16:36] <rogpeppe> niemeyer: i thought you were suggesting the events would contain the revno as well as the id
[16:36] <rogpeppe> niemeyer: which may be a good idea, i suppose
[16:37] <niemeyer> rogpeppe: Nope.. not suggesting that yet, at least
[16:37] <rogpeppe> niemeyer: it kinda makes sense - you give a revno to watch from, then you're handed revnos as it changes.
[16:38] <niemeyer> rogpeppe: I'm slightly concerned that we might see code ignoring the initial watch thinking "Oh, but when the initial event arrives, the machine/unit/service hasn't yet changed"
[16:38] <niemeyer> rogpeppe: Which is not necessarily true.. let's watch out for that
[16:38] <rogpeppe> niemeyer: yeah
[16:38] <niemeyer> rogpeppe: The concept of revno is internal pretty much everywhere
[16:38] <niemeyer> rogpeppe: I'm not keen on exposing it, if possible
[16:39] <rogpeppe> niemeyer: fair enough.
[16:39] <rogpeppe> niemeyer: though doesn't the uniter make use of revnos?
[16:39] <niemeyer> rogpeppe: That where the "pretty much" comes from. The only exception is the settings version, because we have to persist them to disk.
[16:43] <rogpeppe> niemeyer: here's an idea for how an updated watcher API might work:
[16:43] <rogpeppe> http://paste.ubuntu.com/1226959/
[16:43] <rogpeppe> niemeyer: i.e. each entity watcher embeds the entity that it's watching
[16:44] <rogpeppe> niemeyer: oops, with one crucial addition: http://paste.ubuntu.com/1226963/
[16:45] <niemeyer> rogpeppe: I don't understand what this is solving
[16:45] <rogpeppe> niemeyer: it's solving, for me at any rate, the fact that i want to watch the same kind of thing on two different kinds of entity
[16:46] <rogpeppe> niemeyer: perhaps that's not a problem anywhere else though, i guess
[16:46] <rogpeppe> niemeyer: it seems kinda logical to tie the watcher together with the thing it's watching.
[16:47] <niemeyer> rogpeppe: What is the MachineUnitsWatcher going to be tied with?
[16:47] <rogpeppe> niemeyer: is MachineUnitsWatcher an entity watcher?
[16:48] <rogpeppe> niemeyer: i'm only thinking of this for things where currently we just send an instance of the object down the channel
[16:48] <niemeyer> rogpeppe: Sorry, seems like a big red-herring
[16:48] <rogpeppe> niemeyer: ok fair enough
[16:48] <rogpeppe> niemeyer: i wondered if UnitWatcher and MachineWatcher could actually be implemented by the same type, and that led me to think in this direction
[16:51] <rogpeppe> niemeyer: looking at TestWatchMachine, it looks as if it *does* test for an initial event
[16:52] <niemeyer> rogpeppe: Please leave that with me.. I'll send a branch in a moment
[16:52] <rogpeppe> niemeyer: ok
[17:08] <rogpeppe> niemeyer: i'm off now. might be able to have a look back in a bit, otherwise see ya tomorrow!
[17:13] <niemeyer> rogpeppe: have a good time there
[17:19] <niemeyer> rogpeppe: Do live tests work, btw?
[17:25] <rogpeppe> niemeyer: no, i'm waiting for your machine watcher CL
[17:25] <niemeyer> rogpeppe: Well.. this will just add an extra event
[17:25] <rogpeppe> niemeyer: i *think* that's what's stopping them passing
[17:25] <rogpeppe> niemeyer: that will be good enough
[17:26] <rogpeppe> niemeyer: currently it blocks waiting for that event and never gets it
[17:26] <niemeyer> rogpeppe: It's a spurious event.. should be trivial to just not wait for it
[17:27] <niemeyer> Either way, too late.. the watcher is ready and you're off.. I'll have a look at it later
[17:27] <rogpeppe> niemeyer: i've actually got another hour or so now
[17:27] <niemeyer> rogpeppe: Oh, okay, let me push the watcher then
[17:31] <niemeyer> rogpeppe: I don't think it's the initial event here, btw
[17:31] <niemeyer> rogpeppe: Have you changed the test so it calls Refresh?
[17:32] <rogpeppe> niemeyer: ok. i changed the test so it used the Machine that it receives on the channel
[17:32] <niemeyer> rogpeppe: That won't work.. the channel contains an id now..
[17:32] <niemeyer> rogpeppe: Just Refresh the machine
[17:32] <rogpeppe> niemeyer: ok, i'll change as needed when i merge
[17:32] <niemeyer> rogpeppe: Ok, I won't touch it
[17:33] <rogpeppe> niemeyer: sounds good
[17:33] <niemeyer> rogpeppe: You'll see why the original tests were working, btw
[17:33] <rogpeppe> niemeyer: cool
[17:33] <niemeyer> Committing & proposing
[17:33] <rogpeppe> niemeyer: i'm interested - they looked plausible!
[17:34] <niemeyer> rogpeppe: Agreed.  Two bugs coalesced for it to work.
[17:37] <niemeyer> rogpeppe:  https://codereview.appspot.com/6564049
[17:37] <rogpeppe> *click*
[17:44] <rogpeppe> niemeyer: so the test was ok, then, and the problem was that the txn-revno was out of date, so it sent an event anyway?
[17:44] <rogpeppe> niemeyer: i'm not sure i see the other bug you refer to though
[17:44] <niemeyer> rogpeppe: Right
[17:45] <niemeyer> rogpeppe: Well, the other bug is the fact it didn't send
[17:45] <niemeyer> rogpeppe: The two bugs, together, make the test pass
[17:46] <rogpeppe> niemeyer: the watcher didn't send?
[17:46] <niemeyer> rogpeppe: The initial event.. :-)
[17:46] <rogpeppe> niemeyer: ah of course!
[17:46] <rogpeppe> niemeyer: it all becomes blindingly obvious
[17:47] <rogpeppe> niemeyer: it would be nice if we could have a test that would have failed with the previous bugs.
[17:48] <niemeyer> rogpeppe: The current test fails if we fix the revno issue
[17:49] <niemeyer> rogpeppe: But it's not easy to test the fact the revno was wrong, precisely because it causes an initial event to be sent, which is the behavior we want
[17:49] <rogpeppe> niemeyer: i wondered about getting a machine from a different source than AddMachine
[17:49] <niemeyer> rogpeppe: The bug is in AddMachine
[17:49] <niemeyer> was
[17:49] <rogpeppe> niemeyer: given that there are several Machine constructors that can be bad in different ways
[17:49] <rogpeppe> niemeyer: indeed.
[17:50] <niemeyer> rogpeppe: Nope.. they are all ok, because they grab the db value
[17:50] <rogpeppe> niemeyer: if the original hadn't used AddMachine, we'd have found the bug
[17:50] <niemeyer> rogpeppe: AddMachine is special because it uses the memory value
[17:51] <rogpeppe> niemeyer: yeah, i'm just saying. maybe there should be a test that AddMachine returns exactly the same values as Machine. but that's hard to do externally.
[17:54] <niemeyer> rogpeppe: We could abuse DeepEquals for that.. it's generally a bad idea, but we can have a single trivial spot doing that for the entities, at least so we consciously know when we break that rule.
[17:58] <rogpeppe> niemeyer: i wondered about that
[17:58] <niemeyer> rogpeppe: I'll add a test
[18:05] <rogpeppe> niemeyer: one thought: is it really worth sending the machine id down the channel. we're never going to actually use it AFAICS. why not chan struct{} ?
[18:09] <niemeyer> rogpeppe: Happy to take it off while we don't care
[18:19] <Aram> niemeyer: what is it that you wanted to talk about?
[18:20] <rogpeppe> niemeyer: it would make me happy. then MachineWatcher and UnitWatcher can implement the same interface.
[18:20] <niemeyer> Aram: Isn't it quite late for you already?  If you're taking the day off, we can talk tomorrow..
[18:21] <niemeyer> rogpeppe: Cool, I'll drop it before merging
[18:21] <Aram> niemeyer: it's late but it's fine, if we talk today I can work on it tomorrow in the morning, when you'll not be here.
[18:22] <rogpeppe> niemeyer: in fact, both Machine.Watch and Unit.Watch could return the same interface type. then Machine and Unit are directly compatible for watching.
[18:23] <rogpeppe> niemeyer: the MachineWatcher type could be unexported.
[18:23] <niemeyer> Aram: I don't actually have much to talk about, I think.. I was going to bring up the auth + SSL stuff, but we don't even have the machine units watcher done yet, so that's probably the first thing to work on
[18:23] <niemeyer> Aram: I think you've seen as well discussion about the latest conventions
[18:24] <Aram> niemeyer: aah, yes. so we continue to do full document watchers or just ids?
[18:24] <niemeyer> Aram: Regarding w.out, nil, dropping the two loops, etc
[18:24] <Aram> I've seen that
[18:24] <Aram> very nice way of dropping the extra loop
[18:24] <niemeyer> Aram: Just ids, and with liveness
[18:24] <niemeyer> Aram: Similar to how the current MachinesWatcher is working
[18:25] <Aram> ok
[18:25] <niemeyer> Aram: Dead+Alive rather than added/removed
[18:25] <Aram> yeah
[18:25] <niemeyer> rogpeppe: Yeah, we can do a lot, but let's hold off a bit.. this is already going quite far
[18:26] <rogpeppe> niemeyer: cool. agreed.
[18:26] <niemeyer> I'm actually going to split this equivalence stuff in its own branch
[18:27] <rogpeppe> niemeyer: that sounds good too
[18:27] <niemeyer> I had to do changes for the charm equivalence which is unrelated to the original goal
[18:33] <niemeyer> Come on LP
[18:38] <niemeyer> rogpeppe: It's in
[18:38] <rogpeppe> niemeyer: i saw. thanks!
[18:39] <niemeyer> rogpeppe: np, will push the follow up for review onw
[18:52] <niemeyer> https://codereview.appspot.com/6566050
[18:56] <niemeyer> rogpeppe: ^
[18:56]  * rogpeppe looks
[18:58] <rogpeppe> niemeyer: LGTM
[18:59] <niemeyer> rogpeppe: Thanks!
[19:15] <rogpeppe> niemeyer: ok, i've updated the live tests for the new interface. now running them live - we'll see what happens.
[19:15] <niemeyer> rogpeppe: Fingers crossed!
[19:15] <rogpeppe> niemeyer: i've got a bus to catch in 15 minutes so if this doesn't work, it'll have to be tomorrow
[19:16]  * rogpeppe wants a connection with faster upload speed
[19:16] <niemeyer> rogpeppe: +1
[19:17] <Aram> yeah, in Romania I have 100Mbps upload for $9/month.
[19:17] <Aram> here in Austria I pay 50€ for only 10Mbps.
[19:18] <Aram> that's 71 times more expensive upload.
[19:19] <rogpeppe> Aram: here i have no option for faster upload. it's crappy copper and they've no plans to upgrade.
[19:19] <Aram> yeah, in Romania I was lucky to have fiber.
[19:20] <rogpeppe> still, it only took 3:10 to upload the tools that time
[19:20] <Aram> at some point they forgot to set speed limits for me and I have 1Gbps download/upload for months :-).
[19:21] <rogpeppe> i should do what dave does and run the live tests on ec2 itself
[19:22] <rogpeppe> gotta go, or will miss bus
[19:23] <rogpeppe> tests still waiting mongod
[19:23] <rogpeppe> niemeyer, Aram: have fun
[19:23] <Aram> cheers.
[19:31] <niemeyer> I wonder what "tests still waiting mongod" means.. It's pretty much instantaneous for me nowadays
[20:01] <hazmat> out of curiosity how big are the tools?
[20:05] <niemeyer> hazmat: Each binary is about 5M stripped
[20:06] <hazmat> niemeyer, and what's the size with symbol?
[20:06] <niemeyer> hazmat: 7MB or so
[20:06] <hazmat> niemeyer, cool, thanks
[20:06] <niemeyer> hazmat: np
[21:23] <niemeyer> Stepping out for a while.. back soon
[22:56] <fwereade> niemeyer, discussion in https://codereview.appspot.com/6567044/ ; trivial in https://codereview.appspot.com/6570050 ; it would be awesome if you could take a look at the first, in particular, if you're around at any stage
[22:57] <niemeyer> fwereade: I'm here
[22:57] <niemeyer> fwereade: Looking
[22:57] <niemeyer> fwereade: Hmm
[22:57] <niemeyer> fwereade: I've already replied to the first a while ago
[22:58] <fwereade> niemeyer, ah, sorry, missed that
[22:58] <niemeyer> fwereade: np
[22:59] <niemeyer> fwereade: LGTM on second
[22:59] <fwereade> niemeyer, hmm, ok, I see; LGTM re out = nil
[22:59] <niemeyer> fwereade: Super
[23:00] <fwereade> niemeyer, LGTM stands with the change then?
[23:00] <niemeyer> fwereade: I'll have some food while another round of live tests run
[23:00] <niemeyer> fwereade: Yep!
[23:00] <fwereade> niemeyer, sweet, the tests will look much nicer once the uniter's in
[23:00] <niemeyer> fwereade: Btw, I'd like to bring the id on machine watcher bakc
[23:01] <fwereade> niemeyer, sorry, context
[23:01] <niemeyer> fwereade: I think it was a mistake to remove it.. the first time I've tried to fix some code, it was using the return :)
[23:01] <niemeyer> fwereade: Ah, sorry
[23:01] <niemeyer> fwereade: We've dropped the result this afternoon, so it returns struct{}
[23:01] <niemeyer> fwereade: It was a candidate change, but it was a mistake.. first code I went to fix in the live tests, it was using the id of the result meaningfully
[23:02] <niemeyer> fwereade: I'll send a branch so we can bring it back.. I don't want to hack the tests more at this point
[23:02] <fwereade> niemeyer, cool, I should sleep soon but I'll be around for a few mins at least
[23:04] <fwereade> niemeyer, I'll just treat those failures as deliberate/expected
[23:05] <niemeyer> fwereade: Which failures?
[23:05] <fwereade> niemeyer
[23:05] <fwereade> cmd/jujud/provisioning_test.go:69: undefined: state
[23:05] <fwereade> # launchpad.net/juju-core/environs/jujutest
[23:05] <fwereade> environs/jujutest/livetests.go:262: m.AgentTools undefined (type struct {} has no field or method AgentTools)
[23:05] <fwereade> # launchpad.net/juju-core/environs/jujutest
[23:05] <fwereade> environs/jujutest/livetests.go:262: m.AgentTools undefined (type struct {} has no field or method AgentTools)
[23:06] <fwereade> niemeyer, I was assuming that jujud was broken deliberately to prevent ugly panics dirtying up the test log
[23:06] <niemeyer> fwereade: Yeah, this is broken and is expected.. I'm working to fix all of this
[23:06] <fwereade> niemeyer, cool
[23:06] <fwereade> niemeyer, I shall not allow them to trouble me
[23:06] <niemeyer> fwereade: https://codereview.appspot.com/6571053
[23:06] <niemeyer> fwereade: Hehe :)
[23:07] <fwereade> niemeyer, LGTM
[23:08] <niemeyer> fwereade: Cheers
[23:09] <niemeyer> fwereade: I have quite a few nice trivials on the pipeline, but I'll try to catch up with Dave after dinner
[23:09] <niemeyer> fwereade: Thanks, and have a nice sleep there
[23:09] <fwereade> niemeyer, cool, perhaps gently encourage him to fix config-get, because I think that will give us more charms to play with right away
[23:10] <niemeyer> fwereade: I think he's on it, but I'll talk to him
[23:10] <fwereade> niemeyer, tyvm
[23:10] <niemeyer> fwereade: np
[23:10] <niemeyer> Dinner time.. biab
[23:10] <fwereade> niemeyer, enjoy


[04:46] <Samuray> hi
[17:19] <SpamapS> jamespage: Are you guys in Lexington this week?
[17:22] <jamespage> SpamapS, yep
[17:23] <SpamapS> jamespage: great. I wonder if I can squeeze in some boot testing into what you guys are doing. :)
[19:03] <jamespage> SpamapS: probably not this week - what was it that you had in mind
[19:03] <jamespage> patrickmw ^^ - might fit with you boot speed stuff (maybe)
[19:07] <SpamapS> jamespage: definitely might fit into that. I want to be able to boot the base system, shut it down, then boot it back up.
[19:07] <SpamapS> jamespage: after that, I'd like to be able to boot it, install any packages, then reboot it.
[19:08] <SpamapS> jamespage: totally willing to do all the leg work myself, but I'd like for it to be a part of the testing framework so I'm not on my own secret island. :)
[20:43] <patrickmw> SpamapS, I essentially have the scripts that drive Orchestra to boot up and system, generate the boot results (using the bootchart package), and then push the results that look like this: http://reports.qa.ubuntu.com/reports/boot-speed/dell-inspiron-1536/index.html
[20:44] <patrickmw> SpamapS, altering them to work with server won't be an issue
[20:50] <SpamapS> patrickmw: cool, so thats most of what I need anyway.. Once it boots, I want to reboot it and check /var/log/boot.log and /var/log/dmesg for some things.. but that should be fairly easy.
[21:12] <patrickmw> SpamapS, I dmesg gets pulled now.  I'm in Lexington this week, but when I'm home I will commit the scripts (I don't have them on this laptop)
[21:16] <GrueMaster> patrickmw: And you don't have remote access tunneling through ipv6 setup at home?  Tisk.  :P