[01:20] <thumper> axw, wallyworld_: I'm prepared to trade review for review... mine is trivial
[01:20] <wallyworld_> ok
[01:20] <thumper> axw: and I'm replying to the maas-allocated one
[01:20] <axw> thumper: okey dokey
[01:20] <thumper> enfixorating it took longer than expected
[01:37] <axw> thumper: sorry, couldn't remember if we were doing a bug or blueprint for the API stuff.. thanks for fixing
[01:49] <thumper> np
[01:50] <thumper> gives me something to do and feel important :)
[02:56] <axw> thumper: did you mean to repropose the maas MP?
[02:56] <axw> there's a bunch of unrelated stuff in there now
[02:56] <thumper> no...
[02:56] <thumper> yes I know
[02:56] <thumper> I'll fixit
[02:56] <axw> k
[02:56] <thumper> dammit
[03:10] <thumper> axw: I'm trying to work out wtf happened
[03:10] <thumper> I had branched from 1.16
[03:11] <thumper> ugh
[03:11] <thumper> I know
[03:11]  * thumper goes to uncommit several
[03:43] <axw> thumper: when you're not busy, can you please take a look at https://codereview.appspot.com/14775044/
[03:43] <axw> a fix for one of the manual provisioning bugs
[03:44] <thumper> bigjools: can I get you to cast a quick eye over https://code.launchpad.net/~thumper/juju-core/maas-allocated/+merge/191090
[03:44] <thumper> bigjools: just to make sure I'm not doing something dumb?
[03:44] <thumper> axw: ack
[03:48] <bigjools> thumper: out of interest,  why the change to name the returned values?
[03:48] <bigjools> line 38 on diff
[03:49] <thumper> I was assigning to them before
[03:49] <thumper> but refactoring took it out
[03:49] <thumper> again
[03:49] <thumper> sometimes it is easier to have the named params
[03:49] <thumper> than to have empty declarations in the code
[03:50] <thumper> they are effectively function local variables
[03:50] <bigjools> yeah
[03:52] <bigjools> sheesh, I don't remember enough Go already to see what this is doing without looking stuff up
[03:52] <bigjools> did my best to banish it from my mind
[03:52] <thumper> axw: var allSeries = [...]string{"precise", "quantal", "raring", "saucy"} <- why the dots in [...] ?
[03:52]  * axw reminds himself
[03:52] <thumper> bigjools: it was more just the filter I cared about
[03:52] <thumper> bigjools: the rest of it I understand
[03:53] <bigjools> filter is fine
[03:53] <axw> thumper: why I did that instead of a slice... *shrug*, it's a little less overhead
[03:53] <bigjools> thumper: having said that
[03:53] <axw> [...]{...} is syntax for an array literal with the size taken from the number of elements
[03:53] <bigjools> thumper: it would be better to have the filtering done in gomaasapi
[03:54] <bigjools> as an optional state param
[03:54] <thumper> bigjools: agreed, but I felt that it was more work, and I think gomaasapi should give juju-core higher level objects to work with
[03:54] <thumper> rather than thin wrappers on a ReST api
[03:55] <thumper> axw: I just wasn't familiar with the syntax
[03:57] <thumper> bigjools: why exactly do we filter out unallocated ones?
[03:57] <bigjools> lol
[03:57] <thumper> I'll update the comment if you give me the reason
[03:57] <bigjools> thumper: nodes can be owned by the same user but not necessarily in use by juju
[03:57] <bigjools> juju just assumes it owns the world
[03:58] <bigjools> this change is not actually strictly necessary after the other work we did
[03:58] <thumper> by not strictly necessary...
[03:58] <thumper> do you mean it isn't needed at all?
[03:58] <bigjools> well, no :)
[03:58] <thumper> if it isn't, then we could flag it
[03:58] <bigjools> the agent_name work marks nodes that juju allocated
[03:58] <thumper> although I wish I knew that before I spent a day trying to massage it into shape
[03:59] <bigjools> I didn't know you were working on it, sorry
[03:59]  * thumper sighs
[03:59] <thumper> I'll strip the filter, but commit the changes because it makes the code more "correct"
[03:59] <thumper> and tweaks the tests
[03:59] <bigjools> ok
[04:14] <axw> wallyworld_, thumper : bot sez "no space left on device"
[04:14] <axw> do either of yo uhave access?
[04:14] <wallyworld_> i do
[04:15] <wallyworld_> which device?
[04:15] <axw> wallyworld_: /tmp
[04:15] <wallyworld_> ok
[04:15] <axw> thanks
[04:16] <wallyworld_> axw: try now
[04:29] <axw> fixed, ta
[05:19] <axw> wallyworld_: do you have any thoughts on this thread, before I land my change? https://lists.ubuntu.com/archives/juju-dev/2013-October/001651.html
[05:20] <wallyworld_> axw: just a sec, otp
[05:27] <wallyworld_> axw: i'm in 2 minds - i can see the need to keep the current behaviour. but seems like there's enough support to land it. especially now there are validation tools so they can verify the image id they will be getting.
[05:28] <axw> wallyworld_: how do the validation tools help? you mean, people can just set the image id explicitly to prevent unexpected images from being provisioned?
[05:29] <axw> ah never mind, I get it
[05:29] <wallyworld_> one source of confusion in changing the behaviour is: people will set up metadata to use precise image 1234 (to override the stock abcd)
[05:30] <wallyworld_> and if we fall back to abcd cause they stuffed up, that's bad
[05:30] <axw> yep
[05:30] <axw> and validation tools can help prevent that
[05:30] <wallyworld_> yeah, if people use them :-)
[05:30] <axw> heh :)
[05:31] <wallyworld_> so i'm sorta -0 on it
[05:31] <axw> we can add an option on datasources to prevent fallback
[05:32] <wallyworld_> yes. let's land this first as is i guess and do more work later if it comes up as an issue
[05:32] <axw> ok, sounds like a plan
[05:32] <wallyworld_> i still get a bit nervous about doing it, but oh well
[05:33] <wallyworld_> so long as it's documented and in the release notes
[05:35] <axw> good point, I don't think there's a card for it.. will create one
[05:37] <wallyworld_> main issue is it's a change in behaviour. and i'm not sure how upstream is set up to handle such things; ideally we'd be consistent but if not, double the need for doco
[06:41] <wallyworld_> jam: https://codereview.appspot.com/20730043/
[07:35] <jam> morning all
[07:37] <axw> morning jam
[08:02] <rogpeppe> mornin' all
[08:04] <axw> morning rogpeppe
[08:04] <rogpeppe> axw: hiya
[10:06] <mgz> mornin' all
[10:08] <dimitern> mgz, morning
[10:17] <rogpeppe> mgz, dimitern: yo!
[10:17] <rogpeppe> jam: i just posted a review of this: https://codereview.appspot.com/21000044/
[10:18] <dimitern> rogpeppe, hiya
[10:21] <rogpeppe> fwereade_: ping
[10:32] <fwereade_> rogpeppe, pong, sorry
[10:33] <rogpeppe> fwereade_: just wanted to point you at the HA doc that nate and i put together on friday. i imagine you'll have some comments to make: https://docs.google.com/a/canonical.com/document/d/1hGa2PNz6JyGFc7FjA-gX2_UnXRUGAZbS8O9TiS51bl8/edit
[10:33] <fwereade_> rogpeppe, sweet, tyvm
[10:47] <jam> rogpeppe: fwereade_: standup?
[10:47] <jam> https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
[10:47] <jam> natefinch: ^^
[11:17] <jam> mgz: https://plus.google.com/hangouts/_/72cpj1004s1il9ggm12bsqttpg
[11:30] <mattyw> fwereade_, you remember a few weeks ago I was working on the mp for adding the owner to the addservice function? It just occured to me I never submitted it for review, I'm just doing it now, I have a feeling there's still lots to be done on it, but thought I'd submit it as a way of getting it moving again
[11:32] <natefinch> jam: ahh crap, daylight savings time. Sorry.
[11:53] <fwereade_> mattyw, ah, great, thanks, about to lunch but I'll take a look this pm
[11:54] <jam> natefinch: I expected as much
[11:54] <jam> I knew it was extra early for you, and wasn't sure if you'd be there. We should sort something out for you
[11:54] <natefinch> jam: I expected better of myself :)
[11:55] <mattyw> fwereade_, thanks. no hurry - I have plenty to keep me busy  (as I'm sure you do as well)
[13:45] <rogpeppe1> natefinch: ping
[14:54] <abentley> marcoceppi: Is it considered bad style to do apt-get upgrade in a charm?
[14:56] <marcoceppi> abentley: not nessisarily
[14:57] <abentley> marcoceppi: It seems to me that upgrading all the packages on your system should be an admin decision, not one that your charms make.
[14:57] <marcoceppi> abentley: charms are extremely opinionated encapsulation
[14:58] <marcoceppi> abentley: if the author thinks that's the best course of action, then so be it
[15:00] <abentley> marcoceppi: So the situation is that wordpress does apt-get upgrade.  This attempts to install cgroups-lite.  But I am running the local provides, so installing cgroups-lite fails (I assume because nested lxcs aren't permitted).  So the charm can't install.
[15:00] <abentley> s/provides/provider.
[15:00] <marcoceppi> what in the chain of deps requires cgroups-lite?
[15:01] <abentley> marcoceppi: None.  It's part of the base install.
[15:01] <natefinch> rogpeppe1: hey, sorry, kids got up late today.  What's up?
[15:01] <marcoceppi> well, that seems like a bigger problem tbh
[15:02] <abentley> marcoceppi: What's the bigger problem?  That the Ubuntu base install has cgroups-lite in it?
[15:02] <marcoceppi> abentley: yeah, that cgroups-lite isn't installing properly on lxc
[15:03] <abentley> marcoceppi: Yes, that's certainly a bug.  I just wondered whether it's also a bug that wordpress is trying to upgrade cgroups-lite.
[15:03] <abentley> marcoceppi: It's clearly irrelevant.  I was able to remove it, and the charm installed fine after that.
[15:04] <marcoceppi> abentley: there's an argument to make that it shouldn't as package versions could become mismatched between units, but the same can happen for long running deployments and updates to the simplestream data for images
[15:06] <abentley> marcoceppi: right.
[15:10] <abentley> marcoceppi: I figure charms are cannot by themselves ensure packages are in sync, and if juju changes to be able to ensure packages are in sync, it probably won't be necessary to do it in the charm.
[15:22] <rogpeppe1> natefinch: we should have another chat about the HA stuff
[15:24] <natefinch> rogpeppe1: cool, whenever is good for you
[15:25] <rogpeppe1> natefinch: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1
[16:48] <rogpeppe1> fwereade_: ping
[18:21] <rogpeppe1> natefinch: i've added some notes to the end of the HA document with some thoughts about HA failover and liveness
[18:22] <natefinch> rogpeppe1: cool
[19:19] <natefinch> rogpeppe2: you around?
[19:27] <thumper-afk> morning
[19:27] <thumper> hi natefinch
[19:27] <abentley> thumper: morning.  Can we chat about local provider when you're free?
[19:28] <thumper> abentley: sure, I need to kick the kids out shortly
[19:28] <thumper> after that?
[19:28] <natefinch> thumper: hi
[19:28] <abentley> thumper: great.
[19:35] <natefinch> thumper: finally had daylight savings over here... nice to have an extra hour of overlap with you.  Makes my afternoons less lonely :)
[19:35] <thumper> :)
[19:35] <thumper> I noticed that too
[19:36] <thumper> now if we could just hire someone on the west coast too
[19:36] <natefinch> Last I saw we had an opening for someone that they specifically wanted to have near San Fransisco for some reason.
[19:38] <natefinch> niemeyer: you around?
[20:09] <thumper> abentley: did you want irc or hangout?
[20:09] <abentley> thumper: Let's hang out.
[20:10]  * thumper waits
[20:10] <abentley> thumper: https://plus.google.com/hangouts/_/72cpiquo8sjrmfhcnqpq31pdi0?authuser=1&hl=en
[21:02] <thumper> abentley: that fixed the install problem
[21:02] <thumper> abentley: just testing something else
[21:02] <abentley> thumper: Cool.
[21:15] <thumper> natefinch: https://codereview.appspot.com/21740043
[21:15] <natefinch> thumper: looking
[21:20] <thumper> natefinch: I initially wanted to move in the direction of nested lxc support
[21:20] <thumper> but I couldn't get lxc-start to work with the apparmor profile
[21:20] <thumper> so I gave up and went with the simple solution
[21:24] <thumper> abentley: no sinzui today?
[21:25] <abentley> thumper: No, he's taking the day off.
[21:25] <thumper> hmm...
[21:25] <thumper> we may want to release 1.16.3
[21:25] <thumper> to fix the local provider
[21:26] <natefinch> thumper: yeah, just disabling nested LXC seems like the best idea.  I doubt it'll be a big problem
[21:33] <thumper> abentley: can you do your CI dance with the trunk branch again once I get the fix landed?
[21:34] <abentley> thumper: Sure, but I need to leave in ~30 minutes.
[21:34] <thumper> ack
[21:34] <thumper> it may have to wait then...
[21:40] <thumper> natefinch: and if you can, the same for 1.16 https://codereview.appspot.com/21420045
[21:41] <natefinch> thumper: done
[21:41] <thumper> ta
[21:45] <natefinch> thumper: welcome.  If you get a chance, I'd like to get the code I wrote for specifying EC2 instance types as constraints in... since the code is slowly bitrotting.   https://codereview.appspot.com/14523052/
[21:46] <thumper> I looked at it at the end of last week, but I couldn't remember what we decided about landing the instance type from our burlingame conversations
[21:46] <thumper> do you recall?
[21:49] <natefinch> thumper: we decided to land it.  I asked specifically at the time
[21:50] <thumper> ok, I vote for landing and cleaning up the mess :)
[21:50]  * thumper goes to do a proper review
[21:50] <natefinch> :)
[21:53] <thumper> natefinch: why type and not instance-type?
[21:54] <thumper> I guess it doesn't matter
[21:54] <thumper> just wondering
[21:55] <natefinch> thumper: I thought instance type was too specific to EC2, but if it's more common than that, that's fine
[21:55] <thumper> I think that type should be fine
[21:56] <thumper> abentley: trunk now has lxc fix
[21:56] <abentley> thumper: okay.
[21:57] <natefinch> thumper: once nice bonus that code gives is that you see the type of the machine in juju status, instead of having to try to infer it.  So you'll see like "hardware: arch=amd64 cpu-cores=1 cpu-power=100 mem=1740M root-disk=8192M type=m1.small"
[21:57] <abentley> thumper: build started at http://<IP_ADDRESS>/job/juju-core-ci/97/console
[21:57] <thumper> natefinch: yep, noticed that
[21:57] <thumper> abentley: ta
[21:58] <natefinch> thumper: actually tempted to put type first in the printout, since it sorta defines the rest of the line
[21:58] <thumper> natefinch: well, line is alphabetical no?
[21:58] <thumper> eye naturally tracks to the end
[21:59] <natefinch> thumper: I think it's in the order we define, which happens to be alphabetical
[21:59] <thumper> natefinch: what happens with the mongo doc
[21:59] <thumper> and output
[21:59] <thumper> for environments that exist already?
[22:00] <natefinch> thumper: it should just default to empty.  admittedly I haven't tried it
[22:00]  * thumper nods
[22:00] <thumper> noticed the bson serialization code
[22:00] <thumper> omitempty *should* be fine
[22:00] <natefinch> thumper: yeah
[22:01]  * natefinch also said *should* ;)
[22:01]  * natefinch covers his ass
[22:02] <natefinch> Cool.   I'll do an upgrade test in the morning to double check,  and then merge it in.
[22:03]  * natefinch has reached end of day.
[22:03] <thumper> natefinch: ack
[22:03] <natefinch> thumper: thanks for the review
[22:04] <abentley> thumper: It errored.  Sorry, I don't have time to look at whether it's the same error as before.
[22:08] <thumper> abentley: kk
[22:26] <bigjools> good moaning
[22:27] <thumper> o/
[23:04] <marcoceppi> Can someone in here help out in #juju with a botched upgrade from 1.14 -> 1.16.2j


