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