[00:22] <davecheney> it is strange
[00:23] <davecheney> i've seen more piture of HRH in NZ that I have in Au
[01:25] <mup> Bug #1588636 changed: mgo: Panic: Test left sockets in a dirty state (PC=0x46257C) <panic> <unit-tests> <juju-core:Invalid> <https://launchpad.net/bugs/1588636>
[01:27] <davecheney> spot the bug         if err != nil && err == mgo.ErrNotFound {
[01:27] <davecheney>                 return errors.Trace(err)
[01:27] <davecheney>         }
[01:28] <natefinch> aside form the err != nil being extraneous?
[01:28] <natefinch> errors.Cause?
[01:29] <natefinch> if errors.Cause(err) == mgo.ErrNotFound { return errors.Trace(err) }
[01:29] <davecheney> yeah, it's eaither
[01:30] <davecheney> err != nil && err != mgo.ErrNotFound
[01:30] <davecheney> or err == mgo.ErroNotFound
[01:30] <davecheney> but the latter would mean ignoreing any error other than mgo.ErrNotFound
[01:31] <natefinch> well, yes.. it depends on the rest of the error stack to figure out which one they meant
[01:31] <natefinch> er s/error stack/context of the code
[01:32] <natefinch> I kinda hate errors.Trace.  It just adds so much noise to the code.   If we had the stacktrace on the error, I don't think I'd ever use trace.
[01:33] <davecheney> https://github.com/juju/juju/commit/93d52ed7
[01:33] <davecheney> fix some log messages ... and add an entire state/presence package
[01:33] <davecheney> no biggie
[01:34] <davecheney> natefinch: that's why my errors package captures the full stacktrace at the point of creatin
[01:34] <davecheney> it has some drawbacks
[01:34] <davecheney> but compared to errors.Trace turds everywhere
[01:34] <davecheney> it's paid for itself
[01:36] <natefinch> davecheney: that commit is pretty funny... I presume the presence stuff was intended to be committed separately
[01:36] <natefinch> davecheney: also, whoowee that is some old code
[01:37] <davecheney> yeah, that line is older than some of your kids
[01:37] <natefinch> davecheney: this is true.
[01:47] <natefinch> wallyworld: I spent Friday looking at the logs, but I can't see any differences between the setaddress calls that work and those that fail. I'm printing out the entire list of operations... and the ones that work look identical to the ones that fail.. and the ones that fail, the ops don't change from attempt to attempt, as they should if things were actually changing.
[01:47] <davecheney> natefinch: https://github.com/juju/juju/pull/5537 if you feel so inclined
[01:49] <wallyworld> natefinch: maybe we need to log what is actually in the db
[01:50] <natefinch> wallyworld: yeah, I had that in there and then must have deleted it while debugging why I wasn't getting any log output.    LGTM
[01:56] <davecheney> natefinch: didn't fail before : didn't fail afterwards :)
[01:57] <natefinch> what I wouldn't give for separate persistence layer
[01:58] <davecheney> you had me at separate layer
[03:06] <davecheney> https://bugs.launchpad.net/juju-core/+bug/1589339
[03:06] <mup> Bug #1589339: environs/manual: test failure if host does not have a valid reverse dns record <juju-core:New> <https://launchpad.net/bugs/1589339>
[03:06] <davecheney> nice
[03:06] <natefinch> lol
[03:08] <davecheney> solution: hack /etc/hosts
[03:09] <davecheney> test isolation, how does it work?
[03:10] <mup> Bug #1589339 opened: environs/manual: test failure if host does not have a valid reverse dns record <juju-core:New> <https://launchpad.net/bugs/1589339>
[03:13] <mup> Bug #1589339 changed: environs/manual: test failure if host does not have a valid reverse dns record <juju-core:New> <https://launchpad.net/bugs/1589339>
[03:22] <mup> Bug #1589339 opened: environs/manual: test failure if host does not have a valid reverse dns record <juju-core:New> <https://launchpad.net/bugs/1589339>
[03:24] <natefinch> davecheney: wow, I just noticed from an offhand comment on golang-nuts that builds are now deterministic... that's amazing
[03:25] <davecheney> natefinch: cool
[03:25] <davecheney> i hope it lasts
[03:25] <davecheney> googlers don't care about byte for byte comparisons
[03:25] <davecheney> and there is no test for it
[03:25] <natefinch> davecheney: gah, there should be a test for it
[03:25] <natefinch> davecheney: it's SOOOO useful
[03:38] <wallyworld> axw: here's part 1. next I can introduce a get-controller-config CLI and make get-model-config only show the model specific bits; we can also pass in config from cloud.yaml as controller config at bootstrap time
[03:38] <wallyworld> http://reviews.vapour.ws/r/4983/
[03:38] <axw> wallyworld: thanks, just saw. just from reading the summary: why in the "controllers" collection rather than the settings collection?
[03:39] <wallyworld> axw: collection needs to be global
[03:39] <wallyworld> so all models can always read the controller config
[03:39] <axw> wallyworld: ok
[03:40] <wallyworld> axw: i started out in settings and it all went to shit with different hosted models
[03:40] <wallyworld> we now use that controllers collection for a few things it seems
[03:42] <wallyworld> axw: once this gets a +1 or whatever, let me know where you're at so we can decide what bit i should do next - the CLI or controller config from clouds.yaml. also, i think we need to handle the case for things like resource-tags where the model values don't overwrite but merge
[03:43] <axw> wallyworld: sure. merging config sounds like something we don't need to do right away
[03:44] <wallyworld> yeah
[03:44] <wallyworld> axw: i should have said in the PR, but a bunch of the green is model config stuff moved from state.go to its own modelconfig.go file
[03:45] <axw> wallyworld: yep, thanks
[03:45] <wallyworld> and i found some old code to delete also
[03:52] <mup> Bug #1589350 opened: apiserver/provisioner: tests do not pass with go 1.7 beta 1 <juju-core:New> <https://launchpad.net/bugs/1589350>
[04:07] <mup> Bug #1589350 changed: apiserver/provisioner: tests do not pass with go 1.7 beta 1 <juju-core:New> <https://launchpad.net/bugs/1589350>
[04:10] <mup> Bug #1589350 opened: apiserver/provisioner: tests do not pass with go 1.7 beta 1 <juju-core:New> <https://launchpad.net/bugs/1589350>
[04:10] <mup> Bug #1589351 opened: provider/azure: test failure during stress test <juju-core:New> <https://launchpad.net/bugs/1589351>
[04:16] <davecheney> https://launchpad.net/bugs/1589353 what a shitshow
[04:16] <mup> Bug #1589353: apiserver/annotations: test failure during setup <juju-core:New> <https://launchpad.net/bugs/1589353>
[04:40] <mup> Bug #1534757 changed: Attempting to run charm before unit provisioned, 1.26 <2.0-count> <juju-release-support> <lxd> <juju-core:Expired> <https://launchpad.net/bugs/1534757>
[04:40] <mup> Bug #1589353 opened: apiserver/annotations: test failure during setup <juju-core:New> <https://launchpad.net/bugs/1589353>
[04:41] <davecheney> axw: wallyworld https://github.com/juju/testing/pull/101
[04:41] <davecheney> here is a simple one
[04:41] <wallyworld> ok
[04:43] <wallyworld> davecheney: ty, nice to see that fixed
[04:43] <davecheney> wallyworld: it's one of those bugs that doesn't stay fixed
[04:44] <davecheney> wallyworld: i've been trying to repro https://bugs.launchpad.net/juju-core/+bug/1588574
[04:44] <mup> Bug #1588574: Session already closed in state/presence <blocker> <ci> <intermittent-failure> <juju-core:In Progress by dave-cheney> <https://launchpad.net/bugs/1588574>
[04:44] <davecheney> but all i've acomplished so far today is raising 4 extra bugs
[04:44] <wallyworld> yeah, the presence stuff sucks
[04:45] <wallyworld> axw: we'll need to get to the inheritance stuff pretty quickly to allow config from clouds.yaml to be handled. i guess we should keep controller only config like api port totally separate from anything that can be inherited
[04:47] <axw> wallyworld: unless it's going to be a huge amount of rework (didn't look like it), I'd feel more confident reviewing them separately.
[04:48] <wallyworld> ok
[04:49] <anastasiamac> davecheney: did u try to remove omitempty as per my suggestion?
[04:50] <davecheney> anastasiamac: no i did not i'm sorry
[04:50] <davecheney> i'm still trying to reproduce the error locally
[04:50] <davecheney> anastasiamac: why will changing the json part of a struct fix the bug ?
[04:50] <anastasiamac> davecheney: it does not cause probs for me except at landing :D
[04:51] <anastasiamac> davecheney: every attemp at landing came up with the error messaage u r chasing "session closed"
[04:51] <anastasiamac> davecheney: possibly unrelated and was just this PR's luck  :-P
[04:52] <davecheney> anastasiamac: yeah, i cannot reprodyce the bug locally either
[04:52] <davecheney> i'm trying to build an environment in ec2 that matches CI
[04:52] <davecheney> but i keep hitting flakey tests
[04:52] <anastasiamac> davecheney: \o/
[04:52] <davecheney> i've raised 4 bugs already today and haven't managed to run all the tests successfully
[04:53] <anastasiamac> davecheney: it's sad but even that makes a productive day :-P
[04:54] <davecheney> if I fix all 4 bugs I raised, then I'm back to square one, so that's something
[04:55] <anastasiamac> :D
[05:06] <davecheney> spoiler alert: i'm probably not goig to fix all four today
[05:13] <anastasiamac> funny and here I was looking forward to watching it all being fixed today :D
[05:14] <wallyworld> axw: bbiab, almost got a revised branch ready, but school pickup
[05:52] <mup> Bug #1589372 opened: state: state test failure during stress test <juju-core:New> <https://launchpad.net/bugs/1589372>
[07:02] <mup> Bug #1589385 opened: leftover eth0.cfg in /etc/network/interfaces.d <4010> <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1589385>
[07:11] <davecheney> mongodb is such a pile of crap
[07:19] <davecheney> I _finally_ got the bug to trigger locally
[07:22] <anastasiamac> davecheney: \o/ how?
[07:22] <davecheney> anastasiamac: persistance
[07:22] <davecheney> just need enough load
[07:22] <davecheney> in the right way
[07:23] <anastasiamac> well done! ;-P
[07:32] <davecheney> https://github.com/juju/testing/pull/102
[08:44] <wallyworld> axw: would you yave time to look at http://reviews.vapour.ws/r/4972/ ? it needs to merge into the feature branch
[09:01] <dimitern> voidspace, fwereade: standup?
[09:01] <dimitern> dooferlad: ^^
[09:05] <voidspace> dimitern: sorry, omw
[09:05] <voidspace> got distracted
[09:34] <dimitern> fwereade: how does the advice to return concrete errors (e.g. ErrFooFailed) align with "no global variables" ?
[09:35] <dimitern> (as I suspect global consts are fine)
[10:06] <davecheney> fwereade: https://github.com/juju/juju/pull/5543
[10:06] <davecheney> if you have the time
[10:25] <fwereade> dimitern, ha :) good point, possibly error types are safer? I have been bitten a couple of times by people assigning to stuff that's "obviously" a global "constant" variable
[10:25] <fwereade> dimitern, but types don't quite feel like they pay for themselves?
[10:26] <dimitern> fwereade: yeah, I suspect so
[10:26] <dimitern> fwereade: it's nice to use if errors.Cause(err) == ErrMyFooFailed
[10:28] <dimitern> fwereade: well, I guess if we define type SimpleError string and func (s SimpleError) Error() { return s }, we can define all such concrete errors as const ErrFooFailed SimpleError = "foo failed"
[10:28] <dimitern> and get both the const guarantee and no global vars
[10:29] <fwereade> davecheney, LGTM
[10:30] <fwereade> dimitern, mm, I think I like that
[10:30] <fwereade> dimitern, neat
[10:32] <dimitern> fwereade: it even works: https://play.golang.org/p/jbCEra4_xi
[10:33] <dimitern> (and it should be almost the same using Cause())
[10:37] <dimitern> fwereade: re tests isolation, while treating tests and production code the same: given a ctor NewFooForSeries(series string) (Foo, error); and Foo being an interface with concrete (unexported) implementations per series
[10:39] <dimitern> fwereade: how to properly isolate this for tests (assuming e.g. Foo.GetFoo() returns different results based on what's there on the local machine)? One option is to allow "dummy" as series and construct a no-op Foo, that has extra methods tests can use to set a pre-canned result from GetFoo()..
[10:50] <fwereade> dimitern, I *think* that if they differ interestingly enough to be different types they deserve different ctors for direct testing? then you can have a wrapper around a map[series]ctor with shims as necessary and test that as much as it needs -- but it's much closer to being purely data-driven
[10:52] <fwereade> dimitern, and then if NewXenialFoo returns an exported *XenialFoo it seems sane/good to check the underlying types that come out of a Foo factory
[10:53] <dimitern> fwereade: I was thinking something like this might work: https://play.golang.org/p/bW-TI4l8yI
[10:53] <fwereade> dimitern, or rather checking that some series return a *UpstartFoo and others a *SystemdFoo
[10:54] <dimitern> fwereade: and the dummyRouteSource there is perfectly valid at run-time, but will be mostly used by tests; no special treatment
[10:56] <dimitern> fwereade_: hey, did you get the last link?
[10:56] <fwereade_> dimitern, I think I'd rather see a *WindowsRouteSource and a *LinuxRouteSource
[10:56] <fwereade_> dimitern, don't think so
[10:57] <fwereade_> dimitern, (both the above could be unit tested everywhere, I think?)
[10:57] <dimitern> fwereade_: here:https://play.golang.org/p/bW-TI4l8yI
[10:57] <fwereade_> ah I did see that one
 dimitern, or rather checking that some series return a *UpstartFoo and others a *SystemdFoo
 dimitern, is anything in there so platform-specific it needs build tags?
[10:58] <dimitern> fwereade_: my point is NewRouteSource() will be called somewhere early as part of a lot of tests, and by default it can use the dummyRouteSource
[10:58] <dimitern> fwereade_: it needs to use different sources (usually execute different tools and parse different outputs)
[10:58] <fwereade_> dimitern, I was thinking I'd rather have an explicit NewFakeRootSource() for tests?
[10:59] <dimitern> fwereade_: that's cleaner perhaps
[10:59] <fwereade_> dimitern, and, yeah, but you don't want to hit the actual OS with those calls in unit tests
[10:59] <dimitern> fwereade_: and the Fake one can implement e.g. SetRoutes() in addition to GetRoutes() from RouteSource
[11:00] <fwereade_> dimitern, yeah, that sounds good, or you could just pass them in in the ctor
[11:00] <fwereade_> dimitern, harder for people to induce races ;p
[11:01] <dimitern> fwereade_: I really don't want to repeat earlier mistakes, e.g. patching the package tests for GetRoutes() to use faked ones, but providing no easy way to do the same outside the package
[11:01] <fwereade_> dimitern, quite so, it feels to me like it's a foo/footest.NewRouteSource(...) situation
[11:01] <dimitern> fwereade_: routes as Fake ctor args is nice! will do that
[11:02] <fwereade_> dimitern, where do we need to thread the routes through to, by the way?
[11:03] <dimitern> fwereade_: and having specific ctor's (NewWindowsRouteSource) rather than a switch-sorta-factory feels better - NewWindowsRouteSource can still be there but it's impl. can be in a +build windows - guarded file
[11:04] <fwereade_> dimitern, why hide it away? just makes it easier to break when you're not running on windows
[11:04] <dimitern> fwereade_: atm I need to implement and parse "get default route", and then use it as part of the container provisioing step
[11:04] <fwereade_> dimitern, unless it's guarding actual syscalls I'd rather steer clear of +build where possible
[11:05] <dimitern> fwereade_: fair point
[11:05] <dimitern> fwereade_: it's more about guarding against the lack of a windows-specific tool
[11:05] <fwereade_> dimitern, ok, but we don't want to *actually* call the tool in the unit tests, regardless of system
[11:09] <dimitern> fwereade_: nope, only in the package tests
[11:09] <dimitern> fwereade_: we'll call a patched executable for the tool
[11:10] <dimitern> fwereade_: I was thinking of using natefinch's PatchExec that uses jujud as the binary to call
[11:10] <dimitern> fwereade_: and outside of the package, the NewDummyRouteSource() will be used in all tests
[11:15] <dimitern> fwereade_: how does that sound?
[11:18] <fwereade_> dimitern, do we have to PatchExec or can we supply, e.g., a `func RunCommand(string, ...string) (notsurewhattoreturn, error)`
[11:18] <dimitern> fwereade_: https://github.com/juju/testing/blob/master/cmd.go#L203
[11:19] <dimitern> it's essentially what it does - patching exec.RunCommand
[11:20] <dimitern> fwereade_: "patching" is incorrect here, as nothing is actually patched
[11:20] <dimitern> fwereade_: AIUI we're using GetExecCommand when needed in the suite, rather than using PatchValue()
[11:21] <axw> wallyworld: I gave that PR a LGTM on GitHub already
[11:22] <wallyworld> axw: oh great ty. just about to push up a new revision of the other. found a bug where we were setting up cfg with controller uuid and then initialising state with something else
[11:22] <axw> wallyworld: cool. I probably won't be able to review till the morning tho, sorry
[11:22] <wallyworld> and then there were inconsistencies. may have just been tests
[11:22] <wallyworld> that's fine
[11:24] <fwereade_> dimitern, I think it *does* still depend on some magic patching, from having to embed that suite, and I think it smells a bit maybe? -- but it *does* still give you a real *exec.Cmd, which *is* pretty cool
[11:25] <fwereade_> dimitern, so that sounds reasonable to me
[11:25] <dimitern> fwereade_: ah, sorry - PatchValue can be used after all (e.g. environs/tools/build_test.go:TestGetVersionFromJujud), but isn't necessary (e.g. cmd/juju/commands/main_test.go:TestFirstRun2xFrom1xNotUbuntu - we can just run the patched command directly with CaptureOutput)
[11:26] <dimitern> I quite like that approach :)
[11:26] <dimitern> s/that/that second/
[11:26] <dimitern> fwereade_: ok, cheers
[11:26] <fwereade_> dimitern, right, ok, but what's writing to os.Stderr/out in the first place? doesn't having to capture those imply broken isolation?
[11:27]  * fwereade_ may well be missing something
[11:27] <dimitern> fwereade_: I think it's still isolated, see: CaptureOutput creates both stderr and stdout in isolation
[11:28] <dimitern> https://github.com/juju/testing/blob/master/cmd.go#L307
[11:28] <fwereade_> dimitern, yeah, that's what's bothering me -- what is causing stuff to be written to os.Std* that we need to patch it out in :317?
[11:29] <dimitern> fwereade_: exec.Cmd.Run() does
[11:30] <fwereade_> dimitern, this feels like a sign that the (string, ...string) shortcut is maybe the source of the problem
[11:30] <fwereade_> dimitern, only if you don't set the command up properly ;p
[11:33] <fwereade_> dimitern, utils/exec doesn't seem that great for replacing either, though, what with RunParams actually being stateful
[11:33] <dimitern> fwereade_: so you're saying rather than embedding PatchExecHelper, then using GetExecCommand() and CaptureOutput, use a ctor e.g. NewWindowsRouteCmd() that sets it up to run "route print", and NewLinuxRouteCmd() doing "ip route ..", and a NewFakeRouteCmd() taking args and output?
[11:35] <dimitern> by "sets it up to run" I mean &exec.Cmd{Args: .., Path: .., Stdin: inBuf.Reader(), ..}
[11:35] <fwereade_> dimitern, I don't *think* so? if we need the types we need the routes, I presume -- clients will just want to accept a `Routes`, right?
[11:35] <dimitern> s/I mean/I mean return/
[11:36] <dimitern> fwereade_: Routes like []RouteInfo argument to the OS-specific RouteSource ctor?
[11:37] <fwereade_> dimitern, no, just a type encapsulating the routes, already created
[11:38]  * dimitern steps out for ~30m
[12:02] <frobware> dooferlad: ping
[12:04] <dooferlad> frobware: pong
[12:14] <frobware> dooferlad: for the reboot cloud-init stanzas - did that work for all of precise, trusty and xenial?
[12:17] <dooferlad> frobware: IIRC, yes
[12:20] <mup> Bug #1589471 opened: Mongo cannot resume transaction <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1589471>
[12:37] <dooferlad> frobware: that branch that did the reboot is gone :-(
[12:38] <frobware> dooferlad: do you recall the name of the branch?
[12:38] <dooferlad> frobware: no
[12:38] <frobware> dooferlad: I have you as a git remote
[12:41] <dooferlad> frobware: git reflog to the rescue :-)
[12:43] <frobware> dooferlad: http://pastebin.ubuntu.com/17060265/
[12:43] <dooferlad> frobware: yep
[12:45] <frobware> dooferlad: just shows how long we've been futzing with this
[12:46] <dooferlad> frobware: no wonder we have a bit of a bunker mentality
[14:00] <frobware> dooferlad: ping
[14:02] <dooferlad> frobware: pong
[14:08] <frobware> dooferlad: please could you capture the output (or perhaps lack of) for the bond/LACP issue and raise a bug.
[14:08] <frobware> dooferlad: asking as you definitively have more NICs.... :)
[14:11] <dooferlad> frobware: it simply hangs after the bridge script runs. Nothing more to say!
[14:13] <babbageclunk> dooferlad, dimitern, frobware: what do maas 1.9 node-groups correspond to in maas 2?
[14:13] <dimitern> babbageclunk: to rack controllers
[14:13] <babbageclunk> dimitern: thanks
[14:29]  * fwereade_ thinks he just barely resisted the urge to name a type *state.Less
[14:34] <natefinch> fwereade_: nice
[14:47] <alexisb> hey all, happy monday!
[14:48] <perrito666> hey
[14:48] <katco> alexisb: happy monday
[15:08] <babbageclunk> dimitern: ping?
[15:09] <dimitern> babbageclunk: pong
[15:12] <babbageclunk> dimitern: can I pick your brains about this maas spaces demo stuff in the juju-sapphire hangout?
[15:12] <dimitern> babbageclunk: yeah, ok - omw
[15:12] <babbageclunk> dimitern: thx!
[15:31] <katco> hey, does anyone know how to manually log into the controller's mongo instance now? the password in accounts.yaml doesn't seem to work
[15:36] <perrito666> katco: if mongo is v3 you need to install mongodb-org ppa and pull the 3.x client
[15:36] <perrito666> people at packaging are working to provide the client along with the tools soon
[15:36] <katco> perrito666: i'm on beta9, so i assume that v3
[15:36] <perrito666> so we dont have to
[15:36] <perrito666> katco: it actualy depends on your distro
[15:36] <perrito666> xenial?
[15:36] <katco> perrito666: the machine i have available atm is wily
[15:36] <perrito666> your => your machine 0
[15:36] <katco> perrito666: host machine
[15:37] <katco> perrito666: bootstrapped controller is xenial though
[15:37] <perrito666> then yes, mongo 3
[15:37] <natefinch> controller is what matters
[15:38]  * perrito666 is stuck waiting for the plumber and has no food, happy monday
[15:38] <natefinch> mramm: thank you for your repro case on lxd
[15:38] <natefinch> mramm: on that ip address setting bug
[15:39] <katco> perrito666: ta. do you have a url for that ppa?
[15:40] <perrito666> katco: https://docs.mongodb.com/v3.0/tutorial/install-mongodb-on-ubuntu/ sorry not a ppa, old style debline
[15:40] <katco> perrito666: ah ok
[15:41] <katco> perrito666: ta for your help
[15:41] <perrito666> np, ask if you need anything else
[15:42] <natefinch> my computer is not so happy about having a 13 machine LXD environment deployed :)
[15:43] <natefinch> obv time for a bigger machine
[15:45] <perrito666> natefinch: openstack bundle?
[15:52] <natefinch> perrito666: just a couple random bundles, HA/big data stuff
[15:53] <mramm> natefinch: yea, I just built a desktop machine with 64 gig ram because juju deploying so much stuff broke my (relatively powerful) laptop
[15:54] <perrito666> yep, lots of ram and lots of ssd :)
[15:55] <mramm> yep, two different SSD's on two different SATA channels, one for the system and one for the lxd filesystem
[15:55] <natefinch> yep... my laptop is quad core i7 with 16GB of RAM... I'm glad they started offering 32GB on new XPS 15s.  But I keep thinking that I should really just get a desktop and keep this laptop just for sprints.  for the amount I spent on this laptop I could get a ridiculous desktop
[15:56] <perrito666> go desktop, is the way
[15:56] <perrito666> I have done that and use the laptop for whenever I cant work at home
[15:56] <natefinch> plus it would be fun to build a desktop from scratch again... haven't done that in like a decade
[16:07] <redir> brb reboot
[16:09] <mup> Bug #1589385 changed: leftover eth0.cfg in /etc/network/interfaces.d <4010> <juju-core:New> <MAAS:Invalid> <https://launchpad.net/bugs/1589385>
[16:11] <perrito666> bbl, errands
[16:19] <bdx> I too had to throw together a more capacitive desktop for deploying lxd in my home lab
[16:19] <bdx> behold her beauty
[16:20] <bdx> http://imghub.org/image/UMUX
[16:20] <bdx> :-) :-)
[16:20] <bdx> http://imghub.org/image/UrGu
[16:21] <bdx> one more, http://imghub.org/image/UxWY
[16:24] <bdx> to be honest, I built her a few yrs ago ... she serves as my lxd lab now though
[16:24] <natefinch> nice cooling rig
[16:24] <mup> Bug #1589581 opened: Consistant basic use of debug-log between 1.25 and 2.0 <pyjuju:New> <https://launchpad.net/bugs/1589581>
[16:25] <natefinch> how many NICs are in there? looks like you have 4 ethernet cords plugged into it?
[16:27] <bdx> natefinch, yea .... things are arranged slightly different now, but I use to have to make up for not having 10G network infra
[16:27] <natefinch> bdx: ha.  yeah, must be hard roughing it on single gigabit ethernet
[16:29] <bdx> I would create iscsi extents and share them to different servers over different interfaces/networks to try to mitigate stomping the 1G
[16:29] <bdx> lol
[16:33] <bdx> now she has 10G, so I can share her fast zfs arrays to other servers more better
[16:35] <bdx> I use to be heavily into the gpu modding game ... those 660's in there are modded to grid k2's
[16:37] <bdx> they no longer exist tho
[16:38] <bdx> she is gpu-less nowadays
[17:34] <alexisb> cherylj, ping
[17:56] <cherylj> alexisb: pong
[17:56] <alexisb> heya cherylj
[17:56] <alexisb> welcome back
[17:59] <cherylj> thanks :)
[18:40] <mup> Bug #1588911 changed: Juju does not support 2.0-beta9 <blocker> <ci> <juju-core:Fix Released by natefinch> <https://launchpad.net/bugs/1588911>
[18:40] <mup> Bug #1589628 opened: Unable to bootstrap lxd with juju 2 because of x509 certificate error <juju-core:New> <https://launchpad.net/bugs/1589628>
[18:40] <mup> Bug #1589635 opened: github.com/juju/juju/state fails on TestMachinePrincipalUnits with an unexpected name <juju-core:New> <https://launchpad.net/bugs/1589635>
[18:43] <mup> Bug #1589628 changed: Unable to bootstrap lxd with juju 2 because of x509 certificate error <juju-core:New> <https://launchpad.net/bugs/1589628>
[18:43] <mup> Bug #1589635 changed: github.com/juju/juju/state fails on TestMachinePrincipalUnits with an unexpected name <juju-core:New> <https://launchpad.net/bugs/1589635>
[18:43] <mup> Bug #1588911 opened: Juju does not support 2.0-beta9 <blocker> <ci> <juju-core:Fix Released by natefinch> <https://launchpad.net/bugs/1588911>
[18:49] <mup> Bug #1588911 changed: Juju does not support 2.0-beta9 <blocker> <ci> <juju-core:Fix Released by natefinch> <https://launchpad.net/bugs/1588911>
[18:49] <mup> Bug #1589628 opened: Unable to bootstrap lxd with juju 2 because of x509 certificate error <juju-core:New> <https://launchpad.net/bugs/1589628>
[18:49] <mup> Bug #1589635 opened: github.com/juju/juju/state fails on TestMachinePrincipalUnits with an unexpected name <juju-core:New> <https://launchpad.net/bugs/1589635>
[18:56] <katco> perrito666: ping
[18:57] <perrito666> katco: pong
[18:58] <katco> perrito666: hey, are api calls currently carrying information about the user who's making it?
[18:58] <perrito666> iirc, the info is in the connection only
[19:00] <katco> perrito666: can you give me a jumping-off point?
[19:02] <perrito666> katco: certainly, if I am guession correctly what you are looking for, apisercer/client_auth_root.go is a great place to start, there you know the facade, method and the user all in the same place
[19:02] <katco> perrito666: awesome, that sounds like a winner, ta
[19:03] <perrito666> wow, my typo rate really worsens when my wrist is hurt
[19:03] <perrito666> katco: np
[19:10] <natefinch> anyone online know anything about the state.address struct?
[19:13] <mup> Bug #1589641 opened: github.com/juju/juju/state fails on ActionSuite.TestUnitWatchActionNotifications <juju-core:Incomplete> <juju-core service-to-application:New> <https://launchpad.net/bugs/1589641>
[19:36] <redir_lunch> natefinch: not I
[20:00] <natefinch> voidspace: don't suppose you're working late today?
[20:13] <mup> Bug #1589670 opened: backups does not implement Backups for non linux OSes <juju-core:New> <https://launchpad.net/bugs/1589670>
[20:15] <thumper> fwereade_: ping?
[20:33] <natefinch> alexisb: btw, we'll need to hand off this bug.  I'll be on later, but I'm not going to figure it out in the next half hour.  .
[20:43] <alexisb> natefinch, did you provide an update in the bug?
[20:43] <mup> Bug #1589680 opened: Upgrading to cloud-archive:mitaka breaks lxc creation <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1589680>
[20:44] <natefinch> alexisb: yep.  Huge brain dump in there
[20:44] <alexisb> thanks
[21:14] <thumper> davecheney: https://bugs.launchpad.net/juju-core/+bug/1588575
[21:14] <mup> Bug #1588575: allwatcher_internal_test has intermittent failure <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1588575>
[21:25] <davecheney> thumper: thanks, no promises I can start on it today, I need to verify that i've found all the places where we stop but don't wait for the watcher to die
[21:46] <mup> Bug #1576874 changed: restore-backup never completes <backup-restore> <blocker> <ci> <regression> <juju-core:Fix Released by hduran-8> <https://launchpad.net/bugs/1576874>
[21:53] <perrito666> wallyworld: ffs, that keeps bitting me
[21:53] <wallyworld> easy fix at least
[21:54] <perrito666> wallyworld: yeah, I keep forgetting we maintain all that thing in windows for no good reason
[23:06] <alexisb> heya wallyworld, do you have a few minutes for me?
[23:06] <wallyworld> suppose so :-)
[23:07] <wallyworld> have standup in 5, meet in 1:1?
[23:08] <wallyworld> alexisb: in hangout
[23:16] <wallyworld> axw: anastasiamac: perrito666: be there real soon
[23:16] <perrito666> k
[23:18] <axw> looking for the end of my webcam USB in the dark, be there soon too...
[23:28] <redir> axw: you coming back?
[23:54] <wallyworld> perrito666: here tis https://github.com/juju/juju/pull/5547
[23:54] <wallyworld> can you +1 and i'll land
[23:55] <perrito666> bastard you got review 4994
[23:55] <perrito666> ship it
[23:55] <wallyworld> ty