[07:57] <didrocks> hey sil2100!
[07:57] <didrocks> sil2100: do you have a minute? We can use an hand from you :)
[07:58] <didrocks> if you look at: http://<IP_ADDRESS>:8080/job/autopilot-raring-daily_release/75/, all tests pass
[07:58] <didrocks> (better that you check the xml though)
[07:58] <didrocks> but we can see some autopilot ogv
[07:58] <didrocks> mind having a look what's going on?
[08:15] <didrocks> sil2100: playing with the sdk stack for saucy FYI
[08:29] <didrocks> sil2100: not around? :/
[08:31] <mzanetti> oh.. seems we moved to saucy
[08:34] <mzanetti> Saviq: do we actually still need the dependency to boost?
[08:34] <Saviq> mzanetti, with https://code.launchpad.net/~saviq/unity/phablet.drop-unity-api/+merge/166019 no
[08:34] <Saviq> mzanetti, but I did forget to drop it from there
[08:35] <mzanetti> Saviq: is that close to being merged?
[08:35] <Saviq> mzanetti, if someone reviews it :)
[08:35] <mzanetti> ok
[08:35] <Saviq> mzanetti, it's 100% red
[08:35] <mzanetti> Saviq: ok. On it
[08:37] <Saviq> mzanetti, and yeah, I'm upgrading to saucy now, I'm inclined to drop the People lens as part of it, to drop the custom (lib)unity and dee-qt
[08:37] <nic-doffay> mzanetti, I managed to figure out the cause of the bug. I need to call a function on the press of the power button, are there any signals that could do the job already?
[08:38] <Saviq> nic-doffay, see Shell.qml:112
[08:38] <nic-doffay> Saviq, ta
[08:39] <mzanetti> Saviq: nic-doffay: I'd rather say it should be in the Component.onCompleted of the GreeterContent
[08:39] <Saviq> mzanetti, yeah, my pointer was very superficial :)
[08:40] <nic-doffay> mzanetti, the function would be called twice since the onDataAppeared is already called on startup.
[08:41] <Saviq> mzanetti, pushed a drop of boost to that branch
[08:42] <sil2100> didrocks: here!
[08:42] <sil2100> Damn
[08:43]  * mzanetti needs more coffee. bbiab
[08:45] <sil2100> didrocks: that's strange, as autopilot didn't seem to fail even once and the videos are basically 'empty'
[08:46] <sil2100> didrocks: this might be some AP issue that the recordmydesktop is being started for a moment for no reason
[08:46]  * Saviq upgrades to saucy, wish me luck :)
[08:50] <didrocks> sil2100: is everything all right in the xml?
[08:50] <didrocks> sil2100: and the videos are showing a successful test?
[08:51] <veebers> didrocks, sil2100: that sounds odd. (I'm now worried this might be related to the changes I made last week :-( )
[08:51] <didrocks> veebers: did you see the link?
[08:51] <didrocks> http://<IP_ADDRESS>:8080/job/autopilot-raring-daily_release/75/,
[08:51] <sil2100> didrocks: the videos are around 2-3 seconds and show no activity at all
[08:51] <sil2100> So they're not really even test videos
[08:51] <didrocks> interesting
[08:52] <didrocks> and the tests passed in the xml, right?
[08:52] <sil2100> didrocks: but the AP logs say that everything went fine, yes
[08:55] <sil2100> didrocks: hm, could you explain how the 'packages:' parameter is used right now? Since I guess it changed since the last time? (because we're not getting those 'error, installing extra packages' errors anymore)
[08:56] <mzanetti> Saviq: there's a conflict in your branch
[08:56] <Saviq> mzanetti, k, will merge
[08:58] <didrocks> sil2100: it's the same as before, but it seems that a change in the other system made it not working
[08:58] <didrocks> sil2100: so UTAH wasn't checking anymore the list of installed package, that's why I have to refresh the list
[08:59] <didrocks> sil2100: FYI, I'm pushing the otto config for cupstream2distro-config at lp:~cupstream2distro-maintainers/cupstream2distro-config/otto
[08:59] <didrocks> sil2100: please, just finish filing up unity (raring, head) and qa (raring) stacks with the package list
[08:59] <Saviq> mzanetti, pushed
[08:59] <Saviq> stupid bzr, btw :P
[08:59] <didrocks> sil2100: the only difference is that we don't have "build with whole ppa anymore" and I plan to do some change for that later on
[09:02] <nic-doffay> Saviq, is there a desktop shortcut to lock?
[09:02] <Saviq> nic-doffay, nope :/
[09:03] <sil2100> ACK
[09:03] <Saviq> nic-doffay, Power would work if Unity didn't take it over ;)
[09:03] <sil2100> didrocks: qa for raring has no tests, sooo... there's actually nothing to fill in
[09:03] <didrocks> sil2100: ah ok :-)
[09:03] <Saviq> nic-doffay, just add something in Shell.qml for the time being
[09:03] <didrocks> sil2100: so only unity ;)
[09:04] <Saviq> nic-doffay, next to the Power one
[09:04] <sil2100> didrocks: I added it to unity raring, but I think I need to add hud and related to the package list still for raring
[09:04] <didrocks> sil2100: why? they are installed by default
[09:04] <didrocks> sil2100: so shouldn't be needed
[09:04] <didrocks> (in the iso)
[09:05] <didrocks> sil2100: remember, we only add the others because they are not installed by default
[09:05] <didrocks> and upgrade picks them up
[09:05] <sil2100> Ah, ok ;)
[09:05] <sil2100> So I think we should be more or less ready with that branch
[09:08] <didrocks> sil2100: great! do you have the link handy so that I can grab in the otto branch?
[09:08] <sil2100> https://code.launchpad.net/~sil2100/cupstream2distro-config/add_packages_to_stacks/+merge/167144 - lp:~sil2100/cupstream2distro-config/add_packages_to_stacks
[09:09] <didrocks> sil2100: excellent! remember what I asked for https://bugs.launchpad.net/cupstream2distro/+bug/1186225 yesterday btw?
[09:12] <sil2100> didrocks: you want to revert the changelog additions?
[09:12] <didrocks> sil2100: for those 2 yeah, in the SRU
[09:12] <didrocks> sil2100: if the wiki is telling to add one changelog, please edit it
[09:12] <didrocks> only change the Vcs-Bzr, this is taken into account and ignored
[09:12] <didrocks> because maybe a Vcs-Bzr change + a changelog could tell "please rebuild"
[09:13] <didrocks> so now real way to detect that
[09:13] <sil2100> didrocks: ok, since it was my habbit to always mention all packaging changes in the changelo ;)
[09:13] <sil2100> *changelog
[09:13] <sil2100> But here indeed it results in problems
[09:13] <didrocks> yep :)
[09:13] <didrocks> sil2100: I think the easiest is to have this policy and document it in the wiki, wdyt?
[09:14] <sil2100> didrocks: makes sense! Let me add that ;)
[09:14] <didrocks> thanks!
[09:15] <didrocks> sil2100: merged your package names into the otto branch, thanks!
[09:16] <pete-woods> does anyone know if there's a way to trigger the screen lock when running unity-next on the desktop?
[09:17] <veebers> didrocks, sil2100: I'm off for the night sorry. I'll check out those None.ogv issues tomorrow my time
[09:17] <didrocks> veebers: ok, thanks
[09:19] <sil2100> veebers: thanks! Goodnight!
[09:20] <veebers> Night guys o/
[09:33] <nic-doffay> Saviq, shall I add the functionality into the greeter's show() ?
[09:38] <didrocks> sdk stack: utah: 15 min, otto: 2.15 min
[09:42] <sil2100> Damn
[09:43] <sil2100> Otto makes UTAH look really really bad ;)
[09:46] <didrocks> QA stack: utah: 18 min, qa: 4.57min
[09:47] <didrocks> (again, all with archive which is taking a minute alone, and an additional feature)
[09:56] <didrocks> sil2100: I saw that kenvandine added a dep on webcred on one stack recently in cupstream2distro
[09:56] <didrocks> sil2100: mind checking this and that the schedule matches the dep order?
[09:56] <didrocks> (I'm afraid it's been oversight)
[10:00] <sil2100> didrocks: yes, he added the dependency to the apps stack, as gallery-app and notes-app (I think) use webcreds
[10:00] <sil2100> But I will check the dep order
[10:00] <didrocks> thanks!
[10:09] <didrocks> indicators: utah: 25 min, otto: 11 min
[10:13] <davidcalle> didrocks, ping
[10:13] <didrocks> davidcalle: pong
[10:13] <davidcalle> didrocks, salut, ça va?
[10:14] <didrocks> ça va bien, et toi?
[10:14] <davidcalle> didrocks, bien. Quand tu auras un instant, tu pourrais jeter un oeil à https://code.launchpad.net/~submarine/cupstream2distro-config/online-wikispecies-scope/+merge/167223 ?
[10:15] <didrocks> davidcalle: c'est une scope qu'on doit mettre dans le desktop?
[10:15] <didrocks> davidcalle: c'est pas dans la liste par défaut, non?
[10:15] <didrocks> ah, server scope
[10:15] <davidcalle> didrocks, non, just dans le online stack, pour une éventuelle inclusion côté serveur
[10:15] <didrocks> ok :)
[10:15] <didrocks> looks good to me :)
[10:15] <davidcalle> didrocks, thanks!
[10:16] <didrocks> oif raring: utah: 18 min, otto 1.26 min :p
[10:16] <didrocks> then, unity
[10:16] <didrocks> and we'll be done with raring release migration to otto
[10:17] <didrocks> sil2100: did you look at why unity/raring, some build failed?
[10:17] <mhr3> didrocks, so did otto just cut off ~15minutes, or did it actually change in a more fundamental way? :)
[10:18] <didrocks> mhr3: cut ~15 minutes, but we have more features like archiving, being able to replay an instance from archive and better logs
[10:18] <didrocks> (and more stability ;))
[10:19] <mhr3> i see
[10:19] <didrocks> and we are some improvment in terms of features planned :)
[10:19] <didrocks> for greater flexibility
[10:20] <Saviq> that could've gone better...
[10:21] <Saviq> note to self: btrfs balance before upgrading 1.3k packages #ENOSPC....
[10:21] <sil2100> didrocks: I checked now, and it seemed like some system problem (the latest failure), as there was a 'runtime error' for powerpc
[10:21] <sil2100> didrocks: previously it was a pandaboard issue ;/
[10:22] <sil2100> Chceking the latest one
[10:25] <sil2100> Rebuilding the powerpc package, not sure what happened but something just crashed during build it seems
[10:27] <didrocks> Mirv: sil2100: please don't rerun any stack for now, we disabled the utah job
[10:27] <didrocks> so we are going to build then in next, merging the saucy branch
[10:27] <Mirv> ok..
[10:27] <didrocks> sil2100: IIRC, from what I've seen, ken merged everything, right?
[10:27] <didrocks> but didn't redeploy
[10:29] <sil2100> didrocks: yes, from my information no redeployment has been made
[10:29] <sil2100> But merges went in
[10:29] <didrocks> sil2100: so, I'll merge trunk in my otto branch
[10:29] <didrocks> and once this autopilot unity on raring is done
[10:29] <didrocks> rerun everything
[10:29] <didrocks> sil2100: as in next, we have libhybris, ofono and so on
[10:30] <didrocks> sounds good to you? I'm not forgetting anything crucial?
[10:31] <sil2100> didrocks: sounds good at least - btw. why did you disable the utah job right now?
[10:31] <sil2100> You did it for the raring migration to otto?
[10:31] <didrocks> sil2100: we are installing the intel machine for otto
[10:31] <didrocks> so, right now, we'll have:
[10:31] <didrocks> intel/ati -> saucy
[10:32] <didrocks> nvidia -> raring
[10:32] <sil2100> All of them running otto, or ati still utah?
[10:32] <didrocks> all otto
[10:32] <sil2100> \o/
[10:32] <didrocks> so now, if something is red, better to check! :)
[10:33] <didrocks> we'll probably have some hickupps
[10:33] <didrocks> but we can fix them promptly
[10:33] <sil2100> Yes, anyway I doubt there would be as many hickups as we had before with utah
[10:33] <mzanetti> Saviq: that fix with the locking up when swiping the greeter has been merged, right?
[10:33] <Saviq> mzanetti, yes
[10:33] <mzanetti> Saviq: I still can reproduce it :/
[10:33] <didrocks> sil2100: crossing fingers :)
[10:33] <sil2100> didrocks: tell me when all is ready, I'll merge in the unity dep-change then
[10:34] <Saviq> mzanetti, with trunk? or with the package?
[10:34] <sil2100> So that we can get the saucy release process rolling ;)
[10:34] <Saviq> mzanetti, maybe you didn't get the latest package? (should be 1.80.1)
[10:34] <mzanetti> Saviq: for example with your drop-unity-api branch
[10:34] <sil2100> (in the end)
[10:34] <didrocks> sil2100: if nobody is going to deploy, I can propose my otto changes rather
[10:34] <didrocks> sil2100: it contains your branch
[10:34] <Saviq> mzanetti, hum, will check
[10:41] <Saviq> mzanetti, nope, can't reproduce on 147 + apt-get upgrade
[10:43] <didrocks> sil2100: meanwhile, did you look at the apps stack?
[10:43] <didrocks> in head
[10:43] <didrocks> seems some failure in the browser apps
[10:43] <didrocks> maybe check with osomon
[10:44] <mzanetti> Saviq: oh... your branch is not merged with trunk, just that one conflict... sorry for the noise then
[10:44] <Saviq> mzanetti, yes it's merged, I pushed :/
[10:45] <Saviq> mzanetti, even Jenkins agrees!
[10:46] <sil2100> didrocks: ok, regarding those reverts of changelog entries - since those triggered already new releases, yes?
[10:52] <sil2100> didrocks: the webcreds build problem I think is still being resolved by Ken
[10:53] <didrocks> sil2100: sorry, didn't get the question on the reverts?
[10:53] <didrocks> sil2100: they will stall in the ppa, but won't be in any publication :)
[10:53] <didrocks> sil2100: webapps is not webcreds?
[10:53] <didrocks> oopss, webbrowser apps
[10:53] <didrocks> sil2100: ^
[10:54] <didrocks> http://<IP_ADDRESS>:8080/job/ps-generic-autopilot-release-testing/585/testReport/
[10:54] <sil2100> didrocks: I know, regarding webbrowser I poked oSoMoN already, he's looking at that
[10:54] <didrocks> ah, I talked about that :)
[10:54] <sil2100> didrocks: but I mean that there's also a webcred's build problem
[10:54] <didrocks> not the webcreds FTBFS :)
[10:54] <didrocks> yeah
[10:54] <sil2100> didrocks: I know ;) Just mentioning it in case you didn't know Ken is working on that
[10:54] <didrocks> sure sure, no worry :)
[10:55] <didrocks> sil2100: do you have a MP if anything needs to be changed in the order though? (because of the apps dep on webcreds)
[10:56] <didrocks> sil2100: and thanks for tracking apps, once robru is back on shape, I think he will take it back ;) (but we need it to be fixed to be able to release to saucy as it's in the critical path now)
[10:57] <sil2100> didrocks: I checked and I didn't see any problem the order right now could cause, but I might not be aware of some inside issues - as there don't seem to be any tricky circular dependencies or anything
[10:58] <sil2100> didrocks: no problem, sorry I didn't check the stack today, I actually didn't look at the status because I thought we're anyway 'pending' on the switch to saucy
[10:59] <sil2100> didrocks: as for the order, I can move webcred before qa if anything, but not sure if that matters that much
[10:59] <sil2100> Since there's no other issue I could see
[11:02] <didrocks> sil2100: I mean, the schedule
[11:03] <didrocks> apps depends on webcred, right?
[11:03] <didrocks> apps starts at 5
[11:03] <didrocks> webcreds at 7
[11:04] <didrocks> so, there is an issue :)
[11:04] <sil2100> Ok, I thought I didn't see an issue, but now I indeed see it's 7!
[11:04] <didrocks> sil2100: let me put it in my otto at 4:30
[11:05] <didrocks> so that the day it deps on the sdk stack (I'm sure it's coming ;)) we are not blocked
[11:06] <sil2100> didrocks: ok, I'll put it as that as well
[11:06] <didrocks> sil2100: I've done it in the otto branch :)
[11:06] <sil2100> btw. can I see the otto branch you were mentioning?
[11:06] <sil2100>  ;)
[11:06] <didrocks> sure
[11:06] <didrocks> lp:~cupstream2distro-maintainers/cupstream2distro-config/otto
[11:06] <sil2100> Since I wonder how the switch looks like
[11:07] <didrocks> basically changing the extracheck job
[11:07] <didrocks> to the otto ones
[11:07] <didrocks> and listing the machines in apmachines
[11:08] <sil2100> hm, ah, so we also have to add recordmydesktop to the testpackages because otto does not install it by itself by default?
[11:09] <didrocks> sil2100: otto doesn't know about autopilot
[11:09] <didrocks> sil2100: and in raring, the deps of autopilot was wrong
[11:09] <didrocks> it's fixed in saucy, now autopilot deps on recordmydesktop
[11:09] <didrocks> as it should, otherwise, it's failing if you use the option :)
[11:10] <sil2100> Indeed, although I always thought that when recordmydesktop is not installed, autopilot will simply not use it
[11:10] <sil2100> That's how it should actually work ;p
[11:10] <sil2100> Just maybe write out a warning ;)
[11:11] <didrocks> right ;)
[11:12] <didrocks> no, it's failing straight away!
[11:15] <mzanetti> Saviq: when you have a minute, I'd need your help
[11:15] <Saviq> mzanetti, now that I got back to a working setup, hit me :)
[11:16] <mzanetti> Saviq: go to my launcher branch, build it, cd builddir and run make testLauncher
[11:16] <mzanetti> it'll fail linking to libuntiy-core
[11:17] <mzanetti> but it works on jenkins, and also works if I export LD_LIBRARY_PATH to the unity_build dir. Now I don't understand why as I can't spot any difference to other tests that import Unity 0.1
[11:17] <mzanetti> Saviq: ^
[11:17] <Saviq> mzanetti, checking
[11:20] <Saviq> mzanetti, it works on Jenkins 'cause "our" version of libunity-core is installed system-wide
[11:21] <mzanetti> Saviq: yes, I understand. but why doesn't that test find it? the others do
[11:21] <Saviq> mzanetti, and also I learned recently that set_target_properties(PROPERTIES ENVIRONMENT ...) is "not a thing" as mterry put it..
[11:21] <mzanetti> Saviq: I couln't find any place where we'd export LD_LIBRARY_PATH for running tests. so the question is rather: Why do all the tests work?
[11:22]  * mzanetti doesn't really understand the "not a thing" thing
[11:22] <Saviq> mzanetti, there's no ENVIRONMENT property on a custom target
[11:22] <Saviq> mzanetti, but!
[11:23] <Saviq> mzanetti, the tests work 'cause they're not using the real Unity plugin
[11:23] <mzanetti> oh
[11:23] <Saviq> mzanetti, and the fake one instead
[11:26] <Saviq> mzanetti, so you need to make sure that /tests/qmltests/plugins is on the import path before /plugins
[11:27] <mzanetti> Saviq: right...
[11:27] <mzanetti> Saviq: tests/plugins/ not?
[11:31] <nic-doffay> Just got newest trunk
[11:31] <nic-doffay> seems the users are hidden
[11:31] <nic-doffay> anyone have any idea about this?
[11:32] <mzanetti> nic-doffay: ./run -f
[11:33] <nic-doffay> mzanetti, autolanding failed for the merge too.
[11:33] <nic-doffay> mzanetti, also for running on device -f isn't an option
[11:35] <Saviq> mzanetti, no, tests/plugins are tests for plugins...
[11:35] <Saviq> mzanetti, I know
[11:35] <mzanetti> nic-doffay: temporarily, open run_on_device and add "-f" to line 89
[11:36] <nic-doffay> mzanetti, I attempted -f on ./run
[11:36] <nic-doffay> I'm not seeing anything.
[11:36] <nic-doffay> Not even the infographic.
[11:37] <mzanetti> nic-doffay: oh... seems to be a bug (which should be fixed when my branch gets merged)
[11:37] <nic-doffay> mzanetti, cool
[11:37] <mzanetti> nic-doffay: for now open run and edit line 39
[11:37] <mzanetti> nic-doffay: replace "single" at the end with "full"
[11:39] <mzanetti> Saviq: no... doesn't really help
[11:40] <Saviq> mzanetti, yes it does ;) look at the resulting qmltestrunner command
[11:40] <Saviq> mzanetti, and make it so that it's what you expect :)
[11:40] <Saviq> mzanetti, gimme 10, will have a line for you
[11:40] <nic-doffay> mzanetti, that change doesn't give me the generic user list.
[11:40] <nic-doffay> That the mock data provides.
[11:41] <mzanetti> nic-doffay: the Lola etc?
[11:41] <mzanetti> nic-doffay: thats gone
[11:41] <nic-doffay> mzanetti, ok. Is there a user without a pass?
[11:41] <mzanetti> nic-doffay: yes, the "no-password" user
[11:42] <mzanetti> nic-doffay: and for the rest the password is "password"
[11:45] <nic-doffay> mzanetti, ta
[11:46] <Saviq> mzanetti, where do I get LauncherModel for the test?
[11:47] <mzanetti> Saviq: I think we need to create a fake Ubuntu.Gestures plugin :/
[11:47] <Saviq> mzanetti, no we don't
[11:47] <Saviq> mzanetti, you need a mock LauncherModel, though
[11:47] <Saviq> mzanetti, in the fake Unity plugin
[11:48] <Saviq> qmltestrunner -input tests/qmltests/Launcher/tst_Launcher.qml -import builddir/plugins/ -import builddir/tests/qmltests/plugins/ -import builddir/tests/utils/modules/
[11:48] <Saviq> mzanetti, that line works ^
[11:48] <Saviq> mzanetti, the thing to note, each -import _prepends_ the import path
[11:49] <mzanetti> right
[11:49] <mzanetti> ok. thanks
[11:49] <Saviq> mzanetti, works with the exception that we need a fake LauncherModel in the fake Unity plugin
[11:49] <dandrader> Saviq, had the meeting with John. those are the conclusions
[11:49] <dandrader> - no need for DirectionalDragArea in the status bar/panel. Only when fullscreen
[11:49] <dandrader> - no hint animations for edge drags
[11:50]  * dandrader just read about the creation of fake Ubuntu.Gestures plugin. what?
[11:50] <Saviq> dandrader, no
[11:50] <Saviq> we won't
[11:50] <Saviq> dandrader, so what do we use for the status bar / panel?
[11:50] <Saviq> dandrader, when not in fullscreen? why can't we use DDA anyway?
[11:51] <dandrader> Saviq, what we currently have. because there is a visual target to interact with. there's no conflict with application UI
[11:52] <Saviq> dandrader, but why would we want to switch between a DraggingArea and a DirectionalDraggingArea?
[11:52] <Saviq> dandrader, for fullscreen / nofullscreen
[11:53] <Saviq> dandrader, we should be able to set DirectionalDraggingArea so that it can be used for non-fullscreen, too, no?
[11:53] <Saviq> dandrader, i.e. wideningAngle=90°
[11:53] <dandrader> Saviq, yes, we just put very relaxed parameters
[11:53] <Saviq> dandrader, yeah, that's what I meant
[11:55] <Saviq> dandrader, and +1 for edge hints, it probably only makes sense on the greeter
[11:55] <Saviq> dandrader, otherwise we should probably wait for the DDA to be sure that it is, in fact, an edge swipe - right?
[11:56] <dandrader> Saviq, yes
[11:56] <Saviq> dandrader, cool
[12:05] <mzanetti> paulliu: when writing new code we should use i18n.tr() on all user visible strings now, right?
[12:06] <paulliu> mzanetti: yes.
[12:06] <mzanetti> paulliu: also on buttons that have 1 number on it (for example like the numberpad in the dialer)?
[12:07] <paulliu> mzanetti: hmm...
[12:07] <paulliu> mzanetti: good question.. But we are using arabic numbers for that.
[12:07] <paulliu> mzanetti: Isn't that a kind of keyboard which shouldn't be translated?
[12:07] <mzanetti> paulliu: I don't know
[12:08] <mzanetti> paulliu: if you have a chineese mobile phone. does the dialer show arabic numbers or some chineese symbols?
[12:08] <paulliu> mzanetti: well, for numpad, We are using arabic numbers.
[12:08] <paulliu> mzanetti: Never saw a chinese numpad before.
[12:09] <mzanetti> paulliu: intersting...  so I won't make it translatable for now.
[12:10] <paulliu> mzanetti: Is there English numpad instead of arabic numbers?
[12:10] <paulliu> mzanetti: or any europe language. I think there isn't?
[12:10] <mzanetti> paulliu: no... we all use arabic numbers around here.
[12:10] <mzanetti> otoh... would be cool to have a dialer with roman letters :D
[12:10] <paulliu> Yeah.. That will be very cool..
[12:10] <mzanetti> lol... /me wants
[12:11] <dandrader> Saviq, should I start on the "OSK on mir-unity" right now or after the edge drag tasks (what's the priority)?
[12:11] <dandrader> Saviq, btw, https://code.launchpad.net/~dandrader/unity/phablet_edgeDragInStage/+merge/166777 should be good to go
[12:11] <paulliu> Yeah, I do think some people loves that. But would cause trouble if someone really translated that on launchpad. You'll see English numpad if someone do the translation.
[12:11] <mzanetti> paulliu: yeah... thats not reall useful... I'll leave it away for now
[12:11] <Saviq> dandrader, I think yes, go for the OSK
[12:12] <Saviq> dandrader, the edges work already
[12:12] <mzanetti> dandrader: btw... I fixed all remaining issues in the launcher branch
[12:12]  * Saviq hates the fact that there's no "msg" on tryCompare :[
[12:12] <mzanetti> +1
[12:13] <Saviq> tsdgeos, you were supposed to fix that ^ ;P
[12:13] <dandrader> mzanetti, already approved
[12:22] <Saviq> ugh Compiz ;(
[12:33] <mzanetti> dandrader: fixed the warnings.
[12:35] <dandrader> mzanetti, bonus points for you! :)
[12:36] <mzanetti> :)
[12:37] <mzanetti> dandrader: however, you would need to reapprove. and If you agree I think its ready to be top-approved
[12:40] <dandrader> mzanetti, technically speaking, my approval still holds and anyone can top-approve. my existing approval will still be carried into the final commit message
[12:40] <dandrader> mzanetti, but I can top-approve, no problem.
[12:41] <mzanetti> dandrader: really? thought only the last comitted revision's approvals will end up in the commit message
[12:42] <dandrader> mzanetti, well, I don't guarantee it but that's my understanding.
[12:42] <sil2100> didrocks: ok, oSoMoN is in the middle of fixing one bug that's causing one of the failures, but still looking on what's wrong with those 2 others
[12:42] <dandrader> mzanetti, e.g. there's this table showing the status of the reviewers
[12:42] <didrocks> ok :)
[12:42] <dandrader> mzanetti, at the top
[12:47] <didrocks> sil2100: ok, so, I'm going to start switching to saucy, merging from trunk and deploying, ok? I'll force manual publication (without commiting) just for the sake of it
[12:54] <dandrader> greyback, where does libubuntu_application_api_mirserver comes from?
[12:54] <greyback> dandrader: platform-api
[12:55] <sil2100> didrocks: ok, all is fine with the unity dep-switch? Do I have to merge it in manually or is it taken care of?
[12:56] <didrocks> sil2100: I have it in my otto branch
[12:56] <didrocks> sil2100: starting with QA stack right now ;)
[12:56]  * sil2100 keeps his fingers crossed
[12:57] <tsdgeos> Saviq: tryCompare? i did, it'll be ther on 5.1
[12:57] <sil2100> rsalveti: I see libhybris is in! \o/ We'll need MIR for that, right?
[12:57] <dandrader> greyback, from ppa:mir-team/staging?
[12:58] <Saviq> tsdgeos, good :)
[12:58] <tsdgeos> Saviq: ah sorry no
[12:58] <tsdgeos> i didn't
[12:58] <tsdgeos> you wanted the msg
[12:58] <Saviq> tsdgeos, bad :(
[12:58] <tsdgeos> didn't have time for that
[12:58] <sil2100> rsalveti: do you know if anyone is working on telepathy-ofono?
[12:58] <Saviq> tsdgeos, that's fine, just complainin' ;)
[12:58] <didrocks> sil2100: we need to daily release telepathy-ofono2
[12:58] <didrocks> sil2100: see the spreadsheet
[12:58] <greyback> dandrader: oh that's the server lib. It comes from ~robertcarr/platform-api/mir, which is still a work in progress.
[12:59] <didrocks> sil2100: want to do that? checking the packaging/meeting our criterias and so on?
[12:59] <didrocks> sil2100: there is a bunch that sergiusens and rsalveti pointed us to ^
[12:59] <didrocks> I wanted to discuss in our meeting, but if you have spare time, please jump on them :)
[12:59] <didrocks> I've done powerd review
[13:00] <dandrader> greyback, hmm, so that's not on http://studio.sketchpad.cc/gmY0M6iqeh? yet, right?
[13:00] <greyback> dandrader: nope, I built packages from that branch and put them in the people.canonical.com link there
[13:01] <greyback> dandrader: probable those packages are out of date, with all the changes to Mir and platform api though
[13:01] <didrocks> sil2100: do you want that we do a hangout?
[13:01] <Saviq> greyback, could you give me a list of branches we'd need to build into the unity-mir integration PPA?
[13:03] <greyback> Saviq: ~robertcarr/platform-api/mir and ~robertcarr/qtubuntu/mirserver/
[13:03] <Saviq> greyback, and your unity branch?
[13:03] <greyback> Saviq: yep ~unity-team/unity/phablet-integrate-mir/
[13:03] <Saviq> greyback, and a dependency on ppa:mir-team/staging, I assume?
[13:03] <greyback> Saviq: correct
[13:04] <Saviq> greyback, and qtubuntu?
[13:04] <greyback> Saviq: note robert's branches are package-ready, he'd not done anything about packaging his changes
[13:04] <greyback> Saviq: it's there, ~robertcarr/qtubuntu/mirserver/
[13:05] <Saviq> greyback, ah
[13:05] <Saviq> greyback, sorry
[13:05] <greyback> the names are mental
[13:05] <Saviq> greyback, and I understand you meant "are _not_ package-ready"?
[13:06] <greyback> Saviq: yep, just saw my error now. Correct, _not_ package-ready
[13:06] <Saviq> greyback, but you did build them - do you mean we should rename the packages and such?
[13:06] <greyback> I've a few hacks in my copy of his branches to get them to build packages
[13:07] <greyback> he's renamed so files which is the main reason stuff in debian/ needs to change a bit
[13:07] <Saviq> greyback, k, can you put a diff you have somewhere?
[13:07] <didrocks> sil2100:?
[13:08] <sil2100> didrocks: I'll just finish lunch and we do that then, and think about a hangout
[13:08] <kgunn> greyback just for my learning....what constitutes "package ready" ?
[13:09] <greyback> kgunn: running dpkg-buildpackage fails. Some files it expects to install are missing from the build directory
[13:09] <greyback> Saviq: for qtubuntu: http://pastebin.ubuntu.com/5732540/
[13:10] <didrocks> seb128: do you have some seconds for https://code.launchpad.net/~didrocks/autopilot/report_changelog_lost_in_trunk/+merge/167267? :)
[13:11] <kgunn> greyback: ah! thanks...
[13:11] <greyback> Saviq: platform-api branch: http://pastebin.ubuntu.com/5732550/
[13:12] <Saviq> greyback, cheers
[13:14] <Saviq> greyback, some of those hunks look like they should go into the branch already?
[13:16] <kgunn> MacSlow: ping
[13:17] <seb128> didrocks, done but I can't change the status, I'm not in the team ... can you do it for me? ;-)
[13:18] <didrocks> seb128: I wonder :)
[13:18] <didrocks> seb128: done, thanks! ;)
[13:18] <seb128> didrocks, yw ;-)
[13:19] <seb128> didrocks, just reviewed/acked ofono-qt in the archive btw
[13:21] <didrocks> oh, excellent! thanks again seb128 :)
[13:21] <seb128> didrocks, yw ;-)
[13:21] <didrocks> moons are slowly aligning!
[13:21] <seb128> indeed
[13:25] <sil2100> Back
[13:26] <greyback> Saviq: sorry, went to make tea. Probably yes, but I didn't want to contribute anything back until the platform-api stuff had settled. Really those were just hacks to get unity+mir to work
[13:26] <MacSlow> kgunn, pong
[13:26] <sil2100> didrocks: assigning those to meh!
[13:26] <Saviq> greyback, k, when do you think we can talk about fleshing this out?
[13:27] <greyback> Saviq: after standup is good for me
[13:27] <Saviq> greyback, ah, I thought that would be like "in two days" or something ;)
[13:27] <greyback> Saviq: let's have a chat then anyway
[13:27] <Saviq> greyback, yup
[13:28] <didrocks> sil2100: great! I disabled them for now in daily release, because they were enabled without checking
[13:29] <didrocks> sil2100: each of them should be a 15 minutes job I guess, the packages are already in a good shape
[13:29] <sil2100> didrocks: who added them btw.?
[13:29] <didrocks> sil2100: ken :(
[13:29] <sil2100> Ah, almost thought it was me by accident ;p
[13:29] <didrocks> you approved on one
[13:29] <didrocks> IIRC
[13:29] <sil2100> ! Oh noes
[13:29] <didrocks> sil2100: mind doing that before the meeting? Should be enough time :)
[13:30] <didrocks> sil2100: so that we release everything at the same time
[13:30] <sil2100> Ok, ubot5 just said to me that he doesn't know anything about "Oh noes"
[13:30] <Saviq> Cimi, tsdgeos standup?
[13:30] <tsdgeos> wops
[13:30] <sil2100> didrocks: yes, doing that!
[13:30] <Saviq> paulliu, standup?
[13:31] <didrocks> :)
[13:31] <paulliu> Saviq: yeah.. I'm connecting it.
[13:31] <Saviq> mterry, you joining the standup?
[13:32] <mterry> Saviq, yes, one sec
[13:35] <paulliu> Are you starting? I didn't hear anything?
[13:35] <Saviq> paulliu, we're talking
[13:39] <Saviq> nic-doffay, you need to up your mic
[13:39] <paulliu> Saviq: I can't hear anything. But I might be able to speak. So ping me if it is my turn.
[13:39] <Saviq> paulliu, ok :)
[13:45] <greyback> kgunn: can you also tell me what's needed for nexus7. I'd incorporate those instructions into the sketchpad to help others.
[13:45] <greyback> and I'm curious why we can't just land the new libhybris
[13:46] <kgunn> greyback: not completely sure those changes are in the new libhybris....there were upstream changes (but not merged)
[13:46] <kgunn> i'll check
[13:46] <kgunn> and if i and mterry can get it working
[13:46] <greyback> kgunn: understood
[13:46] <kgunn> then maybe we can propose
[13:51] <Saviq> paulliu, your turn
[13:51] <Saviq> paulliu, yes
[13:51] <Saviq> paulliu, we can hear you
[13:51] <greyback> paulliu: we hear you!
[13:51] <sergiusens> sil2100: didrocks just in case, hybris does not depend on mir and telepathy-ofono is not need but more so telepathy-ofono2
[13:52] <sergiusens> if we want to relink where trunk points to, I'll leave to you
[13:52] <paulliu> greyback: so strange.. I hear nothing from you and even the mouth of yours isn't turning read.
[13:52] <paulliu> s/read/red/
[13:52] <paulliu> But my mouth is red when I speaking.
[13:52] <greyback> paulliu: strange, just me?
[13:53] <paulliu> greyback: no, all of you.
[13:54] <sil2100> sergiusens: wait, you mean it does not depend on telepathy-ofono2, yes?
[13:58] <sergiusens> sil2100: you said that now that hybris is in, you need to wait for Mir
[13:59] <sergiusens> sil2100: so in other words... hybris does not depend on mir... but the other way around may be true
[13:59] <sil2100> sergiusens: hehe, I didn't mean mir as the mir project
[13:59] <sil2100> sergiusens: I meant MIR as in Main Inclusion Request ;)
[13:59] <sil2100> sergiusens: since libhybris needs to be in main, right?
[13:59] <sil2100> (those abbreviations are getting really confusing)
[14:00] <sil2100> sergiusens: a MIR would be needed for libhybris then for it inclusion to main, since right now it's in universe
[14:02] <didrocks> sergiusens: ack about hybris and mir (we are not having mir daily releasing anyway). I think moving telepathy-ofono2 to telepathy-ofono would make sense
[14:02] <didrocks> sergiusens: ah MIR, not Mir ;)
[14:02] <didrocks> as sil2100 told :)
[14:03] <didrocks> sil2100: about the telepathy-ofono2 thing, moving to lp:telepathy-ofono would make sense
[14:05] <sil2100> didrocks: I'm doing a packaging review of lp:telepathy-ofono/telepathy-ofono2 right now
[14:05] <sil2100> didrocks: (I did one for dbus-cpp already)
[14:05] <sergiusens> sil2100: ahhhh
[14:05] <sil2100> didrocks: what about the name of the package?
[14:06] <sil2100> didrocks: should we simply switch back to telepathy-ofono then? Since right now we have telepathy-ofono2 there that's 'replacing' telepathy-ofono
[14:06] <sil2100> (conflicts+provides+replaces)
[14:08] <didrocks> sil2100: I would prefer that: sergiusens, rsalveti: agree in renaming telepathy-ofono2 to telepathy-ofono?
[14:09] <sil2100> Yeah
[14:09] <sil2100> sergiusens, rsalveti: will the old telepathy-ofono be used anywhere anyway?
[14:12] <Saviq> mzanetti, re unity8 - that's only because we want Unity7 and 8 installable in parallel
[14:13] <Saviq> mzanetti, it's a temporary name, but a better one than qml-phone-shell or unity-next
[14:13] <pete-woods> Saviq, mzanetti: just wanted to check it was known that the "narrow mode" detection seems to be broken on phablet head
[14:13] <Saviq> pete-woods, -f
[14:13] <mzanetti> Saviq: not sure if its better than unity-next
[14:14] <Saviq> mzanetti, it is because there is no "Unity Next"
[14:14] <Saviq> mzanetti, the decision was made that there is only Unity
[14:14] <Saviq> and what we're working on now is version 8 of Unity
[14:14] <sergiusens> sil2100: telepathy-ofono no... but to get more input on that we need to switch channels ;-)
[14:14] <mzanetti> Saviq: yeah... but then there will be unity9 and we have to rename. and then rename to unity10 and then to unity11 and then probably the old unity dies and we can get rid of the problem
[14:15] <pete-woods> Saviq: with -f the screen is totally blank, instead of just having the infographic
[14:15] <Saviq> mzanetti, mterry what's the deal with the -f switch ^?
[14:15] <pete-woods> (on desktop machine at 1080p here)
[14:15] <mzanetti> pete-woods: its not related to screen size any more
[14:15] <Saviq> mzanetti, before we get to unity9 we'll rename to unity
[14:16] <pete-woods> haha!
[14:16] <mterry> Saviq, mzanetti, pete-woods: what's the question about -f?
[14:16] <pete-woods> I need to add another fake user to my computer
[14:16] <mzanetti> Saviq: will we rename the old one to unity7 then?
[14:16] <mterry> pete-woods, you want tablet mode?
[14:16] <mzanetti> mterry: he wants a infographic
[14:16] <Saviq> mzanetti, no, at that point we replace unity-7* with unity-8*
[14:16] <Saviq> mzanetti, i.e. upgrade
[14:16] <mzanetti> Saviq: right... lets talk again then
[14:16] <mzanetti> :P
[14:17] <mterry> mzanetti, oh, yeah I think the single/ user doesn't have infographic data
[14:17] <mterry> mzanetti, but your pin/ user does, right?
[14:17] <mzanetti> mterry: yes
[14:17] <pete-woods> mterry: yes, I want it to run in tablet mode when I start it fullscren
[14:17] <mzanetti> pete-woods: there is no tablet mode
[14:17] <pete-woods> unless there's a more "proper" solution coming along
[14:17] <pete-woods> oh
[14:17] <pete-woods> fair enough then
[14:17] <mterry> pete-woods, ah, that is no longer a thing.  it shows phone or multi-user login based on how many users
[14:18] <mterry> pete-woods, but I can show you how to get the multi-user login
[14:18] <pete-woods> that would be good :)
[14:18] <mterry> pete-woods, LD_LIBRARY_PATH=./builddir/tests/mocks/LightDM/full ./run -f
[14:18] <mzanetti> pete-woods: there is multiUser yes/no. dpeending on that the LoginList is shown or not. so what you have to do is to load a lightdm backend that has multiple users
[14:19] <pete-woods> okay, so the demo data has been cleaned up
[14:20] <pete-woods> it might have been sensible to change the infograhic data at the same time as changing all the users
[14:21] <kgunn> Saviq: ping
[14:21] <pete-woods> oh you have
[14:21] <Saviq> kgunn, pong
[14:21] <pete-woods> so why not working then, confusion
[14:21] <pete-woods> ah, there's some discrepancy with the "wide mode" detection
[14:22] <pete-woods> start fullscreen with -f and you'll see what I mean
[14:24] <pete-woods> I'm sure this will get sorted, but now fresh tablet installs will bring up a screen containing only the infographic
[14:26] <mzanetti> pete-woods: yeah... we can choose between having a loginlist on the phone or a single-user tablet
[14:27] <mzanetti> pete-woods: we opted to make it closer to what the phone will be
[14:27] <pete-woods> mzanetti: that's fair enough, but at the moment it just looks like it's broken
[14:27] <pete-woods> (as in it appears that way to the user)
[14:27] <mzanetti> pete-woods: but you still can run it with -f (once its fixed - there seems to be an issue) to get an emulation of a multiuser setup
[14:28] <pete-woods> okay
[14:28] <mzanetti> pete-woods: question is whether the infographic should be centered on the tablet too if there is no user list
[14:29] <pete-woods> mzanetti: the infographic just uses the "am I in narrow mode" flag
[14:29] <mzanetti> bad narrow mode flag :D
[14:29] <pete-woods> yes!
[14:29] <pete-woods> bad flag!
[14:30] <pete-woods> mzanetti: grep -r 'narrowMode:' .
[14:30] <pete-woods> ./Greeter/Greeter.qml:    readonly property bool narrowMode: !multiUser && width <= units.gu(60)
[14:30] <pete-woods> ./Components/PageHeader.qml:                property bool narrowMode: parent.width < label.contentWidth + units.gu(50)
[14:30] <pete-woods> ./Dash/DashPreview.qml:    readonly property bool narrowMode: width <= height
[14:31] <pete-woods> there seem to be 3 of them
[14:31] <greyback> kgunn or Saviq: can either of you move this doc into the "UnityNextUI" folder on gdoc please: https://docs.google.com/a/canonical.com/document/d/1874UWc-968YI70u9FxcOs_HWNmlqWGO8iKofToUwjMw/edit?usp=sharing
[14:31] <greyback> I don't seem to have that ability
[14:31] <mzanetti> pete-woods: for DashPreview its ok...
[14:31] <mzanetti> pete-woods: page-header too
[14:31] <kgunn> greyback: ack
[14:31] <mzanetti> pete-woods: in that case they just check how to layout depending on the space
[14:31] <pete-woods> fair enough
[14:31] <mzanetti> pete-woods: but the other in the Greeter... that seems fishy
[14:32] <pete-woods> I agree
[14:32] <kgunn> greyback: done
[14:32] <greyback> kgunn: thank you
[14:32] <pete-woods> mzanetti: (I haven't changed it because I've never understood the narrow mode plan myself)
[14:33] <mzanetti> pete-woods: well that was basically a temporary hack to simulate multiuser on the tablet (it also had a FIXME: replace with real stuff)
[14:33] <mzanetti> pete-woods: now that we can really determine if there is a multiuser or not, this should probably go away and the infographic should do something like:
[14:34] <mzanetti> if loginList.visible: show-next-to-list(); else: show-centered()
[14:36] <mzanetti> pete-woods: actually I'm not sure... it could be that we want the login list also in single user scenarios if the screen is large enough. I think we need to discuss that in the next greeter weekly
[14:36] <pete-woods> mzanetti: I would tend to agree with that
[14:37] <mzanetti> that said, I'll miss the next greeter weekly
[14:37] <mzanetti> :P
[14:37] <mzanetti> anyways, I'll write a mail with the problematic
[14:38] <tedg> mhr3, seb128, what's the plan with the new ZG and Saucy?
[14:39] <sil2100> didrocks: a quick packaging question - since we're renaming the source name, what should I do with the old changelog entries for the package?
[14:41] <tedg> mzanetti, pete-woods, wouldn't we need it for things like remote login and guest users if we had space?
[14:42] <didrocks> sil2100: you can remove them as they were never in distro
[14:42] <mzanetti> tedg: yes... but in terms of greeter-speak thats just a normal multi user scenario, I'd say
[14:43] <Saviq> greyback, my solution for that: star both, go into "Starred" folder, drag the new doc into the other starred folder :D
[14:43] <Saviq> greyback, I know, but it's the only way I found how to do that :D
[14:43] <greyback> Saviq: oh wow
[14:43] <tedg> mzanetti, Kinda, except that we'll never not have guest functionality -- so we'd always require a prompt then :-)
[14:43] <greyback> Saviq: I gave up suspecting permissions or something weird
[14:43] <mzanetti> tedg: I think we will disable guest login in some cases, no?
[14:43] <Saviq> greyback, no, it seems to just be usability FAIL
[14:43] <mhr3> tedg, why do you ask?
[14:44] <mhr3> i mean, there isn't that much new
[14:44] <tedg> mzanetti, Only for space I'd think.  It doesn't take any space on disk or anything, so I imagine we'll just keep the images the same.
[14:44] <tedg> mhr3, Well, a new package name for me to depend on :-)  libzg-2.0-dev
[14:45] <tedg> At least how it's packaged in the PPA
[14:45] <fginther> sil2100, ping
[14:45] <mzanetti> tedg: hmm... I think on phones there will be no guest user, no? Also on the desktop I can disable it if I want, I think
[14:45] <tedg> mzanetti, Disable, yes.  Remove, no.
[14:45] <tedg> (well, it's open source, but easily)
[14:46] <mhr3> tedg, you don't *have* to use it, -1.0 will work just fine (and it's more c-friendly), -2.0 is more vala friendly
[14:46] <tedg> mhr3, K, but that's why I'm asking.  Avoiding be deprecated as long as possible :-)
[14:47] <mhr3> tedg, libzg-1.0 is canonical project, so we can decide when to deprecate it :)
[14:47] <mterry> mzanetti, current plan for phone guest user is just to not implement it yet in the qml greeter  :)
[14:47] <tedg> mhr3, Also, I guess I'd need a distro patch for the action type thingy that we added.
[14:47] <mhr3> tedg, right, as i said, we own it :)
[14:48] <mzanetti> mterry: huh? isn't it just a regular user in the ListModel whos name happens to be Guest and he doesn't like to set a password?
[14:48] <tedg> mzanetti, No, it's special.
[14:48] <mzanetti> I mean on top of the LightDM.UserModel
[14:48] <mterry> mzanetti, oh, that's how it looks right now in the demo.  But there is a special hint in lightdm that the greeter is supposed to show a guest account, which will trigger the usual Ubuntu guest login
[14:48] <tedg> Guests get created and destroyed dynamically.
[14:49] <tedg> mhr3, Okay, but why not go to the new one and deprecate 1.0?
[14:49] <mzanetti> mterry: I suggest to aggregate that user in the C++ model and make it transparent for QML unless you like pain when implementing animations
[14:49] <tedg> mhr3, I mean, that seems easier, no?
[14:50] <mterry> mzanetti, yeah agreed
[14:50] <mhr3> tedg, one doesn't have a symbol, the other isn't in distro... don't see much difference in easiness :)
[14:51] <mhr3> tedg, actually s/symbol/define/ so you can use it right away, for zg api it's just a string
[14:52] <tedg> mhr3, Sure, but once seif finds out it's not in distro, he'll start visiting seb128's house daily.  I'm trying to protect seb128 here :-)
[14:52] <mhr3> tedg, aaah, right, yea didn't think about that... poor seb128, but maybe he deserves it ;)
[14:52] <tedg> mhr3, Okay, I'll go with distro today, seb128 can get me if that changes :-)
[14:52] <mhr3> at least for a few days :)
[14:53] <sil2100> didrocks: ok, so, I created a new series, switched the name and pointed the trunk series to it and made a packaging review (with the name switch)
[14:53] <sil2100> didrocks: https://code.launchpad.net/~sil2100/telepathy-ofono/name_switch_and_packaging_review/+merge/167301
[14:53] <sil2100> didrocks: besides that, there's still the dbus thing:
[14:53] <sil2100> https://code.launchpad.net/~sil2100/dbus-cpp/packaging_review/+merge/167286
[14:54] <sil2100> But I see CI doesn't like it, let me see why
[14:54] <didrocks> sil2100: ok, can you get kenvandine reviewing it for you?
[14:54] <didrocks> sil2100: I'm really busy switching all the branches to saucy
[14:54] <sil2100> didrocks: ah, the merge fails because saucy has a different toolchain and some C++ is failing...
[14:54] <sil2100> didrocks: ACK :)
[14:55] <kenvandine> sil2100, sounds like what i've been fighting with webcred
[14:55] <kenvandine> i fixed the build failures related to the toolchain  changes...
[14:55] <kenvandine> but now we have tests that fail on saucy that don't fail on raring
[14:56] <sil2100> kenvandine: ;) I'll take care of those then, in the meantime could you take a look at my ofono branch? (should be safer)
[14:56] <sil2100> kenvandine: ouch...
[14:56] <kenvandine> sure
[14:56] <sil2100> kenvandine: we'll be anyway switching to saucy only, so maybe it would be wise to just wait for the switch
[14:56] <sergiusens> sil2100: added a comment to telepathy-oofno
[14:56] <kenvandine> and i am starting to this the problem is with the tests
[14:57] <kenvandine> sil2100, that is why i need to get these fixed :)
[14:57] <sil2100> sergiusens: thanks! Will give that a look ;)
[14:57] <sil2100> Good catch
[14:57] <sil2100> kenvandine: ;)
[14:58] <didrocks> kenvandine: that's why we have a FTBFS on webcreds?
[14:58] <sil2100> kenvandine: when you have a moment, could you take a look at https://code.launchpad.net/~sil2100/dbus-cpp/packaging_review/+merge/167286 packaging-wise without top-approving?
[14:58] <kenvandine> didrocks, yes
[14:58] <sil2100> I'll look into the thing that sergiusens mentioned
[14:58] <didrocks> kenvandine: do you know if it's going to be fixed? as now apps are depending on webcreds, we can't release them, so all touch is blocked on that.
[14:58] <kenvandine> didrocks, yes, it will
[14:59] <kenvandine> i've fixed all the builds and deprecations
[14:59] <didrocks> kenvandine: I think I meant "when?" :)
[14:59]  * rsalveti reading backlog
[14:59] <kenvandine> mardy is going to fix the tests tomorrow
[14:59] <didrocks> hum…
[14:59] <olli_> sil2100, didrocks, any news on scopes *nag*
[14:59] <didrocks> olli_: so still no touch in distro tomorrow (and no 100 scopes) because of this ^
[14:59] <didrocks> only once webcred will be fixed I guess
[15:00] <kenvandine> i am reasonably sure these test failures are the last thing
[15:00] <kgunn> mterry here's the upstream changes that are supposed to address hybris for nexus7 https://github.com/libhybris/libhybris/pull/49
[15:00] <didrocks> olli_: nice double pinging btw :)
[15:00] <kgunn> i went about manually merging....thot i had it, but
[15:00] <mterry> kgunn, yes...  I remember looking at that a while ago, but it was unclear if only that patch or additional upstream changes which that patch presupposes were needed
[15:00] <sil2100> kenvandine: could you also take a look at https://code.launchpad.net/~sil2100/dbus-cpp/packaging_review/+merge/167286 packaging-wise? Approve locally as well, since this won't go in until I get it fixed
[15:01] <kenvandine> sil2100, sorry.. yes
[15:01] <kenvandine> but not until after the meeting
[15:01] <kgunn> building from scratch didn't automagically use what i pulled over
[15:01] <kenvandine> trying to finish some SRUs
[15:01] <sil2100> (I might push Thomas to help me here, he probably knows the code better too!)
[15:01] <sil2100> kenvandine: thanks!
[15:01] <didrocks> olli_: also, the QA stack has some new tests failing, they have been poked FYI
[15:01] <kenvandine> sil2100, is that the only branch you need right now?
[15:02] <sil2100> kenvandine: just the two I mentioned ;) the ofono one and dbus-cpp
[15:02] <kgunn> mterry: my understanding based on kdub comments is that we only need to pull over the changes from hooks & hooks_shm
[15:02] <olli_> didrocks, sorry, wasn't reading backlog
[15:02] <kenvandine> ah, i thought i had missed one
[15:02] <sil2100> :)
[15:02] <kenvandine> sil2100, i'll do those
[15:02] <sil2100> kenvandine: big thanks!
[15:02] <didrocks> olli_: no worry ;)
[15:03] <kgunn> mterry...i had just yesterday pulled a clean proprietary bins from n7
[15:03] <didrocks> kenvandine: btw, on the webcred stack, it seems that account-plugins had some manual upload to fix in trunk :)
[15:03] <kenvandine> sil2100,  has telepathy-ofono2 ever been uploaded?
[15:03] <kgunn> to give it another go
[15:03] <didrocks> kenvandine: same for some friends stuff
[15:04] <didrocks> (see the yellow in prepare)
[15:04] <kenvandine> didrocks, i did the account-plugins one
[15:04] <kgunn> but you are welcome to put me to shame and move faster :)
[15:04] <kenvandine> already proposed merging to trunk
[15:04] <mterry> kgunn, alright, I'll play with it today
[15:04] <kenvandine> we needed to get the facebook fix in before the SRUs
[15:04] <didrocks> kenvandine: ok, so will be good in tomorrow daily?
[15:05] <kenvandine> yes
[15:05] <kenvandine> at least for that :)
[15:05] <kenvandine> and hopefully sometime tomorrow mardy will have those tests fixed
[15:05] <kenvandine> libsignon-glib and libaccounts-glib
[15:06] <didrocks> ok :)
[15:07] <didrocks> tedg: larsu: so indicators enabled back in saucy is fine for you, right?
[15:07] <didrocks> from what I read from cyphermox and sil2100 yesterday
[15:08] <tedg> didrocks, Yes, please.
[15:09] <larsu> didrocks: \o/
[15:09]  * didrocks pushes THE button
[15:09] <larsu> haha
[15:09]  * larsu wants to see what THAT button looks like
[15:10] <didrocks> larsu: a not sexy jenkins button until we have the dashboard :p
[15:10] <cyphermox> let's MAKE one
[15:10] <didrocks> but then, I'll make one in the dashboard
[15:10] <didrocks> with some gangam style music :)
[15:10] <cyphermox> didrocks: actually, we should make an actual big red button that does something
[15:10] <cyphermox> haha
[15:10] <didrocks> gangnam*
[15:10] <didrocks> cyphermox: complete +1 ;)
[15:12] <cyphermox> should be easy enough too, I have an arduino here, and there's a office supply company which sells big red buttons that trigger some kind of music
[15:12] <sil2100> didrocks: what abour powerd? Since you said something you were working on it?
[15:12] <seb128> tedg, mhr3: what do you guys plan to break?
[15:13] <sil2100> didrocks, kenvandine: another branch, small changes to dee-qt this time: https://code.launchpad.net/~sil2100/dee-qt/packaging_review/+merge/167312
[15:14] <didrocks> sil2100: I've done a review of powerd
[15:14] <didrocks> sil2100: so, it should be fine
[15:14] <sil2100> ACK ;)
[15:15] <didrocks> sil2100: for dee-qt, think about precise -> next LTS upgrade
[15:16] <sil2100> didrocks: precise?
[15:16] <sil2100> ah
[15:16] <didrocks> sil2100: precise had dee-qt for unity-2d
[15:16] <sil2100> Upgrade cases, yes?
[15:16] <didrocks> yep :)
[15:16] <sil2100> Right!
[15:17] <sil2100> Let me check that
[15:17] <mterry> kgunn, is there any way to download a simple diff from github?  Not used to its UI
[15:17] <didrocks> thanks
[15:17] <kgunn> mterry: github total pain
[15:17]  * mterry copies and pastes
[15:18] <kgunn> mterry: i did manage to clone i can send you a zip
[15:18] <mterry> kgunn, no, I think I got it, thanks
[15:52] <nic-doffay> warning to anyone who has Kdevelop installed.  Packages are bust.
[15:56] <tedg> mhr3, Wait, doesn't libzg 2 do the mmap thing where libzg 1 is all dbus?
[15:57] <mhr3> tedg, for reading the db, yea
[15:57] <tedg> seb128, No, just looking at the zg task for hud to get rid of our custom usage database.
[15:57] <tedg> mhr3, Hah!  There is a feature I want ;-)
[15:58] <seb128> tedg, ah ;-)
[15:58] <mhr3> tedg, welcome to our beta-testers group then ;P
[15:58] <tedg> mhr3, I actually already have it installed.  But I didn't want it to get blocked going into saucy.
[15:59] <tedg> So seb128, can haz libzg v2?
[15:59] <seb128> tedg, ask to didrocks
[15:59] <seb128> not sure why they stopped updating it
[15:59] <seb128> didrocks, ^?
[15:59] <tedg> didrocks, seb128 said you need to update libzg before you leave today.
[16:00] <tedg> didrocks, I told him that was unreasonable and by the end of the week was better.
[16:00] <tedg> didrocks, I'm on your side here.
[16:00] <seb128> ;-)
[16:01] <didrocks> tedg: ahah :p
[16:01] <didrocks> not sure what the context is, but I have clearly no time for it AFAIK ;)
[16:03] <seb128> didrocks, do you need if there is any reason to not update libzg? (you had been looking at it in the past so I figured that if you didn't update there was a reason) ... we can discuss that after your meeting
[16:06] <didrocks> seb128: really? you are talking about prehistoric age, isn't it? :)
[16:06] <didrocks> it seems to be some kind of "you touched it, it sticks"
[16:06] <didrocks> don't really like that :)
[16:07] <seb128> didrocks, well, it's how it works here! ;-)
[16:07]  * tedg thinks that didrocks now learns why he doesn't want upload privileges -- "Oh, sorry, I can't do that"  ;-)
[16:08] <rsalveti> sergiusens: https://code.launchpad.net/~sil2100/telepathy-ofono/name_switch_and_packaging_review/+merge/167301 looks good to me
[16:08] <rsalveti> sergiusens: any concern?
[16:09] <nic-doffay> Saviq, I'm on Saucy now. You encountered issues with this PPA: http://ppa.launchpad.net/phablet-team/desktop-deps/ubuntu/dists/saucy/main/binary-i386/Packages ?
[16:10] <Saviq> nic-doffay, there's no saucy packages there yet
[16:10] <sergiusens> rsalveti: in itself it looks good... but the phone app has a hard dep on telepathy-ofono2
[16:10] <Saviq> nic-doffay, I'll take care of that tomorrow morning
[16:10] <nic-doffay> Saviq, cool.
[16:11] <rsalveti> sergiusens: right, that needs to be changed as well then
[16:11] <rsalveti> sil2100: do we have a mr for that already?
[16:12] <sil2100> rsalveti: for what? Let me backtrack
[16:12] <sil2100> Ah
[16:13] <sil2100> No, not yet, but it's in the works, since I have a meeting right now
[16:14] <sergiusens> sil2100: rsalveti as long as we are in sync I can change the phone-app... but it would be good to trigger a build of telepathy-ofono as soon as it lands in trunk
[16:15] <rsalveti> sergiusens: right
[16:16] <sil2100> sergiusens: please do then, I think that would be a good idea ;)
[16:17] <tedg> larsu, Seems there's a conflict in your libindicator branch: https://jenkins.qa.ubuntu.com/job/libindicator-saucy-amd64-autolanding/6/console
[16:18] <sergiusens> sil2100: ok, ping me as soon as it's built and I'll get that MR in
[16:19] <sil2100> sergiusens: ok! Thanks
[16:19] <sergiusens> sil2100: rsalveti approved the mr from my part
[16:20] <larsu> tedg: weird, the launchpad diff doesn't complain. I'll investigate
[16:21]  * greyback needs to reboot
[16:22] <rsalveti> sergiusens: sil2100: happroved it
[16:44] <rsalveti> sil2100: https://code.launchpad.net/~sil2100/telepathy-ofono/name_switch_and_packaging_review/+merge/167301 just got merged
[16:44] <rsalveti> mind triggering a new build and proposing the other mr for the phone-app?
[16:45] <sil2100> rsalveti: is telepathy-ofono already added to cupstream2distro-config in head?
[16:45] <sil2100> rsalveti: since when I checked before, I couldn't find it in head yet
[16:45] <rsalveti> sil2100: probably not, sergiusens might know better
[16:45] <sil2100> If that's true, we need to add it first and redeploy
[16:46] <sil2100> sergiusens: ^ ?
[16:46] <kgunn> mterry: mzanetti ....was chatting with nic-doffay on mock infog data being removed to "make the ui work"
[16:47] <kgunn> can you elaborate why ?
[16:47] <mzanetti> kgunn: the mock data is split up in multiple parts now
[16:48] <mzanetti> kgunn: there is one with a single user, one with multiple users, one with the previous demo content
[16:48] <mzanetti> kgunn: per default we are loading a single user one right now to move closer to what it really will be on the phone
[16:48] <kgunn> mzanetti: ah...making more sense
[16:49] <kgunn> mzanetti: question is....does pete or nic need to do anything to get the infographic working again?
[16:49] <mzanetti> kgunn: I think there is a small bug right now, but once fixed, you can ./run -f  to get the demo data (mterry, correct me if I'm wrong)
[16:49] <kgunn> mzanetti: right...i was thinking ./run_on_device
[16:50] <mzanetti> kgunn: ah yeah... its not passed through yet... and I didn't want to add it right now because it would conflict in multiple places with my lockscreen branch thats close to land
[16:50] <mzanetti> kgunn: let me just check if its landed
[16:52] <mzanetti> kgunn: no... its not landed yet
[16:52] <mzanetti> someone up for a review? https://code.launchpad.net/~unity-team/unity/phablet-pinlock/+merge/167115
[16:52] <kgunn> mzanetti: thanks...makes more sense to me now
[16:53] <mzanetti> kgunn: this already adds -p and -k to load user backends with either a PIN (-p) or a passphrase with keyboard input (-k)
[16:53] <kgunn> yep
[16:53] <mzanetti> kgunn: just the same way we'd need to pass -f through
[17:06] <sil2100> rsalveti, sergiusens: I need to go now, but if anything I submitted a MR for the move of ofono to head (but you guys need to check if it's ok)
[17:06] <sil2100> rsalveti, sergiusens, kenvandine: https://code.launchpad.net/~sil2100/cupstream2distro-config/move_ofono_to_head/+merge/167344
[17:06] <sil2100> We'll probably deal with that tomorrow in the end
[17:08] <sil2100> didrocks: ^
[17:08] <sil2100> Ok, see you tomorrow!
[18:41] <mardy> larsu: forgot to tell you that that QQmlPropertyMap fix has been accepted for Qt 5.1
[18:41] <mardy> kenvandine: do you think you can add a distro-patch to Qt 5.0.2?
[18:42] <kenvandine> mardy, probably
[18:42] <kenvandine> but might be best to ask Mirv
[18:42] <mardy> kenvandine: https://codereview.qt-project.org/#change,57392 if you think it's fine, I can prepare a clean patch tomorrow
[18:42] <mardy> Mirv: ^
[18:42] <kenvandine> and he is closer to your timezone :)
[18:42] <mardy> kenvandine: right :-)
[18:43] <kenvandine> so if you prepare a patch you can sync up with him before i wake up :)
[18:43] <kenvandine> mardy, don't forget those tests!
[18:43] <kenvandine> i've fixed the g-c-c-s build problem
[18:43] <kenvandine> but tests fail there too
[18:43] <kenvandine> so libsignon-glib, libaccounts-glib and g-c-c-s :)
[18:43] <kenvandine> it's blocking the whole touch stack for saucy... no pressure :)
[20:23] <kgunn> mterry ping
[20:23] <mterry> kgunn, hello
[20:24] <mterry> kgunn, so I had a dentist appointment, but I've got a patch that applies and builds, just need to test it
[20:24] <kgunn> mterry: hey weird one...if we say have a unity7 greeter leading to either a unity7 desktop session or a unity8 desktopsession
[20:24] <kgunn> how does lock screen play there ?
[20:24] <mterry> (my thing was about libhyrbis)
[20:25] <kgunn> ack the libhybris stuff
[20:25] <kgunn> e.g. is lock screen part of lightdm
[20:25] <mterry> kgunn, shouldn't matter...  Unity7 throws up a gnome-screensaver screen right now (though they've been meaning to make that go to greeter instead)
[20:26] <mterry> kgunn, the blocker for that was Mir, since they (robert-ancell) ran into some problems making the vt switch happen with some proprietary drivers for some reason
[20:26] <mterry> kgunn, I'm not well versed on the issue
[20:26] <mterry> kgunn, but with Mir that would be solved, presumably
[20:26] <mterry> kgunn, so unity7 can continue using gnome-screensaver if it wants
[20:27] <mterry> kgunn, and unity8 could just switch to a greeter if it wanted too, assuming Mir was present
[20:28] <kgunn> mterry: cool thanks
[20:34] <greyback_> kgunn: before you go, can you point me to a doc/branch with nexus7 Mir instructions/code?
[20:34] <kgunn> greyback_: mterry  is just now testing it
[20:34] <mterry> Hmm, using my new libhybris, I still get a black screen on startup....  greyback_ do you know how to debug the libhybris-on-nexus7 issue?  Like, is there a log somewhere that will have relevant messages?
[20:35] <greyback_> mterry: adb logcat maybe
[20:35] <mterry> greyback_, I can give you a debdiff against the current libhybris if you want to test yourself
[20:35] <greyback_> mterry: unfortunately I don't have a nexus 7 to test with
[20:35] <greyback_> mterry: but do any of the mir-demos work (via adb shell)
[20:36] <mterry> greyback_, not sure.  I'm not familiar with debugging mir on a device
[20:36] <mterry> greyback_, you mean just log in, and launch some of the demos?
[20:36] <greyback_> mterry: yep
[20:36] <kgunn> mterry....try to catch right at boot from your console adb logcat > log.txt
[20:37] <kgunn> oh yeah...even better
[20:37] <kgunn> check if mir is functional
[20:38] <greyback_> mterry: http://unity.ubuntu.com/mir/installing_prebuilt_on_android.html should help
[20:38] <greyback_> mterry: and then http://unity.ubuntu.com/mir/using_mir_on_android.html
[20:39] <mterry> greyback_, hrm, mir_demo_server segfaults
[20:39] <greyback_> mterry: any error output?
[20:40] <mterry> greyback_, some property_set outputs and then "__pthread_gettid -2"
[20:40] <greyback_> mterry: nothing useful :(
[20:41] <kgunn> mterry: my guess is....that's probably what you nornmally get on hybris today....
[20:41] <greyback_> mterry: aside from rebooting and running through the steps again, there's not much I can help with if mir_demo_server fails. It's too low-level for my knowledge right now
[20:41] <mterry> kgunn, yes
[20:42] <mterry> greyback_, who is next down?  robert carr?
[20:42] <kgunn> kdub on
[20:42] <greyback_> mterry: kdub
[20:42] <mterry> kdub_, poke!  :)
[20:42] <kdub_> hello
[20:42] <mterry> kdub_, so I've been trying to get mir-on-nexus7 to work
[20:42] <kdub_> ah, ok
[20:42] <mterry> kdub_, I've download and built a version of libhybris with that shm patch
[20:43] <mterry> kdub_, but it still doesn't work right, and I wanted to try to debug further.  But I'm not sure how
[20:43] <kgunn> mterry: did you manual merge into the phablet version of hybris ?
[20:43] <kdub_> how isn't it working right?
[20:43] <kgunn> or just build an upstream ?
[20:43] <mterry> kgunn, patched our phablet version
[20:44] <mterry> kdub_, well, I get the same result as if I didn't have a patched libhybris.  Which is just a black screen on startup because mir segfaults
[20:44] <kdub_> there are some tests in hybris that drive the screen... test_glesv2
[20:45] <kdub_> i'd see if those work
[20:45] <kdub_> because the problem shouldn't be when mir starts, it should be when a client connects
[20:46] <mterry> kdub_, well, the mir_demo_server executable crashes too
[20:46] <greyback_> mterry: that patch wouldn't change the abi of libhybris, would it?
[20:47] <mterry> greyback_, oh god, good point.  I'm not sure
[20:47] <kdub_> mterry,  so something is going wrong before we get to the point that we can test if the patches are working
[20:47] <greyback_> mterry: can you link me to the patch? I'd like a look
[20:47] <mterry> greyback_, no, I don't think so
[20:47] <mterry> greyback_, https://github.com/libhybris/libhybris/pull/49/files
[20:47] <greyback_> mterry: thanks
[20:48] <mterry> kdub_, hrm.  any good way to get feedback about where I should be looking then?
[20:48] <kdub_> well, id start with that test program from the hybris build tree
[20:49] <greyback_> mterry: it's changing int to an 'unsigned int' in several function definitions. That would break ABI, no?
[20:51] <mterry> greyback_, those are public functions?
[20:52] <mterry> greyback_, the only header it touches is a new one
[20:52] <greyback_> mterry: hmmm, so I see
[20:53] <mterry> kdub_, test_hw segfaults
[20:53] <mterry> kdub_, I'm guessing that's not typical
[20:53] <kdub_> mir has a similar program that just drives the display, called mir_demo_standalone_render_to_fb, but i'd expect that to do the same thing
[20:54] <kdub_> with test_glesv2, you should see a spinning spiral
[20:55] <mterry> kdub_, running that in a shell without any mir server?
[20:55] <mterry> kdub_, it's running, but I don't see anything
[20:56] <kdub_> running in the ubuntu chroot, with both mir and surfaceflinger disabled, you should see the spiral
[20:56] <mterry> kdub_, and I don't see mir_demo_standalone* installed
[20:56] <kdub_> i'm not sure if we distribute that one actually, would have to check the packaging
[20:56] <kdub_> but it would pretty much do the same thing as the full mir server
[20:58] <mterry> kdub_, after stopping surfaceflinger, I see the swirls
[20:58] <kdub_> hopefully mir works now too :)
[20:58] <mterry> kdub_, nope, same result
[20:58] <kdub_> is there a backtrace?
[20:58] <mterry> at least, running the demo
[20:59] <mterry> no
[20:59] <kdub_> a logcat?
[21:00] <mterry> kdub_, hrmm..  "failed to load libnvcap_video.so" ?
[21:01] <kdub_> eh, don't know if that will matter, could pastebin?
[21:01] <kdub_> *could you pastebin
[21:01] <mterry> sure
[21:01] <mterry> kdub_, http://pastebin.ubuntu.com/5733951/
[21:04] <kdub_> mterry, is there a /system/lib/hw/hwcomposer.tegra3.so or /vendor/lib/hw/hwcomposer.tegra3.so ?
[21:04] <kgunn> kdub_: doesn't seem so
[21:05] <kgunn> i just did extract_files fresh today
[21:05] <kgunn> ooops
[21:05] <kgunn> nvmd
[21:05] <kgunn> i meant...i couldn't find libnvcap_video.so
[21:06] <mterry> kdub_, there is a /system one but not a /vendor one
[21:07] <kdub_> mterry, ok, let's force mir's fallback display... 'mv /system/lib/hw/hwcomposer.tegra3.so /system/lib/hw/blah'
[21:07] <kdub_> there should be a mir command line option for that... but moving files so mir can't find them works too :)
[21:07] <mterry> kdub_, heh, ok
[21:08] <mterry> kdub_, read only filesystem?
[21:08] <kdub_> adb remount
[21:09] <kdub_> from the host, will fix that
[21:11] <mterry> kdub_, it says it works, but then it's still ro....  I must be doing something wrong
[21:12] <mterry> nope, unless there are more args I have to give...  I don't see it working for /data/ubuntu/system
[21:14] <kdub_> oh, do the mv from the adb shell
[21:14] <kdub_> not from the ubuntu_chroot
[21:15] <mterry> kdub_, yar I'm not in ubuntu_chroot yet, but I am mv'ing /data/ubuntu/system/lib...  Should I be doing a different path?
[21:15] <kdub_> just /system/lib/hw
[21:15] <mterry> kdub_, oh, those are the same?  ok
[21:16] <mterry> kdub_, ok, that worked.  finally  :)
[21:16] <kdub_> well, /data/ubuntu/system is a loopback readonly mount of /system
[21:16] <mterry> kdub_, ah, I couldn't figure that from the mount output, ok
[21:16] <mterry> kdub_, mir_demo_server doesn't crash anymore
[21:17] <kdub_> a good sign :) try a demo client
[21:17] <mterry> kdub_, and a demo client works
[21:17] <kdub_> yay
[21:17] <kdub_> wait a minute
[21:17] <kdub_> the problem (if present) destabilizes stuff after about a minute
[21:18] <kdub_> but if its working it should work forever
[21:18] <kdub_> everyone cross their fingers!
[21:18] <kgunn> kdub_: so what's the theory....w/ renaming hwc hal ?
[21:19] <kgunn> shouldn't it be compat with hwc1.0 ?
[21:19] <kdub_> kgunn, if we can't load that file, i have mir try a fallback display without hwc
[21:19] <mterry> kdub_, heh, ok.  So now we are actually getting to the point of testing the libhybris patch?
[21:20] <mterry> kdub_, if it matters, I used mir_demo_client_accelerated
[21:20] <kdub_> mterry, if the client works, the patch works
[21:20] <kgunn> kdub_: thanks for the help
[21:20] <mterry> kdub_, you mean, if the client works for a few minutes, the patch works?
[21:20] <kdub_> right
[21:20] <mterry> ok.  will get back to you  :) still strong
[21:21] <kdub_> really, if it works for over 15-20seconds without crashing horribly, we're in the clear :)
[21:21] <kgunn> kdub_: but....still, i guess that means our integration of hwc's...is really device specific not hwc api specific right ?
[21:22] <kgunn> e.g. mir on tegra hwc not cool
[21:23] <kdub_> well, hwc will pull in libraries over hybris that we havent been loading before
[21:23] <mterry> kdub_, well, it's been 6 minutes, seems solid
[21:23] <kdub_> so what's probably happening is libnvcap_video.so is not found, and its causing failures in tegra/hwc/hybris
[21:24] <kgunn> kdub, got it, whatever the heck libnvcap_video.so was
[21:24] <kgunn> right
[21:24] <kdub_> right
[21:24] <mterry> kdub_, so...  I guess I'll push my patch to the daily-build-next ppa.  The moving of the hw lib was a different issue it seems
[21:24] <kdub_> mterry, indeed
[21:25] <kdub_> mterry, you mean, put the patch in the hybris packages?
[21:25] <mterry> kdub_, yeah.  is that going to negatively affect other nexus machines?
[21:25] <kgunn> ah!.....so that particular so would just need to be added to the proprietary-blobs.txt
[21:26] <kdub_> kgunn, right... sergiusens might be able to do that :)
[21:26]  * kgunn 's brain just connected a couple of synapses
[21:27] <kdub_> mterry, depends on how performance-friendly the patch is
[21:27] <kgunn> mterry: you could push the patch & get folks on n4, galaxy, n10 to test
[21:28] <mterry> kdub_, is there easy way to test that?  or shall I just push and we find out?  :)
[21:29] <kdub_> there's not an easy way i'd say
[21:30] <kdub_> like, its probably not a critical performance hit, but it might be a lookup at every hybrisized pthread mutex/cv
[21:32] <sergiusens> kdub_: do ?
[21:32]  * sergiusens reads
[21:32] <kdub_> sergiusens, when the hwcomposer.tegra3.so functions cross the hybris barrier, we see in the logcat that 'libnvcap_video.so' is not found
[21:33] <kdub_> so we're hoping that that file is just missing from the proprietary-blobs.txt file
[21:34] <sergiusens> kdub_: ack... let me check
[21:34] <kdub_> mterry, good job btw :)
[21:34] <mterry> kdub_, thanks for walking me through it
[21:34] <mterry> I've pushed to the PPA, hopefully they build fine
[22:33] <greyback_> kdub_: any status change for mir support on nexus10?
[22:33] <kdub_> no, i need to sit with that one for a while
[22:33] <greyback_> kdub_: ok. Let me know if you want a tester :)
[22:34] <kdub_> i have one, what i really need is a nexus time machine
[22:34] <kdub_> maybe that'll be the big seller in android-L
[22:36] <kdub_> :)
[22:36] <greyback_> hopefully will be integrated with Glass


