[07:29] <Saviq> didrocks, ping
[07:31] <didrocks> pong Saviq
[07:32] <Saviq> didrocks, first of all - I blame you :P how could we upload the whole new unity stack without ever bumping SONAME? :P
[07:32] <Saviq> didrocks, now that we have that off our plate ;)
[07:32] <Saviq> didrocks, http://packages.debian.org/source/experimental/zeroc-ice say we wanted that in ubuntu, what's the correct process?
[07:33] <didrocks> Saviq: hum, you are talking about libunity or unity/nux? :p
[07:33] <Saviq> didrocks, libunity
[07:33] <didrocks> Saviq: for libunity, only the scope part is impacted (but yeah, unity8 as well I guess), bumping the soname once again makes rebuilding 40 components
[07:33] <didrocks> Saviq: making the transition even harder :p
[07:34] <Saviq> didrocks, ok, actually I meant libunity-core
[07:34] <didrocks> people should start to know about ABI stability (especially when in 2 years, we went to 9 :p)
[07:34] <Saviq> ;)
[07:34] <didrocks> Saviq: ah, that's something else, I guess upstream forgot about it ;)
[07:35] <didrocks> Saviq: on the ice version
[07:35] <didrocks> Saviq: so, you are using that component? You know it's not in main
[07:35] <didrocks> so not officially supported
[07:35] <Saviq> didrocks, michi is about to use it
[07:36] <Saviq> didrocks, the version in debian is 3.5b, 3.5 is already out
[07:36] <didrocks> Saviq: right, doesn't mean it qualifies for main though :p
[07:36] <Saviq> didrocks, yeah, I understand
[07:36] <Saviq> didrocks, that's why I'm asking about the process (and if the answer is "just stay away from it", that's what it is...)
[07:37] <didrocks>  * libmcpp-dev binary and source package is in universe
[07:37] <didrocks>  * python-support binary and source package is in universe
[07:37] <didrocks>  * g++-4.6 binary and source package is in universe
[07:37] <didrocks>  * proguard binary and source package is in universe
[07:37] <didrocks>  * libjgoodies-forms-java binary and source package is in universe
[07:37] <didrocks>  * libjgoodies-looks-java binary and source package is in universe
[07:37] <didrocks> python-support -> we can handle the transition, as for g++
[07:37] <didrocks> I'm more afraid about the others
[07:37] <Saviq> those are the deps?
[07:37] <didrocks> yeah, build-deps and deps
[07:37] <Saviq> uh
[07:38] <didrocks> and that would mean all this needs to be in main
[07:38] <didrocks> which, maybe, pull other stuff in main
[07:38] <Saviq> yeah
[07:38] <didrocks> let's try the java part, juts for fun
[07:38] <didrocks>  * maven-debian-helper binary and source package is in universe
[07:38] <didrocks>  * libjgoodies-common-java binary and source package is in universe
[07:38] <didrocks>  * libmaven-javadoc-plugin-java binary and source package is in universe
[07:38] <didrocks> ah maven… :p
[07:38] <didrocks> (and that's only for libjgoodies-forms-java)
[07:39] <didrocks> Saviq: without even seeing the code, I would gard against using it, and look if we can find an equivalent in main
[07:40] <Saviq> didrocks, yeah, feels like it's too big a beast with some weird deps :/
[07:40] <Saviq> didrocks, here's michi__ ^
[07:40] <michi__> Yep
[07:40] <didrocks> Saviq: yeah, not really thrilled to get java in
[07:40] <didrocks> hey michi__
[07:40] <michi__> We don't need that.
[07:40] <Saviq> michi__, I pasted you the discussion in PM
[07:40] <michi__> Only need the C++ sub-sections
[07:40] <didrocks> michi__: well, the package build-dep on it
[07:40] <didrocks> so we need it to build the package
[07:41] <michi__> You don't need Java to build Ice for C++
[07:41] <didrocks> michi__: right, but they are built from the same package
[07:41] <michi__> It's just that all the different Ice versions are bundled into a single source release
[07:41] <didrocks> indeed
[07:41] <michi__> So you get Ice for Java, C++, C# etc.
[07:41] <didrocks> and for having it in main
[07:41] <didrocks> it means, you need to have all build-deps in main
[07:41] <michi__> Hmmm...
[07:41] <michi__> Basically, all I want is a ppa or some such that gets us Ice for C++.
[07:41] <michi__> I can build it from source, including one minor bug fix.
[07:42] <didrocks> michi__: but then, you will use it, right?
[07:42] <michi__> But I don't know how to create a PPA and so on.
[07:42] <michi__> Use it to build unity-scopes-api, yes
[07:42] <didrocks> and so, once we get unity 8 into distro and installed by default, it will need to be in main
[07:42] <michi__> Until the 3.5 packages are released.
[07:42] <didrocks> which will get to that issue
[07:42] <michi__> I don't know what "need to be in main" means, sorry.
[07:42] <michi__> I'm totally ignorant about all the packaging stuff :(
[07:42] <didrocks> michi__: you don't know ubuntu? :/
[07:43] <didrocks> there is main/universe
[07:43] <michi__> Nope :)
[07:43] <didrocks> (restricted/multiverse)
[07:43] <michi__> Ah, OK. Yes, I know about that.
[07:43] <didrocks> basically, ubuntu/canonical supports main and restricted
[07:43] <michi__> So, we can't do this?
[07:43] <didrocks> meaning that packages in those pockets need to be supportable for us (contractually)
[07:43] <michi__> right
[07:43] <didrocks> stuff that builds in main needs to be buildable with only components in main
[07:43] <michi__> This is for development on scopes only, for a limited period.
[07:44] <michi__> Yes, makes sense.
[07:44] <michi__> OK.
[07:44] <didrocks> michi__: you mean that we won't need it in the end?
[07:44] <michi__> If I can't have it, that's really serious.
[07:44] <didrocks> (like, in October)
[07:44] <michi__> No, I will need it eventually.
[07:44] <didrocks> ok, so we need to ask this question now
[07:45] <didrocks> because if we can't support it, the "put that in a ppa" won't fix it
[07:45] <didrocks> and seeing what it is pulling, I have doubt
[07:45] <michi__> Could we take the 3.5b packages from here? http://packages.debian.org/source/experimental/zeroc-ice
[07:45] <didrocks> michi__: again, this is *NOT* the pb
[07:45] <didrocks> to update
[07:45] <didrocks> the issue is with the source itself
[07:45] <michi__> Hmmm...
[07:45] <michi__> Ice 3.4 is in the normal repositories right now.
[07:46] <michi__> It's just that we can't use that version.
[07:46] <didrocks> defines "normal" repositories
[07:46] <michi__> Sec...
[07:46] <didrocks> tvoss: would be great that we do some kind of tutoring on how ubuntu work for PS techs btw ^ (not the first time I see that kind of questions ;))
[07:46] <michi__> Yes, please!
[07:46] <tsdgeos> Saviq: ok, i pushed a different showheader animation, i think it's what you wanted, if you can check
[07:46] <Saviq> tsdgeos, cheers
[07:47] <michi__> Hmmm...
[07:47] <michi__> I just found Ice-3.5b with package manager.
[07:47] <michi__> It wasn't there a few days ago.
[07:47] <Saviq> michi__, what didrocks is after
[07:47] <michi__> libzeroc-ice35b
[07:47] <Saviq> michi__, is main vs. universe
[07:48] <Saviq> michi__, main ubuntu repository is what goes into the .iso
[07:48] <tvoss> didrocks, good idea. Do we have some slides available? Or even better: why don't we do a hangout on air, with a tutorial and some q&a? might be interesting to external folks, too
[07:48] <tvoss> didrocks, thinking about xda and such
[07:48] <Saviq> michi__, and that's what's officially supported - by us
[07:48] <michi__> Right.
[07:48] <Saviq> michi__, so for unity-scopes-api, that will land in main ultimately
[07:48] <Saviq> michi__, if ice is required
[07:48] <Saviq> michi__, we need to bring ice into main
[07:48] <michi__> Yes, got that.
[07:48] <Saviq> michi__, and all of it's build dependencies
[07:48] <didrocks> tvoss: yeah, there is no real slides AFAIK, but we need to do it :)
[07:48] <michi__> Right.
[07:48] <didrocks> or check for alternatives
[07:49] <didrocks> if we can't support ice
[07:49] <Saviq> michi__, because everything in main needs to build within main
[07:49] <michi__> And that means everything then, including Java, C#, Python, Objective-C, etc?
[07:49] <didrocks> michi__: right, because they are all build-deps
[07:49] <didrocks> or if we can separate the C++ part
[07:49] <Saviq> yes, because you're including the _source_, not the binaries
[07:49] <didrocks> we can do that as well
[07:49] <michi__> Can we put a butchered down source tree into main?
[07:49] <Saviq> but yeah ^
[07:49] <didrocks> it really needs a good analyze
[07:49] <Saviq> that's what I thought
[07:49] <michi__> that only contains C++?
[07:49] <Saviq> we could try and have separate source packages
[07:49] <didrocks> michi__: is the upstream source separated?
[07:49] <michi__> Yes
[07:49] <tvoss> michi__, plus: everything that should go into main needs to be reviewed by security
[07:50] <michi__> I can hack up a butchered tree in an hour or so.
[07:50] <michi__> I'm quite familiar with that code :)
[07:50] <Saviq> michi__, that's not maintainable ;D
[07:50] <didrocks> michi__: hum, no, if it's not supported upstream, we can't really
[07:50] <didrocks> on the long term
[07:50] <didrocks> we need to pick upstream new versions
[07:50] <didrocks> and upstream security fixes
[07:50] <michi__> Can we do something with RPMs?
[07:50] <didrocks> ?
[07:50] <michi__> ZeroC publishes RPMs
[07:50] <didrocks> no
[07:50] <michi__> Redhat packages
[07:50] <didrocks> we build from sources in ubuntu
[07:50] <didrocks> michi__: thanks, I know what a RPM is :)
[07:50] <michi__> :)
[07:50] <michi__> Sorry
[07:51] <michi__> :)
[07:51] <didrocks> so, basically being in main means:
[07:51] <didrocks> - having something we can maintain and provide support on
[07:51] <didrocks> - being able to look at security issues and backport them promptly
[07:51] <tvoss> didrocks, is there a wiki page for Ubuntu Engineering development practice?
[07:51] <didrocks> - ensuring we don't duplicate with something that would work equally in main
[07:52] <didrocks> tvoss: there are a lot of wiki page on how ubuntu is structured, but I guess that's too big for all UE upstream to digest
[07:52] <michi__> So, in effect, this means that we can use Ice I take it.
[07:52] <tvoss> didrocks, yup, I was thinking about the executive summary
[07:53] <didrocks> tvoss: not that I know of, maybe there is something that dholbach could point us at?
[07:53] <didrocks> michi__: what does mean that? did you forget a "if"?
[07:53] <michi__> Yes. Rephrase: "Am I correct in my understanding that using Ice is not possible?"
[07:54] <didrocks> michi__: no, we should really investigate properly
[07:54] <michi__> OK, what I can I do to help with that?
[07:54] <didrocks> which means: what feature would you like to use from Ice?
[07:54] <didrocks> do we already have an equivalent in main?
[07:54] <michi__> Not in main, I don't think.
[07:54] <michi__> How can I ask the bloody package manager to show where a package lives, main or universe?
[07:54] <didrocks> michi__: you know that main used to build KDE. I think there are a lot of libraries :)
[07:54] <michi__> Properties doesn't seem to show it.
[07:54] <didrocks> apt-cache policy <bin package>
[07:55] <michi__> Thanks!
[07:55] <michi__> Sec.
[07:55] <didrocks> saucy/universe
[07:55] <didrocks> or saucy/main
[07:55] <michi__> Ice 3.4 for C++ is in raring/universe
[07:55] <michi__> I imagine it'll be in Saucy too.
[07:56] <michi__> That's libzeroc-ice34
[07:56] <didrocks> right
[07:56] <michi__> and libzeroc-ice34-dbg
[07:56] <didrocks> yeah, so hence my question:
[07:56] <didrocks> what do you use from ice that you don't find in other packages in main?
[07:56] <michi__> I'm not sure I get the question.
[07:56] <didrocks> why you need Ice?
[07:57] <didrocks> basically
[07:57] <michi__> It's middleware.
[07:57] <michi__> Does lots of smart things that will save a lot of work.
[07:57] <michi__> Like not having to hand-write marshaling and unmarshaling code, for example.
[07:57] <michi__> Process activation and deactivation.
[07:57] <michi__> load balancing.
[07:57] <michi__> on-demand loading of object implementations.
[07:57] <michi__> you name it.
[07:58] <michi__> I was looking at Ice because it would save us a fair amount of delopment time.
[07:58] <michi__> Hmmm...
[07:58] <michi__> About maintainability of a cut-down source tree.
[07:58] <michi__> The Ice source is organised like this:
[07:58] <michi__> ice/cpp
[07:58] <michi__> ice/java/
[07:59] <michi__> ice/csharp
[07:59] <michi__> etc.
[07:59] <Saviq> they should provide split tarballs ^, IMO
[07:59] <michi__> You can throw away all the top-level directories and only keep ice/cpp
[07:59] <michi__> and it'll work
[07:59] <michi__> Yes.
[07:59] <didrocks> Saviq: +1 on that
[07:59] <michi__> For ZeroC, the debian packaging was never an issue because there is someone who did that as a volunteer.
[08:00] <didrocks> michi__: mind opening the discussion with them?
[08:00] <michi__> I can try and talk to the Ice guys about this.
[08:00] <michi__> I do not like my chances though.
[08:00] <didrocks> michi__: that would be great
[08:00] <michi__> It just means more work for them, for no gain for ZeroC.
[08:00] <michi__> I'll see how far I get.
[08:00] <didrocks> michi__: basically, the requirements for having a package in main are at: https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
[08:00] <Saviq> michi__, wtym, it'll get included and supported in Ubuntu main, that's gain for ZeroC :D
[08:00] <didrocks> michi__: keep me posted please :)
[08:00] <michi__> Thanks! Will read that now.
[08:00] <michi__> Will do!
[08:00] <didrocks> Saviq: yeah, meaning more debugging, more users
[08:00] <Saviq> rotfl
[08:01] <didrocks> :)
[08:01] <Saviq> michi__, and it's easiest to do close to the source - they can just have a script that will split the tarball in parts
[08:01] <michi__> Yes.
[08:01] <Saviq> michi__, we could do that, too, in theory, but that would be painful to maintain
[08:02] <michi__> OK, so if ZeroC puts up a tarball that contains only the C++ parts and builds, we'd be OK?
[08:02] <didrocks> yeah, we avoid to fork the source tarballs for that reasons
[08:02] <michi__> Makes sense.
[08:02] <didrocks> michi__: I'm looking at the code right now, to check quickly, but it seems ok for now
[08:02] <michi__> Doing it ourselves is probably no more work than writing rm -fr for a handful of directories.
[08:02] <Saviq> michi__, once
[08:02] <michi__> I'll check with my former collegues
[08:03] <Saviq> michi__, but then you need to maintain it
[08:03] <michi__> Yes, I know.
[08:03] <didrocks> yeah, the one shot is easy
[08:03] <michi__> I hear you :)
[08:03] <didrocks> maintenance is what the MIR asses :)
[08:03] <Saviq> :)
[08:03] <michi__> MIR asses? I dont' get the joke
[08:03] <didrocks> assess*
[08:03] <sil2100> hehehe
[08:04] <sil2100> Ah typos...
[08:04] <didrocks> sil2100: I'll always blame my keyboard!
[08:05] <greyback> mzanetti: just to tell you, I managed to repro the crashing tests I've been fighting with and get a stacktrace. And thanks for your help
[08:06] <Saviq> tvoss, I managed to break it
[08:06] <tvoss> Saviq, ?
[08:06] <Saviq> tvoss, sorry, tsdgeos
[08:06] <tvoss> Saviq, :)
[08:06] <greyback> mzanetti: I used cgroups to limit the cpu allocated to the tests, figuring Jenkins was also running with lower available cpu than my local machine.
[08:07] <Saviq> tsdgeos, when you make it so that the two section headers are close to each other
[08:07] <mzanetti> greyback: oh... interesting
[08:08] <Saviq> tsdgeos, so: in Home, drag up so that "Frequent Apps" and "Favourite People" are on top of one another
[08:08] <Saviq> tsdgeos, then swipe to the side
[08:08] <Saviq> tsdgeos, the header comes down correctly
[08:08] <Saviq> tsdgeos, but then drag down to reveal the apps
[08:08] <Saviq> tsdgeos, they get confused and stuck to the top
[08:10] <Saviq> tsdgeos, but yeah, the showHeader() anim is correct now - better than the original that got confused when the list was at the bottom
[08:10] <Saviq> tsdgeos, easier to reproduce
[08:10] <Saviq> tsdgeos, go to Apps, tap on SEARCH, drag
[08:11] <Saviq> tsdgeos, actually: go to Apps, hide the page header, tap on SEARCH, drag
[08:12] <Saviq> tsdgeos, it doesn't take the page header into account anymore
[08:12]  * tsdgeos tries
[08:12] <Saviq> tsdgeos, but otherwise it's great :)
[08:13] <tsdgeos> boooo
[08:13] <tsdgeos> ok
[08:13] <tsdgeos> need to fix that
[08:16] <Saviq> paulliu, can you tackle https://bugs.launchpad.net/touch-preview-images/+bug/1190400 ? should be easy to fix
[08:25] <paulliu> Saviq: ok
[08:25] <Saviq> paulliu, thanks
[08:46] <nic-doffay> Saviq, have a moment?
[08:46] <Saviq> nic-doffay, hit me
[08:47] <nic-doffay> Saviq, rotation is working well, however I'm having an issue with the slide out for the launcher.
[08:48] <nic-doffay> I'm attempting to use a standalone property animation since I figured it doesn't need states and thus wouldn't need an additional Item wrapper around the launcher.
[08:48] <nic-doffay> https://pastebin.canonical.com/92695/
[08:49] <nic-doffay> Saviq, check lines 134 & 529
[08:49] <nic-doffay> Nothing is happening. No output either.
[08:50] <nic-doffay> (Unless if the animation is absent obv)
[08:51] <Saviq> nic-doffay, that's probably because the launcher alread has states
[08:51] <mzanetti> Saviq: lp:~saviq/unity/8.fix-coding is conflicting
[08:51] <Saviq> mzanetti, uh, fixing
[08:52] <Saviq> nic-doffay, and they have precedence over any custom animation you use
[08:52] <Saviq> nic-doffay, but actually
[08:52] <Saviq> property PropertyAnimation animation: animation
[08:52] <mzanetti> whats wrong with the launcher?
[08:52] <Saviq> mzanetti, nothing
[08:52] <Saviq> nic-doffay, that binds the property to itself
[08:53] <Saviq> nic-doffay, i.e. undefined
[08:53] <nic-doffay> Saviq, I did try before with another different name.
[08:53] <nic-doffay> How should I get around this issue?
[08:54] <Saviq> nic-doffay, you need a different name, that's all
[08:54] <Saviq> nic-doffay, but if you mean to get around the states issue
[08:54] <Saviq> nic-doffay, first of all, make sure that the animation is actually running
[08:57] <nic-doffay> Saviq, I have already, it apparently is.
[08:57] <nic-doffay> Saviq, that was with the different name yesterday.
[08:57] <nic-doffay> changed the name again now just to confirm.
[09:00] <Saviq> mzanetti, q about Launcher.qml: 175
[09:01] <Saviq> mzanetti, why not Behavior.enabled: !(launcherDragArea.drag.active || dragArea.dragging) ?
[09:02] <mzanetti> hmm... there is a Behavior.enabled? interesting... must have missed that
[09:02] <Saviq> mzanetti, http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-behavior.html#enabled-prop
[09:02] <mzanetti> Saviq: I'll change it in my next MR
[09:02] <mzanetti> yep, found it
[09:02] <Saviq>  k
[09:05] <Saviq> nic-doffay, so, I'd probably go about and add a new state
[09:06] <nic-doffay> Saviq, in another parent item?
[09:06] <nic-doffay> Saviq, or in the launcher itself?
[09:06] <Saviq> nic-doffay, no, in Launcher.qml itself
[09:06] <nic-doffay> Saviq, kk
[09:06] <Saviq> nic-doffay, to hide "quickly"
[09:06] <Saviq> mzanetti, one more q: Launcher.qml:232
[09:07] <Saviq> mzanetti, not sure I understand the comment
[09:07] <nic-doffay> Saviq, I'd have to handle this in the onRotatedChange (unless I expose the rotating variable to Launcher.qml).
[09:07] <Saviq> mzanetti, but I do know that "unnamed" state is problematic
[09:07] <nic-doffay> This would override any binds.
[09:08] <mzanetti> Saviq: well, want this to be the default state.
[09:08] <Saviq> mzanetti, there's no such thing as a default state
[09:08] <Saviq> mzanetti, unnamed states will bite you in the a$$
[09:09] <Saviq> mzanetti, why can't it have a name?
[09:09] <mzanetti> because QML falls back to ""
[09:09] <Saviq> mzanetti, ah wait, this way it might be fine
[09:09] <mzanetti> Saviq: one moment... searching for the right page in the docs
[09:09] <Saviq> mzanetti, so you mean if no other states have when: true
[09:10] <Saviq> mzanetti, then it falls back to the unnamed state
[09:10] <mzanetti> exactly
[09:10] <mzanetti> Saviq: from the docs: If the item is in its default state — that is, no explicit state has been set — then this property holds an empty string. Likewise, you can return an item to its default state by setting this property to an empty string.
[09:10] <mzanetti> http://qt-project.org/doc/qt-5.0/qtquick/qtquick-statesanimations-states.html#the-default-state
[09:10] <Saviq> mzanetti, yeah, problem is what the default state is
[09:11] <Saviq> mzanetti, i.e. if an animation changes some values, that becomes the default staet
[09:11] <Saviq> mzanetti, not the "initial" one
[09:11] <Saviq> mzanetti, but yeah, your use case is ifne
[09:11] <Saviq> fine
[09:12] <Saviq> mzanetti, what I mean is that the default state is modal
[09:12] <Saviq> mzanetti, i.e. the default state is whatever the values were _when_ the state changed to non-default
[09:12] <Saviq> mzanetti, so that can be tricky
[09:12] <mzanetti> Saviq: yep. and exactly thats the reason why I have that here... to make sure it actually reverts to being hidden
[09:13] <mzanetti> instead of staying to whatever x has been set
[09:13] <Saviq> mzanetti, I'd probably go for explicit state name then
[09:13] <Saviq> mzanetti, but yeah, that would require when:s everywhere
[09:13] <mzanetti> Saviq: yep... and quite tricky ones... I had that before
[09:14] <Saviq> mzanetti, I'd probably go for a state: if/else...
[09:14] <Saviq> mzanetti, but yeah, that then makes it tricky because you need additional properties to get where you want
[09:15] <Saviq> nic-doffay, all in all, I'd go for another state
[09:15] <Saviq> nic-doffay, and convert the Behavior on x in Launcher.qml
[09:15] <Saviq> nic-doffay, to transitions: [ ]
[09:15] <mzanetti> hmm... yeah, that might do it... still this seems to work quite nicely... if you want me to change it I'll do... but I don't see the need right now tbh
[09:15] <paulliu> Saviq: Argh.. people-lens -> libfolks -> gee-0.8  and people-lens -> unity -> gee-1.0..
[09:15] <Saviq> paulliu, right
[09:15] <nic-doffay> Saviq, with the rotation variable exposed to the launcher?
[09:15] <nic-doffay> and a when:
[09:15] <Saviq> nic-doffay, sec
[09:16] <paulliu> Saviq: I need to port libfolks first..
[09:16] <Saviq> paulliu, ignore, then, we're dropping the people lens this week
[09:16] <Saviq> paulliu, at least temporarily
[09:16] <paulliu> Saviq: ok
[09:16] <Saviq> paulliu, please write on the bug what's the issue
[09:16] <Saviq> paulliu, and return it to Confirmed
[09:16] <paulliu> ok
[09:17] <Saviq> nic-doffay, didn't you say that your only issue was hiding the launcher?
[09:17] <nic-doffay> Saviq, yeah
[09:17] <Saviq> nic-doffay, so yeah, just have State { name: "quickHide"; extends: "" }
[09:18]  * mzanetti needs to go buying some poison to get rid of lice on his strawberries :D
[09:18] <Saviq> nic-doffay, and then a Transition { to: "quickHide" Sequentialanimation { NumberAnimation { duration: SnapDuration }; PropertyAction { target: launcher; property: "state", value: "" } }
[09:18] <Saviq> or similar
[09:19] <Saviq> mzanetti, lol lice? http://dictionary.cambridge.org/dictionary/british/louse
[09:19] <Saviq> mzanetti, I hope you mean http://dictionary.cambridge.org/dictionary/british/aphid?q=aphids
[09:22] <Saviq> mzanetti, maybe you have a different idea about temporarily changing the duration of the Launcher.x behaviour?
[09:22] <Saviq> mzanetti, like a one-shot quick-hide
[09:22] <Saviq> mzanetti, maybe something fits more with your other plans
[09:23] <Saviq> nic-doffay, there's a bunch of different approaches you could take, like disabling the Behavior while a separate animation is running
[09:23] <Saviq> nic-doffay, or the transitions
[09:23] <nic-doffay> Saviq, I'm going to opt for the transitions.
[09:23] <Saviq> nic-doffay, or changing the Behavior's duration temporarily
[09:23] <nic-doffay> Shall I expose the rotation variable to the launcher?
[09:24] <nic-doffay> or set the state from outside as I'm doing with the panel?
[09:24] <Saviq> nic-doffay, no, nothing should know
[09:24] <Saviq> nic-doffay, no of the shell parts should need to know that they got rotated
[09:24] <Saviq> none
[09:24] <nic-doffay> Saviq, as I thought, cool.
[09:25] <Saviq> nic-doffay, there's a Launcher.switchToNextState(string state) method you should use
[09:25] <nic-doffay> Saviq, I'll have a look.
[09:37]  * greyback moving to office, bbiab
[09:42] <nic-doffay> Saviq, it's looking slick.
[09:43] <Saviq> nic-doffay, cool
[09:44] <Saviq> http://pastebin.ubuntu.com/5760874/
[09:44] <Saviq> erm
[09:45] <mzanetti> re
[09:45] <mzanetti> Saviq: yeah... the ones on plants ofc
[09:45] <nic-doffay> Saviq, pushed. https://code.launchpad.net/~nicolas-doffay/unity/orientation/+merge/168100
[09:47] <Saviq> nic-doffay, conflict in Shell.qml
[09:50] <nic-doffay> Saviq, cool sorting it.
[09:57] <MacSlow> Saviq, regarding... https://code.launchpad.net/~macslow/unity/phone-shell-integration-notifications/+merge/168715
[09:59] <Saviq> MacSlow, pass the notification object to Notification.qml in Notifications.qml
[09:59] <MacSlow> Saviq, I've fixed the main issue (now using Notification's invokeAction() again), but want to ask if we can stick to "notificationRenderer" as I think naming it just "notifications" gets confusing becuase there's little difference in the naming of frontend and backend
[09:59] <Saviq> MacSlow, let's go for "notificationList" maybe?
[10:00] <Saviq> MacSlow, it's just a name, so...
[10:00] <MacSlow> Saviq, "notificationList" that' s ok too
[10:00] <dednick> larsu: ping
[10:00] <Saviq> MacSlow, but do pass the notification object via a property to Notification.qml
[10:00] <Saviq> MacSlow, instead of reaching back to the notificationList.model.get()
[10:01] <Saviq> MacSlow, also, why get(id) and not get(index)?
[10:01] <Saviq> MacSlow, feels like more work for the backend?
[10:01] <Saviq> MacSlow, and also get(index) would be consistent with the current API
[10:01] <MacSlow> Saviq, but it does not seem recommended to do that (passing a pointer from C++ to QML), when it's coming from a QShardPointer... I've read http://qt-project.org/wiki/SharedPointersAndQmlOwnership
[10:02] <Saviq> MacSlow, just set the ownership to Cpp
[10:02] <Saviq> MacSlow, so that QML won't delete it
[10:03] <Saviq> MacSlow, but yeah, I didn't read through that
[10:03] <Saviq> MacSlow, yet
[10:06] <Saviq> MacSlow, shouldn't it be enough to ::data() it?
[10:06] <Saviq> MacSlow, it has a parent, so the Qml engine won't assume ownership
[10:07] <MacSlow> Saviq, it works right now and I'm using ::data()...
[10:07] <Saviq> MacSlow, yeah, I feel like it's fine
[10:08] <tsdgeos> Saviq: do we have an eta for saucy desktop lenses working again in unity8?
[10:08] <tsdgeos> i'm trying to debug the jumpyness problem
[10:08] <Saviq> tsdgeos, ASAP
[10:08] <tsdgeos> and having my own qt to get some debug would help
[10:08] <Saviq> tsdgeos, as in, it's in review now
[10:08] <tsdgeos> i'm random-guessing it may have to do with the height of the flickable changing mid-flick
[10:08] <tsdgeos> Saviq: awesome
[10:08] <tsdgeos> i'll do some test/doc work then
[10:08] <tsdgeos> wait for it to land
[10:09] <Saviq> tsdgeos, you can use https://docs.google.com/a/canonical.com/document/d/1aNB6kfLOMq0asyxiSLahakfLU5si6V5RqxBuacMB0-U/edit
[10:09] <Saviq> tsdgeos, all's described there
[10:30] <mzanetti> katie: hello! In case you want to try: lp:~mzanetti/unity/8-greeter-edge-hinting
[10:30] <katie> mzanetti, thanks
[10:31] <katie> mzanetti, i'm working at home without a phone today, so I'll test it tomorrow
[10:32] <nic-doffay> Saviq, pushed a while ago
[10:32] <nic-doffay> re the conflict
[10:32] <mzanetti> katie: sure. just FYI, it works on the desktop too. but of course, you don't get the feeling using the mouse
[10:33] <mzanetti> katie: but the animation and duration is cloned from the launcher hinting, so I think this should be mostly ok
[10:37] <sil2100> pete-woods: hi!
[10:51] <Saviq> nic-doffay, k
[10:53] <Saviq> mzanetti, can you fix qmluitests to not add the daily-build-next ppa?
[10:54] <mzanetti> Saviq: oh, its still there... yep. fixing now
[10:55] <mzanetti> Saviq: hmm... its not there...
[10:55] <mzanetti> Saviq: we use those currently: D08add_ppa-qt5-proper D09add_ppa-phablet-team-ppa D09add_ppa-ubuntu-sdk-team-ppa
[10:55] <mzanetti> Saviq: which seems wrong too
[10:55] <Saviq> mzanetti, I: user script /var/cache/pbuilder/build//2751/tmp/hooks/D09add_ppa~ubuntu-unity~daily-build-next starting
[10:55] <Saviq> mzanetti, in https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-saucy/24/consoleFull
[10:55] <Saviq> mzanetti, and yeah, I saw it's not there in the parameters
[10:56] <Saviq> mzanetti, but somehow it's still being added
[10:56] <sil2100> didrocks: who besides Ted could do some HUD related work? I remember pete-woods doing some hud development in the past, but who else?
[10:56] <sil2100> Who should I ping?
[10:56] <Saviq> mzanetti, and I'm not sure what's happening here https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-saucy/77/consoleFull
[10:56] <mzanetti> Saviq: oh... its in the saucy job
[10:56] <Saviq> mzanetti, the package conflicts with libunity-core-6.0-5 (>= 7.80~)
[10:57] <didrocks> sil2100: I guess it's the only two who I can get from my head. Ask maybe their manager, thorst? (but he's on vacations this week I guess)
[10:57] <Saviq> mzanetti, but still 7.81~phablet2 gets installed :/
[10:57] <mzanetti> Saviq: what package should be installed?
[10:57] <Saviq> mzanetti, the saucy one
[10:58] <Saviq> mzanetti, 7.0.0daily13.06.07-0ubuntu1
[10:59] <mzanetti> Saviq: hmm... dunno why... but shouldn't that be handled by the packaging?
[10:59] <Saviq> mzanetti, yeah, it should
[11:01] <Saviq> mzanetti, I think the problem is it first does apt-get update/upgrade
[11:01] <Saviq> mzanetti, instead of just installing the package
[11:01] <mzanetti> it does?
[11:02] <Saviq> mzanetti, feels like it
[11:02] <Saviq> mzanetti, + sudo apt-get -y upgrade
[11:02] <Saviq> mzanetti, so yeah, it is
[11:02] <Saviq> mzanetti, and then the packaging can't handle it without downgrading
[11:03] <mzanetti> Saviq: oh... yeah... someone added the upgrade :/
[11:03] <Saviq> mzanetti, apt-get remove libunity-core-6.0-5 in the VMs could help...
[11:03] <mzanetti> Saviq: but why doesn't it downgrade then?
[11:03] <Saviq> mzanetti, because dpkg doesn't like downgrading
[11:04] <mzanetti> ah... I see
[11:04] <Saviq> mzanetti, as you can see at the end of https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-saucy/78/console
[11:04] <Saviq> mzanetti, it just complains that there's a conflict
[11:04] <mhr3> Saviq, how about just bumping the new libunity-core to 7.9 for now?
[11:04] <mhr3> that will unblock all this, no?
[11:04] <Saviq> mhr3, we should be able to handle it without that
[11:05] <mhr3> as you wish... just a thought
[11:05] <mzanetti> Saviq: removed the upgrade step
[11:05] <Saviq> mzanetti, thanks, let's see what happens
[11:05] <Saviq> mhr3, but will you guys bump the soname in libunity-core?
[11:06] <mzanetti> Saviq: does dpkg upgrade if dependencies are too old?
[11:06] <Saviq> mzanetti, yes
[11:06] <mzanetti> ok. fine then
[11:06] <mhr3> didrocks, should we? ^ should have been done when the smart-scopes branches were merged, but we missed it
[11:06] <mzanetti> if anything breaks now, its a packaging bug I'd say
[11:06] <Saviq> mzanetti, +1
[11:07] <mhr3> Saviq, i guess it's too late now, the older libunity-core is already in the archive with the changed interface
[11:08] <mhr3> but didrocks can correct me if i'm wrong
[11:08] <Saviq> mhr3, I don't think that's a problem?
[11:08] <didrocks> Saviq: mzanetti: hum?
[11:08] <didrocks> Saviq: mzanetti: the package takes the ABI from upstream
[11:09] <didrocks> if upstream doesn't bump the ABI, the package won't
[11:09] <Saviq> didrocks, of course, yeah
[11:09] <mhr3> Saviq, well it kinda misses the point of bumping, the old unity-core is not abi compatible
[11:09] <didrocks> so not a "packaging bug"
[11:09] <didrocks> as mzanetti told
[11:09] <Saviq> didrocks, no, a "packaging bug" if something doesn't depend on the correct versions
[11:09] <mzanetti> didrocks: there were 2 discussions, somewhat unrelated
[11:09] <didrocks> mzanetti: ah sorry :)
[11:09] <Saviq> mhr3, so what, we'll not bump it ever anymore?
[11:09] <didrocks> we can bump it
[11:09] <Saviq> yeah
[11:09] <Saviq> we should
[11:10] <didrocks> there is no reason to oppose to that and will ensure that migratoin from raring -> saucy is good
[11:10] <mhr3> Saviq, i'm just not seeing what the benefit now
[11:10] <didrocks> migration*
[11:10] <didrocks> for those already upgrading, it's too late of course :)
[11:10] <Saviq> mhr3, unity8 will depend on the new SONAME version
[11:10] <Saviq> mhr3, that's the benefit, IMO
[11:11] <mhr3> Saviq, but it can just as well depend on the old one, as the binaries will be the same
[11:11] <Saviq> mhr3, but it won't
[11:11] <Saviq> mhr3, and right now the "7.80" version still has the old SONAME
[11:12] <mhr3> Saviq, which can you to get new binary and old headers
[11:12] <mhr3> can cause*
[11:12] <Saviq> mhr3, well, that we can handle with depending on <= 7.80 headers
[11:13] <Saviq> mhr3, that will make sure the new SONAME version is installed
[11:13] <Saviq> mhr3, and thus the binary dependency would be correct, no?
[11:13] <Saviq> mhr3, obviously when we get rid of the 7.80 version that Build-Depends can be changed
[11:13] <mhr3> if it builds with correct headers :)
[11:13] <Saviq> mhr3, yeah, it will
[11:14] <mhr3> but yea, fine let's do it
[11:22] <mhr3> Saviq, thoughts on https://code.launchpad.net/~jamesh/unity-lens-applications/libunity7-phablet/+merge/169116/comments/375912 ?
[11:24] <pete-woods> sil2100: hi
[11:25] <Saviq> mhr3, sure, that could work
[11:25] <Saviq> mhr3, problem is, it can't be "only in", but rather "do show in"
[11:25] <Saviq> mhr3, i.e. explicit, not implicit
[11:26] <mhr3> Saviq, hmm, perhaps a special Category then?
[11:26] <Saviq> mhr3, which will not be obvious if we require "UbuntuTouch" for "OnlyShowIn"
[11:26] <Saviq> mhr3, I can go for whatever
[11:26] <Saviq> mhr3, not really me to decide
[11:27] <Saviq> mhr3, it's more of a bzoltan question
[11:27] <mhr3> k, let me ask him
[11:30] <sil2100> pete-woods: hello, are you busy recently? You think you could help out with HUD related stuff?
[11:31] <pete-woods> sil2100: fairly busy, I'm full time implementing the infographic backend atm. What's going wrong with HUD now?
[11:32] <pete-woods> sil2100: basically with HUD, I know the voice recognition code
[11:33] <pete-woods> sil2100: and I wrote (most of) the unit tests
[11:34] <sil2100> pete-woods: oh oooh!
[11:35] <sil2100> pete-woods: ok, since there seems to be a unit test failing, Ted is working on that one , but he's still working on that one
[11:35] <sil2100> pete-woods: we seem to be lacking manpower!
[11:35] <pete-woods> sil2100: what do we know about what's changed? I mean the tests were all passing reliably when I left it
[11:36] <pete-woods> sil2100: well thostr has taken everyone off of HUD
[11:36] <pete-woods> as it appeared to be "finished"
[11:37] <Saviq> man I'm getting a lot of timeouts from LP recently
[11:38] <sil2100> pete-woods: yes, I think some BAMF related things changed and suddenly one unit test started failing on jenkins
[11:38] <sil2100> pete-woods: probably it's not your thing anyway...
[11:40] <pete-woods> sil2100: unfortunately I do not understand the BAMF stuff
[11:40] <sil2100> Wellark: hi! Maybe you could help?
[11:40] <pete-woods> sil2100: do we know what has changed in BAMF?
[11:40] <pete-woods> surely the behaviour change is documented (or at least known)
[11:41] <sil2100> pete-woods: from what I remember, Ted said this might help, but he's still working on it: https://code.launchpad.net/~ted/bamf/free-in-finalize/+merge/168985 (bamf-side fix)
[11:41] <sil2100> But I also see some other HUD branches he made with some fixes
[11:41] <pete-woods> sil2100: he did say that there was a bug in BAMF that was causing the HUD problem
[11:42] <sil2100> https://code.launchpad.net/~ted/hud/bamf-saucy-fix/+merge/168952 <- for instance, this fix can't get in because of the unit test failing
[11:42] <sil2100> So the merge fails
[11:42] <sil2100> Wellark: ^
[11:44] <pete-woods> sil2100: from cursory inspection it looks like the BAMF DBus API has changed, and the mock of it hasn't been updated
[11:45] <seb128> sil2100, get Trevinho to update it to match the bamf changes he did
[11:45] <seb128> ;-)
[11:45] <Trevinho> pete-woods: no change actually, I've deprecated some methods/signals though
[11:46] <Trevinho> seb128: : what should I update, however?
[11:46] <seb128> Trevinho, not sure, I just read those guys saying that the bamf update broke the hud, so I figured out you should be pinged in case you have an idea what can cause the problem... ;-)
[11:46] <pete-woods> Trevinho: I don't know if this is your responsibility to update, but basically HUD has a mock of the BAMF DBus service in it, and some changes to BAMF have made it break
[11:47] <pete-woods> trevinho: WindowType' returned type '(i)', but expected '(u)'
[11:47] <Trevinho> pete-woods: mh... weird, probably it was a typo
[11:48] <Trevinho> pete-woods: one thing that was changed in library is that I'm using dbus properties instead of signals / methods, but the old ones are still treated as before from the deaemon
[11:51] <sil2100> Trevinho: ^
[11:51] <sil2100> \o/
[11:58] <pete-woods> Trevinho: this is using the "private" API, btw, as it has the real BAMF code running on a mocked DBus Service
[12:02] <pete-woods> sil2100: I've pushed a branch that has a tiny chance of fixing that test failure: https://code.launchpad.net/~pete-woods/hud/bamf-mock-fix/+merge/169176
[12:02] <pete-woods> sil2100: I haven't been able to see that failure locally, presumably because I need a newer version of BAMF
[12:03]  * pete-woods lunch
[12:03] <sil2100> pete-woods: thanks! Let's see if CI is able to build that
[12:03] <sil2100> If yes, it might indeed fix it
[12:49] <Saviq> dednick, how do you feel about the indicators branch, btw? reviewing now, to me it feels much easier to grasp than the previous approach
[12:50] <larsu> dednick: morning
[12:58] <tedg> Trevinho, So, I'd really like *a* BAMF fix, don't care if it's mine or yours, but it's blocking HUD branches from landing right now.
[12:59] <Trevinho> tedg: I'm about to push it now...
[12:59] <tedg> Trevinho, Push harder!
[12:59] <tedg> :-)
[12:59] <tedg> Trevinho, Cool
[13:00] <Trevinho> tedg: can you check if lp:~3v1n0/bamf/factory-ref-rework works for you?
[13:01] <tedg> Trevinho, I can't really verify because it only breaks on Jenkins.
[13:01] <Trevinho> tedg: ah, ok
[13:01] <Trevinho> tedg: I read that, but I was wondering if you found a way to slow down things and reproduce it :)
[13:02] <tedg> Trevinho, No, must work faster!  :-)
[13:02] <Trevinho> ah, so it's harder to do :D
[13:03]  * Trevinho misses reviewers now
[13:03] <tedg> Trevinho, I'll review.
[13:03] <tedg> Yeah, I think it must be that in normal cases the process dies before the error can occur.
[13:03] <dednick> Saviq: yeah, i agree. I think once we can get the network code out it will be in a pretty good condition.
[13:04] <tedg> Trevinho, Click here: https://code.launchpad.net/~3v1n0/bamf/factory-ref-rework/+register-merge
[13:04] <tedg> Trevinho, ;-)
[13:04] <Trevinho> tedg: eheh, yes just one final commit :)
[13:05] <Saviq> didrocks, any idea about https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-saucy/85/console ?
[13:05]  * Trevinho is fighting with race conditions and reffing issues for two days... It's getting slower. :|
[13:05] <dednick> larsu: hey. was wondering what the status of the unityqmenumodel code was. I've had some issues with the one in the indicators-client. I don't want to spend to much time on fixing it if it's going to be replaced soon.
[13:05] <Saviq> tedg, hey, can I have like a half an hour with you on a hangout sometime today?
[13:06] <tedg> Saviq, Sure, at a coffee shop now.  So probably don't have the bandwidth.
[13:07] <Saviq> tedg, sure, please ping me when available
[13:07] <larsu> dednick: I got distracted by other stuff this week. But you can probably already use it if you fell adventurous (it's at lp:~larsu/qmenumodel/add-unitymenumodel)
[13:07] <didrocks> Saviq: the only way as it's hard to debug this kind of issues with apt is to ssh in the chroot and try apt-get install the package directly
[13:07] <didrocks> and see what apt says
[13:07] <larsu> s/fell/feel
[13:07] <Saviq> didrocks, mhm :/
[13:07] <Saviq> mzanetti, can you investigate mzanetti, https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-saucy/85/console ?
[13:07] <larsu> dednick: anyway, I'm aiming to land it early next week
[13:07] <didrocks> Saviq: It's installable in the distro, so I guess you have something conflicting in the ppa
[13:07] <mzanetti> Saviq: yes, Saviq
[13:07] <didrocks> like a nux or whatever
[13:08] <tedg> didrocks, alesage|afk, fginther, can I top approve this?  https://code.launchpad.net/~ted/cupstream2distro-config/upstart-app-launch/+merge/169047
[13:09] <didrocks> tedg: fine for me, fginther +1 on the upstream, so I think it's a yes :)
[13:09] <didrocks> tedg: you told someone is doing the packaging sanity check?
[13:09] <tedg> didrocks, Yup, it's on kenvandine's TODO list
[13:10] <didrocks> ok :)
[13:10] <mzanetti> Saviq: hmm... I guess the VM's need to be dist-upgraded...
[13:11] <mzanetti> Saviq: however, we have a problem with libunity-core then if we're not able to downgrade
[13:11] <Saviq> mzanetti, can we just remove libunity-core from them?
[13:11] <Saviq> mzanetti, it will get installed when needed
[13:11] <mzanetti> Saviq: hmm... yeah... that might do it...
[13:11] <mzanetti> fginther: you around?
[13:12] <mzanetti> Saviq: btw... I still didn't understand the issue exactly tbh. So we require a older version of libunity-core than the one released into saucy?
[13:13] <Saviq> mzanetti, no, than the one in the phablet-team PPA
[13:13] <Saviq> mzanetti, that's been bumped over the raring/saucy one so that we can maintain our own
[13:13] <Saviq> mzanetti, but now we're switching to the distro one
[13:13] <dednick> larsu: ok great. ta
[13:14] <Saviq> brb
[13:14] <mzanetti> Saviq: ah... so wouldn't it be a good idea to remove the phablet-team ppa from our builders?
[13:14] <Saviq> mzanetti, no, not yet
[13:14] <Saviq> mzanetti, we've not moved _yet_
[13:14] <Saviq> mzanetti, and it's best to support both for the time being, if we can at all
[13:15] <Saviq> mzanetti, and also there's other things in the ppa than just unity (unity will simply go away from the ppa)
[13:16] <mzanetti> Saviq: ok...
[13:16] <mzanetti> tricky one...
[13:17] <dednick> Saviq: re indicator review. did you mean Ubuntu.Indicators?
[13:18] <Trevinho> tedg: diff is ready at https://code.launchpad.net/~3v1n0/bamf/factory-ref-rework/+merge/169193
[13:19]  * tedg clicks
[13:19] <dednick> Saviq: or you want me to move it under (module|plugin)/Unity/Indicators?
[13:21] <fginther> mzanetti, what's up?
[13:21] <mzanetti> fginther: moved the discussion to ps-qa
[13:23] <Trevinho> tedg: FYI in saucy doing something like "count=0; while [ $count -lt 20 ]; do xclock& sleep 0.3 && kill $(pidof xclock); count=$((count+1)); done" crashes unity, or other libbamf clients, this branch should fix it
[13:23] <tedg> Trevinho, Heh, I'm not going to try it :-)
[13:24]  * Trevinho wanted to make crash tedg's machine! :D
[13:27] <didrocks> tedg: come on, I want the "before" and "after" :p
[13:27] <didrocks> Trevinho: why did you tell him about the crash? Just that it should make that use case working :)
[13:27] <didrocks> "how whould I know?"
[13:27] <didrocks> "you will know" :)
[13:28] <Trevinho> :D
[13:28] <tedg> didrocks, BTW, did you see this?  http://nerdapproved.com/misc-weirdness/adding-a-dinosaur-makes-for-the-most-epic-wedding-photo-ever/
[13:28] <tedg> didrocks, Just sayin', you could do it.
[13:28] <Trevinho> Cimi: know it crashes though :D (not really that test, but it should be the same)
[13:29] <Trevinho> lol
[13:29] <didrocks> tedg: ahah, I'm sure my fiancee will love that :)
[13:29] <Cimi> I've moved to kde
[13:29] <Cimi> until unity will work again
[13:29] <Trevinho> Cimi: it's time to get back home, dude
[13:30] <Trevinho> Cimi: grab lp:~3v1n0/bamf/factory-ref-rework/ and you'll be happier
[13:30] <Cimi> Trevinho, can't be bothered :D
[13:30] <Cimi> when will be in distro
[13:31] <didrocks> it seems Trevinho has a branch to fix everything :)
[13:31] <Trevinho> hopefully...
[13:31] <didrocks> soon, it will be attached with patches "need to get your intim parts larger? Takes that branch: lp:~3v1n0/bamf/factory-ref-rework/"
[13:31] <didrocks> s/patches/spams/
[13:31] <Trevinho> ahah
[13:32] <Trevinho> that patch also solves personal issues, Cimi you really need it! :)
[13:33] <didrocks> heh :)
[13:34] <greyback> Saviq: standup
[13:35]  * Saviq needs to recreate the standup to add a reminded...
[13:35] <Saviq> reminder, even
[13:43] <tedg> Trevinho, Think, soon you'll be close enough to just smack Cimi when he uses KDE ;-)
[13:43] <Cimi> tedg, kde is a pain compared to UX in unity
[13:43] <Cimi> tedg, but at least is doesn't crash as often :)
[13:44] <tedg> Cimi, Heh, I was more interested in Trevinho smacking you, it'd be good for you ;-)
[13:44]  * tedg wants YouTube videos
[13:45] <tedg> We could have the Italian version of the Three Stooges!
[13:46] <Trevinho> ahaha
[13:47] <Trevinho> tedg: back to the branch, I need to start testing the library also... it seems your libdbustest might help a lot... Unfortunately we had basically 0 tests for bamf until few months ago, so I'm slowly adding them...
[13:47] <tedg> Trevinho, Ah, yeah.  You should look at HUD, we even have a BAMF server mock in there for a few things.
[13:48] <Trevinho> tedg: yes, I've seen that
[13:48] <pete-woods> tedg: don't know if this has reached you, but I pushed this MR to try and help with the unit test failures: https://code.launchpad.net/~pete-woods/hud/bamf-mock-fix/+merge/169176
[13:48] <pete-woods> ted: and it has got past the first error, but as usual there's now a better error :)
[13:48] <tedg> pete-woods, Ah, no I hadn't, but I have the same fix here :-)  https://code.launchpad.net/~ted/hud/bamf-saucy-fix/+merge/168952
[13:48] <Trevinho> tedg: in the mean time, using http://pastebin.ubuntu.com/5761483/ plus the xlcock script can also be a "kind of test"
[13:48] <pete-woods> tedg: the bamf private dbus API has (quite reasonably) changed
[13:49] <tedg> pete-woods, Yeah
[13:49] <pete-woods> tedg: awesome, as long as you're on it I will cancel that MR
[13:49] <tedg> I also have a bunch of debugging info in there which allowed to me to track it down to unref'ing the matcher.
[13:50] <sil2100> pete-woods: ouch, it seems to still be broken... sadly!
[13:50] <tedg> Jenkins is happy, top approving.
[13:51] <tedg> sil2100, We think this BAMF patch is the culprit.  https://code.launchpad.net/~3v1n0/bamf/factory-ref-rework/+merge/169193
[13:51] <tedg> sil2100, Once it lands and builds we can retry the HUD builds and I think things will be better.
[13:59] <sil2100> \o/
[13:59] <sil2100> /o/
[13:59] <sil2100> \o\
[13:59] <sil2100> Would be awesome!
[13:59] <sil2100> tedg, Trevinho: thanks guys, can't wait to see the results
[14:00] <didrocks> tedg: i'll really keep this branch around and propose that for a solution to any pain in the world :)
[14:01] <tedg> didrocks, We don't have a test, but we think this branch may help create peace in the Middle East.  YMMV.
[14:02] <didrocks> tedg: is it going to end the financial crisis as well?
[14:02]  * Trevinho does bzr push middle-east:~3v1n0/bamf/factory-ref-rework
[14:03] <dandrader> mzanetti, so you're doing the drag hint for the greeter, right?
[14:03] <tedg> didrocks, No, no.  That requires putting bankers in jail for being liars, which is apparently impossible.
[14:06] <tedg> Trevinho, Could we make libbamf3-1 not depend on bamfdaemon?
[14:07] <Trevinho> tedg: it's something I've been thinking as well..
[14:07] <tedg> Trevinho, Okay, I'll propose a patch.
[14:07] <Trevinho> tedg:but it's  also true that without it it does nothing... distroooo??? didrocks ???
[14:07] <mzanetti> dandrader: yes
[14:08] <tedg> Trevinho, Yeah, but I need to have HUD handle both Unity 7 and 8 with Mir.  So we're going to have to detect somehow.
[14:08] <mzanetti> dandrader: its already done actually
[14:08] <tedg> Trevinho, I'd rather link to libbamf, but not use it in the Mir case.
[14:08] <Trevinho> tedg: then unity should depend on daemon, isn't it?
[14:08] <Trevinho> 7, I mean
[14:08] <tedg> Trevinho, Yes
[14:09] <didrocks> Trevinho: tedg: hum, but libbamf3-1 without bamfdaemon is useless, isn't it?
[14:10] <tedg> didrocks, Could we do a "Breaks: bamfdaemon (!= ${binary:Version})" ?
[14:10] <tedg> didrocks, Yes, and that's fine.
[14:10] <didrocks> hum, I would be interested in the intend :)
[14:10] <tedg> didrocks, But we don't want bamfdaemon on the phone, but we do want a hud linking to libbamf.
[14:10] <didrocks> ok, that's what I was going to say :)
[14:10] <didrocks> tedg: hud linking to libbamf -> for the convergence story, right?
[14:10] <tedg> didrocks, Yes
[14:11] <didrocks> (even if it won't use it on the phone)
[14:11] <tedg> didrocks, Eventually, if all goes to plan, we won't use it on the desktop either.  But that's going to be in time.
[14:11] <didrocks> yeah, so I guess remove this dep and adding unity7 dep on bamfdaemon is fine
[14:11] <didrocks> yep, agreed
[14:11] <tedg> didrocks, Does that breaks thing above make sense?
[14:11] <didrocks> tedg: not sure about the Breaks: though, what do you want to express?
[14:11] <tedg> I think we want the DBus API to match.
[14:11] <tedg> Just that the version of the lib and daemon should be the same.
[14:12] <didrocks> hum, interesting case :)
[14:12] <didrocks> let me dive a little bit on debian policy
[14:12] <tedg> K
[14:12] <didrocks> The relations allowed are <<, <=, =, >= and >> for strictly earlier, earlier or equal, exactly equal, later or equal and strictly later, respectively.
[14:12] <didrocks> so, doesn't seem
[14:13] <didrocks> but!
[14:13] <didrocks> we can breaks with (<< ${binary:Version}), (>> ${binary:Version})
[14:13] <dandrader> mzanetti, is it in a branch?
[14:13] <didrocks> tedg: wdyt? ^
[14:13] <dandrader> mzanetti, I wanna see how it would (or if it would) conflict with what I'm working on
[14:14] <tedg> didrocks, Sure.  Another thought is that we could make the daemon hard dep on the lib.  Seems you wouldn't want the daemon without the lib.
[14:14] <dandrader> mzanetti, I think I found it: lp:~mzanetti/unity/8-greeter-edge-hinting
[14:14] <mzanetti> dandrader: yep, thats it
[14:14] <mzanetti> dandrader: still need to update the tests
[14:14] <didrocks> tedg: yeah, it's a better idea for apt to handle it I guess, so yeah, go that road please :)
[14:15]  * greyback hates the whitespace checker
[14:15] <didrocks> tedg: so both branch? the bamf part + unity dep?
[14:15] <tedg> didrocks, Yeah, will do.
[14:15] <didrocks> sil2100: FYI ^ as if it lands for tomorrow, as I'm not around, please ensure to land both indicators AND unity
[14:15] <didrocks> otherwise, we'll have some isos broken :)
[14:15] <didrocks> thanks tedg :)
[14:15] <didrocks> sil2100: remember that we have dailies on week-end then, so take care that both lands the same day :)
[14:16] <dandrader> mzanetti, hmm, looks there will be no conflicts. so the idea is that if you tap anywhere on the greeter it will bounce sideways to hint that you can drag it (like on the N9)?
[14:17] <mzanetti> dandrader: only if you tap on the right half of the greeter. if you tap on the left half the launcher will be hinted (which is already in)
[14:17] <mzanetti> dandrader: but yeah... basically like on the N9
[14:17] <dandrader> mzanetti, right
[14:18] <tedg> didrocks, Did the unity-panel-service upstart job get re-added?
[14:18] <didrocks> tedg: not yet sorry, it's on my list on the spreadsheet, but had some other work to do, will do it on Monday to avoid breaking the world before the week-end if any :)
[14:18] <didrocks> tedg: don't worry, I'll handle it anyway
[14:18] <didrocks> and let you know if I can reproduce some bad cases
[14:18] <tedg> Cool, good.  Missing my fast Unity login :-)
[14:18] <Saviq> tsdgeos, do you know if we have https://codereview.qt-project.org/#change,54808 backported?
[14:19] <didrocks> tedg: did it make that much a difference for you?
[14:19] <didrocks> in term of login speed?
[14:19] <tedg> didrocks, Not entirely sure, but it looked faster.
[14:19] <sil2100> didrocks: ACK
[14:19] <tedg> didrocks, No timing or anything.
[14:19] <didrocks> maybe, I was more focused on the indicator-network making my panel bleeding :p
[14:19] <Trevinho> ah tedg about the upstart u-p-s integration, one of the comment of the review (reason why I also waited to appprove), was that it should be possible to do the same witha  dbus call... is this possible already in saucy?
[14:19] <tedg> didrocks, Once we get the indicators out of the way we should get a much more sensible boot.
[14:20] <didrocks> yep
[14:20] <tedg> Trevinho, You mean the signal?  Yeah, there's a work item to get an upstart lib for that stuff.
[14:20] <tedg> Trevinho, I forget which blueprint though....
[14:21] <Trevinho> tedg: ah, nice
[14:21] <Trevinho> tedg: no worries
[14:21] <tsdgeos> Saviq: we should yes
[14:22] <Saviq> tsdgeos, thanks
[14:22] <tsdgeos> Saviq: why?
[14:22] <Saviq> tsdgeos, there's a FIXME that we could get rid of
[14:22] <Saviq> tsdgeos, in indicators
[14:24] <tsdgeos> yep it's there
[14:24] <tsdgeos> debian/patches/03_51665a9ecaebaef2382c1e76ebedfeffacb4b3de_backport.patch
[14:25] <tedg> didrocks, Do you know if the autolander waits for it to build in the PPA?
[14:25] <tedg> Curious if I can kick off HUD builds now or I should wait.
[14:25] <mzanetti> dandrader: pushed the updated tests. feel free to do a proper review of the branch if you have time ;)
[14:25] <didrocks> tedg: sorry, what is the "it"?
[14:25] <didrocks> tedg: once stack wait on the other one to finish first
[14:25] <tedg> didrocks, What ever branch it's landing.
[14:26] <didrocks> within the stack, it's the traditional build-dep order
[14:26] <didrocks> (with constraints in debian/control)
[14:26] <sil2100> didrocks, tedg: I think we would have to re-run the stack that has bamf in it, for the new bamf to land in the PPA
[14:26] <tedg> Wait, but isn't there a PPA of just "this is the latest trunk commit" without releases?
[14:26] <sil2100> So that we can then re-run HUD
[14:27] <didrocks> tedg: I don't think there is anymore. There is a local repository for upstream merger, but that's it
[14:27] <didrocks> sil2100: agreed
[14:28] <tedg> Hmm, okay.  If we could stop changing things that'd make my life easier ;-)
[14:28] <tedg> sil2100, Can you do that please?  The BAMF patch is in trunk.
[14:28] <tedg> I'd like to get my merges in.
[14:29] <sil2100> tedg: I see, hm, just been thinking if this could be in as well before that?https://code.launchpad.net/~laney/indicator-datetime/gtest-linking-order/+merge/169161
[14:29] <sil2100> Since this way I could rebuild bamf and indicator-datetime, unblock 'slightly' indicators and killing 2 birds with one stone
[14:29] <nic-doffay> mzanetti, how free are you?
[14:30] <nic-doffay> On a scale of 1/10 - 5/10 :P
[14:30] <tedg> Sure, that's a silly comment though.  Known issues can be documented.
[14:30] <mzanetti> nic-doffay: given my weekly sync meetings with design start now I'd say 0 :/
[14:30] <mzanetti> nic-doffay: I'll ping you if I have a couple of minutes for you in between the meetings
[14:31] <sil2100> tedg: just the very second that gets merged, I'll run all the machinery and get back to you
[14:33] <nic-doffay> mzanetti, cool
[14:33] <nic-doffay> mzanetti, just need a review of that branch sometime.
[14:33] <nic-doffay> the orientation one.
[14:33] <mzanetti> nic-doffay: yeah, I think I can do that today
[14:33] <nic-doffay> Need some further suggestions on how to speed it up even more.
[14:33] <nic-doffay> eg what components can be moved out the "main" orientation helper.
[14:42] <dandrader> mzanetti, will do
[14:49] <dednick> Saviq: ping
[14:51] <Saviq> dednick, pong
[14:52] <dednick> Saviq: about moving to Unity.Indicator namspace? did you mean Ubuntu.Indicators? I dont see anything else using that
[14:53] <dednick> except for the bridge between old unity & new.
[14:54] <Saviq> dednick, no, Unity.Indicators
[14:54] <Saviq> dednick, the shell-facing plugins are like that
[14:54] <Saviq> or will be
[14:54] <Saviq> dednick, Unity.Notifications is the one that's going to be there the soonest
[14:54] <dednick> Saviq: ah. ok
[14:54] <Saviq> dednick, then Unity.Launcher, Unity should be moved to Unity.Scopes
[14:59] <dandrader> mzanetti, the wonders of multitouch: you can keep a finger on the greeter to activate the launcher hint and then, with another finger, drag in the hinted launcher
[15:00] <mzanetti> dandrader: does it work?
[15:00] <mzanetti> dandrader: I didn't try it to be honest
[15:00] <mzanetti> hehe... yeah, it does
[15:00] <mzanetti> pretty cool, eh
[15:00] <dandrader> mzanetti, yes! it's not a bug or anythin. it's just  amusing :)
[15:01] <dandrader> mzanetti, but not with the Greeter as it currently still uses a Revealer which is MouseArea-based
[15:01] <mzanetti> ah, I see
[15:05] <dandrader> mzanetti, Saviq, oh crap. 1- hold the phone with both hands 2- launch 2 apps (gallery an phone) 3- with left thumb bring in the launcher (but not so much as the app window starts to move away) 4 - with right thumb start bringing in the previous app  from right edge
[15:06] <Saviq> dandrader, lol
[15:07] <dandrader> it all works nicely until the launcher animation starts moving the application window as well
[15:07] <Saviq> dandrader, well, yeah, but that should just be disabled, I think
[15:07] <Saviq> dandrader, the first one wins
[15:08] <Saviq> dandrader, still, it's better than what I'd expect :)
[15:08] <dandrader> yeah :)
[15:09] <Saviq> dandrader, but the launcher hint + drag I say is correct
[15:09] <dandrader> Saviq, yeah, I see no problem with it
[15:10] <dandrader> Saviq, about the "the first one wins", sounds like the single-pointer paradigm where there can be only one interaction at a time. Which you get for free from the touch to pointer conversion when MouseAreas are used.
[15:11] <Saviq> dandrader, yeah, TBH I see nothing wrong with what happens currently
[15:11] <Saviq> dandrader, it's just a case of the two inputs fighting, which is fine, IMO
[15:13] <dandrader> although I'm not suggesting us getting back to MouseAreas. As that limit our possibilities
[15:23] <mterry> pete-woods, so again, I was a little fuzzy on where the infographic backend data lived.  It's not in accountsservice?
[15:23] <pete-woods> mterry: that's where it will live, yeah
[15:23] <mterry> pete-woods, OK.  Hasn't landed yet?
[15:24] <mzanetti> nic-doffay: hey. my meetings are over. I could help you / review now
[15:24] <mzanetti> ah... let me test dandrader's findings first
[15:24] <mterry> pete-woods, I guess it doesn't really matter, lightdm can add support ahead of it in accountsservice and just use an error fallback until it lands
[15:24] <pete-woods> mterry: I'm still waiting on that patch for account service to land that lets me store data there
[15:24] <pete-woods> mterry:  basically I've put together an API that handles that side of things, and gets the data split into the form that the infographic
[15:24] <mterry> pete-woods, but is there a document that describes what the dbus api will look like?
[15:24] <mterry> pete-woods, oh, there is a shim library?
[15:25] <pete-woods> mterry: yes
[15:25] <mterry> pete-woods, I was imagining that liblightdm would be the shim library itself, but that's good too
[15:25] <mhall119> davidcalle: ping
[15:25] <mterry> pete-woods, you were talking about packages, did you mean that you packaged up your shim library?
[15:26] <pete-woods> mterry: basically I was worried that it might be considered to not be part of lightdm, so I've put it in another lib
[15:26] <davidcalle> mhall119, pong
[15:26] <pete-woods> mterry: yes, the API is fixed now, but the lib doesn't "work" yet
[15:26] <mterry> pete-woods, that's fine yeah
[15:26] <mhall119> davidcalle: hey, we need to get a tutorial for writing scopes with the new API, do you happen to have one?
[15:26] <mterry> pete-woods, where is this code?
[15:27] <pete-woods> mterry: https://launchpad.net/libusermetrics
[15:27] <nic-doffay> mzanetti, wicked ill get the link
[15:27] <nic-doffay> mzanetti, https://code.launchpad.net/~nicolas-doffay/unity/orientation/+merge/168100
[15:27] <pete-woods> mterry: I've not pushed the C (GObject) API yet
[15:27] <pete-woods> so it's Qt only at the moment
[15:28] <mterry> pete-woods, maybe we just use this directly then instead of going through liblightdm
[15:28] <davidcalle> mhall119, I do have a lengthy one, which is WIP, but I can make a rather quick one from it. When would you need it?
[15:28] <mhall119> davidcalle: next week if possible
[15:28] <pete-woods> mterry: that was always a possibility - I wanted to protect against it being decided that it didn't belong in LightDM
[15:28] <mhall119> if you can't in that timeframe, I can work on what you have currently
[15:29] <mterry> pete-woods, I was just mentally sticking it in liblightdm because a lot of other accountsservice stuff is there, but agreed that this feels a bit different, and since you've already done the work for it, no reason to then stick another layer in the mix
[15:29] <davidcalle> mhall119, I can probably do it tomorrow.
[15:29] <mhall119> davidcalle: that would be awesome, thanks
[15:29] <mterry> pete-woods, is this in saucy yet?
[15:29] <pete-woods> mterry: we would still need a plugin in the shell adding for it
[15:29] <mhall119> I'll get it up on developer.ubuntu.com as soon as it's ready
[15:30] <davidcalle> mhall119, saucy or raring?
[15:30] <mhall119> davidcalle: saucy
[15:30] <mhall119> smart scopes
[15:30] <davidcalle> mhall119, ok
[15:30] <mterry> pete-woods, sure.  We could stuff it in the "LightDM" plugin, since from the shell's perspective, it's still login-related stuff
[15:30] <pete-woods> mterry: I actually have no idea where the packages go, the CI side of things was set up for me
[15:30] <pete-woods> mterry: good point!
[15:31] <mterry> pete-woods, OK...  So you set up CI, good.  I'll poke didrocks.  didrocks, do you know the distro-status of libusermetrics?  I can be a reviewer if you need more
[15:31] <Saviq> mzanetti, fginther any ETA on the mediumtests VMs?
[15:32] <mzanetti> Saviq: that could take quite a bit... anything that needs to land? in that case I could workaround it temporary
[15:32] <fginther> Saviq, still working on it, I'll hopefully have one ready in the next two or three hours (better if all goes well)
[15:33] <sil2100> tedg: ok, so... we need to wait for didrocks sadly\
[15:33] <Saviq> mzanetti, https://code.launchpad.net/~unity-team/unity/8.new-libunity/+merge/167733 is waiting on that
[15:33] <Saviq> yikes
[15:34] <sil2100> tedg: since I re-ran indicators (bamf and indicator-datetime), but something got broken in the system and the build job just crashes
[15:34] <mhr3> davidcalle, keep in mind that things might still be changing... for example today's discussion
[15:34] <sil2100> tedg: only didrocks can help us nooow ;_;
[15:34] <sil2100> tedg: he should be back soon I hope!
[15:34] <Saviq> mzanetti, fginther, if it's there for tomorrow, we'll be fine, I really hope to land this tomorrow
[15:34] <mhr3> davidcalle, so working on a lengthy one right now isn't the best use of time :)
[15:34] <tedg> sil2100, Ah, okay.
[15:34] <fginther> Saviq, that would be better, give us a chance to run a few extra tests first :-)
[15:35] <mzanetti> Saviq: ok... then I won't hack some workarounds now. if fginther encounters problems and vm's are not ready tomorrow, I'll punch it through CI tomorrow
[15:35] <Saviq> mzanetti, fginther thanks
[15:35] <fginther> Saviq, np
[15:37] <davidcalle> mhr3, indeed, but the lenghty one is mostly about how to use the set of scripts in scope-tools, so that should work as long as I keep maintaining it
[15:44] <mzanetti> nic-doffay: where do I get the file you patched in the SDK?
[15:45] <nic-doffay> mzanetti, I that slipped my mind.
[15:45] <nic-doffay> one sec
[15:46] <nic-doffay> mzanetti, lp:~nicolas-doffay/ubuntu-ui-toolkit/orientation-helper-anim-alias
[15:48] <Trevinho> sil2100: do you know for when is planned an SRU for unity in raring? THere are a couple of annoying bugs staring there for too much time I think
[15:50] <sil2100> Trevinho: for raring you say... I think it should be really soon, since the SRU is ready but from what I know it was waiting for a patch pilot to pick it up
[15:50] <Trevinho> sil2100: ah, ok
[15:51] <Trevinho> sil2100: since we support it only 9 months I think that for this short period at least we should be quick in providing fixes :)
[15:51] <mzanetti> nic-doffay: Cannot assign to non-existent property "transitionEnabled"
[15:52] <mzanetti> nic-doffay: the OrientationHelper from your branch does not seem to have that property
[15:52] <nic-doffay> mzanetti, I must have forgotten to push it.
[15:52] <nic-doffay> one sec..
[15:52] <seb128> sil2100, Trevinho: there is  a raring SRU in the queue waiting for review for like a month, infinity said he would review it soon ... but maybe a ping on #ubuntu-release as a reminder could be useful
[15:53] <Trevinho> seb128: ah
[15:53] <sil2100> Indeed
[15:53] <nic-doffay> mzanetti, pushed
[15:57] <Cimi>                     property color backgroundColor: "transparent"
[15:57] <Cimi>                     property color sundayBackgroundColor: "#19AEA79F"
[15:57] <Cimi>                     property color rectangleColor: isSunday ? sundayBackgroundColor : backgroundColor
[15:57] <Cimi> Saviq, ^^ rectangleColor loses the alpha channel
[15:57] <Cimi> any idea why?
[15:58] <Saviq> Cimi, trying
[15:58] <mzanetti> Saviq: hmmm.. I'm having troubles with run_on_device on the latest image. already known?
[15:59] <Saviq> mzanetti, no, wassup?
[15:59] <mzanetti> The C compiler "/usr/bin/cc" is not able to compile a simple test program.
[15:59] <mzanetti> I didn't investigate yet...
[15:59] <Cimi> mzanetti, remember we have saucy now
[16:00] <mzanetti> Cimi: yeah... I know
[16:00] <mhr3> ricotz, re your yesterday's question - it affects just libunity, and that still builds with 0.18, so shouldn't cause any issues atm
[16:00] <mzanetti> apt-get upgarde seems to upgrade all the compiler stuff... lets see what happens
[16:02] <Saviq> Cimi, s/color/var/
[16:03] <Cimi> Saviq, last one?
[16:03] <Saviq> Cimi, seems assigning to a color property loses alpha
[16:03] <Saviq> Cimi, all props
[16:03] <Cimi> Saviq, ok
[16:03] <Cimi> Saviq, weird... if I use directly backgroundColor is indeed transparent
[16:03] <Cimi> Saviq, if I do if else, it loses
[16:03] <Saviq> Cimi, yeah, the binding must break it somehow
[16:05] <tedg> bregma, Do you have a name for what the unity 8 session will be called?
[16:06] <bregma> not yet, but "Kevin" is a good candidate
[16:06] <bregma> realistically, I would choose "unity8" for testing purposes
[16:07] <Cimi> Saviq, bugreport for qt?
[16:08] <Saviq> Cimi, definitely
[16:08] <bregma> currently unity8 does not even build from source on Saucy, is anyone tracking that?
[16:08] <mzanetti> nic-doffay: ok... got it running
[16:08] <nic-doffay> mzanetti, awesome
[16:09] <Saviq> Cimi, tsdgeos, http://pastebin.ubuntu.com/5761876/
[16:09] <dednick> Saviq: ping
[16:09] <nic-doffay> mzanetti, sorry for the delay
[16:09] <Saviq> dednick, pong
[16:09] <nic-doffay> usual absent minded stuff.
[16:09] <dednick> Saviq: qml shouldnt really be copied into the binary folder right?
[16:09] <Saviq> dednick, ideally no, but if you have a module there's no way around it
[16:10] <mzanetti> nic-doffay: no worries. any specific questions?
[16:10] <Saviq> dednick, the plugin .so needs to be in the same place the qmldir and the qml files are
[16:10] <tsdgeos> Saviq: what?
[16:10] <Saviq> tsdgeos, check out that QML
[16:10] <dednick> Saviq: right, but if we split the indicators to plugin + import would be better?
[16:10] <dednick> or still needs to be in same?
[16:10] <Saviq> tsdgeos, and then s/color/var/ in lines 21,22
[16:10] <Saviq> dednick, yeah, better
[16:10] <Saviq> dednick, since they're going to be on a separate import path
[16:10] <tsdgeos> weird
[16:11] <Saviq> tsdgeos, feels like QColor(QColor()) looses alpha or something
[16:11] <dednick> Saviq: some of the qml files have resources (images) though. how do we ship those with imports?
[16:11] <Saviq> tsdgeos, or the bindings, something's really weird
[16:11] <Saviq> dednick, with the import, in a graphics/ folder
[16:11] <tsdgeos> hope i didn't break that :D
[16:11]  * tsdgeos checks his patch to qcolor
[16:11] <nic-doffay> mzanetti, not really just wanted to get your thoughts on which components don't have to rotate.
[16:11] <nic-doffay> to speed it up.
[16:11] <Saviq> tsdgeos, yeah, that's why I pointed it at you :D
[16:11] <Saviq> tsdgeos, or you at it
[16:12] <Saviq> dednick, we don't have any imports yet, but I'm getting to the point where I want to split the source into some imports
[16:12] <dednick> Saviq: yeah, but if you load something with a loader, i think it uses a path relative to where the loader is :(
[16:12] <Saviq> dednick, hmm, it shouldn't
[16:12] <tsdgeos> but i didn't change that
[16:12] <tsdgeos> i think
[16:12]  * tsdgeos is looking for the comit
[16:12] <Saviq> tsdgeos, yeah, that's fine
[16:12] <Saviq> tsdgeos, but it's also only happening with a conditional binding
[16:13] <Saviq> tsdgeos, if you do color: backgroundColor
[16:13] <Saviq> tsdgeos, it's fine
[16:13] <Saviq> so no, it's not even QColor(QColor())
[16:13] <tsdgeos> nah didn't change that
[16:13] <dednick> Saviq: ok, well i'll give splitting the indicators into imports and plugin tomorrow. can't promis anything though :)
[16:13] <Saviq> dednick, sure, that's not a priority, though
[16:13] <Saviq> dednick, can happen when we do more of that in the whole shell
[16:13] <mzanetti> nic-doffay: good question... thats a tough one
[16:13] <dednick> Saviq: ok.
[16:14] <Saviq> dednick, but then the QML should just maybe live in Panel/Indicators
[16:14] <Saviq> dednick, and not in the module
[16:14] <mzanetti> nic-doffay: you could try to destroy the non-visible lenses during rotation and create them again afterwards
[16:14] <tsdgeos> Saviq: all i can say it's it shold work, but it doesn't :D I can have a look but i guess it's not really critical
[16:14] <mzanetti> nic-doffay: just a guess tho... not sure what ramifications that brings
[16:15] <Saviq> tsdgeos, yeah, there's a workaround, so we'll use that and Cimi will file a QTBUG
[16:15] <nic-doffay> mzanetti, what about the various stages?
[16:15] <Saviq> tsdgeos, so yeah, don't spend any time on it
[16:15] <tsdgeos> Saviq: maybe i can find time to have a look at it while at QTCS or something :-)
[16:16] <Saviq> tsdgeos, have fun there :)
[16:16] <didrocks> mterry: libusermetrics? either my memory is not good, either it's the first time I heard about it for dailies ;)
[16:16] <mzanetti> nic-doffay: in Dash/DashContent.qml try setting cachebuffer to 0 while rotation is running
[16:16] <Cimi> Saviq, that theming thing is so fun :D
[16:17] <Saviq> Cimi, yeah, it's a pain we're not using it yet in the shell
[16:17] <Saviq> Cimi, every time I see a "color: "something"" or "weight: Text.Medium" I cringe :D
[16:17] <Cimi> Saviq, you mean shame?
[16:17] <Saviq> Cimi, yeah
[16:17] <Cimi> I can work on that after
[16:17] <Saviq> Cimi, I know you can
[16:17] <Saviq> Cimi, I even know that you will ;)
[16:17] <mzanetti> nic-doffay: hmmm. don't think you can remove the stages
[16:17] <Cimi> lol
[16:18] <Saviq> tsdgeos, jenkins: ouch
[16:19] <mzanetti> nic-doffay: I guess if that cacheBuffer thing doesn't work, one thing would be to try serializing the rotations... E.g. the visible parts first, and then, when done, the non visible ones... I understand thats quite tricky to do tho
[16:19] <Saviq> tsdgeos, you committed a test.qml
[16:19] <Saviq> mzanetti, nic-doffay, yeah I did some thinking about that, too
[16:19] <mzanetti> nic-doffay: also play around with things like "layer.enabled: rotation.running" or something like that
[16:20] <tsdgeos> i did
[16:20] <tsdgeos> Saviq: what's wrong about it?
[16:20] <Saviq> tsdgeos, no copyright :D
[16:20] <tsdgeos> right
[16:20] <Saviq> mzanetti, layering won't help if the component is _in_ an orientationHelper
[16:21] <Saviq> mzanetti, 'cause it will get updated with each geometry change anyway
[16:21] <Saviq> nic-doffay, ^
[16:21] <mzanetti> hmm... I see..
[16:21] <Saviq> mzanetti, nic-doffay, it's gonna get better with tsdgeos's new ListViewWithPageHeader
[16:21] <Saviq> mzanetti, nic-doffay and even better later when we rebuild only the visible lenses
[16:21] <mzanetti> Saviq: I think the slowness comes from the fact that we have all lenses created all the time
[16:21] <Saviq> mzanetti, yeah, and all the categories
[16:22] <mzanetti> yeah. those 2 things should help a lot
[16:22] <mzanetti> still... try to get as much as possible out of the current state... it can only get better later
[16:22] <Saviq> nic-doffay, mzanetti I'm inclined to say that until then we should not rotate the dash
[16:22] <mzanetti> Saviq: I tend to agree
[16:22] <Saviq> design folks were thinking that, too
[16:23] <mzanetti> Saviq: also, it causes a conflict with the greeter, now that we have the hack for the tablet
[16:23] <mzanetti> looks like a micro tablet now :)
[16:23] <Saviq> ;)
[16:23] <Saviq> mzanetti, nic-doffay, so I'm thinking let's go for "only rotate the shell when app is focused"
[16:23] <Saviq> mzanetti, tablet is completely broken for rotation, too
[16:23] <Saviq> mzanetti, as side stage isn't moved to the right edge
[16:24] <mzanetti> oh... I see
[16:24] <Saviq> but that won't happen before Mir integration
[16:24] <Saviq> when we can actually control the surfaces
[16:24] <mzanetti> actually, we should only rotate the shell if an app is focused AND the app handles rotation
[16:24] <mzanetti> which might reveal some lacking API
[16:24] <mzanetti> Saviq: ^
[16:24] <nic-doffay> Saviq, mzanetti can you leave these as comments so I can read them tomorrow again?
[16:25] <Saviq> mzanetti, yeah, of course
[16:25] <Saviq> mzanetti, there's even more to that
[16:25] <Saviq> mzanetti, question is not "does app support rotation", but what orientations it supports (landscape / portrait)
[16:25] <mzanetti> exactly
[16:25] <Saviq> mzanetti, and if it only supports one of them (and it's not the native one)
[16:25] <Saviq> mzanetti, we actually need to rotate the surface
[16:26] <mzanetti> yep
[16:26] <Saviq> because the app won't know
[16:26] <Saviq> then there's the question of 180° rotation
[16:26] <Saviq> we could support it regardless of app's abilities
[16:26] <Saviq> s/could/should/
[16:26] <mzanetti> hehe... yeah... I already was close to talking to the speaker while listening to the mic in my last call
[16:26] <mzanetti> as the phone-app does 180° rotation
[16:26] <Saviq> :)
[16:27] <Saviq> mzanetti, so yeah, we got some questions to answer
[16:27] <mzanetti> yep...
[16:27] <Saviq> ricmm was setting up a call about that
[16:45] <nic-doffay> mzanetti, thanks for the comment!
[16:59] <Trevinho> tedg: how is going the hud with new factory?
[16:59] <Trevinho> ouch, he's out...
[17:00] <Trevinho> sil2100: do you know that? ^
[17:00] <sil2100> Trevinho: hi! Ok, so we had some issues in the stack
[17:01] <sil2100> Trevinho: someone did an direct upload to the archive and broke the daily-release
[17:01] <Trevinho> ah
[17:01] <sil2100> Trevinho: we fixed that, waiting for the merge to go in
[17:01] <sil2100> Once that's done, I'll restart
[17:29] <jbicha> mfisch: can you merge https://code.launchpad.net/~jbicha/account-plugin-fitbit/build-with-valac/+merge/168227 ?
[17:30] <mfisch> jbicha: that's cwayne's baby, let me ping him, if he can't I can
[17:31] <cwayne> mfisch, heyo
[17:32] <mfisch> cwayne: <jbicha> mfisch: can you merge https://code.launchpad.net/~jbicha/account-plugin-fitbit/build-with-valac/+merge/168227 ?
[17:32] <mfisch> cwayne: do you want to do that or do you need me to?
[17:35] <cwayne> mfisch, would you please?  MR looks fine to me though
[17:35] <cwayne> jbicha, thanks for the MR!
[17:36] <mfisch> jbicha: building now
[17:37] <mfisch> I wonder why I never got an email about that MR
[17:38] <cwayne> i didnt either
[17:38] <cwayne> weird
[17:38] <cwayne> mfisch, that package is in universe btw
[17:38] <cwayne> so i guess you can push updates to it now :P
[17:39] <cwayne> mfisch, youre now my go-to motu, mterry  you're off the hook :D
[17:39] <jbicha> mterry: could you re-approve https://code.launchpad.net/~jbicha/gnome-control-center-unity/rename-desktop-for-38/+merge/167608 ?
[17:39] <mfisch> I was hoping my first push would be some massive awesomeness but this will do
[17:40] <mfisch> jbicha: is there a bug for this ?
[17:40] <jbicha> mfisch: fixing ftbfs issues are massive awesomeness :)
[17:40] <jbicha> no bug
[17:41] <mfisch> jbicha: I dont see it on the qa site for ftbfs?
[17:42] <jbicha> that's because the last time it was pushed to Ubuntu it did build but it wouldn't now that the dependencies shifted
[17:42] <mfisch> ah
[17:44] <jbicha> that's why there's periodic rebuilds of everything in Ubuntu to catch build failures like that
[17:44] <jbicha> I think the last one was http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130329-raring.html
[17:45] <mhr3> Saviq, almost forgot but i pushed the soname branch
[17:45] <mhr3> Saviq, so pls look if you're still around
[17:46] <mfisch> jbicha: merged and pushed up
[17:46] <mfisch> jbicha: does it also need to be dput now?
[17:47] <jbicha> mfisch: yes, unless that branch does that fancy autolanding
[17:47] <mfisch> nope
[17:49] <Saviq> mhr3, already approved, shall we wait for someone else to top-approve or do you think it's fine to land?
[17:49] <jbicha> you could maybe opt in to the autolanding program but I've no idea how much work is required for that
[17:50] <mterry> didrocks, ah, it must have just been set up for CI, not daily-release...  I'd like to set it up for daily-release, let me see about filing a MR to do that
[17:50] <mhr3> Saviq, i didn't exactly test the deb, other than building it, but we have testing that should catch if it breaks something, don't we? ;)
[17:51] <didrocks> mterry: the packaging should be pre-NEWed if not in the archive, check for compatibility with our rules
[17:51] <Saviq> mhr3, indeed
[17:51] <didrocks> mterry: I'm not there tomorrow, but I guess sil2100 can help you :)
[17:51] <didrocks> mterry: and it's not like if you were a stranger to the rules for daily release :p
[17:51] <sil2100> mterry: what's up? What package?
[17:52] <mterry> didrocks, yar, I was going to check the process page again, it's been a while since I did a NEW package for daily
[17:52] <Saviq> mhr3, k, building myself, too
[17:52] <didrocks> mterry: we added "multi-arch if possible" to the list (but not the wiki page)
[17:52] <mterry> sil2100, I'm looking at libusermetrics, something used for the infographic on the phone
[17:52] <mterry> sil2100, not in archive yet
[17:53] <didrocks> mterry: and you know this MIR things… check for build-deps to not have bad surprise later on and having someone MIRing 20 components :p
[17:53] <didrocks> first time you heard of it I'm sure! :p
[17:53] <sil2100> :D
[17:53] <mterry> didrocks, are we mainlining unity8 stuff?
[17:53] <sil2100> mterry: I could look at that, but tomorrow
[17:53] <mterry> I guess we must, we'll make an image for it
[17:53] <didrocks> mterry: not yet, I'm just checking we don't introduce crazy stuff as I've already seen :)
[18:04] <sil2100> Trevinho: are you still around?
[18:05] <sil2100> Trevinho: https://launchpadlibrarian.net/142339353/buildlog_ubuntu-saucy-armhf.bamf_0.5.0daily13.06.13.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[18:05] <Trevinho> sil2100: yes
[18:05] <sil2100> I wonder what's up... not sure if we had a new webapps?
[18:05] <Trevinho> sil2100: mh
[18:05] <Trevinho> sil2100: has the package name changed?
[18:06] <mterry> sil2100, so yeah, I'll review lp:libusermetrics today, if you have time tomorrow, I'd appreciate a second look
[18:07] <sil2100> Trevinho: not sure, since it's in the archive
[18:09] <sil2100> I mean, in the PPA
[18:10] <sil2100> fginther: ping!
[18:10] <fginther> sil2100, pong
[18:11] <sil2100> fginther: maybe you would be able to help? As we're getting a build failure of bamf on armhf, saying it cannot find a version of libunity-webapps
[18:11] <sil2100> fginther: while the very same version is in the PPA already
[18:12] <sil2100> Rebuilding does not help...
[18:12] <fginther> sil2100, do you have a link to the build?
[18:12] <sil2100> https://launchpadlibrarian.net/142339353/buildlog_ubuntu-saucy-armhf.bamf_0.5.0daily13.06.13.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[18:12] <sil2100> https://launchpad.net/~ubuntu-unity/+archive/daily-build/+sourcepub/3243556/+listing-archive-extra <- while this is in the same PPA
[18:13] <sil2100> I need to finish soon, but this is still broken ;/
[18:13] <sil2100> I want to unblock the stacks
[18:14] <sil2100> https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4669110
[18:15] <sil2100> Ok, I really have to go now
[18:15] <sil2100> fginther: could you take a look?
[18:15] <sil2100> kenvandine: could I ask you something?
[18:15] <fginther> sil2100, I'm looking
[18:16] <kenvandine> sil2100,  certainly
[18:16] <sil2100> kenvandine: if this gets somehow resolved, could you please re-run the indicator stack with 'foo' as the project list?
[18:16] <sil2100> Since I'd like to have it unblocked
[18:16] <kenvandine> yup
[18:16] <sil2100> fginther, kenvandine: thanks guys!
[18:16] <sil2100> Sorry about that ;)
[18:16] <kenvandine> np
[18:16] <kenvandine> fginther, can you ping me?
[18:16] <sil2100> See you tomorrow!
[18:54] <ricotz> mhr3, re vala -- then it seems fine, although there might be other libraries affected too
[18:57] <fginther> kenvandine, I found the issue with bamf, the latest libunity failed to build on armhf
[18:58] <fginther> kenvandine, looks like maybe a launchpad hiccup, I'm going to retry the build
[18:58] <kenvandine> fginther, cool
[18:58] <fginther> kenvandine, except, I can't.  Can you: https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4667352
[18:58] <kenvandine> fginther, restarted
[18:58] <fginther> kenvandine, thanks
[19:04] <gQuigs> trying to figure out why this happens: http://askubuntu.com/questions/230270/immediately-after-login-my-12-04-lts-desktop-asks-for-my-password-for-authenti
[19:05] <gQuigs> error from auth.log: polkitd(authority=local): Operator of unix-session:/org/freedesktop/ConsoleKit/Session2 FAILED to authenticate to gain authorization for action org.freedesktop.accounts.user-administration for system-bus-name::1.54 [/usr/lib/indicator-messages/indicator-messages-service] (owned by unix-user:REMOVED)
[19:06] <gQuigs> removing the indicator-messages packages fixed it, but I can't figure out why it would be trying to access user-admin...
[20:10] <gotwig> mhall119, so are the scopes going to be more integrated into the smart scopes?
[20:10] <gotwig> mhall119, imagine the possibilities of a smart scope for recipes :O ^^
[20:11] <gotwig> mhall119, when I once released my first versions, people already wrote in the comments that it could be useful for use with a tablet in the kitchen. The following years may realize this idea
[20:20] <fginther> kenvandine, can you try rebuilding bamf now?
[20:21] <kenvandine> fginther, again?
[20:21] <fginther> kenvandine, bamf was not building due to libunity
[20:22] <fginther> libunity is oknow
[20:22] <fginther> libunity is ok now
[20:22] <kenvandine> fginther, yeah, i rebuilt it earlier
[20:22] <kenvandine> and it succeeded
[20:22] <kenvandine> oh
[20:22] <fginther> ok, so can we rebuild the stack now as sil2100 wanted?
[20:22] <kenvandine> wait... i did the rebuild on libunity
[20:23] <kenvandine> and i did what he asked on the stack
[20:23] <fginther> oh, so a build is in progress?
[20:23] <kenvandine> no... it failed again
[20:23]  * kenvandine looks
[20:23] <fginther> i mean a daily release build...
[20:24] <kenvandine> yeah, i did
[20:24] <kenvandine> but it failed because of the failed bamf build
[20:24] <kenvandine> i just poked that one
[20:24] <kenvandine> and i'll run it again
[20:25] <fginther> ohhh, ok
[20:25] <fginther> thanks
[20:25] <kenvandine> thx for the reminder
[20:25] <kenvandine> i had missed a step in there :)
[21:03] <fginther> kenvandine, bamf is good now
[21:03] <kenvandine> fginther: cool
[21:03] <kenvandine> i'll rerun the stack then
[21:51] <om26er> where can I find the latest unity8 build ?
[22:00] <om26er> ouch wrong channel\