[00:14] <charlee> hey guys, good morning, does anyone know how to start unity using startx? i have tried to put in `exec unity`, unity started but lot of things were missing, compiz wasn't loading, etc..
[00:15] <charlee> also tried `exec gnome-session --session=unity`, couldn't get unity to start
[00:16] <charlee> I personally don't want to use any of the display manager, so is there a way to just startx it? thanks
[07:10] <tsdgeos> mzanetti: is https://code.launchpad.net/~mzanetti/unity8/update-inputinfo/+merge/273248 something we want in or still a WiP?
[07:43] <mzanetti> tsdgeos, still WIP. need to update tests... have them half working here
[07:43] <tsdgeos> ok
[08:14] <tsdgeos> mzanetti: so no need for the extra carefulness i suggested in the autorepeat MR?
[08:14] <tsdgeos> i guess it was a bit too much :D
[09:13] <Saviq> mzanetti, you got an arale? can you try bug #1508830 ?
[10:08] <tsdgeos> sigh
[10:08] <tsdgeos> something has changed on the SDK
[10:08] <tsdgeos> and stuff now doesn't even compile
[10:11] <tsdgeos> in the use_sdk_13 bnranch
[10:12]  * tsdgeos investigates
[10:14] <tsdgeos> ah new item clashes with one of ours
[10:14] <davmor2> tsdgeos: blame Saviq, it won't fix it but you'll feel much better
[10:35] <tsdgeos> Saviq: mzanetti: are you guys doing the audiorole compatibility branch with that loader thing you showed me yesterday or want me to? (since the bug is assigned to me)
[10:37] <Saviq> tsdgeos, you might very well do it, basically take the component from https://code.launchpad.net/~mzanetti/ubuntu-clock-app/detect-qtmm-version/+merge/275177
[10:37] <tsdgeos> ok, /me does
[10:37] <mzanetti> oops... sorry, missed your earlier message Saviq
[10:37] <Saviq> nw
[10:38] <mzanetti> Saviq, yes, I have, will try, (re arale)
[10:38] <Saviq> mzanetti, jibel was able to repro once, there's a chance the "refresh apps scope" is a red herring
[10:38] <Saviq> I wasn't able to repro on krillin with, or without apps scope refresh
[10:49] <mzanetti> yeah... looks like something goes wonky on dbus
[10:50] <mzanetti> media hub dying and the shell trying to reach it for the screenshot sound
[11:12] <Saviq> man... DST change this weekend "16 trains will stop for an hour"...
[11:13] <ltinkl> lol
[11:14] <Saviq> can we please stop this madness
[11:15] <ltinkl> I agree but this change is to the right time
[11:16] <Saviq> ok then, can we please only do this this one last time?
[12:59] <tsdgeos> mterry: can you review https://code.launchpad.net/~aacid/unity8/scope_settings_keyboard_scroll/+merge/274874 ?
[12:59] <mterry> k
[13:01] <mterry> tsdgeos, I wanted something like this in one of my apps but was too lazy to do it  :)
[13:01] <mterry> tsdgeos, SDK should have an option on its UbuntuListView for this
[13:02] <tsdgeos> the problem is that it still needs the delegates to request the visibilty
[13:02] <tsdgeos> ideally one could watch all children created and inject the request
[13:02] <tsdgeos> but i decided not to spend so much time :D
[13:03] <mterry> tsdgeos, why this line in setMake...Item()?  "d.previousVisibleHeight = d.visibleHeight;"
[13:03] <mterry> is it for the initial setting?  could do that by "property real previousVisibleHeight: visibleHeight"
[13:04] <mterry> tsdgeos, also, mightn't you want to ensure it's visible in that same call without having to wait for visibleHeight to change again?
[13:05] <tsdgeos> mterry: this is reusing some of the code we use for the previews
[13:05] <tsdgeos> in which the items change height so we need to account for that
[13:05] <tsdgeos> hence the complex stuff with height
[13:05] <mterry> tsdgeos, ?  but in onVisibleHeightChanged you always set previous.  So the only time previous will be out of sync will be before the first onVisibleHeightChanged
[13:06] <mterry> tsdgeos, in which case you can just start with an initial binding on previous
[13:06] <tsdgeos> mterry: yes i set it for the next change
[13:06] <tsdgeos> that's what previous is for, no?
[13:07] <mterry> tsdgeos, right.  I'm saying I don't see the need for the additional set in setMakeSureVisibleItem(). But it doesn't matter.  It's not harmful.  Just hard to see why it's there
[13:07] <tsdgeos> mterry: otherwise the first onvisibleheightchanged has un-initialized value, no?
[13:08] <mterry> tsdgeos, right.  And that's why I suggested "property real previousVisibleHeight: visibleHeight" instead of ": 0".  Thought it was clearer than an extra previous set
[13:08] <mterry> But it doesn't matter
[13:08] <tsdgeos> mterry: but then it doesn't work for the next item
[13:08] <tsdgeos> since the binding would already be broken
[13:09] <mterry> tsdgeos, but previousVisibleHeight doesn't depend on the item.  The next item will have it set from a onVisibleHeightChanged call
[13:11] <tsdgeos> hmmm, might be
[13:11] <tsdgeos> tbh i just moved this code around :D
[13:11] <mterry> tsdgeos, I'm seeing that now  :)  You just kept the set from the previous code
[13:12] <mterry> tsdgeos, wouldn't it be better to adjust contentY immediately when setMakeSureVisibleItem() is called, rather than waiting for the next onVisibleHeightChanged?
[13:13] <tsdgeos> to which value?
[13:14] <mterry> tsdgeos, I mean, force a recalculation, as if onVisibleHeightChanged happened
[13:14] <mterry> tsdgeos, but just to do it immediately after receiving a new item
[13:14] <tsdgeos> but at that point it won't do anything
[13:14] <tsdgeos> since you're already visible
[13:14] <tsdgeos> since you gained focus
[13:14] <mterry> tsdgeos, how does this component know that?
[13:14] <tsdgeos> so the user can see you
[13:15] <mterry> tsdgeos, you're saying that all callers make sure to only call it after they are visible?  fine
[13:15] <mterry> tsdgeos, but as a component API, I'd have expected it to make sure
[13:16] <tsdgeos> well it's a component since i didn't want to c&p code :D
[13:16] <mterry> Seems less fragile to not rely on callers being smart
[13:16] <tsdgeos> it doesn't matter anyway
[13:16] <tsdgeos> since it'll work
[13:16] <tsdgeos> on the height change
[13:16] <tsdgeos> if somehow you can make a thing gain focus without having it in view
[13:19] <mterry> tsdgeos, you're talking about the specific narrow situations we use this component in now.  But I'm just seeing a component that has an API that says "make me visible" -- no API contract for being focused or in view.
[13:19] <mterry> tsdgeos, I'm thinking a future unity8 developer might reasonably use this for a different purpose and expect its API to do what it says
[13:19] <tsdgeos> mterry: sure, as said, it'll get visible on first height change by the sdk
[13:20] <mterry> tsdgeos, right...
[13:20] <tsdgeos> not as you'd see the difference at all
[13:20] <mterry> tsdgeos, and I'm saying there's a gap there  before that happens  :)
[13:20] <mterry> this is a theoretical problem, I'm just trying to be defensive against future bugs/misunderstandings
[13:20] <tsdgeos> i don't understand what you say
[13:20] <tsdgeos> i don't see any theoretical problem
[13:21] <tsdgeos> please explain where is the problem
[13:21] <mterry> tsdgeos, so let's say in a year, I see this component.  I have some code that wants to pull a widget in my list into view.  So I call this setMakeSureVisibleItem().  And nothing changes!  It's not in view.  Only the next time the OSK appears does it finally scroll to my widget
[13:22] <tsdgeos> correct
[13:22] <mterry> tsdgeos, why would setMakeSureVisibleItem() not make sure my item is visible after the call?  :)
[13:22] <tsdgeos> because you're using a component called ListViewOSKScroller
[13:22] <tsdgeos> you're doing it wrong
[13:22] <tsdgeos> it's not what you want
[13:22] <tsdgeos> and it should not do that
[13:23] <mterry> Oh fair, OSK is in the title...  But fine.  What if I call this after the OSK is up?
[13:23] <tsdgeos> if you want to make an item visible there's other things to use
[13:24] <mterry> tsdgeos, but now there's a race between the OSK and this API call.  What if I call this after the OSK appears?
[13:24] <tsdgeos> i'd still argue you're using it wrong
[13:24] <tsdgeos> it's not what the component is for
[13:24] <mterry> Says every widget designer  :)
[13:24] <tsdgeos> this is *not* a widget by the way
[13:25] <tsdgeos> it's a helper
[13:25] <mterry> I know
[13:25] <tsdgeos> if it doesn't do what you want
[13:25] <tsdgeos> don't use it
[13:25] <mterry> Says every API designer  :)
[13:25] <tsdgeos> it's not like you're forced to use it
[13:25] <tsdgeos> that's silly
[13:25] <tsdgeos> you're forced to use a button
[13:25] <tsdgeos> so button has to be flexible
[13:25] <tsdgeos> you're not forced to use this, so it can do its thing
[13:25] <tsdgeos> if it doesn't do what you want, you can still do it
[13:26] <tsdgeos> you're not being excluded
[13:26] <tsdgeos> so yes, this component doesn't do what you want when the OSK is open
[13:26] <tsdgeos> that's what it has been coded to do
[13:26] <tsdgeos> it's not a bug, it's a feature
[13:26] <mterry> Right...  It seems needlessly fragile is all.  But sure, I'm not saying there's a bug in the code right now.  Just trying to be defensive
[13:26] <tsdgeos> it is not needlessly fragile
[13:27] <tsdgeos> doing one thing well it's easier than doing more things we don't need to do
[13:27] <tsdgeos> introduces more bugs
[13:27] <tsdgeos> i need extra code to make a use case we don't need to work
[13:27] <tsdgeos> i agree with you that it needs documentation though
[13:27] <tsdgeos> we can go back to the version that copies the code ;)
[13:28] <mterry> It'd be one line of code after refactoring onVisibleHeightChanged into a function.  But sure
[13:28] <tsdgeos> mterry: it won't
[13:28] <mterry> tsdgeos, I feel like this is a more heated argument than I intended to bring up
[13:29] <tsdgeos> i'm sorry for trying to counterargue your arguments
[13:29] <tsdgeos> :D
[13:30] <mterry> tsdgeos, no that's fine  :)
[13:30] <mterry> tsdgeos, you say it won't be one line of code?  Maybe that's the confusion.  What are you envisioning I'm suggesting?
[13:31] <mterry> (I was thinking move onVisibleHeightChanged logic into a d.doTheThing() method.  And just call d.doTheThing() after setting a new item to watch)
[13:31] <mterry> tsdgeos, ^
[13:32] <tsdgeos> you need to at least split the if into two
[13:32] <tsdgeos> since you have previousVisibleHeight > visibleHeight that won't work if you don't
[13:33] <mterry> tsdgeos, sure... so onVisibleHeightChanged becomes "if (previousHeight > nowHeight) doTheThing(); previous = now;"
[13:34] <mterry> tsdgeos, like, this is a super minor point.  I didn't mean to start a 30min debate about it  :)
[13:34] <tsdgeos> i just wanted to not have a discussion about code i just moved around
[13:34] <mterry> tsdgeos, it's fine if you don't think it's worth the bother.  I just felt I had to explain my side of things and then we got here
[13:35] <mterry> tsdgeos, well I think there's a higher standard for standalone components than code that gets used in one place
[13:35] <tsdgeos> sounded it was the safest solution not to change code we already have and works
[13:35] <cimi> tsdgeos, small bug I noticed in new navigation
[13:35] <cimi> tsdgeos, try searching in music scope where there is no departments
[13:36] <cimi> tsdgeos, then clear the search
[13:36] <cimi> then tap the search again so you see recent searches
[13:36] <tsdgeos> mterry: i can move it to Dash/ instead of Components/ if it makes your "standalone compoennts" worry better?
[13:36] <cimi> we miss the shadow at the bottom of the box
[13:38] <mterry> tsdgeos, no that wouldn't change anything  :)  But like I said, this is fine as is.  I get that it's code you are just moving.  (I don't think that means you absolve all responsibility for that code, but I understand reluctance to change it)
[13:40] <mterry> tsdgeos, like when you make a bug fix and a reviewer asks you to refactor the component :)
[13:41] <mterry> I hate that  :)
[13:42] <tsdgeos> mterry: so want me to add some documentation to the qml file saying what the component does?
[13:43] <mterry> tsdgeos, the answer to that question is always yes, even without a debate as a prompt  ;)  But I don't think it's required here, if existing usage is documentation enough
[13:44] <tsdgeos> well there's no documentation at all
[13:47] <mterry> tsdgeos, just noticed another place where this would be useful -- the authentication dialog to sign into U1 from the dash scope, when you need to give a two-factor code.  No need to change your branch, but just saying, a useful component
[13:47] <tsdgeos> mterry: but that's not in unity8 so can't be used
[13:47] <tsdgeos> sure it's an useful component if done better in the SDK
[13:47] <tsdgeos> as we started the discussion with :D
[13:47] <mterry> tsdgeos, right, that's what I was saying at the start  :)
[13:53] <cimi> tsdgeos, also, when I am in a department and I search, the text is higher
[13:53] <tsdgeos> cimi: what do you mean "the text is higher"?
[13:53] <tsdgeos> in the search bar?
[13:53] <cimi> tsdgeos, yes
[13:53] <cimi> tsdgeos, not vertically aligned
[13:53] <tsdgeos> cimi: that already happens today
[13:54] <cimi> aw ok )
[13:54] <tsdgeos> i'd say
[13:54] <tsdgeos> please double check
[13:54] <tsdgeos> afaik gets fixed when moving to sdk 1.3 for some reason
[13:54] <cimi> tsdgeos, yeah all text is higher now
[13:54] <cimi> seems sdk bug
[13:55] <tsdgeos> Mirv: there?
[13:56] <cimi> tsdgeos, did you see the other bug of the shadow?
[13:56] <tsdgeos> cimi: i am having a look at the 5.5 multimedia thing so don't have the silo installed
[13:56] <tsdgeos> i've copied your text and will check later
[14:01] <Mirv> tsdgeos: barely but yes
[14:02] <Mirv> tsdgeos: FYI I just filed bug #1508945 ie the weather app misbehaves still with 5.5.1 (similar to what it did when I backported certain patches fixing 1470700 to 5.4.1)
[14:02] <Mirv> or maybe appaarmor is coming into the way or something. but other apps don't seem to have network issues.
[14:03] <tsdgeos> Mirv: cool
[14:03] <mterry> tsdgeos, what tool is the //! syntax for?  or is that just stylistic?
[14:03] <tsdgeos> mterry: it's doxygen
[14:03] <mterry> tsdgeos, ah makes sense
[14:03] <tsdgeos> i think
[14:03] <tsdgeos> or maybe qdoc
[14:04] <tsdgeos> one of the two :D
[14:04] <tsdgeos> doxygen afair
[14:04] <Mirv> tsdgeos: all UITK issues start to be resolved. oh and btw I'm away next week (Saviq too fyi), but it's getting reasonably closer to landing to xenial now
[14:04] <tsdgeos> Mirv: :)
[14:04] <tsdgeos> Mirv: the new silo has 5.5.1 but still with the audiorole patches, right?
[14:05] <Mirv> tsdgeos: yes, still with audio role patches
[14:05] <Mirv> tsdgeos: and qtubuntu-camera/media ported to it
[14:05] <tsdgeos> ok, i'm having some issues, will double check what i'm doing wrong
[14:05] <Mirv> tsdgeos: so Unity 8 would appreciate a patch so that people would not need to hand edit qml files (as guided at https://wiki.ubuntu.com/Touch/QtTesting though)
[14:05] <tsdgeos> yeah
[14:05] <tsdgeos> on it
[14:06] <Mirv> videos, camera work too again as of today. I've been filling some holes of rebuilds needed today after I copied the 5.5.1 there.
[14:06] <Mirv> now it's pretty complete aside from qtcreator still building for the desktop.
[14:09] <tsdgeos> i'm getting
[14:09] <tsdgeos> file:///home/phablet/main.qml:6 "Audio.audioRole" is not available in QtMultimedia 5.5.
[14:09] <tsdgeos> wonder what is wrong?¿
[14:10]  * tsdgeos starts all over
[14:10] <Mirv> tsdgeos: the revision: 1; I asked about in the bug report maybe?
[14:11] <tsdgeos> mzanetti: Saviq: did you guys actually test https://code.launchpad.net/~mzanetti/ubuntu-clock-app/detect-qtmm-version/+merge/275177 ?
[14:11] <tsdgeos> with our 5.5 packages?
[14:11] <Mirv> porting seemed alright for c++ code but I didn't know what to do on the qml side
[14:11] <Saviq> tsdgeos, I di'in, since I disapproved it ;)
[14:11] <tsdgeos> Mirv: tbh i'm not totally sure what that revision does
[14:12] <tsdgeos> Saviq: k
[14:13] <Saviq> tsdgeos, I think you can have multiple implementations of the same method, of different revisions, exported in different versions
[14:13] <Saviq> or something like that
[14:14] <Saviq> Mirv, ↑
[14:14] <Saviq> mzanetti, can you comment what you found on bug #1508830 please
[14:15] <Saviq> tsdgeos, Mirv, http://doc.qt.io/qt-5/qtqml-cppintegration-definetypes.html#type-revisions-and-versions
[14:15] <tsdgeos> does anyone know how to make bluez dist-upgrade not stall forever?
[14:16] <Mirv> Saviq: yeah, I just douldn't figure out how to actually use it. and I was on that doc page :)
[14:17] <Saviq> Mirv, what you do is have implementations marked by Q_REVISION(), then, as you qmlRegisterType, you supply that for version foo, revision bar should be exported, for version baz, revision blah
[14:17] <Saviq> Mirv, this way from a single component you can export multiple versions of an import
[14:17] <tsdgeos> Mirv: i'd say we miss part of the patch
[14:17] <tsdgeos> let me check
[14:17] <Mirv> Saviq: yeah, thre's no qmlRegisterType in the patch (http://anonscm.debian.org/cgit/pkg-kde/qt/qtmultimedia.git/tree/debian/patches/Add-audio-role-API-to-QMediaPlayer.patch?h=ubuntu)
[14:17] <Mirv> tsdgeos: it's the whole commit at least
[14:18] <Saviq> Mirv, it could be that the 5.5 import is marked for revision(1) earlier
[14:18] <tsdgeos> or maybe the patch is wrong upstream too
[14:18] <Saviq> i.e. qmlRegisterType for 5.5 was already there, with revision 1
[14:18] <Saviq> or well, that
[14:18] <Saviq> but then, because it defaults to 0
[14:19] <Mirv> it's possible upstream didn't test the qml part when they merged it to 5.6..
[14:19] <Saviq> if there isn't a 5.5 import registered with revision 1, then audioRole shouldn't be available
[14:19] <Saviq> but .qmltypes says otherwise
[14:20] <tsdgeos> yeah they have
[14:20] <tsdgeos>         qmlRegisterType<QDeclarativeAudio, 1>(uri, 5, 6, "Audio");
[14:20] <Saviq> but for 5.6
[14:20] <Saviq> Mirv, what does `qmlplugindump QtMultimedia 5.5` say?
[14:20] <tsdgeos> which is the correct version the upstream patch is being added
[14:20] <Saviq> so 5.5 exports a 5.6 version
[14:21] <Saviq> weird, but not necessarily wrong
[14:21] <tsdgeos> no we're doing it ourslves
[14:21] <Saviq> just means to use audioRole we actually need to import 5.6
[14:21] <tsdgeos> not upstream, no?
[14:21] <tsdgeos> no means our backport is incomplete and we need a
[14:21] <Saviq> oh right, *we* backport to 5.5
[14:21] <tsdgeos> qmlRegisterType<QDeclarativeAudio, 1>(uri, 5, 5, "Audio");
[14:21] <tsdgeos> and the mess continues :D
[14:21] <Saviq> yay
[14:22] <Saviq> tsdgeos, we could leave it as 5.6
[14:22] <tsdgeos> but i'd say that should be good
[14:22] <tsdgeos> or that
[14:22] <Saviq> tsdgeos, noting that the only feature available there over 5.5
[14:22] <Saviq> is audioRole
[14:22] <Saviq> I'd go for that
[14:22] <tsdgeos> it's like we partly have 5.6
[14:22] <Saviq> then we don't need to migrate to 5.6 proper
[14:22] <Saviq> exactly
[14:23] <Saviq> assuming 5.6 is backwards compatible :)
[14:23] <tsdgeos> actually we have it already :D
[14:23] <tsdgeos> boo me
[14:23] <Saviq> yes, we do
[14:23] <tsdgeos> so with the import for 5.6 it should work
[14:23] <tsdgeos> let's see
[14:23] <Mirv> tsdgeos: ok so there's another MP in addition to https://codereview.qt-project.org/#/c/122658/ ?
[14:24] <Mirv> and we miss that
[14:24] <tsdgeos> file:///home/phablet/main.qml:3 module "QtMultimedia" version 5.6 is not installed
[14:25] <Mirv> tsdgeos: I've sed 's/5.5/5.6/ in that ^ when backporting
[14:26] <tsdgeos> we still have
[14:26] <tsdgeos>         // 5.6 types
[14:26] <tsdgeos>         qmlRegisterRevision<QDeclarativeAudio, 1>(uri, 5, 6);
[14:26] <tsdgeos>         qmlRegisterType<QDeclarativePlaylist>(uri, 5, 6, "Playlist");
[14:26] <tsdgeos>         qmlRegisterType<QDeclarativePlaylistItem>(uri, 5, 6, "PlaylistItem");
[14:26] <tsdgeos> in the code
[14:26] <tsdgeos> wait tha error i got was with the wrong qt installed :D
[14:26] <tsdgeos> i'm confusing myself now
[14:27] <tsdgeos> give me 30 min to regather my thoughts
[14:27] <Mirv> tsdgeos: playlist is different backport/patch
[14:27] <tsdgeos> i know
[14:27] <tsdgeos> still says "audio" in there
[14:28] <mzanetti> Saviq, I didn't really find much... took like 30 screenshots and can't reproduce the hanging
[14:29] <mzanetti> also tried the scope refreshing... no avail
[14:29] <mzanetti> reading jibel's log output suggests media hub is not responding on dbus and we try to play the screenshot camera sound
[14:29] <mzanetti> ok, I guess that qualifies...
[14:29] <mzanetti> will add this
[14:30] <Saviq> mzanetti, ah I thought you actually saw the media issue
[14:39] <mzanetti> no, sorry
[14:40] <Saviq> no need to be sorry :)
[14:41] <mzanetti> new inputinfo api is great
[14:41] <mzanetti> could drop all the wrapper stuff etc... also mocking was super easy
[14:41] <mzanetti> ljp, ^
[14:52] <Saviq> nice
[15:07] <dandrader> mzanetti, so the "reveal sensitivity"  of the edge push to showing the launcher should be configurable. what's the prefered way to expose it? gconf?
[15:08] <tsdgeos> Mirv__: https://code.launchpad.net/~aacid/unity8/new_and_old_audio_role/+merge/275365 should be it
[15:08] <tsdgeos> need to triple check
[15:08] <tsdgeos> but looks good to me
[15:08] <tsdgeos> arg it has a stray commit
[15:10] <tsdgeos> better
[15:21] <mzanetti> tsdgeos, our packages that have the feature backported to 5.5, will they also bump the version to 5.6, even if it's 5.5?
[15:22] <tsdgeos> mzanetti: yep
[15:22] <mzanetti> ok, that's weird
[15:22] <tsdgeos> or at least that's what the current packages have
[15:22] <mzanetti> are they backporting *all* 5.6 changes?
[15:22] <tsdgeos> don't think so
[15:22] <tsdgeos> but if we do use 5.5
[15:22] <mzanetti> why bumping the version then?
[15:22] <tsdgeos> then it'll be even more weird
[15:22] <tsdgeos> because we'll need revision 2 for 5.6
[15:22] <tsdgeos> and then all is evil
[15:23] <mzanetti> not following...
[15:24] <tsdgeos> we can say 5.5 supports Audio Revision 1
[15:24] <tsdgeos> or
[15:24] <tsdgeos> 5.6 supports Audio Revision 1
[15:24] <tsdgeos> upstream is the second
[15:24] <tsdgeos> if we do the first, we're also lying
[15:25] <tsdgeos> i actually think it makes more sense to say we've backported parts of 5.6
[15:25] <tsdgeos> and act accordingly as 5.6 will act
[15:25] <tsdgeos> so we need to change less things later
[15:26] <tsdgeos> it's all "wrong" dependening how you want to think it
[15:27] <tsdgeos> we don't support all 5.6
[15:27] <tsdgeos> but 5.5 doesn't have audioRole either
[15:27] <tsdgeos> but at least the core is more "correct upstream" if we say 5.6
[15:27] <tsdgeos> in the sense it'll work on other non ubuntu-patched Qts
[15:27] <mzanetti> fair enough...
[15:28] <mzanetti> well, if other apps check for 5.6 and end up with our patched 5.5 version there's no guarantee it'll work
[15:28] <Mirv> tsdgeos: so should I revert the http://anonscm.debian.org/cgit/pkg-kde/qt/qtmultimedia.git/commit/?h=ubuntu&id=8b95cbe6b78041047ac0a993b8986e6e836c719c which is currently in the package?
[15:29] <tsdgeos> Mirv: i'd say so since it's misleading
[15:29] <Mirv> ok, rebuilding qtmultimedia then
[15:29] <tsdgeos> mzanetti: sure not for other code
[15:29] <tsdgeos> but for ours it will
[15:29] <tsdgeos> at still the lib is called 5.5.1
[15:29] <mzanetti> tsdgeos, in any case, we're just going to drop the audioRole usage in the clock app too
[15:30] <tsdgeos> even it partly supports things of 5.6
[15:30] <mzanetti> right... got it...
[15:30] <tsdgeos> mzanetti: i agree it's "bad" both ways
[15:30] <mzanetti> yeah...
[15:30] <mzanetti> well, distro-patching :)
[15:30] <tsdgeos> but i'd say that calling 5.6 is the less bad of them
[15:34] <Mirv> tsdgeos: ok qtmultimedia building, unity8 building at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012/+packages
[15:34] <Mirv> I really should stop now, bad way to start vacation totally exhausted :) there's tomorrow still.
[15:35] <Mirv> see you tomorrow
[15:36] <mhall119> bregma: any new puritine packages I can try out?
[15:36] <bregma> mhall119, nope, all the fighing is happening on other fronts right now
[15:38] <mhall119> ok, let me know when there is and I'll give it a try
[15:39] <tsdgeos> cimi: yes, can repro the shadow thing
[15:39] <cimi> tsdgeos, good
[15:45] <tsdgeos> cimi: fix pushed
[15:46] <tsdgeos> greyback: i added the comment you wanted, https://code.launchpad.net/~aacid/unity8/fix_cropped_image_binding_loop top approve?
[15:47] <greyback> done
[15:50] <tsdgeos> greyback: tx
[15:51] <tsdgeos> larsu: top approve https://code.launchpad.net/~aacid/qmenumodel/clazy_run/+merge/272788 ?
[16:56] <darklight_> the link http://cdimage.ubuntu.com/ubuntu-desktop-next/daily-live/ is broken
[17:41] <kgunn> bregma: ^ see the darklight ping, so do we need to remove something there ?
[17:42] <bregma> kgunn, it looks like darklight_ has a bookmark to something that no longer exists
[17:43] <kgunn> bregma: mmm, will go back to my tinkering