[15:47] <Odd_Bloke> Heads up: GitHub is having availability issues: https://www.githubstatus.com/
[17:55] <Odd_Bloke> powersj: blackboxsw: So do we have a release process that I should be following?  (I don't _think_ I've cut an upstream release before.)
[17:55] <blackboxsw> Odd_Bloke: I added you to the trello board
[17:56] <blackboxsw> https://trello.com/b/obFWGwZY/upstream-cloud-init-201
[17:56] <blackboxsw> I copied it yesterday from the template board https://trello.com/b/QQYFXpsA/template-sru-cloud-init-xy and deleted any "SRU" cards
[17:56] <Odd_Bloke> Status update on 20.1: we've tested the change that we were worried about and it does not appear to be causing issues
[17:56] <Odd_Bloke> blackboxsw: Cool, thanks!
[17:56] <Odd_Bloke> rharper: Where are we on the IMDS change you wanted to land for 20.1?
[17:57] <rharper> well, it's not a one liner =/
[17:57] <rharper> writing a unittest (augmenting one to ensure we do the redaction)
[17:57] <blackboxsw> Odd_Bloke: and the SRU process for that trello board template came originally from https://github.com/CanonicalLtd/uss-tableflip/blob/master/doc/upstream_release_process.md
[17:57] <Odd_Bloke> rharper: OK, but in your view it's close enough that it's worth waiting for?
[17:58] <rharper> it should be; but since it's not a one liner; I don't suppose we should wait
[18:08] <Odd_Bloke> rharper: I'm going to go grab lunch, so you have a bit of time to get something up for review. :)
[19:15] <rharper> Odd_Bloke: https://github.com/canonical/cloud-init/pull/219
[19:21] <blackboxsw> minor volley back rharper
[19:33] <blackboxsw> I might have to re-review the token interaction again. jussec
[19:36] <blackboxsw> yeah X-aws-ec2-metadata-token-ttl-seconds header is just a seconds value, non-secret. so no need to redact
[19:37] <rharper> blackboxsw: true but we don't need the value logged do we?
[19:40] <rharper> I've replied; having the value won't aide in debugging; and if we lower it, we just end up obtaining a new token more frequently;
[19:41] <blackboxsw> I guess we would if at some point we reduce the hardcoded AWS_TOKEN_TTL_SECONDS which afair I thought we would intend at at some point.
[19:42] <blackboxsw> fair rharper I concede it's not a big deal, just recognizing that we are redacting things that aren't necessarily sensitive, by that measure where do we draw the line.
[19:57] <blackboxsw> I have a couple more nits. we're doing a lot more work in that function than we need with every retry.
[19:58] <blackboxsw> will finish my review in ~30. have to afk for a bit
[20:11] <Odd_Bloke> rharper: blackboxsw: OK, that lunch break ended up longer than anticipated; I see that PR is Approved so I'll wait for it before cutting the release.
[20:11] <blackboxsw> back as well now. a minor set of review comments to followup with
[20:12] <blackboxsw> throwing together a paste to see what you guys think
[20:28] <rharper> blackboxsw: on my errand I was thinking I'd like to see if I can just copy the redacted header value instead of all headers;
[20:30] <blackboxsw> Odd_Bloke: rharper here's what I was thinking https://paste.ubuntu.com/p/NXXXyMZKFH/ . I think we should be hoisting the headers_cb calculation out of the retry for loop as those headers should not change across calls to the same url.
[20:30] <rharper> blackboxsw: well, that's a separate fixup  no ?
[20:31] <rharper> blackboxsw: an alternative approach I thought about was having the headers_cb return the headers and a list of keys to be redacted
[20:31] <blackboxsw> as it is currently in the function, we are re-calculating and copying the dict of headers on each run. with rharper's change it gets more costly as we are now extracting each header on each retry and comparing it to the redacted list on every iteration of the liip
[20:31] <blackboxsw> loop
[20:31] <rharper> and I guess we don't pass back to headers_cb that we're retrying it just gets called a second time
[20:31] <blackboxsw> rharper: that'd work, but it's also doing that work on every single retry against a url.
[20:32] <rharper> so even if headers_cb wanted to vary based on retry it doesn't know
[20:32] <blackboxsw> right, it just gets called again and again
[20:32] <blackboxsw> soliciting the same response
[20:32] <rharper> well, I like you suggestion but it seems like an optimization
[20:32] <blackboxsw> rharper: it does seem like an optimization.
[20:32] <rharper> and if I push this copy down to only if the key is in redacted list; we're copying a very small amount of data
[20:33] <blackboxsw> rharper: well yes, we are copying a small amount and settting up a pointer to every key in req_args.
[20:36] <rharper> blackboxsw: for now, the only time that it's hitting is if we do a retry anyhow; the happy path never does it more than once;  but I generally like it;
[20:36] <blackboxsw> right, I think the optimization can wait. I'll add the paste there for reference in case we want to go that route in the future.
[20:38] <Odd_Bloke> I'm not really following here, but dict operations are generally _very_ optimised in Python (because it's dicts all the way down, internally :p) so I would be surprised if this is a substantial slowdown.  Which is to say: I think we can land as-is and then follow with the optimisation.
[20:39] <rharper> Odd_Bloke: I'm pushing up two changes in just a second, one blackboxsw wanted the string moved to module variable; and the other is to push the copy down to the matched keys rather than copying all headers even if we don't have anything to redact
[20:40] <blackboxsw> yep I've pasted that comment to the PR and set approved from my end
[20:41] <Odd_Bloke> rharper: OK, nice.
[20:56] <powersj> Odd_Bloke, how's 20.1?
[20:59] <Odd_Bloke> powersj: We're landing this IMDS change, then cutting it.
[21:00] <Odd_Bloke> blackboxsw: Your Approved is from before rharper's latest push; are you still +1?
[21:00] <blackboxsw> I'm still  +1 Odd_Bloke
[21:00] <blackboxsw> yeah looks good
[21:01] <Odd_Bloke> Cool, merged.
[21:01] <blackboxsw> heh ohh well.
[21:02] <blackboxsw> we didn't really need to deepcopy the entry and then reset the value to REDACTED
[21:05] <blackboxsw> Odd_Bloke: rharper not needed for 20.1, but here's a low-hanging-fruit review. sorry I just missed that
[21:05] <blackboxsw> https://github.com/canonical/cloud-init/pull/220
[21:06] <blackboxsw> hrm strike that.
[21:06] <blackboxsw> shame on me
[21:06] <rharper> hehe
[21:06] <blackboxsw> yes we did, otherwise we'd overwrite the actual headers
[21:06] <rharper> it would have had this done a lot faster if I knew I was modifying my req_args
[21:06] <rharper> and then we never pass tests... and the execption callback runs *forever*
[21:06] <rharper> it's inifinite
[21:06] <rharper> so I sat there... for some tim e
[21:06] <blackboxsw> heh
[21:06] <rharper> before realizing what was happening
[21:06] <blackboxsw> yeah I was wondering the same for me. oopsie
[21:07] <blackboxsw> closing that PR
[21:07] <rharper> even after I realized that headers were a key *in* all of the args
[21:13] <Odd_Bloke> powersj: rharper: blackboxsw: So I just opened up the card for 20.1 (I used shortcuts to assign and move it earlier), and it calls for us to land https://github.com/canonical/cloud-init/pull/54 before cutting.
[21:13] <Odd_Bloke> What do we think?
[21:14] <powersj> that needs to come after
[21:14] <powersj> I don't want to land that right before focal goes out
[21:14] <Odd_Bloke> After what?
[21:14] <rharper> well
[21:14] <rharper> it's non master
[21:14] <rharper> it's on the xenial branch only
[21:14] <powersj> oh right
[21:14] <blackboxsw> rharper: hrm. gonna need a second glance at that..... we are in the middle of the for loop where we are setting filtered_reg_args[k] = value... if we aren't copying over filtered_req_args['headers'] = req_args[k], then we don't have to deepcopy I don't think.   Again, doesn't matter for 20.1, but I do think again we can drop that
[21:14] <powersj> in which case, not an issue for 20.1, it is for the SRU
[21:15] <Odd_Bloke> OK, so that's an SRU thing, cool.
[21:15] <rharper> blackboxsw: I was thinking that was correct; it's just a single dict entry;  it *could* have a value of a dict; but I think we can reason that header values cannot be dict
[21:16] <rharper> blackboxsw: do we know if we pay a heavier cost calling deepcopy() when we don't need it with such a small dict ?
[21:16]  * rharper smells a timeit coming on
[21:16] <blackboxsw> rharper: ahh your branch didn't have my local changes. I did the if k != 'headers': filtered_req_args[k] = v     else: filtered_req_args[k] = REDACTED
[21:17] <blackboxsw> I wasn't setting filtered_req_args[k] = v   if we were dealing with a 'headers' key
[21:17] <blackboxsw> rharper: +1 on headers values also being a dict and being concerned about not blowing that away
[21:18] <blackboxsw> but, I think our logic initially path setting that filtered_req_args[k] = v  and then dropping into if k == 'headers' to redact is what causes the need for the copy.
[21:18] <blackboxsw> if we didn't set that in the first place, we wouldn't have to copy and overwrite
[21:19] <blackboxsw> anyway, not for 20.1 but I'll reopen the appropriate cleanup for us to look at for later
[21:22] <blackboxsw> and yes might as well add a timeit to the PR once up :)
[21:25] <rharper> blackboxsw: ok, I can see a way without copy
[21:25] <rharper> https://paste.ubuntu.com/p/2XQF6CPntK/
[21:26] <rharper> however, I wonder if it's really faster than copying the headers dict
[21:26] <blackboxsw> https://github.com/canonical/cloud-init/pull/220
[21:26] <rharper> for small sized dict;
[21:27] <blackboxsw> https://github.com/canonical/cloud-init/pull/221
[21:27] <blackboxsw> yeah not much performance improvement I don't think
[21:28] <blackboxsw> yeah and now we've spent more time on this than we'll ever likely get back in performance runs ;)
[21:28] <blackboxsw> sorry about the rathole there
[21:29] <blackboxsw> especially given that our only case of redacting is a simple string value and not a large dict of values
[22:19] <johnsonshi> According to https://cloudinit.readthedocs.io/en/latest/topics/modules.html#mounts , "Swap files can be configured by setting the path to the swap file to create with filename". The docs imply that cloud-init creates a swap file at the specified filename if using the swap module.
[22:20] <Odd_Bloke> blackboxsw: So I'm looking at the release process, and it assumes that I can push the commit I've created locally to master.  We, of course, can't do that with branch protection.  We can either revise the docs to document disabling branch protection temporarily (probably not?), or we can update things so that the tagging of the release happens _after_ merge (via GH button) into master.  However, I think
[22:20] <Odd_Bloke> that will cause CI to fail, because it will look for a 20.1 tag (to determine versions) and fail.
[22:20] <johnsonshi> My swap settings contain:
[22:20] <johnsonshi> ...
[22:20] <johnsonshi> swap:
[22:20] <johnsonshi>    filename: /mnt/resource/swapfile
[22:20] <johnsonshi>    ...
[22:20] <johnsonshi> ...
[22:20] <johnsonshi> When the machine is provisioned, cloud-init fails to create the swapfile. The cloud-init.log file shows that the "swapon -a" command failed. When I ssh into the machine and try running "swapon -a" myself, it says that "swapon: stat failed /mnt/resource/swapfile: No such file or directory".
[22:20] <johnsonshi> However, I can confirm that the /mnt/resource path exists and is accessible, and I am able to read/write files within /mnt/resource. I can also see that cloud-init added the swap entry to /etc/fstab.
[22:20] <johnsonshi> When I look through the cloud-init code, I can see cloud-init adds the swap entry to /etc/fstab if it exists, then runs "swapon -a" without creating the swapfile.
[22:20] <johnsonshi> Is cloud-init supposed to create the swapfile by if it is instructed to do so (the docs seem to imply that)?
[22:22] <Odd_Bloke> johnsonshi: I believe you need to specify "size" for the creation to occur.
[22:22] <blackboxsw> Odd_Bloke: doc reference?
[22:22] <Odd_Bloke> blackboxsw: https://github.com/CanonicalLtd/uss-tableflip/blob/master/doc/upstream_release_process.md
[22:22] <blackboxsw> thnaks
[22:23] <Odd_Bloke> blackboxsw: Specifically "Note: you need to push the tag or c-i will fail in check version."
[22:23] <blackboxsw> Odd_Bloke: we have the ability to git push tags
[22:23] <blackboxsw> right?
[22:23] <Odd_Bloke> blackboxsw: But we don't have the commit to tag until after merge.
[22:23] <Odd_Bloke> It never exists on my system until then.
[22:24] <Odd_Bloke> Which means the 20.1 tag I have pushed (until I realised the conflict) points at the commit which will be squashed into master (and then discarded, of course).
[22:24] <blackboxsw> ahh right, but we will merge you MP into master once you've bumped version to 20.1 right
[22:24] <Odd_Bloke> Right.
[22:25] <johnsonshi> swap:
[22:25] <johnsonshi>    filename: /mnt/resource/swapfile
[22:25] <johnsonshi>    size:<PHONE_NUMBER>
[22:25] <johnsonshi> I tried it again and the swapfile still isn't being created.
[22:25] <Odd_Bloke> johnsonshi: Could you file a bug with `cloud-init collect-logs` attached to it and drop the link to it back in here?
[22:25] <johnsonshi> cc_mounts.py does not seem to have code that creates a swapfile?
[22:25] <blackboxsw> Odd_Bloke: ok, hrm, but your branch did pass ci https://github.com/canonical/cloud-init/pull/222
[22:25] <Odd_Bloke> blackboxsw: Right, I pushed the tag.
[22:25]  * blackboxsw checks it out again
[22:25] <Odd_Bloke> As instructed.
[22:26] <blackboxsw> with branch restrictions reduced?
[22:26] <Odd_Bloke> But that tag points at a commit which will never be in master.
[22:26] <blackboxsw> or tag push worked
[22:26] <Odd_Bloke> Tag push is fine.
[22:26] <blackboxsw> ahh ok. gotcha
[22:26] <johnsonshi> Odd_Bloke: Sure thing. So missing swapfile creation is a bug due to the code not being in cloud-init?
[22:26] <blackboxsw> not sure if that's a broken process that should be fixes. stale tags pointing to nowhere for previous releases
[22:26] <Odd_Bloke> johnsonshi: What version of cloud-init are you using?
[22:27] <johnsonshi> Odd_Bloke: The distro I am using it with (RHEL 7.7) comes with cloud-init 18.5.
[22:28] <Odd_Bloke> Yeah, that should definitely have swap support, I don't know why you wouldn't be seeing that in cc_mounts.
[22:28] <Odd_Bloke> There have been changes since 18.4, however, so you might be hitting an existing bug.
[22:28] <Odd_Bloke> *18.5
[22:28] <Odd_Bloke> johnsonshi: Are you able to try again with 19.4 somehow?
[22:30] <Odd_Bloke> blackboxsw: It looks like I fixed up the 19.4 tag on the day it happened.
[22:30] <Odd_Bloke> blackboxsw: (And 19.3 predated the GH move, I think?)
[22:30] <blackboxsw>  johnsonshi: any of the copr dev builds work for you? https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/
[22:31] <blackboxsw> Odd_Bloke:  you are right . ok so, branch restrictions causing some issues then with upstream releases.
[22:31] <johnsonshi> Odd_Bloke: wait a sec
[22:31] <johnsonshi> Yeah I'll try out 19.4
[22:31] <Odd_Bloke> Thanks!
[22:32] <Odd_Bloke> johnsonshi: Actually, if you're able, there have been further changes since 19.4, so a test of a daily build would be best.  (That cloud-init-dev link has those, so you're already doing that if that's how you're going to do it. :)
[22:33] <johnsonshi> Thanks!
[22:33] <Odd_Bloke> blackboxsw: I'm thinking that retagging after is probably easier in the short term.
[22:34] <Odd_Bloke> But I think I'm going to remove the tag and re-run CI, to see if we actually need it before at all.
[22:34] <Odd_Bloke> Just in case that the move to Travis has happened to obviate that need.
[22:35] <blackboxsw> +1 Odd_Bloke
[22:36] <rharper> johnsonshi: from I can tell, the additional paths to your file are the issue;  a work around would be to either use file in an existing directory; or use bootcmd to run an mkdir -p
[22:36] <rharper> and the fix is for cloud-init to use util.ensure_file() on the swapfile path
[22:37] <Odd_Bloke> powersj: FYI, we've run into some release tooling issues with the migration to GitHub.  I'm currently pursuing getting it right this time, so we don't have to revisit it, because I'm not aware of any pressing need for 20.1 to be out the door.  Am I missing some info, or are you happy for me to proceed along this path?
[22:38] <powersj> Odd_Bloke, can you estimate how long this delay would take?
[22:39] <Odd_Bloke> powersj: Tomorrow instead of tonight.
[22:39] <powersj> that's fine
[22:59] <johnsonshi> Odd_Bloke: Hmmm this is weird. The logs show that the swapfile creation command succeeds (for RHEL 7.7 cloud-init 18.4).
[22:59] <johnsonshi> 2020-02-19 22:23:35,338 - cc_mounts.py[DEBUG]: swap file /mnt/resource/swapfile exists, but not in /proc/swaps
[22:59] <johnsonshi> 2020-02-19 22:23:35,338 - util.py[DEBUG]: Running command ['sh', '-c', 'rm -f "$1" && umask 0066 && { fallocate -l "${2}M" "$1" ||  dd if=/dev/zero "of=$1" bs=1M "count=$2"; } && mkswap "$1" || { r=$?; rm -f "$1"; exit $r; }', 'setup_swap', '/mnt/resource/swapfile', '2048'] with allowed return codes [0] (shell=False, capture=True)
[22:59] <johnsonshi> 2020-02-19 22:23:35,400 - util.py[DEBUG]: creating swap file '/mnt/resource/swapfile' of 2048MB took 0.062 seconds
[23:00] <johnsonshi> After rebooting (cloud-init clean -lr) as well as a fresh provision of another machine, the file still was not being created (despite cloud-init.log saying that it is created). When I ssh'ed into the machine and ran the command above, the command succeeded and the swapfile was created.
[23:00] <johnsonshi> I just asked some of my teammates (I am in the Azure Linux provisioning team), and they said that we'd have to use this  specific version of cloud-init due to a host of reasons.
[23:02] <Odd_Bloke> johnsonshi: What FS is /mnt/resource?
[23:03] <Odd_Bloke> johnsonshi: And is /mnt/resource ephemeral?  I think cloud-init is going to assume that if it creates a swapfile, it stays there.
[23:04] <johnsonshi> Odd_Bloke: ext4. Yeah it is an ephemeral disk.
[23:04] <johnsonshi> Odd_Bloke: Oddly enough, when I included a runcmd directive, the swapfile was created.
[23:05] <Odd_Bloke> johnsonshi: So that shell snippet has been replaced by Python code in cloud-init master.
[23:06] <Odd_Bloke> So a one-off test with a recent daily build would give us some more information about what's going on here.
[23:07] <Odd_Bloke> Because if the completely rewritten code _also_ exhibits failure then my guess is that this isn't actually directly related to the swap creation, and instead it's something more complex.
[23:08] <Odd_Bloke> johnsonshi: I'm finishing up my day now, I'm afraid.  If you can reproduce this with cloud-init dailies, then please file a bug.  If it only exhibits in the version you're pinned on, then I think you'll need to talk to your team about how you've handled such issues in the past.
[23:08] <Odd_Bloke> (And have a good evening once you're done with your day too, of course. :)
[23:09] <johnsonshi> Odd_Bloke: OK I will try that out. Thanks for your help and have a good evening too! :)