[16:33] <MTecknology> nhandler: "You will want to poke a Fridge Editor using one of the first two methods on this page to get your submission reviewed."
[16:34] <MTecknology> nhandler: maybe it would be a good idea to add a letter or roman numeral to each option and specify whixh options that is referring to; or maybe put that line in the description of the ones it's relevant to
[16:37] <MTecknology> the numbering could help if someone pops in here saying they tried option a, then tried option c, but are still having issues; just a thought
[16:37] <MTecknology> either way, looks great, I like :)
[16:43] <nhandler> MTecknology: Well, I'm still hoping to get it wikified a bit (which would mean bullets instead of paragraphs), so once that happens, the issue you brought up should resolve itself
[16:59] <MTecknology> nhandler: :)
[18:36] <jono> would someone mind putting http://www.jonobacon.org/2011/02/02/weekly-qa-sessions/ on ubuntu-news?
[18:53] <nhandler> jono: I'll have some time in a bit. You do know that you can submit stories directly (which makes it faster for editors to publish). Probably the easiest way for you and us would be to login with ubuntu/ubuntu on ubuntu-news.org and enter the post (remember the citation at the end and tags). Then an editor can publish it after reviewing
[19:41] <akgraner> hey nhandler pleia2  - I am waiting hear back from Charlie - but looks like they will be standing up the new fridge shortly
[19:42] <akgraner> they are going to make sure they have the content sync done then let me know so I can let you all know when to stop adding content to ubuntu-news.org and when fridge.ubuntu.news is ready for content to be added
[19:44] <nhandler> akgraner: The biggest issue will be updating all of the links (and trying to fix all of the broken links)
[19:45] <akgraner> nhandler, I guess we will have to deal with that when and as it happens - I am not sure anyone has a magic solution?  I though Canonical was taking care of that part of the migration but I guess we shall see
[19:46] <nhandler> akgraner: Yep. There really isn't a /nice/ solution :(
[19:46] <akgraner> I was afraid of than :-(
[19:46] <akgraner> that even
[19:47] <akgraner> I'm adding the new Weekly QA Sessions to the Fridge Calendar now
[19:49] <pleia2> are they syncing the database itself?
[19:49] <pleia2> if so, it should retain the post links
[20:05] <akgraner> pleia2, I believe they are yes
[20:05] <akgraner> so there was only one missing Q&A session so I just added that one
[20:07] <nhandler> akgraner: Want to handle the blog post as well if you have time?
[20:07] <nhandler> pleia2: But we'll lose the old fridge.ubuntu.com links
[20:08] <akgraner> nhandler, about the QA sure - I already posted one on You in Ubuntu I'll just grab that one
[20:08] <pleia2> nhandler: ah, right
[20:10]  * nhandler also doubts that Canonical would let us have something like a .htaccess file that we could modify to manually setup redirects for some of the older more popular links
[20:13] <pleia2> at the very least we should make sure there is a redirect for the old rss feed for fridge (since that's still what feeds the mysteriously-owned twitte accountr, and I suspect some people still have it in their reader
[20:25] <akgraner> pleia2, I'll send the old content link concerns to Charlie anything else?
[20:26] <pleia2> did anyone review Nick's email? there are some concerns about the plugin combination
[20:26] <pleia2> two twitter plugins, multiple tag cloud things
[20:27] <pleia2> maybe not critical for now, but they did play a part in Nick's site croaking over the weekend
[20:34] <nhandler> pleia2: I thought the broken link checker, fv community news, and tweetmeme were the bad plugins (combined with apache) and he removed those
[20:34] <pleia2> nhandler: right, those are still on the canonical install
[20:35] <pleia2> if we don't want them around because they cause problems, we should advise accordingly
[20:35] <nhandler> The multiple tag plugins are actually being used. i.e. we have one that suggests tags based on the content of the post, another that displays a list of all tags for you to click on, and a third for a tag cloud. Those should definitely stay
[20:35] <pleia2> the nifty tag cloud thing is gone from Nick's site
[20:35] <nhandler> pleia2: Might be worth making a note somewhere about them, but until we narrow down the problem a bit more, I think we could leave them (they worked fine for months)
[20:35] <pleia2> I forget what it's called
[20:36] <nhandler> pleia2: Any idea why?
[20:36] <pleia2> I assumed it was something he disabled
[20:36] <nhandler> As for the twitter stuff, I thought we removed the second one a while ago
[20:36] <pleia2> no, we've had the one at the top that counts tweets all along, until this weekend
[20:37] <nhandler> pleia2: Yeah (assuming we are talking about the same one), but I thought that was the only one we had
[20:38] <pleia2> there is one at the bottom of each post too that was always active
[20:38] <pleia2> (it's still there)
[20:45] <jono> nhandler, will do
[20:46] <nhandler> pleia2: Then I don't know ;) I'll try and look more later
[20:46] <nhandler> jono: I think akgraner took care of this one already
[20:47] <akgraner> he did but he missed one of the days
[20:47] <akgraner> I fixed it though
[20:52] <pleia2> publish now?
[20:52] <pleia2> (it's still a draft)
[20:53] <pleia2> hmm, actually I can't find it at all
[20:53] <jono> thanks nhandler akgraner
[20:54] <akgraner> jono, hey I just blogged about all the QA stuff and told readers if they couldn't make I would ask questions for them provided they gave me their name etc so I could attribute the questions to them.. let's see if there is any response..
[20:55] <jono> cool
[20:55] <jono> :-)
[20:56] <akgraner> pleia2, nhandler so can you sum up for me what I need to pass along to Charlie and crew?
[20:56] <akgraner> or should i just send Nick's email to RT
[20:57] <nhandler> akgraner: For nick's email, I'm not sure we should take any actions until we reproduce/identify what is causing the problem (it worked for months just fine with that setup). The links are the big thing imo
[20:59] <akgraner> ok then I won't worry about that part then
[21:00] <pleia2> akgraner: jono was asking for the blog post itself be put on ubuntu-news, not (just) the fridge calendar
[21:01] <akgraner> pleia2, I'll add it
[21:01] <pleia2> thanks :)
[21:01]  * pleia2 back2work


[00:05] <PCLine_> I dont know if I would call it lucky.
[00:05] <Unit193> It's rain/storming, that's good weather. :D
[00:05] <belkinsa> +1
[00:06] <belkinsa> Well, with the weather we have been having.
[00:06] <PCLine_> I got about 30 drops on my windshield.
[00:06] <Unit193> I tend to like what others call "bad weather", except when I'm cleaning up after it or driving in it (but even then, it's still good.)
[08:48] <Unit193> Mmmm, but splitty still.
[11:48] <Unit193> Hmmm, anyone else on TWC besides Derath?
[19:09] <Unit193> http://www.ohiolinux.org/sessions/keep-your-secrets-secret-cloud-ecryptfs there's a speaker we know.
[19:09] <jenni> [ Keep Your Secrets Secret in the Cloud with eCryptfs | Ohio LinuxFest 2014 - The Future of Free ] - https://j.mp/1qL96Ld