[14:05] <cjohnston> mhall119: please look at your email.. do you have thoughts on the two opinions re: hallway monitors
[14:07] <mhall119> nope, I'm going to leave the decision up to you
[14:08] <cjohnston> I didn't ask for a decision, I asked for thoughts
[14:08] <mhall119> I agree with you, there's too much unused space, I'd rather see more of the schedule info and less grey space
[14:09] <newz2000> hey cjohnston can you extend my membership on community themes developers team?
[14:09] <cjohnston> I personally think on the wide display that things shouldn't be seperated by track, and that's, again IMO, what is causing so much grey
[14:09] <cjohnston> newz2000: no :-P
[14:09] <newz2000> oops, sorry, didn't mean to butt in
[14:09]  * newz2000 is multi-tasking
[14:09] <cjohnston> hehe
[14:09] <mhall119> cjohnston: can you reject my membership in the community themes too?
[14:10] <cjohnston> mhall119: no
[14:16] <cjohnston> steveedwards_: ^^
[14:16] <steveedwards_> cjohnston: Bonjour.
[14:17] <cjohnston> steveedwards_: howdy.. the problem I think is that since it isn't organized by room, that doesn't mean that there is actually 'free time'
[14:19] <cjohnston> and I get that we actually have alot more meetings than what are on the demo, but I think its possible that where the 'community' track has three lines, and two of them only have one meeting, that is going to open up alot of grey space, but that grey space isn't actually free time
[14:19] <steveedwards_> cjohnston: Is it the grey that's the problem? Are we making the 'holes' too obvious?
[14:22] <cjohnston> IMO, yes... because I don't think that they are always holes... Without putting real data into the demo, I don't know that we can entirely determine it, but if you look at the two lower community lines, they each only have one meeting.. the rest of the 'holes' in those two rows aren't necessarly free time.. its just that the community track doesn't have anything going on.. so maybe server has multiple meetings at
[14:24] <steveedwards_> cjohnston: Hmm. Let me consult with the group and we'll see if we can come up with something...
[14:24] <steveedwards_> cjohnston: I'm loathe to have a different version of the schedule just for the screens. The whole point is to make a single page of markup work for every type of device.
[14:25] <steveedwards_> cjohnston: Which is why I'm keen to keep the track format.
[14:25] <steveedwards_> cjohnston: But I'm sure there's something we can do to improve the visual feel.
[14:25] <cjohnston> I agree
[14:25] <cjohnston> I almost wonder tho if with that display=wide flag it could still suit both needs
[14:27] <steveedwards_> cjohnston: Well, we ditch the track filter buttons for wide display. They're really useful when viewing on a tablet.
[14:28] <cjohnston> I agree
[14:28] <steveedwards_> cjohnston: We're close. I can smell it.
[14:28] <cjohnston> I think on the personal devices its really cool
[14:28] <cjohnston> its just that wide display... and like you, I think it's close, just needs a little more tweaking and we will be there
[14:29] <steveedwards_> cjohnston: Excellent. So...
[14:29] <steveedwards_> cjohnston: 1) Make it fit (duh)
[14:29] <steveedwards_> cjohnston: 2) Do something with the holes
[14:29] <cjohnston> yup..
[14:30] <steveedwards_> cjohnston: Super. I'll gather some opinions, update the demo and drop you and Michael a line.
[14:30] <cjohnston> thanks steveedwards_ @
[14:30] <cjohnston> !
[14:31] <steveedwards_> cjohnston: No worries. Thank -you-.
[14:42] <mhall119> steveedwards_: if the schedule is arranged by room and time, instead of track and time, there will be less empty space
[14:46] <steveedwards_> cjohnston: Gotcha. We're trying to figure out a smarter solution than just knocking the colour back.
[14:46] <steveedwards_> cjohnston: Though even that would help, I'm sure.
[14:48] <daker> mhall119: steveedwards_ cjohnston http://people.ubuntu.com/~daker/demo/test.html FYI
[14:49] <mhall119> daker: that would be even better if it had rooms across the top, and time down the side
[14:49] <mhall119> it'll fit the hallway monitors better that way
[14:51] <steveedwards_> daker: Ooh, nice.