[08:58] <alo21> hi all
[08:59] <alo21> Us there a wisheslist for Unity features?
[08:59] <alo21> Is*
[10:04] <alo21> #ubuntu-motu
[22:30] <alo21> hi everybody, I would like to contribute developing unity (fixing bug or packaging)...Can someone help me to start in the right way, please?


[00:28] <Saintly-i386> in xorg.conf, my mouse is ste up but refuses to work... i think its either the device option file settings or the driver, but i dont know whether changing the driver will help becaouse i dont know the driver.
[00:29] <Saintly-i386> should i change the device option from /dev/input/mice to /dev/input/mouse0 ?
[00:32] <Saintly-i386> slow day in here lol.
[00:38] <Saintly-i386> REALLY slow day
[00:41] <dr4c4n> Saintly-i386: yes, but I'm good for a laugh.. doh on the \join
[00:48] <Saintly-i386> ROFL
[00:51] <Saintly-i386> really dont wanna wait here till my question gets answered... i love this laptop lol, its older than my son. :D
[00:53] <dr4c4n> question? what's the question?
[00:53] <Saintly-i386> in xorg.conf, my mouse is ste up but refuses to work... i think its either the device option file settings or the driver, but i dont know whether changing the driver will help becaouse i dont know the driver.
[00:53] <dr4c4n> Saintly-i386: sorry that last msg was directed to you..
[00:53] <Saintly-i386> should i change the device option from /dev/input/mice to /dev/input/mouse0 ?
[00:53] <Saintly-i386> its fine :D
[00:54] <dr4c4n> Saintly-i386: as per most linux configs.. backup ur orig, test the change :)
[00:54] <Saintly-i386> lol of course :D
[00:54] <dr4c4n> I would try it out, and see if it works, otherwise if it was from default config, if you look up your model, and see if other's have had the same issue
[00:55] <dr4c4n> and check to see if it does the same thing if u plug in external mouse
[00:55] <Saintly-i386> does the confige actually differ from "mouse" for a device? ive never seen it other wise... oh and though i say "mouse" i really mena touch pad :D
[00:55] <Saintly-i386> will do
[00:55] <Saintly-i386> knew it was a good idea to get this targus mouse :D
[00:56] <dr4c4n> :) yes it works in a pinch but your touchpad should work too
[00:56] <dr4c4n> i know mine does, btw are u running xubuntu or ubuntu?
[02:09] <wizardslovak> helo people
[02:55] <wizardslovak> how do i shrink or expand hard drive?
[02:58] <psycho_oreos> what the total physical capacity or the partitions?
[03:00] <likemindead> wizardslovak: https://help.ubuntu.com/community/HowtoPartition
[06:02]  * UBuxuBU and his 8 tiny reindeer land on a small airstrip deep in the cerebral jungle of Xubuntu!
[06:35] <reis> hi I cant show the path of a program installed on my xubuntu example when ım downloading I want to use Gwget but ı cant show its path how can ı find the path of the programs
[06:55] <lighta> did you tryed locate ?
[07:03] <reis> how to locate
[07:04] <reis> when it writes donwload ı want to show the download sectiion the gwget program but from the list ı cant find the path of the prog
[08:29] <Arpad2> hello
[08:33] <share> hello
[08:40] <Arpad2> from live cd how can be the HDD mounted<
[08:40] <Arpad2> ?
[08:40] <knome> Arpad2, it should be mounted automatically to /media
[08:41] <Arpad2> ok
[08:41] <Arpad2> I tried nvisdia driver , after removed it
[08:41] <Arpad2> and now xubuntu doesnt appears
[08:42] <Arpad2> knome> thx
[08:42] <knome> np
[08:43] <Arpad2> knome: that folder is emptz
[08:43] <knome> !mount
[09:19] <Arpad2> can I modify xorg.conf from live cd?
[09:21] <knome> yes
[09:22] <Arpad2> >(
[09:22] <Arpad2> :)
[09:22] <Arpad2> ok
[09:22] <Arpad2> knome: how? :)
[09:22] <Arpad2> sudo nano xorg.conf didnt work
[09:23] <knome> first you have to get the disc mounted where your xorg.conf lies
[09:23] <knome> let's say it's mounted to /media/system
[09:24] <knome> then you'd edit xorg.conf by /media/system/etc/X11/xorg.conf
[09:24] <knome> s/by/from
[09:25] <Arpad2> what is tha lat line<
[09:25] <Arpad2> ?
[09:26] <knome> Arpad2, have you mounted the disc where your xorg.conf is?
[09:26] <Arpad2> not zet. ok I ll do it
[09:33] <xubi> newcomer from windows;where do I find xorg in 10.4
[09:37] <knome> xubi, by xorg, what do you mean?
[09:41] <Arpad2> knome: I think mz disk is not mounted to /media/szstem
[09:41] <Arpad2> knome: I think it is in /cdrom
[09:41] <knome> Arpad2, that was just an example. if you mount the disk, you define the mount point yourself
[09:42] <knome> Arpad2, err, that's the cd, not the hard drive
[09:42] <knome> Arpad2, you can't edit the xorg.conf of the cd
[09:43] <Arpad2> ok
[09:43] <knome> Arpad2, is that what you wanted?
[09:44] <Arpad2> no
[09:44] <Arpad2> I want to change the xorg.conf on my harddrive
[09:44] <knome> Arpad2, okay. your HDD mount command should be something LIKE (note: not necessarily exactly): "mount /dev/sda1 /media/system"
[09:44] <xubi> well I actually dont know, I understand is a file
[09:45] <knome> xubi, right - newer xubuntu installations do not have that by default, but the correct path is /etc/X11/zorg.xonf
[09:45] <knome> erm, xorg.conf apparently..
[09:45] <Arpad2> i mounted the partition to /mnt
[09:45] <knome> Arpad2, then your xorg.conf should be at /mnt/etc/X11/xorg.conf
[09:46] <xubi> I found a solution for a display problem I have , and refers to xorg editing
[09:46] <Arpad2> yes
[09:46] <Arpad2> there it is
[09:46] <knome> xubi, yeah. you can create the file :)
[09:46] <xubi> I suppose I should better tell you my prob;
[09:46] <knome> might help as well
[09:47] <xubi> after installing the 10.04 on my old HP xh 455(256MB RAM), 18 GBhard,with athlon at 900 MHz,
[09:48] <knome> Arpad2, well, you're free to edit the file ;)
[09:48] <xubi> the display is abt 10" and my screen is probably 15"
[09:48] <Arpad2> I tried with sudo nano
[09:49] <knome> Arpad2, and?
[09:49] <Arpad2> knome: Error opening terminal: unknown.
[09:50] <knome> Arpad2, try 'export TERM=xterm' first
[09:50] <Arpad2> knome: ok I tzpe it
[09:53] <Arpad2> knome: it worked :)
[09:53] <knome> good, so you now can edit the file? :)
[09:54] <knome> xubi, erm... yeah, what are you suggested to do in order to fix the problem?
[09:54] <Arpad2> knome: already did :)
[09:54] <knome> great
[09:54] <Arpad2> knome: what was this trick  all about?
[09:55] <knome> Arpad2, nano didn't know the terminal type, since the TERM variable was unset. by exporting it with value xterm, nano knew it could work like it was in an xterm terminal
[09:56] <xubi> well, I can't use the command line yet so I tried over menues; with driver looks ok so far but does not accept a better resolution than 800x600
[09:57] <Arpad2> knome: thx for the extensive explanation
[09:57] <knome> Arpad2, no problem ;)
[09:58] <knome> xubi, well, in order to create an xorg.conf file, follow these instructions: http://www.osguides.net/operation-systems/217-how-to-create-xorgconf-in-ubuntu-910.html
[09:58] <knome> xubi, then after that, you can edit the file from any text editor
[09:58] <xubi> I was suggested to edit xorg, course I didn't find it.
[09:58] <xubi> now I understand, I have to create it
[09:59] <xubi> thanx for instrux
[09:59] <knome> no problem
[10:00] <xubi> isn't another way do solve my display problem?
[10:00] <knome> xubi, probably not
[10:02] <xubi> what is zorg.xonf? it is in the same path where I should put the xorg
[10:03] <knome> that was a typo, it should be xorg.conf :)
[10:03] <xubi> :) ok I was wild trying to find it
[10:04] <knome> anyway, i have to go
[10:04] <knome> goodl uck and see you later
[10:06] <Arpad2> knome: thx for help, now it from harddrive
[10:07] <Arpad2> how can I restore the Places tad on the upper panel?
[10:07] <Arpad2> tab
[10:07] <xubi> thanks Knome,  will also be around for the next months from now
[10:08] <Sysi> Arpad2: add it there
[10:08] <Sysi> normal panel item (Sysi@gprs)
[10:08] <Arpad2> after upgrade to maverick it dissappeared
[10:09] <Arpad2> oon my copmp at least
[11:05] <infrid64> hi!
[11:16] <infrid64> how can i get exale in tray? --startd-minimized doesn't work
[11:27] <infrid64> bye
[14:10] <dvanstone> Merry Chistmas
[14:11] <Sysi> merry what-ever-you-want on-what-timezone-you-ever-happen-to-be
[14:15] <dvanstone> hmmm
[14:17] <dvanstone> can I add an entry to boot a different OS on a separate disc
[14:18] <dvanstone> ?
[14:18] <Sysi> update-grub may does it automatically
[14:19] <Sysi> !grub2 | or see
[14:20] <dvanstone> update grub? is wikified somewhere?
[14:20] <Sysi> it's just command
[14:20] <Sysi> sudo update-grub
[14:21] <dvanstone> can one grub load both deb and rpm builds
[14:22] <Sysi> it can load different distros
[14:22] <Sysi> rpm and deb are just packages that package manager extracts
[14:22] <Sysi> g2g →
[15:13] <MorphixNW> A Very Merry Christmas To Everyone :)
[15:13] <MorphixNW> hope you all are having a great day
[15:17] <Sysi> merry what-ever-you-want on-what-timezone-you-ever-happen-to-be
[15:18] <MorphixNW> well its 15:18 here at the moment
[15:19] <Sysi> we celebrated yesterday, we even celebrated
[15:19] <MorphixNW> just another day for me, BARRRR HUMBUG
[15:20] <MorphixNW> a day when the internet seems very fast lol
[15:21] <Sysi> gprs, pretty much middle of nowhere
[15:22] <MorphixNW> couldnt put up with that :(
[15:48] <cazandobits> hi can I speak here in spanish?
[15:48] <psycho_oreos> !es| cazandobits
[15:48] <cazandobits> thx
[16:01] <MorphixNW> man its quite lool
[17:34] <reis> mary cristmas for all of you :D
[17:35] <Sysi> merry what-ever-you-want on-what-timezone-you-ever-happen-to-be
[17:38] <reis>  how can ı be a member of this page?
[19:22] <scifi> hi, i cant get any sound from my laptop speakers, any suggestions?
[19:49] <sparkie> merry xmas guys
[20:02] <Sysi> scifi: check everything unmuted from mixer
[20:02] <Sysi> you could try googling by name of your souncard
[21:52] <nicofs> if i want a certain command (bash) to be run, every time the system starts - what file should i put it in?
[21:53] <TheSheep> nicofs: as root?
[21:54] <TheSheep> nicofs: or as user when you log in?
[21:54] <TheSheep> nicofs: also, what command is it, there may be a better way to do it
[21:54] <nicofs> TheSheep, i need to add a bit to $PATH - and then set the screen resolution...
[21:55] <TheSheep> nicofs: that's way after the system boot
[21:56] <TheSheep> nicofs: adding to path -- check ~/.bash_profile and ~/.bashrc, and global equivalents in /etc/ for all users
[21:56] <TheSheep> nicofs: setting resolution -- create an xorg.conf file and set it there
[21:56] <nicofs> TheSheep, xorg.conf doesn't work...
[21:57] <TheSheep> !doesn't work
[21:57] <nicofs> TheSheep, i wrote a script to do that... you just enter "resolution width height hz" and your screen gets  adjusted...
[21:58] <TheSheep> nicofs: wow, you wrote your own version of xrandr? :D
[21:58] <nicofs> TheSheep, no - but a script that unifies gtf and xrandr to something user-friendly...
[21:59] <nicofs> TheSheep, basically, it does all the addmode, changemode and so on for you...
[21:59] <TheSheep> anyways, just put it in your 'autostarted applications' in 'sessions and startup'
[21:59] <TheSheep> if you really must
[23:20] <wizardslovak> hello people
[23:20] <wizardslovak> where do i find c heaader files?
[23:21] <wizardslovak> What is the location of the directory of C header files that match your running
[23:21] <wizardslovak> kernel?
[23:22] <scifi> my laptop has a AD1996A high definition audio chipset and i cant get any sound from it, any suggestions
[23:25] <well_laid_lawn> wizardslovak: in /usr/include if you have them installed
[23:27] <wizardslovak> hmm
[23:27] <wizardslovak> i am getting this
[23:27] <wizardslovak> The header files in /usr/include are generally for C libraries, not for the
[23:27] <wizardslovak> running kernel. If you do not have kernel header files in your /usr/src
[23:27] <wizardslovak> directory, you probably do not have the kernel-source package installed. Are
[23:27] <wizardslovak> you sure that /usr/include contains the header files associated with your
[23:27] <wizardslovak> how do i install them tho?
[23:28] <well_laid_lawn> oh ok try apt-get source linux
[23:29] <wizardslovak> installed something
[23:29] <wizardslovak> but still
[23:29] <wizardslovak> The directory of kernel headers (version @@VMWARE@@ UTS_RELEASE) does not match
[23:29] <wizardslovak> your running kernel (version 2.6.35-24-generic).  Even if the module were to
[23:29] <wizardslovak> compile successfully, it would not load into the running kernel.


[10:55]  * benji gets some pre-standup coffee.
[11:25]  * benji has finished his pre-standup coffee and wonders where the standup went.
[11:25] <gmb> benji: Um, isn't it in an hour?
[11:25] <benji> oh!
[11:26] <benji> gmb: combine me being in a different time zone and having been up since 3 AM because I couldn't sleep and that's what happens :)
[11:26] <gmb> Ah, yes, that can and will happen.
[11:27] <gmb> benji: Which timezone are you in now, then?
[11:27] <benji> "Central" which is UTC minus 5 hours
[11:27] <gmb> Ah.
[11:49] <bac> gmb: i got a spyder4 yesterday.  the world is a little less green today.  :)
[11:49] <gmb> :)
[11:49] <gmb> Reminds me, I need to recalibrate.
[11:49] <bac> the laptop was particularly bad
[11:50] <gmb> Yeah, laptop panels are traditionally awful when it comes to colour accuracy.
[12:08] <gary_poster> bac benji frankban gmb call in 2
[12:08] <gary_poster> getting url
[12:09] <gary_poster> https://plus.google.com/hangouts/_/bc3d875fdcbeb3e248cf65d4577704a3deea777e bac benji frankban gmb
[12:10]  * gmb -> Joining
[12:26]  * gmb -> lunch
[12:27] <bac> benji: is that the same house you mentioned a few weeks ago?
[12:27] <benji> bac: nope, we lost out on that one, it was bank-owned and they took a competing bid
[12:28] <benji> the one from a couple of weeks ago was much cheaper but needed much, much more work
[12:28] <bac> b/c this one looks a lot nicer than you described the original one
[12:28] <bac> good luck
[12:28] <gary_poster> @ more than 3x the price one woud hope so :-)
[12:29] <benji> yeah, this one mostly just has cosmetic problems, there are a couple of water-induced rot issues, but it's pretty minor compared with the last one
[12:29] <gary_poster> bac, gmb approved expenses
[12:33] <gary_poster> nice blog post gmb.
[12:35] <gary_poster> And I even added your first comment, so as to have you not appear to be speaking to crickets
[13:30] <frankban> gary_poster: if you are running tests on buildbot, could you please check if this directory exists? /var/tmp/buildd/ and could you please run: find / -name ".bzr.log" ?
[13:30] <gary_poster> looking frankban
[13:30] <frankban> thanks
[13:35] <gary_poster> actually frankban, um...you need me to look in the container don't you.  I'll need to restart a build for that, after I add the root password there....  I'll ping you when I have something
[13:37]  * bac is irritated that DocFileSuite is not a class but a method.  nice naming.
[13:37] <gary_poster> heh
[13:38] <frankban> gary_poster: ah! you are right, thanks
[13:44] <benji> yeah, I think the reasoning is that it is a factory method, so it's named like that (not that I agree with the reasoning)
[13:45] <gary_poster> Ah yeah, I've done that sort of thing too.  "class in spirit if not in form" or something
[14:07] <gary_poster> frankban, :
[14:07] <gary_poster> # ls /var/tmp/
[14:07] <gary_poster> bazaar.launchpad.dev  bzrsync  codeimport  launchpad_mailqueue  mailman  xvfb-errors.log
[14:08] <gary_poster> # find / -name ".bzr.log"
[14:08] <gary_poster> /var/lib/buildbot/.bzr.log
[14:08] <gary_poster> anything else frankban?
[14:08] <frankban> gary_poster: no thanks
[14:08] <gary_poster> cool
[14:33] <gary_poster> system restart.  Hopefully back soon...
[15:16] <bac> hey gary_poster got a sec to chat?
[15:16] <gary_poster> bac, sure, but I didn't bring headphones down to porch.  Will get and ping.  Could you get hangout going?
[15:16] <bac> yep
[15:18] <gary_poster> bac, url pls?
[15:19] <bac> gary_poster: gah, i don't know how to find it
[15:19] <gary_poster> k 1 sec
[15:19] <bac> ur, nm this time it showed up
[15:19] <bac> https://plus.google.com/hangouts/_/2a1331a87490df2ce18c411f9f1ed15714c40f8c?authuser=0&hl=en
[15:19] <bac> in the past when i enabled the toolbar the URL never did show
[16:02] <frankban> gary_poster: so it appears that there is a bug in launchpad-buildd: please ping me when you have a minute
[16:03] <gary_poster> ack
[16:06] <gary_poster> frankban, hi
[16:06] <gary_poster> hangout?
[16:06] <frankban> ok
[16:06] <gary_poster> https://plus.google.com/hangouts/_/afd99e78e61364cfa374448a2cc7f911cf1799d4
[16:06] <gary_poster> frankban, ^^
[16:23]  * gary_poster goes to lunch to take advantage of Triangle Restaurant Week...biab
[18:47] <benji> gary_poster: I'm tardy in asking to pair, but I thought I had it done... I didn't
[19:23] <gary_poster> benji, ack.  I'll be redy in a few.
[19:23] <gary_poster> ready, even.
[19:38] <gary_poster>  benji https://plus.google.com/hangouts/_/c8219c883d90e3dc3f289defedfd95083e4f2b64 whenever you are ready
[20:25] <bac> gary_poster: we were wrong yesterday about the redundancy of the 'partial'.
[20:27] <gary_poster> bac ack on call would like to know
[20:52] <gary_poster> bac, why was it important?
[20:53] <bac> gary_poster: your test you did something like t.id = lambda: 'foo'
[20:53] <gary_poster> yes
[20:53] <bac> but if you don't use a constant, then they are all bound to the variable
[20:54] <bac> this may be clearer: http://pastebin.ubuntu.com/1025738/
[20:54] <bac> oops, not that version
[20:55] <gary_poster> k :-)
[20:55] <bac> this one: http://pastebin.ubuntu.com/1025740/
[20:56] <gary_poster> oh.  so it is being used to capture a state for a closure
[20:56] <gary_poster> I haven't used partial for that
[20:56] <gary_poster> I usually write a function to capture
[20:57] <gary_poster> using partial is clever, if not as obvious
[21:00] <gary_poster> thanks bac; sorry for leading you astray.  everything going ok otherwise?
[21:00] <bac> gary_poster: np
[21:01] <bac> gary_poster: yeah, just finding all of the offending tests with duplication and whacking them
[21:04] <gary_poster> cool


