[00:00] <ali1234> currently appindicators are failing to add menu items correctly but removing works
[00:00] <ali1234> see bug 1203888
[00:01] <tedg> ali1234, I don't remember.  Does adding that on those fix it?
[00:03] <ali1234> well adding is what is broken, so i suspect removing the check like with remove would fix it... just about to try it
[01:06] <ali1234> well, this is certainly related - changing "child-added" to "something-else" causes the error message to change as expected. but changing it to "insert" to match the GTK3 case causes a segfault
[01:45] <ali1234> tedg: so it turns out the fix is to remove all the GTK3 tests from that file - they all apply only to the item insert cb
[01:46] <ali1234> and specifically the other two modify the argument list to the cb function - and calling it with the wrong set of arguments obviously caused the segfault
[08:47] <tsdgeos> mhr3: can you comment on https://code.launchpad.net/~aacid/unity8/lvwph_bad_header_position_1240118/+merge/193200 that it actually fixes the problem for you?
[08:52] <mhr3> tsdgeos, done
[08:54] <tsdgeos> tx
[08:56] <tsdgeos> mzanetti: so no landing of the packages we needed?
[08:57] <mzanetti> tsdgeos: hmm... seems so :/
[08:58] <tsdgeos> :(
[08:58] <tsdgeos> keep piling up! :D
[08:58] <tsdgeos> it's almost my full screen height of reviews now :D
[09:00] <tsdgeos> mzanetti: can you quick look at https://code.launchpad.net/~cimi/unity8/fix-1231731/+merge/191414 ? can i top approve?
[09:01] <mzanetti> tsdgeos: done
[09:01] <tsdgeos> tx
[09:02] <mzanetti> tsdgeos: a few days ago you asked me about the searchhistorymodel
[09:02] <tsdgeos> yep
[09:02] <mzanetti> tsdgeos: I see in nic's branch that there is one in Shell.qml
[09:02] <tsdgeos> yep
[09:03] <mzanetti> which doesn't seem to be used at all
[09:03] <tsdgeos> it's just unused as stands now
[09:03] <tsdgeos> yep
[09:03] <mzanetti> ok.
[09:03] <mzanetti> I'll note that down
[09:03] <tsdgeos> and every ScopeView ahs anthoer
[09:03] <tsdgeos> that is also unused as of now
[09:03] <mzanetti> yeah, now there is one in Dash.qml with makes it shared among all scopes
[09:03] <tsdgeos> just the ones in PageHeader are being used now
[09:03] <mzanetti> oh, another one?
[09:03] <mzanetti> yeah, the one in PageHeader is gone now
[09:04] <tsdgeos> ok
[09:04] <tsdgeos> yet another conflict for my tabbar branch :D
[09:04] <tsdgeos> need multi-rebasing :D
[09:04] <tsdgeos> or just wait some decent time for all the stuff to be merged in
[09:04] <mzanetti> yeah... I guess we should start rebasing stuff and create a chain of prerequisities
[09:05] <mzanetti> although that has potential to explode too
[09:07] <tsdgeos> yeah
[09:08] <tsdgeos> let's just let it explode organically
[09:09] <tsdgeos> oh man the new notify-osd killer code is annoying
[09:09] <tsdgeos> hmmm
[09:09] <tsdgeos> which actually means it's been released?
[09:10] <tsdgeos> the shell now kills my notify-osd
[09:10] <tsdgeos> and obviously it doesn't come back after killing the shell
[09:10] <tsdgeos> so i get some weird old kde notifications floating around :D
[09:10] <tsdgeos> mzanetti: was notify-osd the only thing we needed?
[09:11] <mzanetti> MacSlow: ^
[09:12] <mzanetti> I think yes
[09:12] <mzanetti> tsdgeos: well, its 2 of them
[09:12] <tsdgeos> so maybe we can trigger a single branch manually or something to see how it goes?
[09:12] <MacSlow> mzanetti, tsdgeos: that's what was supposed to happen
[09:12] <mzanetti> one moment
[09:13] <tsdgeos> MacSlow: i know, it's only annoying as a desktop user :D
[09:13] <MacSlow> tsdgeos, probably... :)
[09:14] <MacSlow> tsdgeos, but as I'm on unity (on the desktop) as soon as I quit my unity8-shell the next notification will trigger starting system-wide notify-osd again
[09:14] <MacSlow> tsdgeos, I assume you're running KDE
[09:15] <tsdgeos> MacSlow: nope at work-work time
[09:15] <tsdgeos> i'm running unity+apps
[09:15] <tsdgeos> most of the apps kdelibs-based
[09:15] <tsdgeos> and notify-osd doesn't restart here unless i manually start it
[09:20] <nic-doffay> mzanetti, ping
[09:20] <mzanetti> nic-doffay: hey
[09:20] <MacSlow> tsdgeos, I assume notify-osd doesn't get retriggered because of the KDE-based apps not using libnotify/protocol
[09:20] <tsdgeos> of course :D
[09:21] <tsdgeos> they just use the com.foo.notification  bla daemon if it's there
[09:21] <tsdgeos> and i guess it isn't
[09:21] <MacSlow> tsdgeos, still if it (notify-osd) runs, it's able to consume notifications triggered by KDE-apps?!
[09:21] <tsdgeos> MacSlow: sure
[09:22] <MacSlow> tsdgeos, but if you see knotify rendered notifications, that means you've some special service-file explicitly triggering that daemon instead of notify-osd?
[09:23] <MacSlow> tsdgeos, I'm just trying to reproduce it on my desktop here... pulling updates atm
[09:23] <tsdgeos> MacSlow: yeah, kdelibs may lift up it's own daemon for org.freedesktop.Notifications if it doesn't find anything there
[09:24] <tsdgeos> does anyone have a clue how to know which app is serving org.freedesktop.Notifications ?
[09:25] <tsdgeos> anyway not something to spend time on
[09:25] <MacSlow> tsdgeos, hm... but should not /usr/share/dbus-1/services/org.freedesktop.Notifications.service be controlling what daemon gets started?
[09:25] <tsdgeos> it's a very -dev specific usecase
[09:25] <tsdgeos> MacSlow: no clue :D
[09:26] <MacSlow> tsdgeos, that's how it works on my system... although I'm not familiar with the KDE-side of this... so no idea how that might inject yet another notification-daemon
[09:26] <MacSlow> tsdgeos, sorry
[09:26] <tsdgeos> as said
[09:27] <nic-doffay> mzanetti, still wondering how to make the search history persist between unity8 restarts. Any ideas?
[09:27] <MacSlow> tsdgeos, sure
[09:27] <tsdgeos> no need to spent time on this
[09:27] <tsdgeos> was just saying
[09:27] <mzanetti> nic-doffay: hmm... let me read the SearchHistoryModel code
[09:28] <tsdgeos> so
[09:28] <tsdgeos> back to test writing land
[09:28] <mzanetti> nic-doffay: 2 options: either you check out the LocalStorage qml plugin (I've never used it before) or you create a small QML plugin yourself which dumps stuff somewhere on disk
[09:28] <mzanetti> tsdgeos: any opinion? ^
[09:29] <tsdgeos> what would you guys go for a test that wants to check we can horizontally swipe the dash if it's scrolling verticallly? ultra scared of "not going to get this to happen at the right time" tbh
[09:30] <tsdgeos> mzanetti: i'd go for the "save it ourselves to disc"
[09:30] <mzanetti> tsdgeos: can we use 2 fingers?
[09:30] <mzanetti> +1 on the "our plugin"
[09:30] <tsdgeos> localstorage seems to much database-y for this usecase
[09:30] <tsdgeos> mzanetti: what do you mean 2 fingers?
[09:30] <mzanetti> nic-doffay: I can help you getting started with the QML plugin if you've never done that before
[09:30] <mzanetti> tsdgeos: let me test something
[09:31] <mzanetti> tsdgeos: is that fix already released?
[09:31] <tsdgeos> mzanetti: yep
[09:31] <tsdgeos> https://code.launchpad.net/~aacid/unity8/dash_disable_hswipe_on_vswipe/+merge/190576
[09:31] <mzanetti> hmm.. ok.
[09:31] <tsdgeos> just wanted to clear that list of bugs without test you created the other day
[09:31] <mzanetti> tsdgeos: well, in the launcher tests I flick it up/down
[09:31] <mzanetti> tsdgeos: if the list is long enough that lasts for 2 secs
[09:31] <tsdgeos> ok
[09:31] <mzanetti> which really should be enough for trying to swipe horizontally
[09:32] <tsdgeos> i guess i can try to have a long list
[09:32] <tsdgeos> let's go for a qml test then :D
[09:32] <mzanetti> definitely
[09:32] <nic-doffay> mzanetti, yeah if you don't mind.
[09:33] <mzanetti> nic-doffay: ok. so. I'd say you dump it into plugins/Unity/
[09:33] <mzanetti> nic-doffay: create a class, inheriting QObject called SearchHistoryModel
[09:34] <mzanetti> hook it up in plugin.cpp just like the others
[09:34] <mzanetti> and give it a function addQuery(const QString &query)
[09:35] <mzanetti> then you should be able to just drop Components/SearchHistoryModel.qml and wherever Unity 0.1 is imported it should just use the new cpp SearchHistoryModel instead
[09:35] <mzanetti> in there you can then easily write/read a file
[09:35] <tsdgeos> mzanetti: wouldn't it be easier to write only the dumper, not a whole model?
[09:35] <tsdgeos> otherwise it'll need to be a QAbstractItemModel and all that, no?
[09:36] <mzanetti> tsdgeos: yeah... was going to say. instead of QObject, make it QAbstractListModel
[09:36] <mzanetti> tsdgeos: hmm... you think we should have only a dumper?
[09:36] <mzanetti> tsdgeos: I guess this well be quite useful in the future, when we might want to filter stuff etc
[09:36] <tsdgeos> mzanetti: i think it'd be easier, i guess it depends if/when we want to sync the file to disk
[09:36] <mzanetti> also we need something like clear() and whatnot.
[09:37] <tsdgeos> mzanetti: ok, if you see us using more modellike stuff
[09:37] <mzanetti> I think implementing count() and data()  would be easier in the long run than keeping a qml ListModel and some file on disk in sync
[09:37] <tsdgeos> mzanetti: may as well use qstringlistmodel
[09:38] <mzanetti> right
[09:38] <tsdgeos> if all we want is a list of strings
[09:38] <mzanetti> nic-doffay: QStringListModel
[09:38] <tsdgeos> though QStringListModel is a bit silly doesn't have an insert
[09:38] <tsdgeos> so don't know :D
[09:38]  * tsdgeos stops suggesting/unsuggesting things
[09:38] <mzanetti> yeah, hence the addQuery() which then keeps it api compatible to the existing one
[09:39] <mzanetti> nic-doffay: is that good enough for a start?
[09:42] <nic-doffay> mzanetti, yeah that's cool.
[09:42] <nic-doffay> cheers
[09:44] <nic-doffay> mzanetti, so inherit from QStringListModel which will replace the current QML class?
[09:44] <mzanetti> nic-doffay: yep. class SearchHistoryModel: public QStringListModel
[09:45] <mzanetti> after you added "addQuery()" it should just work automagically to replace the qml one
[09:45] <nic-doffay> mzanetti, great. I wanted the break from QML too tbh!
[09:45] <mzanetti> cool
[10:16] <mzanetti> tsdgeos: fyi: notify-osd has been released. but I just realize that we probably need to upgrade the jenkins machines, otherwise the old one is still running
[10:16] <mzanetti> and I've no clue about the otto jenkins machines
[10:16] <tsdgeos> mzanetti: hmmm
[10:16] <mzanetti> but once fginther shows up I think we can have that
[10:16] <tsdgeos> ok
[10:17] <tsdgeos> i thought stuff was upgraded on each run?
[10:17] <tsdgeos> or only the stuff we depend on
[10:17] <tsdgeos> and not the base system?
[10:17] <mzanetti> tsdgeos: I don't think we upgrade the base system every time. would be a huge waste of time
[10:18] <tsdgeos> but a way we work against the current status of system libs :D
[10:18] <tsdgeos> but i can see why we don't do it
[10:18] <tsdgeos> anyway, good that we're one step closer!
[10:34] <Cimi> you guys have bugs for me?
[10:43] <tsdgeos> Cimi: https://code.launchpad.net/~aacid/unity8/no_hswipe_if_vswipe_test/+merge/193401
[10:46] <Cimi> tsdgeos, and?
[10:46] <tsdgeos> review?
[10:46] <tsdgeos> :D
[10:46] <Cimi> tsdgeos, why this?
[10:46] <tsdgeos> why not?
[10:48] <tsdgeos> anyone knows how to know which "3 people" are affected by a bug when launchpad says "3 people affected by this bug"
[10:48] <tsdgeos> ?
[10:50]  * tsdgeos likes c++ chained constructors
[10:50] <tsdgeos> hurray for them
[10:50] <tsdgeos> \o/
[10:55] <tsdgeos> hmmm
[10:55] <tsdgeos> https://bugs.launchpad.net/unity8/+bug/1229652 is not *our* bug, no?
[10:55] <tsdgeos> we don't have those strings anywhere
[10:55] <tsdgeos> mhr3: ? ↑↑ ?
[10:59] <mhr3> tsdgeos, right
[10:59] <tsdgeos> mhr3: which projects do i reassign this to
[10:59] <tsdgeos> ?
[10:59] <mhr3> already done
[10:59] <tsdgeos> tx
[11:00] <tsdgeos> Cimi: if you're totally bored, can you try to reproduce the crash mentioned in https://bugs.launchpad.net/unity8/+bug/1240408 ?
[11:08] <Cimi> tsdgeos, nt that bored :D
[11:14] <tsdgeos> Cimi: ok, we ave around 155 bugs
[11:15] <tsdgeos> i'm sure you can find something, no?
[11:15] <Cimi> tsdgeos, not much on unassigned ones
[11:15] <Cimi> tsdgeos, I picked up a dozen already, fixed all
[11:15] <Cimi> tsdgeos, we need more bugs :)
[11:16] <Cimi> http://goo.gl/VDU0V4
[11:17] <tsdgeos> Cimi: that's the unassigned ones?
[11:17] <Cimi> y
[11:17] <Cimi> I'm looking if there's something for me
[11:18] <Cimi> might do this https://bugs.launchpad.net/unity8/+bug/1236280
[11:19] <Cimi> but probably requires a snapshot of the dash as a normal app?
[11:19] <tsdgeos> greyback: ↑↑↑
[11:21] <greyback> Cimi: yes it would. That can be done, but I believe I designed unity-mir to not make that easy
[11:23] <Cimi> preserving the scroll position is complicated also
[11:23] <Cimi> because I put that when you left swipe
[11:23] <Cimi> it switches to app scope
[11:23] <Cimi> so if the user starts a left swipe, cancels
[11:23] <Cimi> does a right swipe
[11:23] <Cimi> the dash will lose the original position
[11:25] <greyback> Cimi: yeah. that bug will require lots of changes everywhere
[11:26] <greyback> Cimi: since I'll be refactoring much of that window management code - and the right-edge switch-application animation will be changed, I don't think now is the good time to take that one on
[11:26] <Cimi> greyback, unless we store contentX of dashContentList and contentY of the dashContentList.currentItem
[11:27] <Cimi> greyback, basically when dash is no longer in focus, we save those
[11:28] <Cimi> greyback, when we go back to the dash, we reapply those
[11:29] <greyback> Cimi: hold on. You'd be taking a snapshot of the shell's surface and adding it to the list of application surfaces to switch through
[11:29] <Cimi> greyback, yes
[11:29] <greyback> Cimi: I don't see why you're changing contentX
[11:29] <Cimi> greyback, but as said, when you left swipe to reveal the dash
[11:30] <Cimi> greyback, we have to switch to app lens, contentY = 0
[11:30] <Cimi> greyback, by design
[11:30] <Cimi> greyback, so if the user is using camera
[11:30] <Cimi> greyback, starts swiping left
[11:31] <Cimi> greyback, (note that now the dash should be on the app lens)
[11:31] <Cimi> greyback, then changes his mind and remains on the camera app
[11:31] <Cimi> then after a while he right swipe and choose the dash
[11:31] <Cimi> greyback, the dash will be on the app lens because the previous left swipe changed that
[11:33] <Cimi> greyback, problem is, left swipe is an animation thus when the finger is a little bit after the launcher you should already start seeing the app lens appearing
[11:34] <Cimi> greyback, relevant code here https://code.launchpad.net/~cimi/unity8/fix-1231996/+merge/192372
[11:34] <Cimi> and bug https://bugs.launchpad.net/unity8/+bug/1231996
[11:35] <Cimi> only way I can see having both scenarios working at the same time is storing the position (contentX and Y) of the dash when you take its snapshot
[11:36] <greyback> Cimi: (aside: for the first MR, that commit message is not clear. It just says steps to repro a problem, not saying what the problem actually is, nor giving the solution the MR performs)
[11:37] <Cimi> greyback, no it says id
[11:37] <Cimi> *it
[11:37] <Cimi> greyback, it switches to app scope when dash swipe *is taking place*
[11:37] <greyback> Cimi: ah I get it, sorry
[11:38] <Cimi> np
[11:39] <greyback> Cimi: so, snapshots of shell surface are tricky. You know that when an application is on screen, the shell surface is always on top of it, but defines a big transparent rectangle that allows the application to be visible
[11:40] <Cimi> yeah got that
[11:40] <Cimi> so yeah it's difficult
[11:40] <greyback> Cimi: so the only time we can grab snapshot of whole dash, is when dash fully on screen.
[11:40] <Cimi> greyback, we should take the snapshot only when the shell is in focus
[11:41] <Cimi> greyback, snapshots of dash are taken only when no app is above it
[11:41] <greyback> Cimi: yep. Taking your problem case, and assuming snapshot of shell Home lens taken and available
[11:41] <Cimi> if you switch to an app, no more snapshots are taken
[11:41] <greyback> Cimi: in camera app, start a left swipe. You see Dash change to Apps lens. Then cancel that left swipe, to return to camera.
[11:42] <greyback> Cimi: in that case, dash is on apps lens. But our snapshot is of home lens.
[11:42] <Cimi> greyback, yes
[11:42] <greyback> and there's no way to grab snapshot of apps lens reliably in that case
[11:42] <Cimi> greyback, so if we stored contentX and Y
[11:42] <Cimi> greyback, when we right swipe we simply restore contentX and Y
[11:43] <greyback> it doesn't matter. User expects to return to apps lens. We cannot show them the home lens snapshot
[11:43] <Cimi> greyback, ok then, no problem exist
[11:43] <Cimi> greyback, problem is the snapshot
[11:43] <Cimi> I see this issue now
[11:43] <Cimi> greyback, we have hard time taking the screeenshot
[11:43] <greyback> Cimi: yep. the snapshot thing is a hack, and this exposes it's faults
[11:43] <greyback> its
[11:44] <Cimi> I thought we wanted to go back to home lens
[11:44] <greyback> so the work to use live surfaces, not screenshots, should fix this. But we're not there yet
[11:46] <mzanetti> greyback: hey
[11:46] <greyback> mzanetti: yo
[11:46] <mzanetti> greyback: veebers would need this to be landed asap: https://code.launchpad.net/~gerboland/unity-mir/crash-fix-on-IFA-removal/+merge/192352
[11:46] <mzanetti> greyback: it looks ok to me, but I don't feel confident enough with the surrounding code to just approve it
[11:47] <greyback> tsdgeos could you have a look, you know that code better
[11:47] <greyback> mzanetti: ^^
[11:48] <tsdgeos> sure
[11:48] <greyback> thanks
[11:51] <tsdgeos> greyback: why aren't you deleting the inputareas anymore?
[11:51] <Cimi> mzanetti, auto landing dance today?
[11:51] <Cimi> how many dancers will fall on the floor? :)
[11:51] <greyback> tsdgeos: I never was. The InputAreas are owned by the QML engine, I let it delete
[11:51] <mzanetti> Cimi: stuff is released. when fginther shows up we can hopefully upgrade the jenkins machines and are good to go
[11:52] <tsdgeos> greyback: oh right, it's commted...
[11:52] <mzanetti> Cimi: can you reproduce this? https://bugs.launchpad.net/unity8/+bug/1240408
[11:52] <Cimi> mzanetti, phone is dead now
[11:52] <Cimi> mzanetti, will try after it charges
[11:53] <mzanetti> ok
[11:54] <tsdgeos> greyback: code looks good, want me tro try it actually fixes the crash or has someone actually done that already?
[11:54] <tsdgeos> mzanetti: ↑ ?
[11:54] <mzanetti> Cimi: there is an issue with the UbuntuShape in the launcher. if you look very closely, the image size doesn't match with the shape's size. I haven't had the time to dig deeper why. if you want you can have a look at that too
[11:54] <mzanetti> tsdgeos: I haven't
[11:54] <Cimi> mzanetti, I know that
[11:54] <Cimi> mzanetti, designers are in oakland
[11:54] <greyback> tsdgeos: the bug report gives step by step instructions. Woudl do no harm to check
[11:54] <greyback> tsdgeos: sorry, the bug description
[11:55] <mzanetti> Cimi: not sure why designers would be needed there
[11:55] <tsdgeos> greyback: i know, i checked it crashes
[11:55] <Cimi> mzanetti, fix the asset?
[11:55] <tsdgeos> greyback: was asking if someone had checked it did not crash with the patch
[11:55] <tsdgeos> greyback: since noone has, i will
[11:55] <mzanetti> Cimi: there's no asset
[11:55] <Cimi> mzanetti, but I'll assign myself
[11:55] <Cimi> mzanetti, ok
[11:55] <Cimi> mzanetti, there was
[11:55] <mzanetti> Cimi: there is a branch which removes the white glow
[11:55] <mzanetti> use that one
[11:55] <greyback> tsdgeos: well I did, but I'm the author :)
[11:56] <tsdgeos> greyback: sure
[11:56] <Cimi> mzanetti, https://bugs.launchpad.net/unity8/+bug/1223795 ?
[11:56] <mzanetti> Cimi: https://code.launchpad.net/~mzanetti/unity8/launcher-small-tweaks/+merge/191380
[11:56] <mzanetti> Cimi: this one drops the highlight glow as jouni didn't want it at all
[11:56] <mzanetti> Cimi: still the shape doesn't really fit with the icon. no clue why yet
[11:56] <Cimi> mzanetti, ok it's a new bug
[11:57] <Cimi> mzanetti, will look into it
[11:57] <mzanetti> Cimi: btw.. feel free to review/approve that branch too
[11:58] <Cimi> mzanetti, https://bugs.launchpad.net/unity8/+bug/1223795
[11:59] <Cimi> #fail
[11:59] <mzanetti> Cimi: yeah... I'm afraid the UbuntuShape doesn't do it correctly.
[11:59] <Cimi> mzanetti, https://bugs.launchpad.net/unity8/+bug/1246688
[12:00] <mzanetti> yeah... I guess it's sort of the same as the other
[12:11] <tsdgeos> greyback: mzanetti: approved
[12:11] <mzanetti> tsdgeos: thanks
[12:11] <mzanetti> veebers: ^
[12:11] <greyback> thanks!
[12:25] <greyback> tsdgeos: ok, so built 5.2 in chroot, and all unity8 dependencies. It starts, but crashes here: http://pastebin.ubuntu.com/6335431/
[12:26] <greyback> just find it hard to believe launcherbackend doing something funny, that only 5.2 shows
[12:28] <tsdgeos> greyback: it's not a crash
[12:28] <tsdgeos> it's an assert
[12:28] <tsdgeos> QDBusArgument: read from a write-only object
[12:28] <greyback> sorry, yes
[12:28] <greyback> oh, probably fails as dbus not working inside the chroot
[12:29] <tsdgeos> hmmm
[12:30] <tsdgeos> greyback: i'd say something like that yeah
[12:30] <tsdgeos> QVariant variant = m_accounts->getUserProperty(m_user, "com.canonical.unity.AccountsService", "launcher-items");
[12:30] <tsdgeos> probably ends up with a "null" variant
[12:30] <tsdgeos> that with variant.value<QDBusArgument>()
[12:30] <tsdgeos> returns a "null" QDBusArgument
[12:30] <tsdgeos> and then we try to read from it
[12:30] <greyback> agreed
[12:30] <tsdgeos> and qt is unhappy
[12:31] <tsdgeos> still it's weird that is crashing instead of just saying "null"
[12:31] <tsdgeos> maybe crashes because you're on debug mode?
[12:33] <greyback> no idea
[12:33] <nic-doffay> mzanetti, Unable to assign SearchHistoryModel to QQuickListModel from QML.
[12:34] <nic-doffay> ever seen this? I can't find any info on it.
[12:34] <mzanetti> huh?
[12:34] <mzanetti> ah right
[12:34]  * mzanetti confused QQuickListModel with the launchers QuickListModel
[12:34] <mzanetti> nic-doffay: you forgot to qmlRegisterType it
[12:35] <nic-doffay> mzanetti, I def did.
[12:35] <mzanetti> did forget it or you did register it?
[12:35] <nic-doffay> mzanetti, here's the line I added: qmlRegisterType<SearchHistoryModel>(uri, 0, 1, "SearchHistoryModel");
[12:35] <mzanetti> that does look ok
[12:36] <mzanetti> nic-doffay: ah sure. unfortunately QStringListModel isn't a QQuickListModel
[12:36] <nic-doffay> mzanetti, where does QQuickListModel come into play though?
[12:37] <mzanetti> nic-doffay: I assume you didn't delete Components/SearchListModel.qml. And wherever you import Components before importing Unity it'll pick that one up which is in fact a QQuickListModel
[12:38] <nic-doffay> mzanetti, I deleted it.
[12:38] <greyback> gah qt docs URLs changed /again/
[12:39] <mzanetti> nic-doffay: still not working?
[12:39] <nic-doffay> mzanetti, well I deleted it from the start.
[12:39] <mzanetti> nic-doffay: I'd need to see code then
[12:39] <nic-doffay> mzanetti, let me go with a fresh build quickly
[12:48] <tsdgeos> greyback: yep
[12:48] <tsdgeos> #ifdef QT_DEBUG
[12:48] <tsdgeos>     qFatal("QDBusArgument: read from a write-only object");
[12:48] <tsdgeos> #else
[12:48] <tsdgeos>     qWarning("QDBusArgument: read from a write-only object");
[12:48] <tsdgeos> #endif
[12:48] <greyback> tsdgeos: aha
[12:49] <tsdgeos> greyback: that's pretty common in qt
[12:49] <tsdgeos> the debug mode is more crashy
[12:49] <tsdgeos> so you fix your crap
[12:49] <greyback> tsdgeos: anyway, I'm just using the fake modules for now.
[12:49] <mzanetti> wouldn't it b easier to just use qWarning and when wanted export QT_FATAL_WARNINGS=1 ?
[12:49] <greyback> tsdgeos: the good news: unity8 kinda works
[12:49] <greyback> tsdgeos: the bad news: lots of things are broken
[12:49] <tsdgeos> like?
[12:49] <greyback> and I'm getting scenegraph renderer crashes
[12:50] <tsdgeos> not good
[12:50] <greyback> tsdgeos: I swipe the greeter away, it disappears immediately, I see "QTransform::translate with NaN called" errors
[12:50] <greyback> hopefully a math problem on our end
[12:51] <tsdgeos> yep
[12:52] <greyback> the indicators Tabs thing crashes when I click on it, giving the SG renderer error
[12:52] <greyback> nothing at all shows in Dash
[12:52] <greyback> possibly due to that math bug again
[12:53] <tsdgeos> greyback: so the thing is, when do we want to tackle those?
[12:53] <tsdgeos> you do it now? or? who and when?
[12:53] <greyback> tsdgeos: well I think the sooner Qt bugs are reported, the better
[12:53] <tsdgeos> we should do before 5.2 is officially out in case it's a qt bug it can try to get fixed before .0
[12:53] <tsdgeos> and that said
[12:53] <tsdgeos> it's lunch time
[12:53] <tsdgeos> :D
[12:53] <greyback> especially if it's in renderer
[12:53] <greyback> right
[12:53] <greyback> also JS engine
[12:54] <greyback> lots of changes, we need to make sure we find the bugs that effect us now
[12:55] <nic-doffay> mzanetti, here's the code. I assumed I'd gotten rid of everything qml related by just deleting the file... lp:~nicolas-doffay/+junk/search-history-model
[12:56] <fginther> mzanetti, ping
[12:56] <mzanetti> fginther: hi
[12:56] <mzanetti> fginther: so. seems the packages have landed
[12:57] <fginther> mzanetti, good, sounds like you needed some jenkins updates:
[12:57] <fginther> ?
[12:57] <mzanetti> fginther: but as it's notify-osd I think we'd need to upgrade the otto machines because it won't be pulled in
[12:57] <mzanetti> just with our tests
[12:58] <mzanetti> fginther: notify-osd 0.9.35+14.04.20131030.1-0ubuntu1 is the required one
[13:00] <fginther> mzanetti, the most recent tests are using 0.9.35+13.10.20130917.1-0ubuntu1. I should be able to get it the test runner to pull in the updated package.
[13:01] <mzanetti> fginther: I had the de.archive.ubuntu.com mirror today, that didn't show it either. I switched to the main mirror and it appeared
[13:02] <fginther> mzanetti, I'm running a test here: http://10.97.0.26:8080/job/autopilot-testrunner-otto-trusty/240/console - it found the right version
[13:02] <mzanetti> nic-doffay: Dash/ScopeView.qml
[13:02] <mzanetti> nic-doffay: property ListModel searchHistory
[13:03] <fginther> mzanetti, If it works, I'll just need to update the cu2d-config to update the parent -ci/-autolanding jobs
[13:03] <mzanetti> nic-doffay: make it a property QtObject searchHistory
[13:03] <mzanetti> fginther: cool. seems we're getting close :)
[13:04] <nic-doffay> mzanetti, ah cool nice one
[13:04] <mzanetti> nic-doffay: FYI: "ListModel" in QML is actually the "QQuickListModel"
[13:04] <mzanetti> nic-doffay: as they did qmlRegisterType<QQuickListModel>(uri, 2, 0, "ListModel")
[13:05] <mzanetti> nic-doffay: the error messages print the C++ type which makes it confusing if you don't know that :/
[13:05] <nic-doffay> mzanetti, yeah I figured as much now!
[13:06] <fginther> mzanetti, tests passed
[13:06] <mzanetti> nic-doffay: actually better: make it "property SearchHistoryModel searchHistory"
[13:06] <mzanetti> fginther: \o/
[13:06] <mzanetti> fginther: that was fast btw
[13:07] <fginther> mzanetti, now let's see if we can do the same starting with unity-ci
[13:07] <mzanetti> yep :)
[13:08] <nic-doffay> mzanetti, that's what I've done everywhere where Unity 0.1 was included.
[13:08] <mzanetti> cool. so it's working now?
[13:09] <fginther> mzanetti, http://10.97.0.26:8080/job/unity8-ci/1535/ == build of lp:unity8 with the addition of notify-osd
[13:09] <nic-doffay> mzanetti, well empty string are just being passed into the addQuery.
[13:09] <nic-doffay> I'm unsure why.
[13:10] <nic-doffay> Ah wait it worked :)
[13:10] <nic-doffay> When I change scopes I see the search is printed.
[13:10] <mzanetti> fginther: ok. monitoring :)
[13:10] <nic-doffay> mzanetti, is that desired behaviour?
[13:10] <nic-doffay> Is the query added when you change scopes?
[13:10] <nic-doffay> I'm a bit unsure about how it's supposed to function.
[13:10] <mzanetti> nic-doffay: I assume that unfocuses the textfield which calls addQuery
[13:18]  * greyback bbiab
[14:28] <Saviq> tsdgeos, mzanetti re: bug #1240408 - doesn't crash for you when expanding the music category in Home?
[14:28] <mzanetti> Saviq: nope
[14:28] <mzanetti> Saviq: neither on phone nor on desktop
[14:29] <tsdgeos> all fine
[14:29] <tsdgeos> argably i only have 1 green day album in there
[14:29] <Saviq> I'll try and trim down my music collection
[14:29] <mzanetti> I have some more...
[14:29] <Saviq> tsdgeos, mzanetti I have some polish music - so utf characters, maybe related
[14:30] <Saviq> will try and get you more info
[14:30] <mzanetti> mhm. makes sense
[14:31] <mzanetti> tsdgeos: nic-doffay: standup
[14:31] <tsdgeos> Saviq: mzanetti was saying it may be the exceptions throw in the album thing
[14:31] <tsdgeos> mzanetti: going
[14:31] <Saviq> tsdgeos, yeah, could be
[14:31] <mzanetti> tsdgeos: I checked a bit more... I think we're catching stuff
[14:32] <mzanetti> but well... if the lower layers throw stuff you never know
[14:32] <greyback> dandrader: you got disconnected
[14:34] <greyback> MacSlow: https://en.wikipedia.org/wiki/Public_holidays_in_Germany
[14:36] <MacSlow> greyback, true... http://www.schulferien.org/Feiertage/Feiertage_Berlin.html
[14:36] <greyback> MacSlow: yeah :(
[14:37] <nic-doffay> mzanetti, whoa was reading doccs
[14:38] <greyback> nic-doffay: we hear you
[14:38] <nic-doffay> greyback, I can't hear anything.
[14:38] <greyback> nic-doffay: :( try re-connecting once more?
[14:38] <nic-doffay> greyback, yeah done now
[14:39] <nic-doffay> this is annoying.
[14:45] <mzanetti> tsdgeos: http://10.97.0.26:8080/job/unity8-ci/1535/
[14:45] <mzanetti> tsdgeos: this one needs to go green
[14:45] <mzanetti> so far it looks good: http://10.97.0.26:8080/job/unity8-ci/1535/console
[14:46] <tsdgeos> 1 hr 37 min?¿
[14:46] <tsdgeos> wasn't it a bit faster before?
[14:46] <tsdgeos> or that accounts for some time in which there were no free machines?
[14:46] <mzanetti> hmm... good point
[14:46] <tsdgeos> like
[14:46] <tsdgeos> http://10.97.0.26:8080/job/generic-mediumtests-runner-maguro/
[14:47] <mzanetti> yeah... I think that's it
[14:47] <mzanetti> because if a single job takes more than 60 mins it'll be killed
[14:47] <mzanetti> so everything above must be queue time
[14:49] <nic-doffay> mzanetti, would the best approach for this be to reset the StringList on the model each time a query is added? I can't really see a better of doing it right now.
[14:50] <mzanetti> nic-doffay: what exactly is the issue?
[14:54] <tsdgeos> mzanetti: there's no append to QStringListMode
[14:54] <tsdgeos> l
[14:54] <nic-doffay> mzanetti, ^
[14:55] <mzanetti> tsdgeos: well there must be something, no?
[14:55] <tsdgeos> mzanetti: not sure tbh
[14:55] <tsdgeos> let me check the code :D
[14:56] <mzanetti> tsdgeos: stringList() and setStringList()
[14:56] <nic-doffay> mzanetti, yeah that's all.
[14:56] <mzanetti> nic-doffay: setStringList(stringList() << newItem);
[14:57] <tsdgeos> nic-doffay: well you can call insertRows
[14:57] <tsdgeos> and then setData
[14:57] <mzanetti> tsdgeos: then you'd need also setdata
[14:57] <mzanetti> yeah... sucks
[14:57] <tsdgeos> sure :D
[14:57] <tsdgeos> it's how it is
[14:57] <nic-doffay> mzanetti, so that's how it is then.
[14:57] <tsdgeos> either that or you do your own model
[14:57] <mzanetti> is there a problem I don't see with this? setStringList(stringList() << newItem);
[14:58] <nic-doffay> mzanetti, there's not a problem. I just expected the class to have it's own append function is all.
[14:58] <tsdgeos> calls beginResetModel
[14:58] <tsdgeos> which may not be the most efficient thing ever
[14:58] <mzanetti> nic-doffay: yeah. the QStringListModel sucks a bit tbh
[14:59] <tsdgeos> who is consuming this?
[14:59] <mzanetti> nic-doffay: you could however, use QAbstractListModel.
[14:59] <tsdgeos> QuickRepeater?
[14:59] <tsdgeos> or?
[14:59] <mzanetti> tsdgeos: I think yeah. could also be a ListView tho
[14:59] <mzanetti> tsdgeos: if it has model in the name I'd prefer to correctly emit signals
[14:59] <nic-doffay> mzanetti, well in another case I'd say lets go for something else but this isn't called an awful lot.
[15:00] <tsdgeos> that's true
[15:00] <mzanetti> nic-doffay: you could take it as a learning opportunity tho
[15:00] <tsdgeos> no need to optimize
[15:00] <tsdgeos> but yeah let's do a simple qabstractlistmodel yourself
[15:00] <tsdgeos> and learn a bit about it
[15:00] <mzanetti> nic-doffay: QAbstractListModel is the most used class in Qt since QML arised
[15:00] <mzanetti> so knowing that one wouldn't hurt ;)
[15:01] <nic-doffay> tsdgeos, mzanetti you're right.
[15:01] <tsdgeos> you can get inspired by the code of QStringListModel and add the missing functionality
[15:02] <mzanetti> nic-doffay: also check out plugins/Unity/Launcher/quicklistmodel. that's roughly the same. a super simple QAbstractListModel
[15:03] <nic-doffay> mzanetti, cool will do.
[15:15] <mzanetti> tsdgeos: I added some tests here: https://code.launchpad.net/~unity-team/unity8/switching-previews/+merge/189556
[15:15] <mzanetti> tsdgeos: mind checking them and reapproving?
[15:15] <tsdgeos> on it
[15:20] <tsdgeos> mzanetti:  /// exposes the distance to the next row (only one row in carousel, so it's the topMargins
[15:20] <tsdgeos> missing ) somewhere
[15:21] <mzanetti> tsdgeos: ack, will fix
[15:21] <mzanetti> fginther: any idea whats happening here? http://10.97.0.26:8080/job/generic-mediumtests-runner-maguro/
[15:21] <tsdgeos> mzanetti: print("should map preview", rendererName);
[15:22] <fginther> mzanetti, all the maguros are stuck after flashing, someone has been asked to get them back online
[15:23] <mzanetti> tsdgeos: both fixed
[15:24] <tsdgeos> mzanetti: is it bzr being stupid here http://bazaar.launchpad.net/~unity-team/unity8/switching-previews/revision/483 ?
[15:24] <mzanetti> tsdgeos: no, it's me being stupid
[15:24] <tsdgeos> i mean r483 doesn't have all taht code, no?
[15:24] <tsdgeos> or?
[15:25] <mzanetti> tsdgeos: I started with a clean unity8 branch to enable the preview mocks
[15:25] <tsdgeos> ah
[15:25] <mzanetti> tsdgeos: then I figured that the switching previews had a failed test from a bad merge
[15:25] <mzanetti> tsdgeos: then I thought, ok, lets fix that one too
[15:25] <mzanetti> tsdgeos: merged everything in there and continued to work without committing
[15:25] <mzanetti> and at the end committed everything
[15:25] <mzanetti> :/
[15:29] <fginther> mzanetti, the devices are up again, jobs are running
[15:29] <mzanetti> cool, thanks
[15:32] <Saviq> mzanetti, fginther the fix for #1240408 should hopefully help our mako mediumtests
[15:32] <Saviq> fginther, could we update notify-osd on the trusty mediumtests, though?
[15:33] <fginther> Saviq, it was added for unity8 jobs, does it need to be added for everything?
[15:34] <Saviq> fginther, no, u8 is enough
[15:35] <Saviq> fginther, but at least http://10.97.0.26:8080/job/autopilot-testrunner-otto-trusty/236/ still suffered from old notify-osd
[15:35] <Saviq> ah, but http://10.97.0.26:8080/job/generic-mediumtests-trusty/254/ was fine
[15:35] <Saviq> cool
[15:35] <fginther> Saviq, http://10.97.0.26:8080/job/generic-mediumtests-trusty/250/ has the update
[15:35] <Saviq> fginther, yup, thanks
[15:42] <mzanetti> failure
[15:43] <mzanetti> http://nooooooooooooooo.com/
[15:45]  * dandrader hears a loud scream
[15:45] <dandrader> what, no autolanding yet?
[15:45] <mzanetti> Saviq: the fix for 1240408 ?
[15:45] <mzanetti> you sure about that?
[15:46] <mzanetti> there is one HUD test failing
[15:46] <mzanetti> on the phone
[15:46] <tsdgeos> autopilot?qml?
[15:46] <Saviq> mzanetti, it's random
[15:46] <Saviq> mzanetti, crash on startup
[15:46] <Cimi> mzanetti, we need the nooooooooo button on ubuntu touch
[15:46] <mzanetti> tsdgeos: AP
[15:46] <mzanetti> Cimi: yeah, thought the same
[15:46] <Saviq> mzanetti, if ap log says "could not find PID blah" or similar
[15:47] <mzanetti> Saviq: yep, that's it
[15:47] <Saviq> mzanetti, it usually means unity8 crashed on startup
[15:47] <mzanetti> so I guess we can fginther to reenable autolanding nevertheless?
[15:47] <Saviq> mzanetti, fginther let's not open the floodgates
[15:47] <mzanetti> huh?
[15:47] <Saviq> mzanetti, fginther can we enable the job but make it manual for now?
[15:48] <mzanetti> ah... yeah. makes sense
[15:48] <Saviq> mzanetti, without https://code.launchpad.net/~saviq/unity8/move-setenv/+merge/193426 we'll be failing anyway
[15:48] <Cimi> mzanetti, we could add noooooo when an autopilot test fails
[15:48] <Cimi> mzanetti, that would be quite fun
[15:48] <fginther> Saviq, mzanetti, yes, I'll let you know when it's ready
[15:59] <greyback> mzanetti: got a sec?
[15:59] <mzanetti> greyback: sure
[15:59] <greyback> mzanetti: I want to understand exactly how we swipe away the greeter
[15:59] <greyback> mzanetti: in Greeter.qml, there's a DragHandle
[16:00] <mzanetti> greyback: yep
[16:00] <greyback> that DragHandle is the thing listening for mouse events to start a drag, yeah?
[16:00] <greyback> what I don't see is where DragHandle sets the x of the Greeter
[16:00] <mzanetti> greyback: one sec
[16:00] <mzanetti> greyback: what's the background for this?
[16:00] <greyback> mzanetti: the x is being set to NaN in Qty5.2
[16:00] <mzanetti> ah, ok
[16:01] <mzanetti> greyback: open Components/DragHandle.qml and check out the example
[16:02] <mzanetti> greyback: basically, DragHandle operates on it's parent if that's a Showable
[16:03] <greyback> mzanetti: aha, now I see it
[16:03] <greyback>                     step = hintingAnimation.targetValue - dragParent[targetProp];
[16:04] <greyback> mzanetti: thanks!
[16:04] <mzanetti> greyback: np
[16:25] <greyback> Hey folks, it's time for another round of "Know your EMCAScript" !!!
[16:26] <greyback> What should this print when I click: http://pastebin.ubuntu.com/6336469/
[16:28] <mzanetti> greyback: "Hi Gerry! You are Hi Gerry!" is what I would assume
[16:28] <mzanetti> greyback: but I wouldn't wonder if it says "Hi Gerry! You are gerry"
[16:29] <mzanetti> being a mix of call by value and call by ref
[16:29] <greyback> mzanetti: in qt5.0, that's correct! In 5.2 however I get, "Hi undefined! you are undefined!"
[16:29]  * mzanetti sees ubuntu core apps falling apart
[16:29] <greyback> we do something similar in DragHandle.qml, limitMovement(step) - causing 1 bug
[16:30] <nic-doffay> greyback, what changed?
[16:30] <mzanetti> greyback: undefined sounds weird tho
[16:30] <mzanetti> greyback: why is that?
[16:30] <greyback> nic-doffay: in Qt5.2, there's a completely new javascript interpretation engine
[16:31] <greyback> so bugs like this could exist
[16:31] <greyback> mzanetti: I dunno, smells like bug to me
[16:32] <mzanetti> greyback: is it the QtObject? try using an Item instead
[16:32] <mzanetti> hmm... no... doesn't make sense either
[16:32] <greyback> mzanetti: same with Item
[16:33] <mzanetti> greyback: however I read it, it doesn't make sense to me
[16:34] <greyback> mzanetti: yep, I think it's 5.2 bug
[16:45] <mzanetti> greyback: somehow I find it hard to believe that there's a bug like this and it only breaks the DragHandle
[16:45] <mzanetti> this feels like *everything* would fall apart
[16:51] <greyback> mzanetti: well, that's the first fix I've made :) And it's kinda bad to overwrite something set in a function argument, so I'd say we unconsciously avoid doing it
[16:56] <mzanetti> greyback: apart form that. any noticeable impact on performance?
[16:58] <greyback> mzanetti: hard to say, I'm running on my laptop. I'd need to gather numbers
[17:01] <Cimi> greyback, isn't 5.2 running faster?
[17:01] <mzanetti> Cimi: well, it's supposed to make property bindings like 4 times faster
[17:01] <greyback> Cimi: it should be. Just hard to tell by eye
[17:01] <mzanetti> Cimi: but in turn slow down imperative javascript quite a bit
[17:02] <mzanetti> which I think would improve situations on state changes and animations
[17:02] <greyback> and there are optimisations introduced by 5.2 which would helps some animations, the "*Animator" classes
[17:03] <greyback> will have to be used with care tho
[17:04] <Cimi> greyback, and new scene graph?
[17:05] <greyback> Cimi: yep, it will improve perf for various situations. Things like lists and grids will be faster
[17:05] <Cimi> greyback, btw we have plenty of time tomorrow to chat while the rest of our colleagues are on holiday -.-
[17:05] <greyback> Cimi: how true :)
[17:05] <mzanetti> muahaha
[17:05] <Saviq> fginther, can you have a look at http://10.97.0.26:8080/job/generic-mediumtests-runner-mako/2921/console
[17:06] <Saviq> yikes that's flaky :/
[17:14] <Cimi> mzanetti, the launcher bus is an asset
[17:14] <mzanetti> huh?
[17:14] <mzanetti> bus?
[17:14] <Cimi> hah
[17:14] <Cimi> bug
[17:14] <mzanetti> haha
[17:14] <mzanetti> ok
[17:15] <mzanetti> really
[17:15] <mzanetti> good catch then
[17:15] <Cimi> mzanetti, you men the weird effect at the bottom?
[17:15] <mzanetti> yeah
[17:15] <mzanetti> in the bottom corners mostly
[17:15] <Cimi> graphics/non-selected.sci
[17:15] <Cimi> I thought was it
[17:15] <greyback> mzanetti: question, what is "gridView.delegateCreation{Begin,End}" in ResponsiveGridView?
[17:16] <ali1234> tedg: what is up with the libdbusmenu tests? they take 20 minutes to run and seem to fail randomly
[17:16] <greyback> are they undocumented properties on a GridView?
[17:16] <mzanetti> greyback: that's albert's solution for the fact that we don't want to have the whole delegate created
[17:16] <mzanetti> greyback: i.e: you have the "recommended apps"
[17:16] <mzanetti> greyback: which is 5km long
[17:17] <greyback> mzanetti: ah yes, that thing
[17:17] <mzanetti> and this creationRange tells the containing gridview which delegates it needs to keep created
[17:17] <greyback> oh, we've a distro patch for it...
[17:17] <Saviq> GREEEEEN
[17:17] <Saviq> http://s-jenkins:8080/job/unity8-ci/
[17:17] <greyback> \o/
[17:18] <Saviq> https://code.launchpad.net/~saviq/unity8/move-setenv/+merge/193426 please
[17:18] <mzanetti> http://www.hiyoooo.com/
[17:19] <mzanetti> Saviq: approved
[17:20] <Saviq> fginther, please ping when we can push that ↑
[17:23] <mzanetti> dafuq.. some halloween kids just were at the door. first time I see that in D
[17:27] <Cimi> mzanetti, I'd scare them :D
[17:27] <Cimi> mzanetti, show them a jenkins log!
[17:31] <mzanetti> lol
[17:35] <Saviq> Cimi, we've green logs now, so that's not gonna help ;)
[17:47] <fginther> Saviq, jenkins is ready, want me to trigger that build?
[17:47] <Saviq> fginther, I'll do
[17:47] <Saviq> fginther, I'll be going through our queue now
[17:48] <fginther> Saviq, ack, let me know when you're ready to enable automated merging again
[17:48] <Saviq> fginther, anything I should make sure of when triggering it? like putting notify-osd in the test_packages prop or something?
[17:48] <fginther> Saviq, the job configs are already set to use notify-osd. You just need to specify the merge_proposal, landing_candidate and candidate_revision
[17:49] <fginther> I see a green light on the last unity8-ci job. awesome
[17:52] <Saviq> fginther, local_archive_pocket? is it used at all?
[17:53] <Saviq> fginther, that looks sane http://s-jenkins:8080/job/unity8-autolanding/615/parameters/? ?
[17:54] <fginther> Saviq, looks good.
[17:55] <fginther> Saviq, the local_arhive* parameters are used, they don't need to be modified
[18:00] <nic-doffay> mzanetti, you there?
[18:15] <om26er> mzanetti, hey! do you think an autopilot test for this will be enough? https://code.launchpad.net/~om26er/unity8/close_preview_on_search/+merge/193467
[18:18] <thomi> om26er: it needs *at least* an autopilot test :)
[18:19] <om26er> thomi, right, I asked that in the description.
[18:19] <thomi> om26er: you asked it here as well :)
[18:20] <om26er> thomi, wow. i am distracted
[18:22] <om26er> thomi, can we  inquire from autopilot if the OSK is visible on screen ?
[18:22] <om26er> considering autopilot is typing with the maliit backend
[18:23] <thomi> om26er: yes, you can - but veebers is the person to ask about that
[18:23] <om26er> thomi, ok
[18:34] <ali1234> tedg: i am having difficulty building libdbusmenu because the tests fail, or simply hang forever
[18:51] <ali1234> (process:27013): LIBDBUSMENU-GLIB-WARNING **: Unable to get session bus: Error sending credentials: Error sending message: Operation not permitted
[18:52] <davmor2> who knew 900 app installs would cripple unity \o/
[18:52] <Mirv> Saviq: https://code.launchpad.net/~saviq/unity8/move-setenv/+merge/193426 jenkins just failed again
[18:53] <greyback> davmor2: well done :)
[18:53] <davmor2> greyback: I think the application search times the dash out
[18:55] <greyback> davmor2: possible, yes. I didn't know we had 900 apps - they're not all click are they?
[18:55] <thomi> Hi guys - I wonder if someone could take a look at this? https://bugs.launchpad.net/unity8/+bug/1246574
[18:56] <thomi> this is a pretty critical bug for the QA team, since it's blocking AP 1.4 landing. We don't need it fixed, but it'd be good to have someone from the unity team at least look at it and comment on the bug
[18:56] <thomi> Saviq: ^^
[18:56] <davmor2> greyback: no this is the commercial apps for the desktop
[18:57] <greyback> davmor2: ahhh. Not good at all then
[18:57] <davmor2> greyback: I'm just getting to the end of the app migrations from raring to Saucy
[18:58] <davmor2> greyback: I don't know anybody who would install them all to be honest :)
[19:01] <greyback> thomi: it possible https://code.launchpad.net/~saviq/unity8/move-setenv/+merge/193426 fixes that.
[19:04] <davmor2> greyback: ha interesting so it looks like it is only the initial opening of the dash where is says there is nothing to find and search finds nothing.  If you close it for a few seconds and then  reopen all the data is back phew :)
[19:16] <thomi> greyback: thanks
[19:30] <Mirv> Saviq: meanwhile on the desktop side, I'm getting the AP errors still. commented on the bug #1244549
[21:31] <Saviq> Mirv, see you published now? you need to upgrade notify-osd / unity-notifications in cu2d
[21:33] <Mirv> Saviq: you mean on the machines? the yesterday's update is in on those
[21:34] <Saviq> Mirv, got artifacts?
[21:35] <Mirv> Saviq: http://10.97.0.1:8080/job/autopilot-trusty-daily_release/305/label=qa-intel-4000/#showFailuresLink - note that I installed the notify-osd there inside lxc-container and stop/started the container, but I'm not 100% sure if that's all that's needed
[21:35] <Saviq> Mirv, http://10.97.0.1:8080/job/autopilot-trusty-daily_release/305/label=qa-intel-4000/artifact/results/autopilot/videos/unity8.shell.tests.test_notifications.EphemeralNotificationsTests.test_append_hint%20%28Desktop%20Nexus%204%29.ogv
[21:35] <Saviq> Mirv, notify-osd was running
[21:36] <Saviq> Mirv, means either notify-osd or unity-notifications weren't upgraded
[21:36] <Mirv> Saviq: notify-osd I updated manually, and unity-notifications gets installed during the test start (in the log)
[21:37] <Saviq> Mirv, not sure what I can say :/ it's working fine in mediumtests
[21:37] <Mirv> Saviq: but as said, I'm not the container expert so I'm not sure if I understand all the details needed
[21:37] <Saviq> Mirv, and we were getting the same failures before
[21:37] <Mirv> Saviq: we may also wait for the next daily container recreation
[21:37] <Saviq> Mirv, ok
[21:40] <Mirv> Saviq: any how unity8 with the setenv change now published
[21:40] <Saviq> Mirv, yup, saw that, thanks
[21:40] <Saviq> Mirv, merging the changelog now
[21:41] <Saviq> Mirv, not sure what happened here though https://code.launchpad.net/~saviq/unity8/move-setenv/+merge/193426
[21:41] <Saviq> Mirv, did you merge manually?
[21:41] <Mirv> Saviq: no, as you see it got approved eventually
[21:42] <Saviq> Mirv, ah right, autolanding doesn't report completely when it merges
[21:42] <Mirv> Saviq: or hmm no real message, maybe it was plar_s doing magic when I asked him to tinker it and then he reported that it ran ok
[21:42] <Saviq> aaanyway
[21:42] <Saviq> it got in ;)
[21:42] <Saviq> and we need to fix flaky tests :)
[21:43] <Mirv> Saviq: so we have a real good chance of successful dashboard unity AP:s now? (minus possible flaky ones)
[21:43] <Mirv> I got all pass myself locally
[21:52] <Saviq> Mirv, on the phone it should be just fine again
[21:56] <Mirv> let's hope so. not sure who will kick the #10 image build
[23:11] <kgunn> Saviq: its been a while...what's the way to superuser on phablet?  su -u phablet -i ?
[23:12] <popey> kgunn: sudo -u phablet -i
[23:12] <kgunn> popey: ta