[07:01] <tsdgeos> pstolowski: hi there, you taking care of the unity-scopes-shell failure in http://people.canonical.com/~platform/citrain_dashboard/#?q=ubuntu%2Flanding-005 ?
[07:02] <pstolowski> tsdgeos, hi! yeah, looking
[07:03] <tsdgeos> :)
[08:39] <tsdgeos> mzanetti: https://code.launchpad.net/~aacid/unity8/fixTodayScope/+merge/262564 fixes the problem with the label being too long
[08:40] <mzanetti> nice!
[08:40] <tsdgeos> basically the label was inside a row and that means you need to set the width if want to limit it not going over the margin
[09:12] <pstolowski> tsdgeos, hey, fix for silo5 on the way, going to reconfig & rebuild
[09:12] <tsdgeos> cool :)
[09:12] <tsdgeos> mzanetti: ↑↑
[09:13] <mzanetti> not sure what fix exactly, but great :D fixes are always good
[09:18] <tsdgeos> mzanetti: what silo are we landing /waiting for QA?
[09:22] <tsdgeos> mzanetti: also do we plan on landing https://code.launchpad.net/~unity-team/unity8/autopkgtests/+merge/258027 soon-ish?
[09:22] <tsdgeos> it's a bit of a pita to keep updating for every new stuff we introduce
[09:23] <mzanetti> tsdgeos, this one is qa approved since friday: http://people.canonical.com/~platform/citrain_dashboard/#?q=ubuntu%2Flanding-026
[09:23] <mzanetti> tsdgeos, should hopefully land soon
[09:24] <tsdgeos> cool
[09:38] <tsdgeos> ltinkl: you running the script on the wrong branch
[09:39] <tsdgeos>  lp:~lukas-kde/unity8/unity8DbusSessionService != ~/bzr/unity8/asyncDbusCalls/
[09:39] <ltinkl> tsdgeos, ok, getting one more coffee :)
[09:40] <tsdgeos> ltinkl: also removing the tags from the local branch won't make the remote one clean
[09:40] <tsdgeos> you need to clean both the one in your PC and the one in launchpad
[09:40] <ltinkl> tsdgeos, push? (with soem special flag)
[09:41] <tsdgeos> ltinkl: just run the script on the remote branch
[09:41] <ltinkl> ltinkl: ok
[09:55] <tsdgeos> mzanetti: i'm confused
[09:55] <tsdgeos> http://people.canonical.com/~platform/citrain_dashboard/#?q=ubuntu%2Flanding-026 says we're landing https://code.launchpad.net/~dandrader/unity8/fixShellTests/+merge/262323 but it has a merge conflict?
[09:55] <mzanetti> welcome to the club
[09:55] <mzanetti> don't touch it :D
[09:55] <mzanetti> daniel needs to revert his last commit
[09:55] <mzanetti> then it'll be fine
[09:56] <tsdgeos> daniel is awol today :/
[09:56] <mzanetti> nooooo
[09:56] <tsdgeos> he sent an email
[09:56] <mzanetti> he superseded it after it has been built in the silo
[09:56] <mzanetti> fuck
[09:56] <mzanetti> oops. sorry
[09:57] <tsdgeos> maybe you can still catch him
[09:57] <tsdgeos> or telegram him
[09:57] <tsdgeos> if it's just 5 min stuff
[09:59] <mzanetti> yeah, it's only 2 minutes stuff
[09:59] <mzanetti> but he doesn't seem to be online on telegram
[10:05] <ltinkl> mzanetti, tsdgeos : I wonder if those things could be run automatically on the server by some bzr hooks (like the tag or conflict checks)
[10:06] <mzanetti> yeah... I proposed the server-side tag stripping/checking multiple times already. Don't really remember why I always got overruled
[10:26] <mzanetti> tsdgeos, ok... silo 26 is publishing
[10:26] <tsdgeos> nice
[10:26] <tsdgeos> how did that happen?
[10:26] <mzanetti> I reached Daniel, he reverted the commit
[10:27] <mzanetti> tsdgeos, so. yes, I'd like to activate the autopkgtests now
[10:27] <tsdgeos> cool
[10:27] <tsdgeos> let's wait for this to land
[10:27] <tsdgeos> and i'll update it
[10:38] <tsdgeos> ltinkl: https://code.launchpad.net/~lukas-kde/unity8/unity8DbusSessionService/+merge/262439 and https://code.launchpad.net/~lukas-kde/unity8/asyncDbusCalls/+merge/262322 start with similar diffs in AccountsService.cpp
[10:38] <tsdgeos> should one be prerequisite from the other?
[10:38] <ltinkl> tsdgeos, let me check
[11:00] <ltinkl> tsdgeos, should be ok now
[11:03] <tsdgeos> k
[11:23] <pstolowski> tsdgeos, silo 5 built. btw, do you know of the issue with card sizes wrt audio card?
[11:23] <tsdgeos> i do not
[11:24] <tsdgeos> pstolowski: what is the problem?
[11:26] <pstolowski> tsdgeos, forwarded you the email
[11:26] <pstolowski> mzanetti, hey, you have investigated this ^ a bit, haven't you?
[11:27] <tsdgeos> ah yeah you can't do that
[11:27] <mzanetti> yes
[11:27] <tsdgeos> hmmm
[11:27] <mzanetti> so the audio cards are too big
[11:27] <tsdgeos> you need to accomodate space for everything
[11:27] <tsdgeos> and then the art needs to be square
[11:27] <tsdgeos> so they'll be bigger than the others
[11:28] <tsdgeos> i can check if the height calculation is broken
[11:28] <tsdgeos> but given that they need to have more stuff than the others
[11:28] <tsdgeos> they'll always be taller and hence the art will be wider
[11:28] <tsdgeos> nothing we can do about it as far as i can see
[11:29] <pstolowski> uhm, i see
[11:30] <tsdgeos> pstolowski: how do i get that image, install silo 5 and that will do it?
[11:31] <tsdgeos> and some local music i guess?
[11:31] <pstolowski> tsdgeos, yes
[11:33] <tsdgeos> food now
[11:34] <tsdgeos> will see if i can do something about it later
[11:34] <tsdgeos> and if not try to write some small text explaining why it happens
[11:37] <pstolowski> tsdgeos, i'm actually wondering if she wasn't asking to only display audio cards in surfacing mode which would solve the problem, but i can't find any evidence in my logs. need to catch her
[11:38] <pstolowski> tsdgeos, so hold on with any code changes for the moment until i confirm
[12:37] <tsdgeos> pstolowski: oki
[13:07] <ltinkl> seb128: ping
[13:07] <seb128> ltinkl, contextless ping ...
[13:08] <ltinkl> seb128, sorry then, I was wondering about the Date&Time module in System Settings; where does it take the list of cities and their corresponding timezone from?
[13:09] <seb128> ltinkl, libtimezonemap /usr/share/libtimezonemap/ui/cities15000.txt
[13:10] <seb128> ltinkl, why?
[14:16] <pete-woods> MacSlow: hi. pretty my silo has broken notifications for accepting calls
[14:16] <pete-woods> any tips for where I should start looking?
[14:17] <MacSlow> pete-woods, what does your silo touch?
[14:17] <pete-woods> MacSlow: this is the unity-notifications silo
[14:17] <MacSlow> pete-woods, unity8, unity-notifications, apps?
[14:17] <pete-woods> the most intrustive thing, is it adds ownership to notifications
[14:18] <pete-woods> so if app A opens a notification, app B cannot close / update it
[14:18] <MacSlow> pete-woods, ? branch?
[14:18] <pete-woods> MacSlow: probably this one is the one you care most about?
[14:18] <pete-woods> https://code.launchpad.net/~pete-woods/unity-notifications/clients-own-their-notifications/+merge/260740
[14:18] <pete-woods> although there are 4 in total
[14:19] <pete-woods> https://code.launchpad.net/~pete-woods/unity-notifications/handle-reopen-notification
[14:19] <pete-woods> https://code.launchpad.net/~pete-woods/unity-notifications/handle-client-death
[14:19] <pete-woods> are the other two interesting ones
[14:19] <MacSlow> pete-woods, do all these pass tests? I assume so... otherwise they would not have been approved...
[14:20] <pete-woods> MacSlow: correct, yes
[14:20] <pete-woods> I have also added additional tests to test the public dbus interface
[14:22] <MacSlow> pete-woods, hm... I can take a closer look... but it'll have to wait after out daily stand up (starting in about 10 min)
[14:23] <pete-woods> MacSlow: the main thing I was hoping for was if you knew the exact client that produces / handles the snap decision for the call accept
[14:23] <pete-woods> is it telephony-service?
[14:24] <MacSlow> pete-woods, yes... but you can keep it even simpler... in lp:unity-notifications/examples are stand-alone python scripts which trigger the different notifiation use-cases without having to setup the whole stack
[14:24] <pete-woods> MacSlow: my main concern is that I've broken the command line tools
[14:25] <pete-woods> as they produce a new dbus connection for each use
[14:25] <MacSlow> pete-woods, if lp:unity-notifications/examples/sd-example-incoming-call.py works with you branches it's not the backend or frontend failing... but the app
[14:25] <pete-woods> MacSlow: okay, will fiddle around with that for a while :)
[14:25] <pete-woods> thanks :)
[14:25] <MacSlow> pete-woods, you seem to be breaking the notification-spec with this one though...
[14:26] <pete-woods> thing is we need to be able to handle clients that crash
[14:26] <pete-woods> and get rid of their notifications when they do
[14:26] <pete-woods> so there needs to be some concept of ownership
[14:27] <MacSlow> pete-woods, there's an hint-system in the notification-spec for such extensions
[15:02] <MacSlow> pete-woods, phew... the changes are pretty huge... I'm trying to get my head wrapped around it...
[15:02] <pete-woods> he first commit is the big one
[15:02] <MacSlow> pete-woods, my first tests (with unity8 and unity-notifications but it's pretty broken...
[15:02] <pete-woods> I wanted to enable testing for the dbus API
[15:03] <MacSlow> pete-woods, I'm using your handle-client-death branch which should have all you changes, right?
[15:03] <pete-woods> yeah
[15:03] <pete-woods> but the big changes happen sooner
[15:03] <pete-woods> earlier I mean
[15:03] <pete-woods> where I'm *fairly* confident I don't break it
[15:05] <MacSlow> pete-woods, I'm running unity8 (and your version of the notificatin-backend) and the python-examples don't work at all or break in odd ways...
[15:05] <pete-woods> well that's a good start for debugging
[15:05] <pete-woods> I tried it a bunch on the device
[15:05] <pete-woods> and saw no problems
[15:05] <pete-woods> until the call answering one
[15:06] <pete-woods> although I was mainly focused on indicator-network notifications
[15:07] <MacSlow> pete-woods, from my first investigation I have the impression that all notification-"bubbles" (libnotify-based notifications) are broken
[15:07] <MacSlow> pete-woods, but I need to get a clean unity-notifications and unity8 compiled to... just to be sure for reference...
[15:08] <MacSlow> pete-woods, not that something else broke in odd ways and slipped through the AP/qmltest somehow
[15:13] <MacSlow> pete-woods, here are a few examples of what the notifications should look/behave like in general https://www.youtube.com/playlist?list=PLXvTBWcnTI1M1n66KdFJRyakGlANTTbfQ  those are created by using the python-examples from lp:unity-notifications
[15:13] <pete-woods> MacSlow: thanks for your help
[15:13] <pete-woods> MacSlow: https://code.launchpad.net/~pete-woods/unity-notifications/add-dbus-tests
[15:13] <pete-woods> that branch is the point at which I think we should be pretty safe
[15:16] <MacSlow> pete-woods, I'll grab each branch (starting with add-dbus-test) and test them against the python examples
[15:16] <pete-woods> MacSlow: awesome!
[15:21] <MacSlow> pete-woods, I'll also make a video/screencast for you to see what it should look like when everything works
[15:45] <MacSlow> pete-woods, check your inbox
[15:47] <pete-woods> MacSlow: how are you running up unity8?
[16:00] <pete-woods> mzanetti: I'm getting package 'unity-shell-application=5' not found
[16:00] <pete-woods> when building unity8 overlay
[16:00] <pete-woods> any suggestions?
[16:00] <mzanetti> pete-woods, is your libunity-api-ev up to date?
[16:01] <mzanetti> libunity-api-dev
[16:01] <pete-woods> mzanetti: according to apt it is
[16:02] <pete-woods> 7.97+15.04.20150611-0ubuntu1
[16:02] <pete-woods> is the version I have
[16:02] <mzanetti> pete-woods, you need: 7.97+15.04.20150611-0ubuntu1
[16:02] <mzanetti> pete-woods, it should be in the overlay ppa and/or wily archive
[16:02] <mzanetti> pete-woods, if you want to build on vivid, you need to enable the ppa. on wily it should work ootb, but is not well tested atm
[16:03] <pete-woods> mzanetti: I'm on vivid+overlay
[16:03] <pete-woods> that looks like the version I have
[16:03] <mzanetti> oh... you have that version
[16:03] <mzanetti> one sec then
[16:03] <mzanetti> pete-woods, check the file: /usr/lib/x86_64-linux-gnu/pkgconfig/unity-shell-application.pc
[16:04] <mzanetti> pete-woods, it probably says version 6
[16:04] <mzanetti> which would mean you'd need to merge your branch with trunk
[16:04] <pete-woods> mzanetti: it does
[16:04] <pete-woods> I don't have a branch yet
[16:04] <pete-woods> I'm just trying to build unity8 for vivid+overlay
[16:04] <pete-woods> so I pulled the overlay branch
[16:04] <pete-woods> will try merging with trunk
[16:05] <mzanetti> pete-woods, right, we're not using the overlay branch yet
[16:05] <mzanetti> trunk should build on both
[16:05] <pete-woods> oh
[16:05] <pete-woods> trunk didn't build for me
[16:06] <pete-woods> hmm
[16:06] <pete-woods> lets try again
[16:06]  * mzanetti rebuilds. now you got me curious
[16:06] <pete-woods> FAILED: : && /usr/bin/ccache  g++  -fvisibility=hidden -std=c++11 -fno-permissive -pedantic -Wall -Wextra -g   tests/plugins/LightDM/CMakeFiles/GreeterDBusTestExec.dir/dbus.cpp.o tests/plugins/LightDM/CMakeFiles/GreeterDBusTestExec.dir/__/__/__/plugins/LightDM/Greeter.cpp.o tests/plugins/LightDM/CMakeFiles/GreeterDBusTestExec.dir/GreeterDBusTestExec_automoc.cpp.o  -o tests/plugins/LightDM/GreeterDBusTestExec  -r
[16:06] <pete-woods> /usr/bin/ld: cannot find -llightdm-qt5-2
[16:07] <pete-woods> I figured trunk needed some new lightdm not in the overlay
[16:07] <pete-woods> so I switched to the overlay branch
[16:07] <pete-woods> mzanetti: ^
[16:07] <mzanetti> should not be the case. let me try to find it
[16:08] <mzanetti> still building. that lib should be part of the unity8 codebase tho
[16:08] <mzanetti> pete-woods, how are you building it? with the ./build.sh script?
[16:09] <pete-woods> mzanetti: yep
[16:09] <pete-woods> ran ./build.sh -s first
[16:09] <pete-woods> deleted builddir just to be paranoid
[16:09] <pete-woods> and then ran the script normally
[16:11] <pete-woods> sudo apt-get install liblightdm-qt5-2-dev
[16:11] <pete-woods> doesn't find the package
[16:11] <pete-woods> which to me sounds like the problem
[16:11] <pete-woods> there's a version 3, I think
[16:12] <pete-woods> liblightdm-qt5-3-dev
[16:12] <mzanetti> pete-woods, it's in ./builddir/plugins/LightDM/liblightdm/liblightdm-qt5-2.so
[16:12] <mzanetti> at least it should be
[16:12] <pete-woods> isn't that a plugin
[16:12] <pete-woods> I didn't think you were supposed to link against plugins
[16:13] <mzanetti> pete-woods, afaict the linker error happens within the LightDM plugin
[16:13] <mzanetti> pete-woods, the plugin internally links to different versions of that lib
[16:13] <pete-woods> ah yeah
[16:13] <pete-woods> that makes sense
[16:13] <pete-woods> well that lib hasn't built for me
[16:14] <pete-woods> I'm using ninja I think
[16:14] <pete-woods> could this be a parallel / dependency ordering issue?
[16:14] <pete-woods> apt-get install ninja-build
[16:15] <pete-woods> I'm hacking the build.sh to not look for ninja
[16:17] <pete-woods> mzanetti: looking like that was the issue
[16:17] <pete-woods> building with make and we're good so far
[16:18] <pete-woods> up to building tests now
[16:18] <mzanetti> pete-woods, good catch!
[16:18] <mzanetti> will get it sorted
[16:18] <pete-woods> mzanetti: thanks :)
[16:20] <pete-woods> damn make is slow compared to ninja
[17:19] <mzanetti> lol... note to myself. Do not run "make tryShell" and press the reboot button in there