[00:23] <jrwren> i follow 604
[00:23] <jrwren> i'm guessing 400 of those tweet once a month :)
[00:24] <jrwren> following count importance < following tweet rate importance
[00:27] <greg-g> yeah, I was wondering if I could find that somewhere...
[00:27] <greg-g> it'd be nice if I could see that number, and see if "if you unfollowed X, your tweet rate would be Y"
[00:30] <jrwren> oh man, I would love that.
[00:47] <cmaloney> Evening
[00:48] <rick_h_> party
[00:49] <cmaloney> greg-g: That would be awesome
[00:49] <cmaloney> assuming I were still on Twitter of course. :)
[02:44] <DrDaemonEye> evening everyone
[03:15] <cmaloney> Evening
[03:16] <rick_h_> howdy
[04:01] <cmaloney> brousch: I'm about two moves from resigning our 19x19 game
[04:01] <cmaloney> I only have a slight advantage but I can see you winning this.
[04:18] <brousch> Never give up!
[04:22] <_stink_> play a bomb piece
[14:05] <cmaloney> Good morning
[15:09] <rick_h_> morning
[15:31] <DrDaemonEye> morning cmaloney, rick_h_
[15:31] <cmaloney> Morning DrDaemonEye
[15:31] <DrDaemonEye> How goes?
[15:37] <cmaloney> It goes.
[15:37] <cmaloney> Yourself?
[15:38] <DrDaemonEye> Very cold and snowman-like.
[15:40] <DrDaemonEye> I guess we're suppose to get a couple inches of snow by mid-afternoon
[15:41] <cmaloney> Yeah, I'm not looking forward to that
[15:42] <DrDaemonEye> nor am I.  I got class this afternoon
[15:47] <brousch> bite me
[15:48] <cmaloney> brousch: OMG IT'S SNOWING OUTSIDE! RUN!
[15:49]  * cmaloney is listening to Chris Christodoulou - Hailstorm
[15:49] <brousch> It's been snowing! I raked my roof and broke 2ft long icicles last night. shoveled another 3" this morning
[15:49] <cmaloney> brousch: Yeah, but that's normal for the west side of the state
[15:49] <cmaloney> We should still be having 70F weather.
[15:49] <rick_h_> I had to go ask my phone 'what's the first day of winter' and it told me a lie and said Dec 21st not Nov 11th
[15:49] <cmaloney> ;)
[15:53] <brousch> At least we're not in Buffalo
[16:14] <DrDaemonEye> brousch: ouch.  no fun
[18:05] <jrwren> greg-g: debian may not exist by the time you migrate to it.
[18:05] <greg-g> lol
[18:05] <jrwren> greg-g: did you see https://lists.debian.org/debian-ctte/2014/11/msg00091.html ?
[18:06] <greg-g> no, but, it's ok
[18:09] <jrwren> 3 resignations in 1 month: https://lists.debian.org/debian-ctte/2014/11/threads.html#00091
[18:10] <greg-g> s'ok
[18:10] <greg-g> Ubuntu survived when I rage-quitted, same for jcastro :P
[18:21] <jrwren> were either of you leaders in the community?
[18:21] <jcastro> I would argue that ubuntu got better when greg quit
[18:21] <jcastro> j/k
[18:21] <greg-g> jcastro: :P
[18:22] <rick_h_> ouch! beard burn right there
[18:25] <brousch> So we're all moving to OpenSuse now?
[18:25] <cmaloney> Wow
[18:26] <jcastro> greg-g, cdimages are cloudfronted
[18:27] <jcastro> dunno about the web stuff
[18:28] <jcastro> god, I don't know how I lived without pushbullet
[18:29] <jcastro> best. app. ever.
[18:29] <cmaloney> ?
[18:29] <jcastro> shows your phone notifications on your desktop
[18:29] <jcastro> so like you can reply to texts, etc.
[18:29] <cmaloney> Ah, you mean Pebble. ;)
[18:29] <jcastro> and also push URLs etc. to your devices
[18:29] <cmaloney> heh
[18:29] <jcastro> so when someone texts me a URL I can push it to a device
[18:30] <jcastro> isn't pebble a watch?
[18:30] <cmaloney> It is.
[18:30] <cmaloney> That gets my notifications
[18:30] <cmaloney> I respond by looking at it and ignoring it.
[18:31] <brousch> Google voice
[18:31] <cmaloney> GV works only when people use your GV number
[18:31] <cmaloney> Though I use Hangouts for pretty much everything
[18:32] <jcastro> also pushbullet is maintained. :)
[18:32]  * jcastro took his number back from GV
[18:33] <brousch> Don't give out your real number!
[18:33] <jrwren> jcastro: +1 pushbullet rules. I have an irssi script I wrote that uses it :)
[18:33] <jrwren> oh, as for phone notifications, iOS+OSX does that OOTB :p
[18:40]  * cmaloney decides against making a public bet that pushbullet will still be around in 3 years
[18:41] <cmaloney> jcastro has enough of my money already. :)
[18:41] <jcastro> https://www.dropbox.com/developers/blog/114/heroku-announces-dropbox-sync
[18:41] <jcastro> cmaloney, it just pushes URLs around
[18:41] <jcastro> it isn't rocket science
[18:46] <cmaloney> jcastro: Yes, but it's a service
[18:46] <cmaloney> and most services have the following lifecycle:
[18:46] <jcastro> yeah but relatively easy to replace
[18:46] <cmaloney> 1) Awesome. Can't live without it
[18:46] <jcastro> it's not like, a life breaker if it goes away
[18:46] <cmaloney> 2) Awesome, but apparently they need to make money
[18:46] <cmaloney> 3) What the fuck?!?
[18:47] <cmaloney> 4) Kill it with fire.
[18:47] <jcastro> you forgot the other one
[18:47] <jcastro> a) Build something interesting, but no idea how to make money
[18:47] <jcastro> b) Get bought
[18:47] <jcastro> c) Fold service, have google/apple/amazon roll it into their basic service
[18:47] <cmaloney> c) Become eBay / Paypal.
[18:47] <jcastro> d) Retire
[18:48] <cmaloney> heh
[18:48] <greg-g> jcastro: you forgot the step between a and b of "???"
[18:48] <cmaloney> greg-g: Obviously
[18:48] <jcastro> greg-g, "get on techcrunch!"
 You spot the packets on the table. You rip them open and start snorting for all you're worth. You're on "Diet Coke"
