[00:05] <Mirv> Saviq: it seems to work great here! too bad you got a Disapprove in the MR as well :P
[01:10] <larsu> Saviq: how do I get unity8 to load the notification plugin?
[01:10]  * larsu has patches but no way to test them
[01:10] <Saviq> larsu, export QML2_IMPORT_PATH to wherever unity-notifications installed the plugin
[01:10] <Saviq> larsu, easiest probably to just build the package
[01:11] <larsu> Saviq: that's what I thought, but it doesn't seem to get called
[01:12] <Saviq> larsu, is the qmldir file there with the .so?
[01:12] <Saviq> larsu, and does the path include Unity/Notifications/ ?
[01:13] <larsu> Saviq: I'm running ot off the package
[01:13] <Saviq> larsu, ah, and why do you feel it's not working?
[01:13] <larsu> Saviq: it's neither taking the name nor printing the message that it wasn't able to
[01:15] <Saviq> larsu, it must be calling it, TBH, try adding some debugging around it, or just gdb it?
[01:16] <larsu> Saviq: meh, I must have messed up. It worked after rebuilding and reinstalling. Sorry 'bout that
[08:48] <tsdgeos> mzanetti: can you have a look at https://code.launchpad.net/~aacid/unity8/tabbar_dash/+merge/192505 ?
[08:48] <mzanetti> tsdgeos: yes, on it
[08:48] <tsdgeos> good
[08:53] <mzanetti> tsdgeos: this will conflict badly with the switching_previews
[08:53] <mzanetti> I thought you were basing this on that one
[08:53] <tsdgeos> i wasn't i said i would rebase after "getting it to work"
[08:54] <tsdgeos> so i guess i should do this now :D
[08:54] <mzanetti> ah right... well, gimme a bit first to understand it better
[08:58] <tsdgeos> [OFFTOPIC] I just bought tickets for a Kavinsky concert in London one of the days of the sprint, going with two friends, if anyone wants to join head to ticketmaster :D
[09:03] <tsdgeos> mzanetti: commented in the wrong MR?
[09:03] <mzanetti> tsdgeos: not sure if this is in the patch you did in the SDK or if it's in unity: https://code.launchpad.net/~aacid/ubuntu-ui-toolkit/tabbar_external_use/+merge/192307/comments/444320
[09:03] <mzanetti> right... I wanted to comment it on the other
[09:04] <tsdgeos> i mean, we didn't use a tabbar before
[09:04] <tsdgeos> it may as well be an existing bug :D
[09:05] <mzanetti> tsdgeos: right. but at least in apps the tabbar's text adjust to the background color
[09:05] <mzanetti> tsdgeos: no clue where the logic for that is located tho
[09:05] <tsdgeos> mzanetti: what do you mean "in apps"?
[09:05] <mzanetti> tsdgeos: well, apps
[09:06] <tsdgeos> isn't just that your background is darker at the bottom + the border/shadow ?
[09:07] <mzanetti> tsdgeos: no... check out some app with white background, the tabs text will be dark grey
[09:07] <mzanetti> tsdgeos: while e.g. in the Authenticator app which has black background, the text is white
[09:08] <tsdgeos> mzanetti: yes, but that's not a tabbar
[09:08] <tsdgeos> is it?
[09:09] <mzanetti> tsdgeos: yes it is. but looking at the rest of unity's text, I think in our case want to keep it white, but just add the shadow etc like you said
[09:09] <tsdgeos> still
[09:09] <tsdgeos> that's the tabbar
[09:10] <tsdgeos> not related at all to the MR you commented at all that only makes the tabbar usable externally
[09:10] <mzanetti> tsdgeos: yeah... I added another comment and clarified that
[09:11] <mzanetti> tsdgeos: I think exactly this is the issue tho. the SDK components are created to change (invert) their text colors depending on the background, while unity's text always stays white but has shadows which make it readable on bright background
[09:13] <tsdgeos> hmmmm
[09:14] <mzanetti> brb
[09:14] <tsdgeos> and that's why we should not ignore the SDK :D
[09:24] <tsdgeos> mzanetti: pushed something that should help, can you update both branches and try again?
[09:26] <tsdgeos> mhr3: can you still create a "search bar broken position" as you reported in https://bugs.launchpad.net/unity8/+bug/1240118 ?
[09:30] <mhr3> tsdgeos, can you ping me about it in an hour? my phone's battery died over the night :)
[09:30] <tsdgeos> mhr3: sure
[09:31] <mzanetti> tsdgeos: yes, this does. The progression arrow is still "invisible" tho. I guess we need a chat with design on what to do with that
[09:33] <tsdgeos> mzanetti: that progression arrow is the same as any white background app
[09:33] <tsdgeos> i.e. the SDK doesn't do anything smart to fix stuff if the background is white for it
[09:33] <tsdgeos> basically because it's an image
[09:33] <mzanetti> tsdgeos: no. in apps it uses a black arrow. But I see why we can't use that one
[09:34] <tsdgeos> well that is if you changed the theme
[09:34] <tsdgeos> to a dark theme
[09:34] <mzanetti> tsdgeos: yeah... I think MainView changes the theme depending on the background color
[09:35] <tsdgeos> ok
[09:35] <tsdgeos> tbh the only thing i can see happening is getting an "image with border"
[09:35] <tsdgeos> and use that all the time
[09:36] <mzanetti> tsdgeos: yes, I think that's what we'd want in unity
[09:37] <tsdgeos> mzanetti: can you take another screenshot with your white background and attach it to the MR? and then we add someone from design to the MR and hope they read their emails?
[09:40] <mzanetti> tsdgeos: ack
[09:41] <mzanetti> tsdgeos: http://i.imgur.com/LH6xe0D.png
[09:41] <tsdgeos> mzanetti: what you are seeing with the scrolling is fine
[09:41] <tsdgeos> it's just that the dash home is some pixels highers than the screen
[09:41] <tsdgeos> so it doesn't come back
[09:41] <tsdgeos> that happens with non patched version too
[09:41] <mzanetti> tsdgeos: really? but it's empty
[09:41] <tsdgeos> i.e. lp:unity8
[09:42] <tsdgeos> well it's "bottom margin"
[09:42] <tsdgeos> that or we're speaking about two different things :D
[09:42] <mzanetti> tsdgeos: right. confirming it in trunk too
[09:43] <tsdgeos> it feels weird
[09:43] <tsdgeos> because it's just something like 1 gu
[09:43] <tsdgeos> but it's how it's supposed to behave if oyu think about it
[09:44] <mzanetti> really? don't see why yet
[09:44] <tsdgeos> because the header is "special"
[09:45] <tsdgeos> it's not a hard body
[09:45] <tsdgeos> it comes out from the bottom
[09:45] <tsdgeos> so that's what's happening here
[09:46] <mzanetti> tsdgeos: it really feels like one last update() call of something is missing
[09:47] <tsdgeos> why?
[09:47] <mzanetti> tsdgeos: for example this: http://i.imgur.com/27z12c4.png
[09:47] <mzanetti> would you still say that the content is higher that the listview?
[09:48] <tsdgeos> nope
[09:48] <mzanetti> but it still happens
[09:48] <mzanetti> and I can't slowly drag it to that place. only when overshooting it not always comes back
[09:49] <mzanetti> here's good one: http://i.imgur.com/qRGh9zV.png
[09:50] <tsdgeos> i can't do that here
[09:50] <mzanetti> flick it upwards as quickly as you can
[09:51] <tsdgeos> sure
[09:51] <mzanetti> but yes. it's the same in trunk
[09:51] <tsdgeos> always comes to the correct position
[09:52] <tsdgeos> mzanetti: that's on your phone or in the desktop too?
[09:52] <tsdgeos> i'm guessing the desktop because of the screenies
[09:52] <mzanetti> tsdgeos: yep. desktop
[09:53] <tsdgeos> mzanetti: can you repro if you resize the window?
[09:53] <tsdgeos> just random asking :D
[09:53] <mzanetti> tsdgeos: just got it reproduced with the video scope on the phone
[09:53] <mzanetti> tsdgeos: to which size do you want me to resize it?
[09:53] <tsdgeos> to any
[09:54] <tsdgeos> since i don't know how do you to do only have one category there
[09:54] <tsdgeos> i'm just making it taller
[09:54] <tsdgeos> so that all fits on screen
[09:54] <tsdgeos> and then doing the overshoot
[09:54] <tsdgeos> i can't make it behave wrong
[09:54] <mzanetti> tsdgeos: yeah. it happens with the standard size and also with that larger one as in the screenshot
[09:54] <tsdgeos> :/
[09:55] <mzanetti> tsdgeos: well, one difference is that I use GRID_UNIT_PX=18. Don't think that's the reason, but who knows
[09:55] <mhr3> tsdgeos, checked and yea, the header is still moving weirdly
[09:56] <mhr3> no scrolling issues though
[09:57] <tsdgeos> mzanetti: can't repro with that either
[09:57] <tsdgeos> :(
[09:58] <mzanetti> tsdgeos: now I can reproduce it 100%
[09:58] <tsdgeos> lol
[09:58] <tsdgeos> really?
[09:58] <mzanetti> tsdgeos: grab the dash, move it quickly up and down a couple of times
[09:58] <mzanetti> tsdgeos: and at some point release it after the upwards movement
[09:58] <tsdgeos> ok
[09:58] <tsdgeos> that helped
[09:59] <mzanetti>  \o/
[09:59] <tsdgeos> but seems to be a regular LVWPH bug
[09:59] <mzanetti> yes
[09:59] <tsdgeos> nothing to do with this one
[09:59] <mzanetti> same in trunk, as I said
[09:59] <tsdgeos> can you report it and assign it to me?
[10:00] <mzanetti> yes
[10:02] <Cimi> tsdgeos, why don't we colour the image depending on the background colour?
[10:02] <Cimi> tsdgeos, http://qt-project.org/doc/qt-5.0/qtgraphicaleffects/qml-qtgraphicaleffects1-colorize.html
[10:03] <tsdgeos> because i don't do graphical decisions
[10:03] <tsdgeos> as i don't expect the designers to tell me how to code
[10:05] <tsdgeos> mhr3: you have that problem only on the device or also on the desktop?
[10:05] <mzanetti> tsdgeos: https://bugs.launchpad.net/unity8/+bug/1245824
[10:06] <mhr3> tsdgeos, both
[10:06] <tsdgeos> mzanetti: tz
[10:06] <tsdgeos> tx
[10:13] <mzanetti> tsdgeos: is it wanted by design that we removed the DashBar?
[10:13] <tsdgeos> mzanetti: yes
[10:13] <mzanetti> ok
[10:19] <mzanetti> tsdgeos: this looks a bit odd: http://i.imgur.com/n2OWijK.jpg  Do you think we could make it fade out towards the right edge in that case?
[10:20] <tsdgeos> do we do any such fading anywhere?
[10:21] <mzanetti> tsdgeos: hmm... probably not. or something else you can think of?
[10:22] <tsdgeos> besides doing the fading wouldn't be easy either
[10:22] <mzanetti> I guess so, yes
[10:23] <tsdgeos> mzanetti: not really, personally it doesn't look bad to me, but i can understand it does for some people
[10:23] <mzanetti> well, not blocking the merge because of this. but I think it's worth to have a chat with jouni
[10:35] <Cimi> tsdgeos, mzanetti http://qt-project.org/doc/qt-5.0/qtgraphicaleffects/qml-qtgraphicaleffects1-opacitymask.html
[10:35] <Cimi> just anchor it left to the search bar
[10:35] <mzanetti> :D
[10:36] <mzanetti> that docs page is badly broken
[10:38] <tsdgeos> Cimi: but you need a mask source for that
[10:38] <tsdgeos> which if we stretch
[10:38] <tsdgeos> is going to look weird, no?
[10:38] <tsdgeos> otoh we can have it fixed size 20 and not stretch
[10:38] <tsdgeos> ignore me
[10:38] <tsdgeos> Cimi: are you in the office?
[10:38] <Cimi> tsdgeos, nope
[10:39] <Cimi> tsdgeos, all designers are in oakland apart rosie
[10:39] <Cimi> might go later
[10:39] <tsdgeos> ah
[10:39] <tsdgeos> ok
[10:39] <Cimi> like after lunch so I can eat good stuff :)
[10:43] <tsdgeos> he he
[10:45] <mzanetti> tsdgeos: some smaller comments: https://code.launchpad.net/~aacid/unity8/tabbar_dash/+merge/192505/comments/444381
[10:45] <mzanetti> tsdgeos: it will also conflict a lot with nic-doffay's filter-selector branch.
[10:46] <tsdgeos> \o/
[10:46] <tsdgeos> not
[10:47] <mzanetti> tsdgeos: that would be /o\
[10:47] <tsdgeos> how do you put your arms on top of your head?
[10:47] <tsdgeos> :D
[10:48] <mzanetti> it's more like this: http://i1.wp.com/theminorityreport.co/stixblog/files/2012/07/demotivational-posters-quadruple-facepalm.jpg
[10:48] <mzanetti> :P
[10:48] <MacSlow> tsdgeos, there's only so much acrobatics one can do in ascii :)
[11:43] <mzanetti> tsdgeos: hey, when you have some time, mind taking over this one while Saviq is away? https://code.launchpad.net/~unity-team/unity8/switching-previews/+merge/189556
[11:43] <tsdgeos> mzanetti: sure
[11:43] <tsdgeos> will have a look later
[11:44] <tsdgeos> working on mhr3's LVWPH bug now
[11:44] <mzanetti> ok.
[11:44] <tsdgeos> my scopes are on strike
[11:44] <tsdgeos> WARN  2013-10-29 12:44:10 unity.dash.scopeproxy ScopeProxy.cpp:516 Could not search '' on applications.scope => Timed out waiting for scope proxy connection
[11:44] <tsdgeos> WARN  2013-10-29 12:44:10 unity.dash.scopeproxy ScopeProxy.cpp:516 Could not search '' on home.scope => Timed out waiting for scope proxy connection
[11:44] <tsdgeos> WARN  2013-10-29 12:44:10 unity.dash.scopeproxy ScopeProxy.cpp:516 Could not search '' on photos.scope => Timed out waiting for scope proxy connection
[11:44] <tsdgeos> WARN  2013-10-29 12:44:10 unity.dash.scopeproxy ScopeProxy.cpp:516 Could not search '' on music.scope => Timed out waiting for scope proxy connection
[11:44] <tsdgeos> WARN  2013-10-29 12:44:10 unity.dash.scopeproxy ScopeProxy.cpp:516 Could not search '' on video.scope => Timed out waiting for scope proxy connection
[11:44] <tsdgeos> WARN  2013-10-29 12:44:10 unity.dash.scopeproxy ScopeProxy.cpp:516 Could not search '' on files.scope => Timed out waiting for scope proxy connection
[11:44] <tsdgeos> :-S
[11:44] <mhr3> tsdgeos, are you able to reproduce it now?
[11:44] <tsdgeos> mhr3: yes
[11:45] <tsdgeos> mhr3: btw, any idea about ↑↑↑↑
[11:45] <mhr3> tsdgeos, hm, just a timeout... should fix itself
[11:45] <davidcalle> tsdgeos, you have activated the french Dash mode. Please deal with the unions first.
[11:45] <mhr3> lol, what?
[11:46] <tsdgeos> mhr3: nope
[11:46] <tsdgeos> just nothing in the dash
[11:46] <tsdgeos> and restarting unity doesn't help either
[11:46] <mhr3> tsdgeos, odd... pkill -f unity-scope-home
[11:46] <tsdgeos> it's eating 60% of my cpu
[11:46] <mhr3> what is?
[11:47] <tsdgeos>  unity-scope-home
[11:47] <tsdgeos> and init was eating 100%
[11:47] <tsdgeos> whatever init is
[11:47] <mhr3> init is upstart
[11:47] <mhr3> tsdgeos, so, yea, kill the home scope and see if it helps
[11:47] <tsdgeos> it did
[11:47] <hyperair> init taking 100% is really weird.
[11:48] <hyperair> if it's taking 100%, that would probably be something dying nad getting restarted
[11:48] <mhr3> tsdgeos, interesting, if you ever see that again ping me, sounds like something very badly broken
[11:48] <tsdgeos> mhr3: ok, will
[11:49] <mhr3> tsdgeos, and don't kill it, we'll try to do some debugging ;)
[11:49] <tsdgeos> sure
[11:49] <tsdgeos> it's not the first time i've had those timeouts
[11:49] <tsdgeos> never realized if the scope was eating the cpu though
[11:50] <mhr3> well fwiw scopes aren't using upstart, so the init cpu usage is weird
[11:54] <mzanetti> really? in a world where 110% of your life is subject to surveillance we are the ones that get the big brother award for a feature that can be turned off?
[11:54] <mzanetti> really Austria, really?
[11:59] <mhr3> mzanetti, link?
[12:00] <mzanetti> mhr3: this is german tho: http://www.golem.de/news/big-brother-award-oesterreich-nominierung-fuer-mark-shuttleworth-1310-102415.html
[12:00] <mzanetti> ah wait. this is only the nomination. But we actually got it... let me find more
[12:01] <sergiusens> mzanetti, it's on omg ubuntu
[12:01] <sergiusens> mzanetti, http://www.omgubuntu.co.uk/2013/10/ubuntu-wins-big-brother-austria-privacy-award
[12:16] <ricotz> charles, hi
[12:17] <ricotz> charles, is it possible that indicator-session makes a more sophisticated check for unity rather than just looking for an available "com.canonical.Unity" dbus
[12:20] <ricotz> while the libunity support can only be activated for other docks while providing this dbus, indicator-session gets fooled and will leave you without an option to shutdown/logout
[12:59] <Cimi> tsdgeos, we needed to stars landing stuff, the queue is impressive!
[13:00] <Cimi> almost 20 branches = BB party (big break)
[13:14] <mzanetti> Cimi: https://code.launchpad.net/~mzanetti/unity8/dont-tease-while-moving/+merge/192366/comments/444432
[13:14] <mzanetti> +1 on getting stuff merged somehow. we're building up conflicts like crazy
[13:17] <dandrader> mzanetti, speaking about it, any news on when stuff will start landing on trunk again?
[13:17] <mzanetti> dandrader: I have no idea
[13:18] <mzanetti> fginther: any updates?
[13:25] <mzanetti> mhr3: what do I need to do to make the music scope pick up album artwork? I tried with folder.jpg or embedding it into the id3 tag.
[13:25] <mhr3> mzanetti, only fetching from lastfm works atm
[13:26] <Cimi> mzanetti, Greeter moved even tho its locked
[13:26] <Cimi> mzanetti, lil typo in the test
[13:26] <mzanetti> mhr3: does that mean it should appear automatically?
[13:26] <mhr3> mzanetti, if it has proper album and artist tags, yes
[13:27] <fginther> mzanetti, sorry, I haven't been keeping up with unity8 specifically, but I see that nothing is passing, does anyone know why?
[13:27] <mzanetti> fginther: Last time I checked it was some setup issues. let me check latest logs
[13:27] <mzanetti> mhr3: works, thanks
[13:28] <mzanetti> Cimi: can't spot it
[13:28] <Cimi> mzanetti, tho is like slang imho :D
[13:28] <Cimi> and it's instead its
[13:29] <mzanetti> ah ok
[13:29] <mzanetti> yeah, can fix it
[13:29] <Cimi> mzanetti, also
[13:29] <Cimi> mzanetti, it's not anymore only when it's locked
[13:29] <Cimi> so I'd change the text
[13:30] <mzanetti> Cimi: ok
[13:33] <mzanetti> fginther: hmm... so the issue seems still to be that we require some post installation script which fails on the read only fs
[13:33] <mzanetti> fginther: not sure if you're indeed the right one to fix this.
[13:35] <mzanetti> fginther: hmm... actually I don't know. This is an example failure: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/2491/console
[13:35] <mzanetti> fginther: happens only on the phones
[13:35] <mzanetti> unfortunately I'm quite out of date nowadays on how those jobs work
[13:37] <fginther> mzanetti, that job is ancient
[13:37] <fginther> mzanetti, :-) anything newer?
[13:38] <mzanetti> sure. one sec
[13:38] <mzanetti> fginther: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/2713/console
[13:40] <fginther> mzanetti, the test runner has changed quite a bit, but this one is recent enough
[13:40] <fginther> mzanetti, ahhh, I remember a bug now related to this: "unable to make backup link of `./usr/bin/unity8' before installing new version: Invalid cross-device link"
[13:40] <fginther> mzanetti, let me dig it out of irc logs
[13:46] <fginther> mzanetti, https://bugs.launchpad.net/ubuntu/+source/lxc-android-config/+bug/1243432
[13:47] <fginther> mzanetti, I fix was committed, but can't yet tell if it's in the image
[13:48] <fginther> s/I fix/a fix/
[13:48] <mzanetti> fginther: where was this fixed? in unity?
[13:48] <fginther> mzanetti, lxc-android-config
[13:50] <fginther> mzanetti, looks like 0.117 is on my phone which was flashed several days ago, so should be fixed...
[13:50] <mzanetti> fginther: ok. thanks. I'll run some build to see if it passes
[13:53] <fginther> mzanetti, so in the runs from the last few days. I see nothing but failed unlock attempts on the touch devices
[13:55] <tsdgeos> back
[13:55] <mzanetti> fginther: hmm, this one? http://10.97.0.26:8080/job/autopilot-testrunner-otto-trusty/134/console
[13:56] <fginther> mzanetti, while I have your attention... Do you recall the origins of the A10checklicenseheaders hook script? It doesn't allow GPL and LGPL, was there a specific reason for this?
[13:56] <mzanetti> fginther: huh? I don't think so... are you referring to renato's branch?
[13:56] <fginther> mzanetti, yes, that started it
[13:57] <mzanetti> fginther: well, it does allow GPL and LGPL, but not if the copyright holder is something else than Canonical (or Digia or Google - which are our exceptions)
[13:57] <mzanetti> fginther: the solution for renato is to move the copied stuff into a subdir called 3rd_party which then will be excluded by the check
[13:58] <mzanetti> fginther: well, I guess the proper long term solution would be to make the hook more customizable and include allowed copyright holders on a per project basis
[13:59] <mzanetti> fginther: in renato's case "Philip Withnall"
[13:59] <fginther> mzanetti, ahh. thanks
[14:04] <fginther> mzanetti, I'm attempting to rebuild http://10.97.0.26:8080/job/autopilot-testrunner-otto-trusty/134/console with the ubuntu-daily ppa, to see if that resolves the package issue
[14:04] <mzanetti> fginther: cool, thanks
[14:11] <fginther> mzanetti, it passed - http://10.97.0.26:8080/job/autopilot-testrunner-otto-trusty/147/console
[14:12] <mzanetti> fginther: nice!
[14:12] <fginther> mzanetti, should that be made into a configuration change? We had to remove that PPA in the past due to building with unreleased package issues
[14:13] <fginther> but maybe this needs to be changed, at least temporarily?
[14:13] <mzanetti> fginther: hmm... thining about it... I don't think that would be a good idea to make persistent
[14:15] <mzanetti> fginther: afaics the month without CI introduced a lot of testing failures...
[14:16] <mzanetti> fginther: I'm going to check our tests and contact you later on how to proceed
[14:16] <mzanetti> thanks a bunch so far
[14:16] <fginther> mzanetti, please let me know if I can help
[14:16] <mzanetti> fginther: I will
[14:16] <mzanetti> fginther: but I need to figure what failures are our tests and what failures are in the CI system first
[14:20] <mzanetti> Cimi: fixed btw
[14:27] <Saviq> MacSlow, hey, could you please look at https://code.launchpad.net/~larsu/notify-osd/allow-being-replaced/+merge/192990 when you have a minute
[14:27] <Saviq> MacSlow, we want notify-osd to give up the service name when unity8 starts
[14:28] <MacSlow> Saviq, yeah... saw Lars' eMail... on my radar today.
[14:28] <Saviq> MacSlow, ok great, thanks
[14:28] <larsu> MacSlow: let me know when you have any questions
[14:28] <MacSlow> larsu, ok
[14:30] <Saviq> nic-doffay, hey, I didn't get a chance to find you anything major to do - but there's plenty of bugs waiting to be fixed - couldn't find nothing interesting?
[14:30] <MacSlow> Saviq, btw... solved all the issues/regression due to the fullscreen-support for the sim-unlock ext. snap-decision
[14:31] <tsdgeos> dandrader: standup?
[14:40] <Saviq> MacSlow, cool
[14:40]  * Saviq → breakfast, ttyl
[14:44] <nic-doffay> Saviq, I haven't look yet, it was more of a pre-emptive ask for an hour or two from now!
[14:47] <mzanetti> MacSlow: do you know why Notification AP tests fail in jenkins?
[14:47] <MacSlow> mzanetti, last time I saw them fail was due to timeouts
[14:48] <mzanetti> MacSlow: http://10.97.0.26:8080/job/autopilot-testrunner-otto-trusty/144/
[14:48] <MacSlow> mzanetti, afaik they've started failing since the move to t
[14:49] <Cimi> Saviq, how is there?
[14:49] <MacSlow> mzanetti, since the AP-test didn't change I expect some underlying (maybe autopilot itself) parts to have introduced this regression
[14:51] <MacSlow> mzanetti, I can try diving into that after I did the MRs for the fullscreen-support and worked on larsu's notify-osd branch he and Saviq asked for
[14:56] <MacSlow> mzanetti, will that work for you?
[14:57] <mzanetti> MacSlow: sure. I'll try collect some more input for you in the meantime
[14:58] <MacSlow> mzanetti, only autopilot-related bit I remember is a switch from ap 1.3 to 1.4 when going from s to t... but not sure what that actually comes with in terms of changes
[15:35] <Saviq> MacSlow, mzanetti not due to timeouts
[15:35] <MacSlow> Saviq, what's the cause then?
[15:35] <Saviq> MacSlow, mzanetti, due to notify-osd stealing notifications from unity8
[15:35] <Saviq> at least that's my suspicion
[15:35] <MacSlow> Saviq, ah... so my unity-notification branch will come in handy then :)
[15:36] <Saviq> MacSlow, mzanetti and that's exactly what the notify-osd and unity-notifications MPs from larsu are about
[15:36] <MacSlow> Saviq, larsu: you have the lp:unity-notification part of the service-request problem already?
[15:37] <Saviq> MacSlow, https://code.launchpad.net/~larsu/unity-notifications/replace-existing-service/+merge/192989
[15:37] <Saviq> MacSlow, only thing missing is notify-osd exiting gracefully when having been replaced
[15:37] <MacSlow> Saviq, from larsu comment I took I needed to do the unity-notification parts still...
[15:37] <Saviq> otherwise we'll be leaving ghoul notify-osd things
[15:38] <Saviq> MacSlow, no, he made it non-replaceable is all
[15:38] <Saviq> MacSlow, http://bazaar.launchpad.net/~larsu/unity-notifications/replace-existing-service/revision/187
[15:38] <MacSlow> Saviq, sure... then let me test that
[15:38] <Saviq> MacSlow, so the thing should be working, but notify-osd won't exit
[15:39] <Saviq> which we should probably fix
[15:39] <MacSlow> Saviq, yeah... I'm looking into that now
[15:39] <Saviq> MacSlow, if you have anything we can/should take over at your EOD, please let us know
[15:40] <MacSlow> Saviq, I just now jumped on the Dbus issue... hope I can resolve it before my EOD
[15:40] <Saviq> MacSlow, cheers
[15:45] <MacSlow> larsu, Saviq: the taking over (unity8 replacing notify-osd) works using your two branches
[15:45] <MacSlow> larsu, Saviq: what's not working on your end? how did you test it?
[15:45] <Saviq> MacSlow, yeah, notify-osd is still running, though, right?
[15:46] <Saviq> MacSlow, which means the next time notify-osd is triggered, there will be two, then three, then four etc...
[15:46] <MacSlow> Saviq, ah ok... yeah it is...
[15:46] <Saviq> only the last of which will actually handle notifications
[15:46] <mzanetti> anyone knows why our autopilot tests take a minute to start?
[15:47] <Saviq> mzanetti, hud
[15:47] <Saviq> ?
[15:47] <mzanetti> Saviq: ./run works fine
[15:47] <Saviq> mzanetti, that trunk on desktop?
[15:47] <mzanetti> yes
[15:49] <Saviq> mzanetti, started fine here
[15:50] <mzanetti> ok... they don't even seem to start... but wait for like 20 secs on each test to fail
[15:50] <mzanetti> ProcessSearchError: Search criteria returned no results
[15:50] <Saviq> mzanetti, look into ~/.cache/upstart/unity8.log
[15:50] <Saviq> mzanetti, to see why it didn't start
[15:50] <Saviq> mzanetti, you can also manually start with
[15:51] <Saviq> initctl start unity8 BINARY=builddir/unity8
[15:51] <Saviq> this way it starts with upstart (you'll then need initctl stop unity8 to stop it respawning)
[15:51] <mzanetti> Saviq: ah, thanks.
[15:51] <Saviq> we should transition ./run to upstart ,btw
[15:51] <mzanetti> food is ready. will try in a sec
[16:33] <Cimi> does stop() reset timers?
[16:33] <Cimi> like, is stop(); start(); the same or restart() ?
[16:37] <mzanetti> Cimi: yes, it does
[16:37] <Cimi> thx
[16:40] <tsdgeos> mhr3: you there? happened again
[16:40] <tsdgeos> init 100% and home-scope 60% cpu
[16:40] <mhr3> tsdgeos, uuuh :)
[16:41] <mhr3> tsdgeos, so, let's get some logs first
[16:41] <mhr3> `bustle-pcap dbus-traffic.bustle`
[16:41] <mhr3> ctrl+c after a few seconds
[16:42] <mhr3> tsdgeos, perhaps also install upstart-monitor to see if that is doing something interesting
[16:43] <tsdgeos> mhr3: did that, got nothing?¿
[16:43] <mhr3> tsdgeos, as in the file is empty?
[16:43] <tsdgeos> ah saves to a file :D
[16:43] <mhr3> yea, the second param is filename :)
[16:44] <tsdgeos> ok, there's stuff in there
[16:44] <mhr3> pls open a bug and attach it there (+ make it private you never know what's in dbus messages)
[16:45] <mhr3> tsdgeos, anything interesting showing up in upstart-monitor?
[16:45] <tsdgeos> installing
[16:46] <tsdgeos> mhr3: bug against what?
[16:46] <tsdgeos> home-scope?
[16:46] <mhr3> tsdgeos, also, the init using 100% cpu is the one owned by root or your user?
[16:46] <mhr3> tsdgeos, yea, home-scope is fine
[16:46] <mhr3> we'll move it if necessary
[16:47] <tsdgeos> me
[16:47] <mhr3> ok
[16:48] <tsdgeos> mhr3: ran upstart-monitor
[16:48] <tsdgeos> seeing nothing
[16:48] <mhr3> tsdgeos, and last thing, clean your /var/crash if you have any unity-scope-home crash files there, and get a crash file from the home scope
[16:48] <tsdgeos> empty
[16:49] <mhr3> tsdgeos, hmm, i guess it's busy processing some events that are just being discarded then
[16:49] <mhr3> tsdgeos, anyway, `ulimit -c unlimited` and pkill -11 -f unity-scope-home
[16:50] <mhr3> that will produce a crash file ^
[16:50] <tsdgeos> didn't :-S
[16:51] <mhr3> tsdgeos, did you do -11?
[16:51] <tsdgeos> yep
[16:51] <tsdgeos> copied from here
[16:51] <mhr3> wth
[16:52] <tsdgeos> mhr3: in /var/crash you mean the file should end up, right?
[16:52] <mhr3> yea
[16:52] <mhr3> tsdgeos, it might take a while for apport to process the core?
[16:52] <mhr3> although it shouldn't be too long
[16:52] <tsdgeos> don't think so
[16:52] <tsdgeos> top and iotop say nothing is going on
[16:53] <mhr3> tsdgeos, you didn't disable apport or anything like that?
[16:53] <tsdgeos> not that i remember
[16:53] <tsdgeos> but it may have happened
[16:53] <tsdgeos> this is a very old install
[16:54] <mhr3> hmm, clean /var/crash would suggest that... there's always something crashing :)
[16:54] <tsdgeos> yeah
[16:55] <mhr3> tsdgeos, grep enabled /etc/default/apport ?
[16:56] <tsdgeos> enabled=1
[17:23] <MacSlow> Saviq, sadly no news yet on the notification-service takeover front... still trying to figure out why I'm not receiving any "NameLost" or "NameOwnerChanged" signals to which I installed callback-handlers in larsu's notify-osd branch...
[17:23] <Saviq> larsu, pointers ↑?
[17:30] <kgunn> man mterry quits a lot
[17:33] <larsu> MacSlow: you should be receiving a NameLost
[17:33] <larsu> as soon as somebody else tries to grab the name
[17:34] <larsu> (if you allow being replaced)
[17:34] <MacSlow> larsu, not happening
[17:35] <MacSlow> larsu, using your branch with that "G_TYPE_UINT, DBUS_NAME_FLAG_ALLOW_REPLACEMENT," change... maybe that's the wrong way to advertise this? but then... unity8 would not be able to step in...
[17:35] <MacSlow> larsu, lots of unknowns to figure out still
[17:37] <larsu> MacSlow: no, that's exactly right. Do you have a branch somewhere for me to look at?
[17:37] <MacSlow> larsu, one sec... let me push my stuff to a +junk one...
[17:38] <larsu> MacSlow: take you're time. Gotta run for ~15 mins anyway
[17:39] <MacSlow> larsu, I'm past my EOD too... and just said screw it...
[17:41] <MacSlow> larsu, lp:~macslow/+junk/notify-osd-allow-being-replaced (still pushing)
[17:41] <MacSlow> larsu, finished
[17:44] <MacSlow> larsu, just touched src/dbus.c there
[17:54] <larsu> MacSlow: thanks, looking into it now
[18:01] <MacSlow> larsu, oh wait...
[18:02] <MacSlow> larsu, I fixed it... just pushing
[18:03] <MacSlow> larsu, I can continue on that if you need to run
[18:04] <larsu> MacSlow: I already did but I also have tons of other stuff to do. Would be nice if you continued if you found the bug
[18:05] <MacSlow> larsu, sure... I'll push a proper branch (non-junk) against yours once I've it all running cleanly...
[18:05] <MacSlow> larsu, watch you inbox by tomorrow
[18:05] <larsu> MacSlow: awesome. Have a nice evening!
[18:33] <ricotz> larsu, hi :)
[18:34] <ricotz> larsu, i am hoping you received my mail
[18:35] <larsu> ricotz: ah sorry I did and meant to answer
[18:35]  * larsu is on a sprint right now
[18:35] <ricotz> larsu, ok, don't worry, just wanted to make sure it reached you
[18:36] <larsu> ricotz: it did. It looks like I'll have time to port that patch early this cycle.
[18:38] <ricotz> larsu, having it soon would be great :) while it is pretty much integrated and its absence breaks things
[18:39] <MacSlow> Saviq, all done... MR for notify-osd is up
[18:40] <Saviq> MacSlow, awesome, thanks
[18:40] <MacSlow> Saviq, see you tomorrow... emails also sent with a quick summary.
[18:56] <Saviq> larsu, that looks good in you G-spectacles https://code.launchpad.net/~macslow/notify-osd/exit-if-being-replaced/+merge/193121 ?
[18:59] <larsu> Saviq: yes, this looks like it's working. Connecting gtk_main_quit directly to the dbus signal is a bit ugly, but won't be a problem
[18:59] <larsu> Saviq: do you want me to comment on the MR?
[18:59] <Saviq> larsu, yeah, that was what I was hoping for input on
[19:00] <larsu> Saviq: ok. I'll approve
[19:00] <Saviq> larsu, you'd rather have a "quit()" that would do cleanup and call gtk_main_quit at the end?
[19:01] <larsu> Saviq: yes, that would be cleaner. The signal puts arguments on the stack. Usually we connect to funtions that expect these arguments. It will work in this case because gtk_main_quit() doesn't take any arguments
[19:01] <larsu> so it just ignores the stack
[19:02] <larsu> I say it's fine, that code base is a bit of a mess at this point anyway
[19:02] <Saviq> larsu, k