[00:12] <hatch> huwshimi: https://github.com/juju/juju-gui/pull/550 +1
[00:12] <huwshimi> hatch: Thanks!
[00:14] <hatch> huw #549 will conflict with develop
[00:14] <hatch> you'll want to rebase
[00:14] <hatch> maybe do that then I'll finish the review
[00:14] <rick_h_> morning huwshimi
[00:16] <huwshimi> hatch: OK no problems
[00:16] <huwshimi> rick_h_: Hey
[00:17] <hatch> huwshimi: have you moved into the garage yet?
[00:17] <hatch> your office I mean ;)
[00:18] <huwshimi> hatch: Not yet, might not be till after our next trip
[00:19] <hatch> ahh
[00:19] <huwshimi> hatch: are you the only one that does that curly style?
[00:19] <huwshimi> :)
[00:20] <hatch> lol I would like to think that others do too :)
[00:20] <hatch> you do some funnyness with the curlies
[00:20] <hatch> elses on a new line
[00:20] <hatch> smushing them into the contents
[00:20] <hatch> that's like two extremes
[00:22] <huwshimi> hatch: Well, if you're the only one doing it we should pick a style...
[00:23] <hatch> huwshimi: look how well picking a commenting style worked out
[00:23] <hatch> ;)
[00:24] <rick_h_> yea, let's have that one again :P
[00:24] <hatch> haha
[00:24]  * rick_h_ /me ls
[00:24] <rick_h_> lsbah
[00:24] <rick_h_> bah
[00:24] <rick_h_> lag
[00:24] <huwshimi> hatch: This is why I've gone with the majority style
[00:24]  * rick_h_ sets up script to throw angry email anyone uses two spaces, doesn't start a comment line with a *, or uses function(e)
[00:25] <hatch> haha
[00:25] <hatch> huwshimi: you can leave it as is - if it passes the linter that's fine by me
[00:25] <huwshimi> rick_h_: If you care about those things you should let us know, at the moment it's arbitrary on who does the review
[00:25] <huwshimi> can be frustrating
[00:26] <hatch> huwshimi: really it's implementers choice if it passes lint
[00:26] <hatch> so you can tell us reviwers to go stuff it
[00:26] <hatch> :D
[00:26] <huwshimi> haha
[00:26] <huwshimi> hatch: Also I rebased and didn't hit a conflict
[00:26] <hatch> really....odd I changed some of the exact same lines lol
[00:26] <rick_h_> huwshimi: yea, but it's stuff I'm passionate about that I argued for when I joined the team but was out voted. I don't want to force 'rick's way' as lead
[00:26] <huwshimi> ok :)
[00:27] <rick_h_> I just rant quietly on the inside :P
[00:27] <huwshimi> hehe
[00:27] <hatch> basically I disagree with every one of those things rick_h_ just posted too lol
[00:27] <hatch> I guess that's why they invented gofmt
[00:28] <rick_h_> yea, watch out the first time i have to write go code
[00:29] <hatch> go fmt will lock up trying to fix everything
[00:29] <hatch> lol
[00:29] <hatch> stack overflow
[00:29] <rick_h_> there will be a nuclear cleanup about an hour north of detroit
[00:29] <hatch> lol
[00:30] <hatch> 'melt down caused by gofmt and a developers opinions"
[00:30] <hatch> for what it's worth I also don't like gofmt
[00:32] <rick_h_> wtf, are we string sorting machine names?
[00:32] <rick_h_> 0 - 1 - 10
[00:32] <rick_h_> 2 - 3 - 4-
[00:33] <rick_h_> hmm, this is tricky though, once we allow naming the machines we'll have to support names. :/
[00:33] <huwshimi> Probably, they are strings :)
[00:35] <rick_h_> huwshimi: filed a bug and aded to the board if you get looking for something else to poke at. I think you did some of the sorting code?
[00:35] <huwshimi> rick_h_: Yeah, it's my fault :)
[00:35] <rick_h_> huwshimi: all good, you're right that they're strings
[00:36] <rick_h_> it just feels very unnatural currently in practice
[00:36] <huwshimi> yeah
[00:36] <hatch> oo huwshimi is gona have to write an alphanumeric sorting algorithm
[00:36] <hatch> I'm sure there are some on the googles which you can use for inspiration
[00:37] <huwshimi> hatch: That's funny I'm pretty sure the card has your head on it
[00:37] <hatch> lol
[00:37] <hatch> is 549 updated and ready?
[00:38] <rick_h_> bah, walk the list, try to parse the int, if you can...then set it as an attribute
[00:38] <rick_h_> get to the end of the list and find they all parsed, then sort on the new attribute vs the name
[00:38] <rick_h_> done
[00:38] <rick_h_> one iteration through the list, one parseInt on xxx machine names
[00:38] <hatch> not sure that will work for things like 1-foo 10-bar style names
[00:39] <rick_h_> that's a string, sort it stringy then
[00:39] <hatch> I suppose
[00:39] <rick_h_> I just want to get pure numbers vs words right for now
[00:39] <rick_h_> I think people will do apache-1 and apache-2 vs 2-apache 1-apache
[00:39] <rick_h_> anyway, but we can tell about that later
[00:40] <hatch> true
[00:41] <huwshimi> hatch: I've pushed up the rebased version of that branch, no changes to my code though
[00:41] <rick_h_> ok, tested jc's branch, now reloading onto latest trunk
[00:43] <rick_h_> switching branches is a LOT faster after the first change
[00:43] <rick_h_> guess all the work is in the deps/etc required
[00:46] <hatch> huwshimi: review done - a few comments around the events
[00:46] <rick_h_> hatch: much nicer ty
[00:47] <rick_h_> hatch: I'm hesitant to mark the bug fix committed though as we want to get a better fix?
[00:47] <hatch> rick_h_: oh I suppose...
[00:47] <hatch> rick_h_: be sure to pick a machine with a bunch of containers to try and fill up that third column a bit :)
[00:48] <huwshimi> hatch: Ah thanks, I was wondering if we could do something like that, much better!
[00:48] <rick_h_> hatch: hah
[00:49] <rick_h_> hatch: I was thinking of trying to see if I could do the ghost blog and show 3 services, and click into machine view and see 10 machines of 10 container's each with a ghost blog :)
[00:49] <rick_h_> hatch: kind of to show that sometimes service view is the clean summary of things and sometimes machine view is the more clear view
[00:49] <hatch> huwshimi: yup as long as all the tokens have their bubble targets set to the mv....so just keep an eye that anywhere the token is created it has `token.addTarget(this)` assuming the token is being created in the mv
[00:50] <huwshimi> hatch: Ah right, that makes sense
[00:50] <hatch> rick_h_: haha I'm not sure why each machine would have multiple containers of the same service
[00:51] <hatch> huwshimi: I also think addTarget is idempotent but best not to repeat it just to be safe
[00:51] <rick_h_> hatch: well you can run 10 ghost nodejs instances on one hardware machine
[00:52] <rick_h_> imagine it's a 6core or something
[00:53] <hatch> rick_h_: ahh I didn't think of that
[00:53] <hatch> yeah I don't think it does multi core by default
[00:53] <rick_h_> yep
[00:54] <hatch> does lxc do cpu locking?
[00:54] <hatch> or would this be a openstack thing
[00:55] <hatch> I would assume lxc would just share resources so the provisioning must be done with something else
[00:56] <hatch> oh i think kvm does that
[00:56]  * hatch is just rambling now
[00:57] <huwshimi> hatch: Changes pushed
[00:58] <hatch> thx
[00:58] <huwshimi> doesn't appear to be picked up in github though
[00:59] <huwshimi> uh, somehow it pushed it to my develop
[01:00] <rick_h_> hatch: next part of your bug
[01:00] <rick_h_> hatch: when I hit commit, in the summary it says "You ahve 23 unplaced units, do you want to: ..."
[01:01] <hatch> oh poo
[01:02] <rick_h_> hatch: added a new card for tomorrow
[01:03] <rick_h_> but got a bunch of great screenshots
[01:03] <hatch> excellent I definitely want to check em out
[01:03] <rick_h_> so can move forward a little bit but can't go through summary/commit process yet
[01:03] <rick_h_> so blocker on any video work
[01:07] <hatch> yeah ok I'll jump on that first thing
[01:13] <huwshimi> hatch: OK, fixed all the weirdness, changes are up
[01:14] <rick_h_> hatch: got a sec to chat?
[01:29] <hatch> rick_h_: actually just making supper
[01:29] <hatch> gona be around in an hour?
[01:30] <rick_h_> hatch: all good, we can sync tomorrow
[01:30] <hatch> cool
[01:30] <hatch> huwshimi: I'll also finish up your review in an hourish
[01:30] <huwshimi> hatch: No problems, no hurry
[01:31] <rick_h_> hatch: sent the screenshot link
[01:31] <rick_h_> my middle-click stopped working all of a sudden wtf
[01:53] <rick_h_> jujugui kind of cool per
[01:53] <rick_h_> per
[01:53] <rick_h_> bah
[01:56] <rick_h_> jujugui https://plus.google.com/116120911388966791792/posts/dR3zqM6E66B kind of cool
[01:59] <huwshimi> rick_h_: Any idea why the hardware details are not available?
[01:59] <rick_h_> huwshimi: no :/
[01:59] <rick_h_> good point, I need to look into that one next. I wonder if it's because of maas or something
[01:59] <huwshimi> rick_h_: Have you ever seen hardware details?
[02:00] <huwshimi> like on ec2 or anything at all?
[02:00]  * rick_h_ thinks so but would have to double check
[02:00] <rick_h_> yea, the hardware inf ois all set to undefined in there
[02:01] <huwshimi> I have a feeling we've broken something
[02:01] <rick_h_> yea, I can't get the websocket data here in FF, will have to test it out in chrome.
[02:01]  * rick_h_ adds another card
[02:10] <rick_h_> huwshimi: ok, so we're not getting any constraint info in the service info. We need to see if there's a way to just get the hardware info on the machine instead
[02:11] <rick_h_> oh hmm, yea there's a delta that has empty hardwareCharacteristics so not sure what we could do about it
[02:17] <rick_h_> huwshimi: ok, verified there was a bug to update juju to show that hardware data: https://bugs.launchpad.net/juju-core/+bug/1193998
[02:17] <mup> Bug #1193998: maas provider doesn't return hardware characteristics of started instances <maas-provider> <tech-debt> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1193998>
[02:17] <rick_h_> huwshimi: but the orange box is on 1.18 and doesn't have the fix
[02:17] <huwshimi> hmm
[02:25] <hatch> rick_h_:  huwshimi if you load the env with the service view selected then it has the machine info
[02:25] <hatch> if you load with the mv then it doesnt
[02:26] <rick_h_> hatch: my issue is the maas bug though
[02:26] <rick_h_> hatch: verified it's getting backported today but will be in the next release
[02:26] <hatch> ohh so this is in addition to the other bug heh
[02:26] <rick_h_> hatch: so just no hardware info for maas atm
[02:26] <rick_h_> hatch: right
[02:26] <rick_h_> this is a juju bug
[02:26] <hatch> man it's all creepy crawly in here lately :)
[02:26] <rick_h_> creepy crawly?
[02:26] <rick_h_> oh buggy :P
[02:27] <rick_h_> huwshimi: if you get a min can you review/qa https://github.com/juju/juju-gui/pull/548 please?
[02:27] <rick_h_> and if it's cool go ahead and shipit
[02:30] <hatch> haha yeah
[02:33] <huwshimi> rick_h_: The fix in that branch also fixes an issue I have in my current branch, expect for deployed services
[02:33] <huwshimi> rick_h_: shipped it
[02:33] <rick_h_> huwshimi: awesome thanks for looking
[02:33] <huwshimi> np
[02:36] <hatch> huwshimi: review done, +1 with some minor stuff
[02:38] <huwshimi> hatch: Thanks
[02:39] <rick_h_> ok, time for me to head out for the night
[02:39] <hatch> huwshimi: feel free to land after your updates
[02:39] <hatch> yup mee too
[02:39] <huwshimi> hatch: Thanks
[02:39] <hatch> night all
[02:39] <rick_h_> hatch: get out of here, need you fresh for the deploy stage bug tomorrow :P
[02:39] <huwshimi> rick_h_, hatch: night
[07:18] <fabrice> good morning !
[07:22] <huwshimi> fabrice: Morning
[07:24] <ant__> huwshimi, morning :)
[07:24] <huwshimi> ant__: Good morning!
[07:24] <ant__> huwshimi, how's it going?
[07:24] <huwshimi> ant__: Good thanks. Yourself>
[07:24] <huwshimi> *?
[07:25] <fabrice> morning
[07:25] <ant__> huwshimi, all good this end thanks
[07:25] <huwshimi> ant__: How long before you head on leave?
[07:26] <huwshimi> well, approximately :)
[07:26] <ant__> huwshimi, im off on the 24th
[07:26] <ant__> only for 2 weeks though
[07:26] <ant__> still have lots of hols left
[07:27] <huwshimi> ant__: Ah ok, very soon!
[07:28] <ant__> huwshimi, yeah b-day soon :/
[07:59] <huwshimi> Night all
[09:28] <frankban> rogpeppe1: morning, could you please take a look at https://github.com/juju/juju/pull/768 ?
[09:34] <rogpeppe1> frankban: looking
[09:34] <frankban> thanks
[09:39] <rogpeppe1> frankban: i'm afraid i'm not qualified to review API implementation changes any more
[09:40] <rogpeppe1> frankban: it seems reasonable to me, but perhaps it needs a new API version or something
[09:40] <frankban> rogpeppe1: it's not backward incompatible, it's just about adding an additional field, but I see your point, I'll ask in #juju-dev
[09:48] <urulama> frankban: i'd say it does need a new API version. just not sure if core is on them already
[09:55] <rogpeppe1> urulama, frankban: if they're doing semantic versions, i guess it would be a minor version increase
[09:56] <rogpeppe1> hmm, weird. my camera seems to have started working again.
[09:57] <urulama> rogpeppe1: no updates or any changes?
[09:57] <rogpeppe1> urulama: nope, none of the above
[09:57] <urulama> interesting :)
[09:57] <rogpeppe1> urulama: hurrah for modern software
[10:01] <frankban> rogpeppe1: it does not seem they are using semantic versioning. AFAICT facades only have a major version number
[10:01] <rogpeppe1> frankban: i have a vague recollection of that too
[10:01] <rogpeppe1> frankban: i don't know what they intend to do about backwardly compatible changes then
[10:02] <frankban> rogpeppe1: yeah, I'll see that in review. FWIW, I see stuff like common.RegisterFacade(
[10:02] <frankban> 		"AllWatcher", 0, newClientAllWatcher,
[10:02] <frankban> 		reflect.TypeOf((*srvClientAllWatcher)(nil)),
[10:02] <frankban> 	)
[10:02] <frankban> where 0 is the version
[11:11] <rick_h_> morning
[11:12] <rick_h_> frankban: <3 thanks for that update to core
[11:12] <rick_h_> it'll make our life a lot easier eventually
[11:12] <frankban> rick_h_: yeah, that's the idea :-)
[11:13] <frankban> urulama, rogpeppe1: FYI, core api version must be increased when introducing backward incompatible changes. so apparently the logic is the same as in gopkg versions
[11:14] <urulama> frankban: thanks. i suspected that, as it makes sense
[11:15] <rogpeppe1> frankban: unfortunately that gives no way for a client to know if it's talking to an API with a given feature or not
[11:16] <rogpeppe1> frankban: i guess it can look to see if the Subordinate field exists in the response
[11:16] <frankban> rogpeppe1: yes, I guess that's the way to go
[11:17] <fabrice> rick_h_: morning !? no it's time for lunch
[11:17] <rick_h_> fabrice: :)
[11:17] <rick_h_> fabrice: hey, still trying to put breakfast together, quit rushing me :P
[11:30]  * rick_h_ steps away to take boy to day care
[11:42] <fabrice> rick_h_:  I am finished with lunch :)
[11:45] <fabrice> rick_h_: but I am not rushing you
[11:54]  * frankban lunches
[13:32] <rick_h_> jujugui can I get a second review/qa of jcsackett's bundle work please? I'd like to test it and see if we can get a demo together for things
[13:36] <rick_h_> frankban: can you peek please? ^ https://github.com/juju/juju-gui/pull/553
[13:37] <frankban> rick_h_: sure
[13:37] <rick_h_> frankban: ty much
[13:38]  * rick_h_ needs to start later. Feels like forever before everyone starts the day heh
[13:38] <jcsackett> rick_h_: do we still have permission to go over the WIP limits on MV?
[13:39] <rick_h_> jcsackett: I'm trying ot make room, if you can help move forward a review I'd prefer that first please
[13:39] <jcsackett> rick_h_: sure.
[13:39] <rick_h_> jcsackett: but yes, permission granted
[13:39] <rick_h_> frankban: you card in coding you got reviewed/landed?
[13:39] <rick_h_> ah no, that's a different one nvm
[13:40] <jcsackett> jujugui: in addition to the one rick_h_ just pinged with, i need reviews/qa on https://github.com/juju/juju-gui/pull/556 (it's a short one)
[13:40] <rick_h_> jcsackett: looking
[13:40] <jcsackett> rick_h_: thanks.
[13:41] <kadams54> jcsackett: I can take a look at both
[13:42] <jcsackett> kadams54: i think frankban is looking at the first one, so just the https://github.com/juju/juju-gui/pull/556 needs it.
[13:42] <kadams54> kk
[13:56] <rick_h_> jcsackett: can I talk you into swapping cards with your head on them there? The sorting I talked to huw about next up for him last night as he did the original sort
[13:57] <jcsackett> rick_h_: oh, sure. meant to take my head off of that one.
[13:57] <rick_h_> jcsackett: the one about the change notifications not showing in the footer would be a really nice one to figure out, probably a simple git bisect as it recently broke
[13:57] <rick_h_> jcsackett: ty
[14:27] <kadams54> jcsackett: just to clarify, I should only be able to drag-n-drop onto the root container of undeployed machines, right?
[14:27] <jcsackett> kadams54: in an environment that doesn't support containers, correct; only the root container should be droppable.
[14:31] <kadams54> jcsackett: Alright, QA is good on #556
[14:31] <jcsackett> kadams54: awesome, thanks.
[14:34] <kadams54> rick_h_: any cards I should be looking at? The one I'm working on right now only impacts sandboxes.
[14:39] <jcsackett> kadams54: i think i misunderstood earlier--you weren't able to drop units onto a deployed root container?
[14:39] <kadams54> Correct
[14:40] <hatch> jcsackett: kadams54 So I can now use the GUI to drop multiple units on a single container in mv?
[14:40] <kadams54> Well, belay that.
[14:40] <jcsackett> pretty sure we are supposed to allow that...i don't recall that not working for me in the branch before.
[14:41] <jcsackett> kadams54: ok, belaying...you double checking that, or did i misstate something...?
[14:41] <kadams54> I'm double checking
[14:42] <kadams54> Alright, I'm not sure what I did the first time around, but the last two times I've tried, I was able to deploy to a committed root container.
[14:43] <kadams54> QA comments updated. Breathe easy, jcsackett :-)
[14:43] <jcsackett> kadams54: hooray!
[14:43] <jcsackett> :)
[14:44] <hatch> excellent
[14:44] <hatch> not being able to do that really irritated me while doing some ghost tests
[14:48] <rick_h_> kadams54: looking
[14:49] <rick_h_> https://bugs.launchpad.net/juju-gui/+bug/1368588
[14:49] <mup> Bug #1368588: Unplaced units show up in changelog and make the "Commit" button active <juju-gui:Triaged> <https://launchpad.net/bugs/1368588>
[14:49] <rick_h_> kadams54: ^ would be good I think as that would effect demo
[14:49] <kadams54> k
[14:49] <rick_h_> kadams54: though see if you can reproduce in a live env first. Huw found that and I know there's a bug with the chagnes not showing at all now
[14:49] <kadams54> will do
[14:49] <rick_h_> ty
[14:50] <rick_h_> jujugui call in 10
[14:50] <rick_h_> hatch: Makyo if you guys are free can we meet now in there to chat demo/blog stuff
[14:50] <rick_h_> jujugui anyone else is welcome to join
[14:51] <hatch> yup joining
[14:51] <rick_h_> hah, standing desk motor is working a bit harder with the orangebox on the desk
[14:55] <jcsackett> frankban: apologies, i was pushing another branch and i just accidentally updated the branch you're reviewing.
[14:56] <frankban> jcsackett: np, I can wait
[14:57] <jcsackett> frankban: well, i won't update anymore until your review is done--what got pushed only addressed comments from rick_h_.
[14:57] <frankban> jcsackett: ah, ok, no problem then, thanks
[14:57] <frankban> jcsackett: where is your card for this task?
[14:57] <jcsackett> frankban: i was insufficiently specific about branches to push and updated *all* of my active branches.
[14:58] <jcsackett> in the review lane; it was briefly in landing as i grabbed the wrong card.
[14:58] <jcsackett> yay (poorly) juggling multiple cards.
[14:58] <frankban> jcsackett: cool, my name is already there
[15:00] <rick_h_> jujugui call time
[15:00] <rick_h_> ant__: jcsackett frankban &
[15:00] <rick_h_> fabrice: ^
[15:21] <frankban> jcsackett: reviewed
[15:23] <jcsackett> frankban: thanks! fixing up the code now.
[15:23] <jcsackett> Makyo: i've reviewed and qa'ed your asterisks branch--looks like rick_h_ was the other reviewer there, so i updated your card tags as well.
[15:24] <Makyo> Cool, thanks jcsackett
[15:37]  * rick_h_ runs to appointment
[15:37] <rick_h_> biab
[15:51] <frankban> hatch_: where is the temporary work around for subordinates in trunk?
[15:57] <hatch_> frankban:  in the initializer for the machine view p;anel.js
[15:58] <hatch_> it checks each units service if it's set to a subordinate
[16:00] <frankban> hatch_: and it can or cannot work right?
[16:01] <hatch_> frankban: it works as long as you don't visit a /mv url directly...If you go from the service view to the mv then it works as expected
[16:02] <hatch_> but if you visit the /mv directly the services charm data hasn't loaded yet by the time the token is rendered
[16:02] <frankban> hatch_: ok, so this will continue to be the best guess with old version of juju
[16:04] <hatch_> frankban:  yeah, not much we can do atm without refactoring the loading/rendering cycle of the mv
[16:05] <frankban> hatch_: ack
[16:06] <frankban> hatch_: can you confirm we don't want to show the scale up view in the inspector for subordinates?
[16:06] <hatch_> correct
[16:06] <hatch_> you cannot scale subordinates
[16:06] <frankban> hatch_: cool, I am refactoring that part too
[16:07] <kadams54> rick_h_: when you get back, we should chat.
[16:11] <hatch_> frankban:  awesome
[16:11] <hatch_> thanks
[16:25] <kadams54> lunching
[16:32] <jcsackett> frankban: i've pushed up changes. do you still have the setup for your QA issue? i believe it is resolved by the db.units.filterByMachine thing.
[16:33] <frankban> jcsackett: I don't have that set up, but I can check again. I'll take a look ASAP.
[16:40] <frankban> jcsackett: on a real env, trying to export a bundle I still get "Uncaught TypeError: Cannot read property 'service' of undefined "
[16:43] <frankban> jcsackett: it might be a red herring, but what happens at  line 1929 if the machine does not include any units?
[16:45] <jcsackett> frankban: good catch; it should abort if a machine has no units.
[16:45] <frankban> jcsackett: yeah, I guess the error I encountered depends on that
[16:45] <jcsackett> actually, it should just filter machines with no units.
[16:46] <jcsackett> ok, that's a quick fix.
[16:46] <jcsackett> i misread your earlier qa error.
[16:47] <frankban> jcsackett: could you please also add a test for existing machine without units, that's a quite common scenario (especially on local envs machine 0)
[16:47] <jcsackett> frankban: yeah, i'll need to update the "filters machines" test for this.
[17:02] <jcsackett> frankban: pushed.
[17:03] <frankban> jcsackett: I;ll reswitch and check again asap
[17:03] <jcsackett> thanks.
[17:05] <hatch_> juju gui lf review and qa for an orangebox bug https://github.com/juju/juju-gui/pull/557
[17:14] <rick_h_> kadams54: back
[17:15] <hatch_> rick_h_: want to qa my branch on Obey?
[17:15] <hatch_> Obee
[17:15] <hatch_> yeah....Obee
[17:16] <kadams54> rick_h_: After looking at https://bugs.launchpad.net/juju-gui/+bug/1368588 I don't think it's a valid bug
[17:16] <mup> Bug #1368588: Unplaced units show up in changelog and make the "Commit" button active <juju-gui:In Progress by kadams54> <https://launchpad.net/bugs/1368588>
[17:16] <rick_h_> kadams54: looking
[17:16] <kadams54> Either that, or I wasn't able to reproduce what Huw was seeing.
[17:17] <rick_h_> kadams54: will try to qa here in a live env
[17:17] <hatch_> kadams54: I believe the bug he was mentioning was fixed.....but I'm not sure by the report heh
[17:17] <kadams54> I see the behavior he describes, but it's how things are supposed to work now that we're not placing units by default.
[17:18] <rick_h_> kadams54: ok, so I think the bug here is more of workflow. We default to checking 'leave unplaced' and so the user can hit 'commit->comfirm' pretty easily and nothing appears to happen
[17:19] <rick_h_> kadams54: so I would ask if we should default to 'leave unplaced' or not default to any value and force the user to check one or the other before hitting confirm
[17:19] <rick_h_> kadams54: what are your thoughts?
[17:20] <kadams54> rick_h_: I like the default we have right now, but mostly because it's very convenient for me :-)
[17:20] <rick_h_> kadams54: well, let's put ourselves in the shoes of users :)
[17:20] <hatch_> I like the default we have now because it's the cheapest option for the user if they misclick
[17:20] <hatch_> heh
[17:20] <rick_h_> kadams54: I can toss it to luca and UX and get their feedback
[17:20] <kadams54> It's also hard because I implemented that, so I have a big blind spot. It would be interesting to talk to Huw and get his impressions, esp. since he wasn't a part of any of the discussions around that.
[17:21] <rick_h_> hatch_: right, but they couldn't mis-click. They'd have to select one or the other if we make it selected
[17:21] <rick_h_> kadams54: understood
[17:21] <rick_h_> kadams54: ok, put that card in 'needs specification' and we'll do some follow up work on the best interaction for users there
[17:21] <kadams54> Technically, something *does* happen… the service gets deployed. You just can't see it in machine view.
[17:22] <rick_h_> kadams54: right, I understand
[17:22] <frankban> guihelp: I need reviews/QA for https://github.com/juju/juju-gui/pull/558 . no rush
[17:23] <kadams54> rick_h_: Anything else that's a higher priority than my happens-in-sandbox-only card?
[17:23] <rick_h_> kadams54: any of the three destroy cards
[17:23] <rick_h_> kadams54: I'd suggest looking at all three to make sure there's not a common theme/overlap while investigating
[17:24] <kadams54> will do
[17:24] <kadams54> I kinda wonder if they might all be sandbox-only bugs…
[17:25] <rick_h_> kadams54: good info to find out for sure
[17:26] <rick_h_> although when huw found these, I had specifically asked him to QA on ec2 and azure
[17:26] <rick_h_> kadams54: so not sure they'll be sandbox only thing
[17:26] <rick_h_> things
[17:26] <hatch_> ywah the description isn't really complete
[17:26] <rick_h_> hatch_: k, looking at your branch
[17:26] <hatch_> coooooo
[17:27] <hatch_> rick_h_: we could also fix these unplaced units issues by 'placing' subordinate services....but then of course they will show up in the mv....whiiiiiiiich I kind of agree with but not really sure
[17:27] <rick_h_> hatch_: understood
[17:28] <rick_h_> hatch_: I think this is defintiely an experiment. I expect we'll have some feedback and debate on the subordinate thing
[17:28] <hatch_> rick_h_: are there any more bugs that are critical?
[17:29] <rick_h_> hatch_: no, I think the rest are just bugs we can avoid in any marketing material
[17:29] <hatch_> ok cool I'll hop back on my previous card
[17:29] <rick_h_> ty
[17:29] <hatch_> try and get that thing finally landed heh
[17:31] <frankban> jcsackett: LGTM
[17:31] <frankban> and done for the day, good night all!
[17:32] <rick_h_> night frankban!
[17:32] <rick_h_> hatch_: couple of notes on your review
[17:33] <rick_h_> jujugui can we get a second review of hatch_'s fix to unblock the orange box please? https://github.com/juju/juju-gui/pull/557
[17:50] <rick_h_> Makyo: I'd be intereted if that works with apache on the root container exposed and mysql and ghost in lxc containers on ec2
[17:51] <rick_h_> Makyo: but you need the feature flag to enable that https://github.com/juju/juju-gui/pull/551/files
[17:52] <Makyo> rick_h_, working on that now.  Can't use apache yet because ghost charm doesn't have the vhost config yet
[17:52] <Makyo> But haproxy will work
[17:52] <rick_h_> Makyo: oh, I thought it did apache
[17:52] <rick_h_> Makyo: ok cool
[17:52] <rick_h_> Makyo: was it nginx?
[17:52] <Makyo> rick_h_, not sure, just going by what hatch_ said when we talked through what we could do.
[17:53] <rick_h_> Makyo: ah ok cool thehn
[17:55] <hatch_> rick_h_: it relates to apache but apache doesn't know what to do without a vhost file
[17:55] <rick_h_> hatch_: gotcha
[17:55] <hatch_> kind of unfortunate it doesn't include even a default one heh
[18:04] <rick_h_> hatch_: shipping your branch
[18:04] <rick_h_> hatch_: thanks for the update, not sure where everyone has gone for the afternoon
[18:05] <hatch_> haha, it's beer oclock maybe
[18:07] <rick_h_> and the motox x won't be on verizon unlocked this time
[18:07] <rick_h_> time to move on
[18:15] <hatch_> :/
[18:15] <rick_h_> phone ordered, new carrier when it gets here
[18:52] <rick_h_> bah guess not ordered
[18:52] <rick_h_> moto site having issues
[19:00] <hatch_> heh I'm sticking with my m7 for a while
[19:00] <hatch_> I'm not sure what upgrading will get me
[19:04] <hatch_> I was thinking a nicer camera might be nice to have
[19:07] <rick_h_> yea, the camera is a big deal, the screen update, the wooden back I didn't get to have on the first one, and the new moto action stuff
[19:07] <rick_h_> but they don't want my $$
[19:07] <rick_h_> hatch_: ty for the update, qa's ok
[19:08] <hatch_> awesome glad we weren't too far off on the orange box stuff
[19:08] <rick_h_> nope, just trying to plan out how to record this demo now
[19:09] <hazmat> rick_h_, there's a bug fix out for deployer (0.4.1) need a minor increment on juju stable ppa for deployer.. some folks on local and openstack providers are seeing regression due to differential juju behavior wrt to post bootstrap contents of jenv file by provider.
[19:10] <hatch_> great
[19:10] <rick_h_> hazmat: rgr, have a link to the bug to use as a track point for us?
[19:12] <hazmat> rick_h_, https://bugs.launchpad.net/juju-deployer/+bug/1368403
[19:12] <mup> Bug #1368403: juju-deployer traceback AttributeError: 'NoneType' object has no attribute 'get_stat' <landscape> <juju-deployer:Fix Released by hazmat> <https://launchpad.net/bugs/1368403>
[19:12] <rick_h_> hazmat: rgr, will look and get a package updated. Tomorrow ok?
[19:12] <hazmat> rick_h_, sounds good
[19:13] <hazmat> rick_h_, thanks
[19:13] <rick_h_> hazmat: np
[19:14] <rick_h_> hazmat: got a sec for an openstack question?
[19:15] <hazmat> rick_h_, shoot
[19:15] <rick_h_> hazmat: doing a video demo of machine view on the orange box with the demo openstack installed
[19:15]  * hazmat nods
[19:15] <rick_h_> for the demo the best thing I can think of is to bring up the two empty machines on the orangebox as two more nove-compute nodes?
[19:15] <rick_h_> and manually place them on there to kind of demo 'growing your cloud' a bit?
[19:16] <rick_h_> is there anything else that's normally the first thing you'd think someone would 'scale up' or something more interesting for those two machines to be as demo material?
[19:16]  * rick_h_ is a bit of an openstack noob
[19:17] <hazmat> rick_h_, hmm... well in bringing up the cloud itself being able to place the parts onto colocated machines is interesting
[19:18] <rick_h_> hazmat: well I was going to start out with it placed via the demo script
[19:18] <hazmat> rick_h_, the add-unit -n 2 nova-compute is going to be pretty similiar.. its the placement of the infrastructure for density bit that's interesting
[19:18] <rick_h_> hazmat: and go through 'look at how it's placed and colocated, now let's use the new features to upgrade it a bit'
[19:18] <hazmat> ic
[19:18] <rick_h_> hazmat: yea, true. I was thinking of doing more rabbit nodes colocated
[19:18] <rick_h_> to expand messaging bandwidth, but that seemed kind of artificial
[19:19] <hazmat> rabbit clustered is okay.. its not totally artificial but i'm not sure how reliable its going to be
[19:19] <rick_h_> hazmat: anything you might deploy along side the openstack stuff?
[19:19] <rick_h_> that I could deploy on the two other nodes in some dense fashion and then relate into the openstacak deployment in a way that's interesting?
[19:19] <hazmat> rick_h_, ceilometer + mongo
[19:20] <hazmat> perhaps
[19:20] <rick_h_> yea, those are in the deployment. I could remove/add them in
[19:21] <rick_h_> ok, I'll play with the compute stuff for the demo. The density stuff will be more interesting in the smaller scale video/demo hatch_ and Makyo are doing.
[19:21] <rick_h_> this is more 'visualize the big' and theirs is more 'scale down things into the small'
[19:21] <rick_h_> hazmat: thanks
[19:22] <hazmat> rick_h_, drawing blanks atm.. the placement story via gui is primarily for custom placement/curation against limited number of machines.. the openstack overlap is primarily to the extent that people  want to deploy ostack on  a limited number of nodes. ie. above the cloud openstack is orthogonal for the most part.. another option might be just using a single maas node directly and placing a whole app st
[19:22] <hazmat> ack there (mediawiki, mysql, memcached, etc). the big data stuff isn't really well suited to density placement.
[19:23] <rick_h_> hazmat: rgr thanks
[19:35] <rick_h_> kadams54: can you check if the background is supposed to be transparent on the services header in MV?
[19:35] <rick_h_> kadams54: it seems really odd and if not, can you update that please?
[19:38] <rick_h_> Makyo: frames per second on the recording? is 15 ok or should it bump to 24?
[19:38] <Makyo> rick_h_, 15 is usually okay for a screencast
[19:38] <rick_h_> Makyo: ok cool then
[20:00] <hatch_> if it's going to be put on youtube why not record at the highest?
[20:03] <rick_h_> I'm way out of practice for doing these things.
[20:03] <rick_h_> take 2!
[20:14] <hatch_> *sigh* depending on where this add machine call is called from it has a different callback
[20:15] <hatch_> break time
[20:30] <kadams54> rick_h_: checking…
[20:33] <kadams54> rick_h_: you mean the Services tab?
[20:34] <rick_h_> kadams54: yes
[20:34] <rick_h_> the nav tab has a css rule setting hte background transparent and no border
[20:34] <rick_h_> and that seems off per designs
[20:36] <kadams54> rick_h_: Is this when the Services tab is active/selected? What should the color be?
[20:37] <kadams54> I looked through the visuals in Google docs and none of them deal with what the services tab should look like when active.
[20:38] <rick_h_> kadams54: true, I think it should stay white, the transparent is a bit of fail with the background/lines showing through
[20:38] <kadams54> rick_h_: I could revert to white with a border, but then it loses it's "tabbish" appearance: http://cl.ly/image/2w3b470i0n1C
[20:38] <rick_h_> when the MV is selected it's white and still has a border, maybe go bacak and look at the commit that added the styles there that are unsetting it
[20:38] <kadams54> That is, it doesn't move to the forefront among the other tabs.
[20:38] <rick_h_> and see if that had any data
[20:39] <rick_h_> kadams54: by data I mean a linked bug or anything
[20:39] <kadams54> Digging
[20:41] <rick_h_> Makyo: around?
[20:42] <kadams54> rick_h_: https://github.com/juju/juju-gui/pull/374 - doesn't appear to have a linked bug.
[20:43] <rick_h_> kadams54: k, thanks for the research. will look into it
[20:44] <kadams54> rick_h_: Another option (one that I'd prefer) would be to change it to #f2f2f2, which would match the canvas background: http://cl.ly/image/0J3t1C0o0q3n
[20:45] <rick_h_> yea, that's not bad
[20:45] <kadams54> Then the tab is clearly active but without letting the background leak through
[20:45] <rick_h_> I think that's what he was going for I bet
[20:45] <rick_h_> but the issue was I had a giant green relation line going through my header lol
[20:45] <kadams54> :-)
[20:45] <rick_h_> kadams54: k, can you move forward with that. We'll jfdi and see if anyone complains
[20:46] <rick_h_> kadams54: just trivial land the change you've got in front of you?
[20:46] <kadams54> jfdi?
[20:46] <rick_h_> just f'ing to it :)
[20:46] <rick_h_> do it
[20:46] <hatch_> DO IT
[20:46] <rick_h_> whoops
[20:46] <hatch_> don't tell anyone but the millions who have access to the channel logs
[20:46] <kadams54> Hah, urban dictionary to the rescue
[20:47] <kadams54> Should I push directly to develop?
[20:47] <hatch_> pssht to trunk!
[20:47] <kadams54> :-b
[20:47] <rick_h_> kadams54: no, do a pr and mark trivial and shipit please
[20:47] <kadams54> Will od
[20:47] <rick_h_> ty
[20:47] <kadams54> do even
[20:50] <rick_h_> Makyo: sending email to peeps, data from screencast is in the dropbox folder
[20:50] <hatch_> not having the ecs update ghost models to real models is seriously causing disasters
[20:50] <hatch_> like I'm surprised this works at all!
[20:50] <Makyo> rick_h_, excellent, thanks
[20:50] <rick_h_> jujugui feel free to listen/look (have to manually sync audio to video) and let me know if it's too bad to use
[20:50] <hatch_> ok thats a little dramatic
[20:51] <rick_h_> there's two of them there at the moment, might try a third depending on feedback before I return the orange box tonight
[20:51] <rick_h_> hatch_: huh?
[20:51] <Makyo> STandard hatch_ fare, then :)
[20:51] <rick_h_> hey, I've got two screencasts showing it work!
[20:51] <kadams54> lol
[20:52] <hatch_> Makyo:  lol true
[20:52] <Makyo> And I'm working on a third, including containerization
[20:52] <hatch_> rick_h_:  how do I get the screencast?
[20:52] <rick_h_> hatch_: go to the dropbox link in the email and open the ogv file and lay the audio file that goes with it and sync the two up so what you see matches what you hear
[20:52] <rick_h_> hatch_: and then do a little dance and three spins and make some more coffee
[20:53] <hatch_> hmm yeah no ogv file there for me
[20:53] <rick_h_> no?
[20:53] <hatch_> a bunch of au files
[20:53] <hatch_> and two aup files
[20:54] <Makyo> hatch_, they have icons.
[20:54] <Makyo> One says 'orangebox maas'
[20:54] <rick_h_> hatch_: go to the list view
[20:54] <Makyo> Oh, just that one, whoops.
[20:54] <rick_h_> hatch_: in the list view it shows up better
[20:55] <rick_h_> machine-view-1.(aup/ogv) and machineview2.aup + machine-view-2.ogv
[20:55] <hatch_> oh there they are
[20:55] <rick_h_> I'm consistant with my naming...almost
[20:55] <hatch_> odd...they just showed up while I was looking at it
[20:55] <rick_h_> might have still been uploading?
[20:55] <rick_h_> little icon wasn't spinning so thought they were done
[20:56] <hatch_> probably their db propagation taking a while
[20:56]  * rick_h_ has to get the kiddo from school
[20:56] <rick_h_> Makyo: if you can listen sooner vs later I'd appreciate it to know if I need to do one more try before I've got to leave to take it back to jcastro tonight
[20:56] <Makyo> rick_h_, sure, will see about grabbing the audacity files.
[20:57] <Makyo> Guess I could just save to my dropbox
[20:57] <rick_h_> hmm yea tried to share with juju-gui-peeps but didn't work out
[20:57] <rick_h_> so not sure.
[20:57] <hatch_> this is the first time I've used dropbox... I think I prefer drive
[20:57] <rick_h_> ok, afk biab
[21:10] <hatch_> ok I think I finally got it....sometimes a good break helps clear the mind
[21:14] <hatch_> the indentation that the linter wants for the break; statement in switches is just odd...
[21:19] <rick_h_> hatch_: :P
[21:20] <hatch_> I now have to rewrite all the tests.....BUT somehow every current test didn't fail...
[21:20] <rick_h_> :/
[21:20] <hatch_> suspicious......vewy suspicious
[21:34] <hatch_> Makyo: was it you that did the orange star thing for config changed stuff? http://imgur.com/gjPWIjh
[21:49] <Makyo> hatch_, 404
[21:50] <hatch_> oops sorry creating bug atm will post the link 2 secs
[21:50] <Makyo> Sure
[21:50] <hatch_> Makyo: https://bugs.launchpad.net/juju-gui/+bug/1370260
[21:50] <mup> Bug #1370260: Saving configuration settings creates white block and checkbox css issue <juju-gui:New> <https://launchpad.net/bugs/1370260>
[21:51] <hatch_> reading the source it seems like this would happen heh...not sure how it worked before :)
[21:51] <Makyo> Okay
[21:51] <hatch_> my guess is a css conflict now
[21:51] <Makyo> I don't have time for it if we're fucking with orangebox today.
[21:52] <Makyo> rick_h_, the second audacity project is corrupted for me.  Can you just export WAV files for both of them?  That's all kdenlive will take, anyway.
[21:52] <hatch_> yeah np just making you aware
[21:55] <rick_h_> Makyo: rgr, looking
[21:58] <rick_h_> Makyo: uploading to dropbox
[21:58] <Makyo> rick_h_, cool, thanks
[21:59] <rick_h_> darn slow upload speeds
[22:13] <rick_h_> Makyo: wav file uploaded
[22:13] <rick_h_> well, think it is, it's more than 44 bytes dropbox
[22:14] <rick_h_> Makyo: well it should be updated soon I guess. It's done syncing according to my client
[22:15] <hatch_> stepping away for a bit picking the pooch up from getting his hair cut
[22:15] <Makyo> rick_h_, alright, cool.  Will grab it in a second.
[22:15] <rick_h_> Makyo: ok, it's actually the 'Richard Harding's conflicted copy' one
[22:18] <Makyo> Cool, got it.  Will get the videos done tonight
[22:19] <rick_h_> Makyo: ok cool thanks
[22:19]  * rick_h_ shuts down the orange box and teary eye'd prepares to sent it home
[22:22] <Makyo> We'll miss you~
[22:39] <hatch_> back
[22:40] <hatch_> oh thanks Makyo
[22:40] <hatch_> oh you meant Obee....
[22:40] <hatch_> :'(
[22:40] <Makyo> Didn't miss you one bit, sorry.
[22:40] <Makyo> :)
[22:41] <hatch_> lol
[22:42] <Makyo> Obee is a sandwich place out here, hard for me to shake that.
[22:42] <Makyo> Well, Obee's.
[22:49] <hatch_> hmm sandwitch
[22:49] <hatch_> I think I'll have a leftover pork sandwich for supper tonight
[23:03] <huwshimi> Morning
[23:05] <hatch_> morning huwshimi
[23:05] <hatch_> how goes the morning?
[23:07] <huwshimi> hatch_: I get to fight writing a test that I couldn't figure out yesterday :)
[23:10] <huwshimi> hatch_: Some friends of mine just moved to Canada.
[23:11] <huwshimi> hatch_: Turns out they're in Saskatchewan!
[23:12] <huwshimi> hatch_: Not only that, but they're in Saskatoon!
[23:28] <hatch_> huwshimi: no way?
[23:28] <huwshimi> hatch_: I've known they were moving there for 6 months or so, but I had no idea where to
[23:28] <hatch_> haha so are they moving here for industry jobs?
[23:28] <huwshimi> (known they were moving to Canada)
[23:29] <huwshimi> hatch_: I think the guy has a job as a biologist at a university or something there
[23:29] <hatch_> ahh very cool
[23:29] <hatch_> so have they moved?
[23:30] <huwshimi> hatch_: His contract expired so they looked around for similar jobs and ended up over there.
[23:30] <huwshimi> hatch_: yeah they moved a few weeks ago
[23:30] <hatch_> haha that's awesome
[23:30] <hatch_> small damn world
[23:31] <huwshimi> yep
[23:31] <hatch_> see it is a real place :P
[23:31] <huwshimi> hatch_: Still doesn't make me believe the place exists though
[23:31] <huwshimi> haha
[23:32] <hatch_> rofl
[23:33] <hatch_> wow that's crazy....
[23:41] <hatch_> huwshimi:  I'm going to be putting in some sporadic OT today....trying to get this stupid branch done - so if you need anything just ping
[23:42] <huwshimi> hatch_: Sure, I'm about to propose a branch that I have no idea if it is doing things in an even remotely sane way, so that'll probably need a review :)
[23:42] <hatch_> haha sounds like a plan
[23:44] <huwshimi> hatch_: https://github.com/juju/juju-gui/pull/560
[23:53] <hatch_> huwshimi: looks good just some trivial comments
[23:53] <hatch_> I haven't qad yet
[23:53] <huwshimi> hatch_: Ah great, thanks!