[18:53] <cmaloney> greg-g: We have a hazardous weather outlook but you're welcome anytime. :)
[18:55] <jcastro> there is snow here
[18:56] <greg-g> I love the snow
[18:56] <greg-g> god I miss it
[19:02] <cmaloney> Damn door-to-door folks
[19:02] <cmaloney> trying to sell appliance protection
[19:02] <cmaloney> There goes the concentration train.
[20:01] <greg-g> Working from Home Rule #3: never answer the door.
[20:01] <rick_h_> hah, gotta love the sales folks
[20:20] <cmaloney> https://plus.google.com/100104437033539828704/posts/V6vkZNvstxM?pid=6083442471842518546&oid=103493459351957813291
[20:21] <greg-g> holy long url batman
[20:21] <cmaloney> Sorry. :)
[20:21] <cmaloney> It's Google Plus, so long URLs are the norm
[22:23]  * DrDaemonEye now has a laser


[01:23] <daker_fork> Leaving)
[01:24] <daker_fork> oh shit!!
[05:58] <aldin> (06:56:31 AM) aldin: hi, if there's someone from ubuntu web admins should fix counters on this link http://www.ubuntu.com/community/countdown
[05:58] <aldin> (06:56:31 AM) aldin: http://img715.imageshack.us/img715/8509/emtybanner.png
[06:03] <zkriesse> aldin: what's wrong with it?
[06:29] <aldin> zkriesse: take look at the (both) link, short answer dead links for ubuntu 10.10 counter images
[06:30] <zkriesse> humm
[12:16] <sim642> Whats with the countdown scripts not working on Ubuntu site? The images dont show up (and on my site either).
[12:25] <cjohnston> sim642: they are broken
[12:25] <sim642> why?
[12:25] <cjohnston> Because there is a problem with them
[12:26] <sim642> will they get fixed soon?
[12:27] <cjohnston> they are trying to... however I would rather them work on having 10.10 ready than a countdown script..... so you have to look at priorities
[15:34] <newz2000> mdke: hey, can you give me a ping when you have a moment?
[15:35] <newz2000> I want to ask you if you like it when a leader takes charge of a situation to give clear direction
[15:35] <newz2000> (careful, that's a baited question) :-)
[22:50] <nhandler> newz2000: Out of curiosity, any plans on incorporating the new Ubuntu emoticons into the new wiki theme?
[22:51] <newz2000> I did not know about them
[22:51] <newz2000> I can look into that, would you mind filing a bug on ubuntu-website and tagging it with light-wiki?
[22:51] <nhandler> newz2000: Sure. Give me a few minutes and I will do so
[22:51] <newz2000> no rush, I'm just in the middle of something and don't trust my memory
[22:51] <newz2000> I'm scheduling time on Wed to work on that theme
[22:55] <nhandler> newz2000: https://bugs.edge.launchpad.net/ubuntu-website/+bug/653298
[22:55] <ubot4> Launchpad bug 653298 in ubuntu-website "Use new Ubuntu Emoticons on Wiki (affects: 1) (heat: 6)" [Undecided,New]
[22:56] <newz2000> thanks nhandler
[23:30] <daker> nhandler, funny


[07:28] <mup> Bug #1724556 changed: MAAS not configuring proper IPMI passwords <4010> <MAAS:Invalid> <https://launchpad.net/bugs/1724556>
[08:24] <TheGreatDoc> Hi all!
[08:24] <TheGreatDoc> Im having some troubles using maas to provision a Dell C6100
[08:25] <TheGreatDoc> Can anyone give me a hint on that?
[08:33] <TheGreatDoc> Is there any way to "clean" or "wipe" the discovery database so I can start again without reinstalling ubuntu/maas?
[08:33] <TheGreatDoc> I have the devices discovered but with wrong address, dunno why
[08:35] <TheGreatDoc> Also, dont know if you have something to do, but the search in the mass.io/docs doesnt work
[09:47] <TheGreatDoc> How can I debug this: 1 node cannot be powered on. To proceed, update your selection.
[09:48] <TheGreatDoc> ipmipower -D LAN_2_0 -h <IP_ADDRESS> -u maas -p CxquVbbxQIfl --stat <-- This works from console, also --on and --off
[09:48] <TheGreatDoc> but from maas gui is impossible. I've tried dedicated and shared ipmi interface, both without success and with the same error
[09:49] <TheGreatDoc> Also, I dont get any cores/ram/disk/storage info in the maas gui
[09:49] <TheGreatDoc> And there is nothing in /var/log/maas/maas.log about this
[14:42] <[Kid]> if i wanted to change IP or hostname, do i have to do a full re-deploy or will MAAS detect it and change it automatically?
[14:43] <Miouge> My MAAS server has 2 interfaces: ens3 (internet access) and ens8 (where my baremetal servers are), I have the DHCP working on ens8, but TFTP ansers only on ens3 and localhost. What am I missing here?
[15:47] <Miouge> Mmm I tracked it down to ens8 using <IP_ADDRESS>/16 which is considered “Unconfigured” by MAAS :(
[18:01] <[Kid]> so i changed hostnames and it wouldn't let me re-deploy. It looks like it is making me go through the entire commission and deploy process. is that the easiest way to do it?
[21:25] <edmz> is it possible to try MAAS with Virtualbox?
[21:25] <edmz> I've only seen a couple of very old tutorials about that (ca 2012). And some of the stuff that they have is not in the latest MAAS. (Like Clusters)


[01:56] <nmarques> anyone can help with a build error on unity ?
[01:56] <nmarques> http://fpaste.org/ITK6/
[01:58] <bschaefer> nmarques, hello, if you'll need libgeis-dev
[01:59] <nmarques> it is installed :/
[01:59] <nmarques> 2.2.10
[02:00] <nmarques> hmmz
[02:00] <bschaefer> nmarques, and then compile nux
[02:01] <bschaefer> with --enable-gesture
[02:01] <bschaefer> with it's autogen
[02:02] <nmarques> I'll update geis meanwhile
[02:04] <nmarques> bschaefer, geis replaces utouch-geis correct ?
[02:04] <bschaefer> nmarques, hmm im pretty sure it does
[02:05] <nmarques> yeah
[02:05] <nmarques> I just saw that the package in Ubuntu is utouch-geis still :)
[02:05] <nmarques> I'll go this way, update to 2.2.11, rebuild nux and friends and then try again Unity
[02:05] <nmarques> bschaefer, thx
[02:05] <bschaefer> nmarques, cool, and yup that should do it
[10:48] <MCR1> Trevinho, Mirv: Hi :) Can you help me find the commit, which introduced a configurable shortcut for the HUD ?
[11:02] <Trevinho> MCR1: around http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/1737.8.3
[11:02] <MCR1> Trevinho: Great. Thanks. I couldn't find it...
[11:03] <Trevinho> MCR1: so main commit at http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/1900
[11:03]  * MCR1 is looking
[11:10] <MCR1> Trevinho: Do you maybe also know where the hardcoded shortcuts are stored ?
[11:11] <MCR1> Trevinho: My problem is that after this fix: https://code.launchpad.net/~mc-return/unity/unity.merge.fix-hardcoded-keys-part1/+merge/119204
[11:12] <MCR1> the shortcut still jumps back to Alt+Space if you change it via CCSM...
[11:14] <MCR1> I do still not know why - the hardcoded shortcuts seem to be stored somewhere else (not only in unityshell.cpp and StandaloneShortcuts.cpp)
[11:14] <MCR1> I guess they might even be stored somewhere outside the unity source ???
[11:20] <Trevinho> MCR1: they're stored on unityshell.xml.in that generates a file in build/generated/unityshell_options.cpp
[11:21] <Trevinho> MCR1: the option value however is saved also in the gconf schemas and on the meteadata compiz file (.xml file)
[11:23] <MCR1> Trevinho: hmmm - that was my understanding also - but I did not know about the gconf schemas...
[11:23] <Trevinho> MCR1: I think you can even change hints_.push_back(std::make_shared<shortcut::Hint>(menubar, "", _(" (Hold)"), _("Reveal the application menu."), shortcut::HARDCODED_OPTION, "Alt")); to unityshell show_hud option, isn't it?
[11:24] <MCR1> Trevinho: No, because this is not for the HUD, but the application menu.
[11:24] <Trevinho> MCR1: ah, right... sorry :/
[11:24] <MCR1> Trevinho: I got it wrong first
[11:24] <MCR1> also
[11:24] <MCR1> hehe ;)
[11:25] <MCR1> it gets confusing - all those different types of shortcuts
[11:25] <MCR1> we really should clean up and make all of them controlled by the plug-in, none should be hardcoded - then all these problems with bindings would resolve themselves
[11:27] <MCR1> Trevinho: brb
[12:16] <MCR1> back
[13:01] <MCR1> Trevinho: I really do not get it. :P "Super + Tab" for example - where is this shortcut defined in the first place ? It is nowhere to be found in unityshell.xml.in, but I cannot find it anywhere else either...
[13:03] <MCR1> Trevinho: Maybe it is best to set the status of the current branch as "ready for review" and continue to work on part2 in a separate branch with this one as prerequisite ?
[13:07] <MCR1> Trevinho: I found it: <default><Super>Tab</default>
[13:08] <MCR1> it is in unityshell.xml.in - seems some blindness got me
[13:15] <MCR1> but Ctrl+Tab seems to be defined nowhere, grmpf
[14:41] <kayo> unity have one way to capture screen like gnome-shell ctrl+shift+alt+r?
[14:43] <CookieM_> tried win-like alt+prtsc?
[14:43] <MCR1> kayo: just prtscrn
[14:44] <kayo> sorry, when i say capture screen i mean record video
[14:45] <MCR1> gtk-record-my-desktop package
[14:46] <MCR1> or gtk-recordmydesktop
[14:48] <kayo> ok
[15:02] <popey> kayo, i'd recommend kazam over gtk-recordmydesktop
[15:07] <kayo> popey, really much better ty
[15:07] <popey> np
[18:50] <nmarques> anyone can point me to the vendor patch applied on xorg-x11-proto that enables Unity to build ? (if it's possible to build without it even better)