[05:53] <twb> Is /lib/init/fstab an upstartism?
[05:53] <twb> lxc-ubuntu creates it, but I'm not sure what uses it
[05:54] <ectospasm> this channel seems underpopulated, and the Upstart documentation seems woefully inadequate.
[05:55] <ectospasm> ...I never see any adequate answers to questions like that here.
[05:57] <twb> ectospasm: I know, but it costs me little to try
[05:58] <ectospasm> true enough
[08:36] <twb> If I'm running upstart inside a container, how do I pass --debug to it?
[08:36] <twb> (container as in LXC)
[08:36] <mbiebl> twb: to be precise, /lib/init/upstart is used by mountall
[08:37] <mbiebl> but yes, it is upstart specific (as is mountall)
[08:37] <twb> OK.
[08:38] <twb> I'm trying to run lucid in an LXC container, but unless I rip out most of /lib/init/fstab, it doesn't start a getty on /dev/console and there's no other output on /dev/console, and I don't know how to work out why -- short of bisecting over /lib/init/fstab
[08:39] <mbiebl> which directories fail to mount under lxc?
[08:40] <twb> mbiebl: I don't know
[08:40] <twb> I don't know *how* to know
[09:43] <twb> In /lib/init/fstab, is "showthrough" a mountallism?
[09:43] <twb> i.e. if I'm moving those mountpoints to pre-upstart code, do I just strip that option out?
[09:45] <mbiebl> showthrough from what I know allows you to mount /var/run early during boot
[09:45] <mbiebl> and later /var
[09:45] <mbiebl> and /var/run won't be shadowed
[09:45] <twb> Oh, I see.
[09:46] <twb> That means I don't need it for my specific use case
[09:49] <mbiebl> twb: if you don't have a separate /var, yes
[09:49] <mbiebl> (not sure if that is even possible within an lxc container)
[09:50] <twb> Yeah, but I happen to not be doing it :-)
[10:10] <twb> Dumb question: does that mean ubuntu/upstart ignores RAMRUN=yes RAMLOCK=yes in /etc/default/rcS?
[10:11] <mbiebl> yes
[10:11] <twb> Hum.
[11:17] <twb> Due to the way LXC operates, I want to instrument wherever the upstart calls the "real" (hard) halt
[11:17] <twb> I can't see where that's happening in /etc/init -- is it done elsewhere?
[11:18] <mbiebl> /etc/init/rc.conf
[11:18] <mbiebl> it calls /etc/init/rc 0|6 on shutdown/reboot
[11:19] <twb> Ah, and the hard halting is done by it
[11:20] <mbiebl> it is done in S90reboot resp. S90halt
[11:20] <twb> Right, I juts found it
[11:52] <twb> Is it just me, or does upstart get pissy if its pid isn't 1
[11:52] <twb> kill -9 1 wasn't working, so my first idea was to make upstart the not-quite-first init
[11:52] <mbiebl> it needs to be pid 1
[11:53] <ectospasm> twb: init is always 1
[11:53] <twb> Because the kerenl gives special treatment to 1?
[11:53] <ectospasm> init is the parent process of everything
[11:53] <ectospasm> init cannot be a child of some other process
[11:53] <ectospasm> old school UNIXy design, IIRC
[11:53] <mbiebl> pid 1 has special semantics
[11:54] <mbiebl> re-parenting of child processes etc
[11:54] <twb> Is there a way to get "kill -9 1" or similar to work?
[11:54] <ectospasm> twb: what are you trying to achieve with "kill -9 1"?
[11:55] <mbiebl> killing pid 1 will result in a kernel panic
[11:55] <twb> I'm in a container, and halt/reboot -f doesn't work quite right, but I'm told LXC will do the right thing if I instea terminate the init process
[11:58] <twb> mbiebl: short of HTFS, is there a way to tell upstart "I know better than you, please let me kernel panic"?
[12:00] <mbiebl> twb: I know there were problems in the past related to openvz and upstart
[12:00] <mbiebl> I can't tell you more, sorry
[12:00] <Keybuk> there's nothing about Upstart that would cause kill -9 1 to not work
[12:01] <Keybuk> if kill isn't working, you have a kernel problem
[12:01] <Keybuk> (which was implied by you saying you were using LXC, I realise)
[12:01] <twb> Keybuk: my host OS is 10.04 (running stock lucid 2.6.32) -- could I fix this with a different / newer kernel?
[12:01] <Keybuk> no idea
[12:02] <twb> Or are you saying that "LXC is just wrong"?
[12:03] <Keybuk> I was ;)
[12:04] <twb> Grmph
[12:04] <Keybuk> I'm not a fan
[12:05] <twb> mbiebl: in case you don't know, lxc is basically openvz cleaned up and accepted into mainline
[12:07] <twb> Well, lucid doesn't boot if /var/run isn't a tmpfs, and lxc doesn't detect the guest halting if /var/run is a tmpfs, so it looks like I'll have to give up and use KVM, taking the performance hit that emulating an entire peecee for every daemon implies
[12:08] <twb> (If lxc doesn't see the domU pid 1 terminate, it does a dirty hack by watching /var/run/utmp for a restart event, but it can't see it when there's a tmpfs mapped over the top.)
[12:09] <Keybuk> that sounds like a bug in lxc
[12:12] <twb> mjt (in #lxcontainers) said: well, the prob can be solved in two places.  Either proper (for a container) sys_reboot in kernel (this is what halt -f is using), or in init.  So far kernel folks tells us "it can be done in userspace" (in init), and init folks say "kernel is wrong".
[12:20] <twb> mjt said -9 might be special
[12:20] <twb> So I just tried everything from -1 up, and -8 worked
[12:21] <twb> So I *think* I can just edit /etc/init.d/S90halt to call "kill -8 1" instead of "halt -f"
[12:24] <Keybuk> if kill -9 1 is being treated as special, it's being treated as special by the kernel ;-)
[12:24] <Keybuk> so again, the fix for that should go in the kernel
[12:24] <twb> I guess so.  Sorry for losing my temper.
[12:25] <Keybuk> so the discord is because when you write software on any platform, you agree to a contract between yourself and things like the kernel for how you should operate
[12:25] <Keybuk> something like init is even more important, it has special behaviours that aren't granted to ordinary processes
[12:25] <Keybuk> so the contract (ie. API/SDK) between you and the kernel is very important
[12:26] <Keybuk> the reason init authors tend to dislike things like LXC is that it makes the kernel break that contract
[12:26] <Keybuk> and the LXC folks seem to think it's our fault
[12:26] <Keybuk> now, if container authors could agree on an alternate contract
[12:27] <Keybuk> *and* provide ways for init to be told which contract we should use
[12:27] <Keybuk> things would be better
[12:27] <Keybuk> but historically they've been unwilling to do that
[12:27] <twb> I suppose they argue the whole point is you shouldn't be able to tell you're in a container
[12:27] <Keybuk> (OpenVZ, LXC, etc. have all randomly changed their APIs and which kernel features they support between releases)
[12:27] <Keybuk> and right, they argue that a call to tell whether you're in a container defeats the point
[12:27] <Keybuk> and our counter-argument is that we *CAN* tell we're in a container
[12:28] <Keybuk> we can tell because the kernel is not obeying its interface contract to userspace
[12:28] <twb> haha
[12:28] <Keybuk> they can't have their cake and eat it
[12:28] <Keybuk> if a container should be invisible, it should also be invisible to init
[12:28] <Keybuk> if init should handle containers specially, so should all user space processes be able to
[12:36] <twb> OK, I think I have it actually working
[12:37] <twb> Now a kill -2 to lxc-start (or upstart) from the dom0 will make upstart see a ctrl-alt-del, and at the end of that, /etc/init.d/reboot (or halt) will kill -SEGV 1, which lxc-start "sees" and handles the cleanup of stuff above upstart.