| sgx1 | hi. now there're two mir PPAs, which one to use? installing_prebuilt_mir_on_pc.md suggests using system-compositor-testing ppa. but i find packages in Mir staging ppa are newer. | 04:17 |
|---|---|---|
| === wgrant_ is now known as wgrant | ||
| larsu | Saviq: I have unity8 running on my desktop, but can't unlock it. Is there a trick? | 07:43 |
| larsu | Saviq: also, good morning :) | 07:43 |
| larsu | lol, maximizing the window allows "tap to unlock", that works. Responsive ftw! | 07:44 |
| larsu | still can't bring down the indicators though | 07:47 |
| sil2100 | jibel: morning! | 08:09 |
| sil2100 | jibel: so, it seems that the same problem as yesterday struck intel this time! | 08:10 |
| sil2100 | jibel: https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/580/label=autopilot-intel/console | 08:10 |
| Saviq | larsu, use ./run | 08:11 |
| Saviq | larsu, it will convert mouse to touch | 08:11 |
| Saviq | larsu, ./run -h has some options | 08:11 |
| Saviq | veebers, the "Declined" was for next week when I'm in IoM | 08:16 |
| veebers | Saviq: heh, I figured that out later on when I actually bothered to look at the date :-P | 08:16 |
| larsu | Saviq: ah cool, but that doesn't seem to work from a build-area created by bzr bd | 08:17 |
| larsu | ./run: 71: ./run: ./builddir/unity8: not found | 08:17 |
| Saviq | larsu, -mousetouch, then | 08:17 |
| larsu | Saviq: awesome. thanks :) | 08:17 |
| Saviq | larsu, but we got a nic ./build script that you should probably use :) | 08:18 |
| larsu | Saviq: last time I tried that, a very polite french guy told me I shouldn't ;) | 08:19 |
| Saviq | larsu, if you want to hack on it - yes you should - otherwise it's available in ppa:ubuntu-unity/next | 08:20 |
| larsu | heh, thanks | 08:21 |
| nic-doffay | Saviq, did you see those questions I shot off to you yesterday? | 08:23 |
| Saviq | nic-doffay, yeah, but I'm not sure I understood them :) | 08:23 |
| nic-doffay | Saviq, here's an example: http://img824.imageshack.us/img824/4346/yk3k.png | 08:23 |
| Saviq | oh goo | 08:24 |
| Saviq | d | 08:24 |
| Saviq | nic-doffay, just clip: true it | 08:24 |
| Saviq | nic-doffay, also, the highlight goes out of the shape | 08:24 |
| Saviq | nic-doffay, you need to use the trick we have in UbuntuShapeForItem.qml | 08:25 |
| Saviq | nic-doffay, and that's actually all you need to do - no clipping required | 08:25 |
| Saviq | nic-doffay, as UbuntuShape will take care of that for you | 08:25 |
| === jasoncwarner__ is now known as jasoncwarner_ | ||
| === seb128_ is now known as seb128 | ||
| jibel | sil2100, I applied the same changes to intel than ATI. That should fix the problem, but it is not normal that tests consume so much memory. | 08:43 |
| sil2100 | jibel: indeed... | 08:43 |
| sil2100 | didrocks: ^ | 08:43 |
| sil2100 | jibel: thanks! | 08:43 |
| didrocks | jibel: ah, you think the memory is fragmented on it? | 08:44 |
| jibel | didrocks, I increased memory limit to 5G on ATI yesterday | 08:44 |
| didrocks | and so tests don't start | 08:44 |
| didrocks | ok | 08:44 |
| nic-doffay | Saviq, I dced there did you get those last few messages? | 08:44 |
| jibel | and just did the same on intel | 08:44 |
| Saviq | <Saviq> nic-doffay, you need to use the trick we have in UbuntuShapeForItem.qml | 08:44 |
| Saviq | nic-doffay, and that's actually all you need to do - no clipping required | 08:44 |
| Saviq | nic-doffay, as UbuntuShape will take care of that for you | 08:44 |
| didrocks | lxc-attach: failed to open log file "/var/log/lxc/saucy-i386-20130723-0916.log" : Read-only file system | 08:44 |
| didrocks | jibel: hum? ^ | 08:45 |
| didrocks | -bash: /usr/bin/less: Input/output error | 08:45 |
| nic-doffay | Saviq, could you tell me more about the trick? | 08:46 |
| jibel | didrocks, the machine is badly damages | 08:46 |
| jibel | damaged | 08:46 |
| didrocks | jibel: yeah, seems so… | 08:47 |
| jibel | I'll reboot it | 08:47 |
| didrocks | thanks! | 08:47 |
| Saviq | nic-doffay, read UbuntuTouchForItem.qml, is all you need | 08:47 |
| Saviq | nic-doffay, it's in unity8 | 08:47 |
| Saviq | nic-doffay, it takes any Item from QML and shapes it | 08:47 |
| Saviq | sil2100, didrocks, hey, how are we looking on unity8 daily release? | 08:53 |
| didrocks | Saviq: we are trying to get stuff releasing first, I'm working on Mir, not sure sil2100 had the time since yesterday evening to tests with trying to release unity7 | 08:53 |
| sil2100 | Saviq: ah, right! Let me finish tweaking the branch and getting it in | 08:53 |
| Saviq | didrocks, sil2100 thanks! | 08:54 |
| didrocks | jibel: are you collecting anything? I can try rebooting, we never know by chance… | 08:55 |
| dandrader | dednick, hey, you owe me a code review! -> http://paste.ubuntu.com/5906906/ | 08:56 |
| * dandrader never forgets | 08:57 | |
| jibel | didrocks, the machine must be rebooted electrically but for this to happen, I need a working java plugin | 08:57 |
| didrocks | argh, ok | 08:57 |
| dednick | dandrader: woops. | 08:57 |
| dednick | dandrader: ok. i'll get on it this morning | 08:58 |
| jibel | didrocks, it is rebooting | 08:58 |
| didrocks | thanks jibel | 08:59 |
| jibel | didrocks, sil2100 ATI seems to be back up | 08:59 |
| didrocks | jibel: thanks, let's see how next test behave | 09:00 |
| sil2100 | jibel: thanks! | 09:01 |
| sil2100 | didrocks: should I re-run QA later? | 09:01 |
| didrocks | sil2100: yeah | 09:01 |
| Saviq | tsdgeos, any idea about http://pastebin.ubuntu.com/5906920/ ? | 09:06 |
| Saviq | tsdgeos, it's what happens in the VM I sent out last week every 3rd unity8 autopilot test or so | 09:06 |
| tsdgeos | nope | 09:07 |
| tsdgeos | but i think i've seen it sometimes | 09:07 |
| tsdgeos | crash at startup¿ | 09:07 |
| Saviq | tsdgeos, not sure if at startup | 09:07 |
| Saviq | tsdgeos, as it says handling keyboard | 09:07 |
| Saviq | mardy, actually you said you know the xcb backend ↑↑ | 09:07 |
| tsdgeos | window=0x0 | 09:08 |
| Saviq | tsdgeos, ah! but it only happens for the lockscreen tests | 09:08 |
| tsdgeos | i guess that's bad :D | 09:08 |
| Saviq | tsdgeos, so very much keyboard related | 09:08 |
| Saviq | tsdgeos, autopilot might be injecting something badly | 09:08 |
| tsdgeos | or the xcb plugin may not be "that good" | 09:09 |
| Saviq | tsdgeos, re: crash on startup, I'm trying to get a core on manta now | 09:09 |
| Saviq | tsdgeos, as 1 in some 50 ap tests we're indeed crashing on startup | 09:09 |
| Saviq | obviously now that I enabled cores | 09:10 |
| Saviq | 50 tests later - no crash | 09:10 |
| tsdgeos | :D | 09:10 |
| tsdgeos | obviously | 09:10 |
| Saviq | tsdgeos, yeah, the crash above - definitely related to keyboard - only crashes on passphrase tests and not on startup - as I can see the thing | 09:11 |
| tsdgeos | oka, no clue then ;./ | 09:11 |
| Saviq | ok, /me gets some time back, biab | 09:12 |
| sil2100 | didrocks: https://code.launchpad.net/~sil2100/cupstream2distro-config/add_check_to_unity8/+merge/176407 <- I think this should be more like it | 09:15 |
| sil2100 | didrocks: probably the packages list will need tweaking, but that's all I could do without having the test environment | 09:16 |
| didrocks | sil2100: as told yesterday, unity-launcher-impl-2 isn't a virtual package? | 09:16 |
| didrocks | ah, diff not updated maybe | 09:16 |
| sil2100 | It is, it's removed from the package list ;) | 09:16 |
| didrocks | sil2100: yeah, ensure the package list is good :) | 09:16 |
| didrocks | then, will just ack it | 09:16 |
| sil2100 | didrocks: we'll know for sure if the list is OK after the check job is ran at least once ;p | 09:17 |
| didrocks | sil2100: yeah, just do a manual run once it's free | 09:17 |
| sil2100 | didrocks: AH! So we have unity8 packages in the daily-build PPA? | 09:18 |
| sil2100 | didrocks: I have no idea why I though that they didn't build even once ;/ | 09:18 |
| gatox | hi, do you guys know if ./run_on_device is working?? | 09:18 |
| didrocks | sil2100: daily-build-next | 09:18 |
| sil2100 | didrocks: eeeh, so my manual mambo-jumbo was unneecessary | 09:18 |
| didrocks | see ppa and dest: | 09:18 |
| sil2100 | Right | 09:18 |
| gatox | didrocks, hi, do you know if ./run_on_device is working?? | 09:22 |
| didrocks | gatox: sorry, I never use that command | 09:22 |
| gatox | ack, thx | 09:22 |
| mardy | Saviq: I only touched QXcbWindow :-p | 09:23 |
| gatox | didrocks, do you know who can i ask that? | 09:23 |
| didrocks | gatox: maybe try on #ubuntu-touch as well? | 09:23 |
| nic-doffay | Saviq, I just looked at UbuntuShapeForItem.qml | 09:32 |
| nic-doffay | I don't see what could be of help there? | 09:32 |
| sil2100 | Saviq_: hi! | 10:19 |
| sil2100 | Saviq_: so, I fixed up the test packages list to enable the check job for the unity8 stack, I also did a test run in jenkins | 10:20 |
| sil2100 | Saviq_: there are some test failures though - could you and your team take a look? | 10:20 |
| sil2100 | Saviq_: https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/591/ | 10:20 |
| === dandrader is now known as dandrader|afk | ||
| Saviq | sil2100, uhm, that's not "some" failures - every single test failed | 10:53 |
| Saviq | sil2100, "09:58:41.723 INFO __init__:333 - DBusException while attempting to get PID for org.freedesktop.DBus: DBusException("Could not get PID of name 'org.freedesktop.DBus': no such name",)" | 10:53 |
| Saviq | sil2100, that sounds bad? | 10:54 |
| sil2100 | Every single test? I saw there were 20 tests and 11 failed, so hm | 10:54 |
| sil2100 | But maybe I looked wrong? | 10:54 |
| Saviq | sil2100, https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/591/ says "22 errors"? | 10:54 |
| sil2100 | Saviq: in overall, 11 on one machine and 11 on the other | 10:55 |
| Saviq | sil2100, yeah, 11 tests with multiple scenarios | 10:55 |
| sil2100 | Saviq: so it's 11/20 | 10:55 |
| sil2100 | So, it looks as if 9 still passed? | 10:55 |
| Saviq | sil2100, ah, what's your guys' resolution? | 10:56 |
| Saviq | sil2100, and could we have recordmydesktop? | 10:56 |
| sil2100 | Saviq: there is recordmydesktop :) Let me paste you the link to the videos | 10:57 |
| sil2100 | Saviq: https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/591/label=autopilot-ati/artifact/results/autopilot/videos/ <- from ATI | 10:57 |
| Saviq | sil2100, so, for the two indicator_client ones we need indicator-battery | 10:57 |
| sil2100 | Ok, noted | 10:58 |
| sil2100 | Will add that | 10:58 |
| Saviq | sil2100, except it's not available in distro... | 10:58 |
| sil2100 | Saviq: so it's not the same as indicator-power? | 10:58 |
| Saviq | sil2100, no, not yet | 10:58 |
| sil2100 | hmmm | 10:58 |
| Saviq | sil2100, we're moving *onto* indicator-power soon, though | 10:58 |
| Saviq | sil2100, so it might not make sense to do anything there | 10:58 |
| Saviq | sil2100, and https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/591/label=autopilot-ati/artifact/results/autopilot/videos/unity8.shell.tests.test_hud.TestHud.test_hide_hud_click%20%28Desktop%20Nexus%2010%29.ogv | 10:59 |
| Saviq | sil2100, our window didn't fit, 'cause of the launcher... | 10:59 |
| Saviq | let me see if we can make that better | 10:59 |
| sil2100 | Saviq: so as didrocks mentioned, some errors might be related to interaction with unity7... ok | 11:00 |
| Saviq | sil2100, we do adapt to smaller resolutions | 11:00 |
| Saviq | sil2100, by means of halving the size of the window when we don't fit... | 11:00 |
| Saviq | sil2100, but obviously didn't take struts into account | 11:00 |
| didrocks | yeah, it seems struts are not taken into account | 11:01 |
| Saviq | dednick, what's the status of us switching onto indicator-power, btw? | 11:01 |
| didrocks | Saviq: on the indicator-power thing, maybe just skip the test for now with a big blinking TODO/FIXME? :) | 11:01 |
| sil2100 | ;) | 11:01 |
| Saviq | didrocks, yeah, will probably skip them | 11:02 |
| dednick | Saviq: we need new qmenumodel from larsu before we do any new indicators. new ones are somewhat less supposed than we thought. | 11:03 |
| Saviq | :/ | 11:03 |
| Saviq | didrocks, sil2100 for the other one, can we do something? like stop unity7 for the time of the test? | 11:03 |
| dednick | s/supposed/supported | 11:03 |
| Saviq | didrocks, sil2100, or maybe hide the launcher at least | 11:03 |
| Saviq | didrocks, I get that you'd probably rather not :) | 11:03 |
| Saviq | but maybe we can solve it somehow without us reducing the res even more | 11:04 |
| didrocks | Saviq: I would be on the "hide the launcher" | 11:04 |
| didrocks | than stopping unity7 | 11:04 |
| didrocks | (as it will respawn without the upstart job) | 11:04 |
| Saviq | didrocks, yeah, /me too | 11:04 |
| didrocks | Saviq: do you have a way to do that in a setUp() in your tests? | 11:05 |
| Saviq | didrocks, probably - via a gsetting | 11:05 |
| didrocks | right, let me find the key, one sec | 11:05 |
| sil2100 | +1 | 11:05 |
| dednick | Saviq: i was looking into getting them working without it, but it's quite a bit of work that will most likely be removed once unitymenumodel is around. | 11:05 |
| Saviq | dednick, ok | 11:06 |
| dednick | and all the icons are different between battery and power :( so will need to update assets | 11:06 |
| didrocks | Saviq: it's a relocatable key FYI | 11:07 |
| didrocks | Saviq: org.compiz.unityshell | 11:07 |
| === MacSlow is now known as MacSlow|lunch | ||
| didrocks | under /org/compiz/profiles/unity/plugins/ | 11:07 |
| didrocks | launcher-hide-mode | 11:07 |
| Saviq | didrocks, relocatable? | 11:07 |
| didrocks | Saviq: yeah, gsettings relocatable schema | 11:07 |
| Saviq | didrocks, no idea what that means :D | 11:08 |
| didrocks | https://developer.gnome.org/gio/2.32/GSettings.html | 11:08 |
| didrocks | Normally, a schema has as fixed path that determines where the settings are stored in the conceptual global tree of settings. However, schemas can also be 'relocatable', i.e. not equipped with a fixed path. This is useful e.g. when the schema describes an 'account', and you want to be able to store a arbitrary number of accounts. | 11:08 |
| didrocks | Saviq: just a warning the way to access it is under a specific path | 11:08 |
| didrocks | Saviq: this is what I'm doing in gnome-control-center: | 11:09 |
| didrocks | priv->unity_settings = g_settings_new_with_path (UNITY_GSETTINGS_SCHEMA, UNITY_GSETTINGS_PATH); | 11:09 |
| didrocks | with #define UNITY_GSETTINGS_SCHEMA "org.compiz.unityshell" | 11:10 |
| didrocks | #define UNITY_PROFILE_PATH "/org/compiz/profiles/unity/plugins/" | 11:10 |
| didrocks | #define UNITY_GSETTINGS_PATH UNITY_PROFILE_PATH"unityshell/" | 11:10 |
| didrocks | then: | 11:10 |
| didrocks | g_settings_set_int (priv->unity_settings, UNITY_LAUNCHERHIDE_KEY, value); | 11:10 |
| Saviq | tsdgeos, any idea about http://pastebin.ubuntu.com/5907226/ ? | 11:10 |
| didrocks | (value being an int, 0/1) | 11:11 |
| didrocks | UNITY_LAUNCHERHIDE_KEY: "launcher-hide-mode" | 11:11 |
| didrocks | Saviq: does it make sense? | 11:11 |
| Saviq | didrocks, kinda :) | 11:11 |
| Saviq | didrocks, do I have to reset it afterwards? | 11:11 |
| Saviq | didrocks, or are the machines reverted? | 11:12 |
| didrocks | Saviq: the whole machine is snapshotted first, and then reverted | 11:12 |
| Saviq | didrocks, ok | 11:12 |
| didrocks | Saviq: so, don't worry about the revert ;) | 11:13 |
| sil2100 | Saviq: you want to change that in the test's setUp? | 11:13 |
| Saviq | sil2100, yeah, probably | 11:13 |
| sil2100 | Saviq: then the clean way is to add the revert back in a cleanUp call, since setUp is called on every test anyway | 11:13 |
| === dandrader|afk is now known as dandrader | ||
| Saviq | sil2100, yeah, I need to revert in case people run it on their desktops | 11:14 |
| tsdgeos | Saviq: woot | 11:14 |
| tsdgeos | Saviq: where does that come from? | 11:15 |
| Saviq | tsdgeos, crash on manta | 11:15 |
| Saviq | tsdgeos, on startup | 11:15 |
| Saviq | tsdgeos, 1 of every 50 runs or so | 11:15 |
| tsdgeos | wow | 11:15 |
| tsdgeos | nope :-/ | 11:15 |
| Saviq | tsdgeos, although I'm not sure the bt is correct, gdb is not working with me | 11:15 |
| Saviq | tsdgeos, would you care to spend a minute with the core dump? | 11:15 |
| tsdgeos | 5.0 or 5.1? | 11:16 |
| Saviq | tsdgeos, 5.0 | 11:16 |
| Saviq | tsdgeos, good point | 11:16 |
| * Saviq will have to try with 5./1 | 11:16 | |
| Saviq | -/ | 11:16 |
| tsdgeos | yeah i think it's better you try 5.1 first | 11:16 |
| tsdgeos | and if it still crashes then we put some time on it | 11:16 |
| Saviq | tsdgeos, yeah | 11:17 |
| Saviq | ok, /me tries to get qt5.1 going on the device... | 11:17 |
| Saviq | didrocks, sil2100 hmm http://pastebin.ubuntu.com/5907259/ | 11:30 |
| Saviq | didrocks, I seem to be changing something else | 11:30 |
| Saviq | didrocks, as the setting changes, but not in dconf | 11:31 |
| seb128 | Saviq, what's the issue? | 11:35 |
| Saviq | seb128, I'm trying to hide the unity7 launcher for unity8 tests on the machines | 11:38 |
| Saviq | seb128, http://pastebin.ubuntu.com/5907259/ | 11:38 |
| Saviq | seb128, but I seem to be changing something else... | 11:38 |
| seb128 | Saviq, how do you check it's not written in dconf? | 11:40 |
| Saviq | seb128, dconf-editor | 11:40 |
| Saviq | seb128, and the fact unity7 doesn't react :) | 11:40 |
| seb128 | Saviq, what's the env? writting to dconf requires a connection to the service over dbus | 11:41 |
| Saviq | ah | 11:41 |
| Saviq | missing / | 11:41 |
| Saviq | interesting | 11:41 |
| seb128 | it works with it? | 11:41 |
| Saviq | seb128, yeah, trailing slash is needed | 11:41 |
| Saviq | for new_with_path | 11:41 |
| seb128 | that seems error prone, maybe mention it to desrt | 11:42 |
| Saviq | seb128, yeah, will do | 11:43 |
| Saviq | jeez and it segfaults with wrong schema... | 11:44 |
| seb128 | yeah, gsettings abort() on missing schemas | 11:44 |
| seb128 | they are considered as part of the installation | 11:45 |
| Saviq | didrocks, sil2100 bug #1204480 btw | 11:54 |
| ubot5 | bug 1204480 in Autopilot "Display should include strut information" [Wishlist,New] https://launchpad.net/bugs/1204480 | 11:54 |
| mzanetti | Saviq: pong | 11:57 |
| mzanetti | err... ping | 11:57 |
| Saviq | mzanetti, did I ping? | 11:57 |
| Saviq | lol | 11:57 |
| mzanetti | Saviq: do you have a couple of minutes to give some opinion? | 11:57 |
| dandrader | dednick, Saviq: do you mind if I rename the context property ApplicationArguments to applicationArguments? Otherwise it's impossible to mock it from within a QML file. | 11:59 |
| Saviq | dednick, +1, it should never have been uppercase | 12:00 |
| sil2100 | Saviq: true, +1 | 12:00 |
| dednick | dandrader: fine | 12:00 |
| Saviq | mzanetti, gimme 5? | 12:00 |
| mzanetti | Saviq: sure | 12:00 |
| sil2100 | Saviq: let's poke the autopilot guys with that | 12:00 |
| Saviq | seb128, ugh, how can I check if a schema is installed? list_schemas() doesn't include org.compiz.unityshell... | 12:08 |
| Saviq | didrocks, ↑? | 12:09 |
| === MacSlow|lunch is now known as MacSlow | ||
| Saviq | ah list_relocatable_schemas :) | 12:11 |
| seb128 | Saviq, right | 12:15 |
| didrocks | Saviq: back, yeah, I was doing that in g-c-c | 12:34 |
| Saviq | mzanetti, I remember about you, will ping when off the phone | 12:34 |
| mzanetti | Saviq: np | 12:34 |
| mzanetti | tsdgeos: I'm sure you're just waiting for the next ListView bug to fix it, right? | 12:39 |
| mzanetti | :P | 12:39 |
| Saviq | lol | 12:40 |
| dednick | Saviq: ping | 12:57 |
| Saviq | sil2100, https://code.launchpad.net/~saviq/unity8/tweak-autopilot-for-daily/+merge/176679 ← can you test with a branch? | 12:57 |
| tsdgeos | mzanetti: lol no :D | 12:57 |
| tsdgeos | mzanetti: you found one? | 12:57 |
| Saviq | dednick, FIFO :D | 12:57 |
| Saviq | mzanetti, here | 12:58 |
| mzanetti | tsdgeos: yeah... if an item shrinks and the others move with a displace animation and at the same time there is a move() operation in the model which would also trigger the displace animation it leaves a gap between items | 12:58 |
| Saviq | sil2100, should I maybe Recommend gi there? so that it gets installed if it isn't? | 12:59 |
| mzanetti | Saviq: lp:~mzanetti/unity8/dnd-and-quicklists | 12:59 |
| mzanetti | Saviq: I kinda fixed what I wanted to ask before, but still it doesn't look good and as vesar is on vacation I'd like someone else to brainstorm how to do it | 12:59 |
| dednick | Saviq: unping :) | 12:59 |
| mzanetti | Saviq: with that branch, try the drag and drop a bit | 13:00 |
| Saviq | dednick, oof | 13:00 |
| tsdgeos | mzanetti: mind -> explosion | 13:00 |
| mzanetti | tsdgeos: hehe | 13:00 |
| mzanetti | tsdgeos: ok. again, a bit slower: | 13:00 |
| mzanetti | tsdgeos: you have a ListView with items and a displace animation | 13:01 |
| mzanetti | tsdgeos: if one of the items shrinks, the others will move according to that animation | 13:01 |
| mzanetti | tsdgeos: so far that works | 13:01 |
| mzanetti | tsdgeos: now, while this moving happens, there can be a beginMoveRows()/endMoveRows() operation (especially with drag'n'drop) | 13:02 |
| mzanetti | tsdgeos: because of the moving item, the displace animation would be triggered again to animate the reordering | 13:02 |
| mzanetti | tsdgeos: if that collides with the already running animation it breaks somehow and just stops the animation, causing a gap between items | 13:03 |
| sil2100 | Saviq: hmm, currently the jenkins job that allows us to test certain 'branches' is not working, so it would be hard to get this tested ;/ | 13:03 |
| Saviq | sil2100, ok, can you review, then? | 13:03 |
| mzanetti | tsdgeos: you can reproduce with my launcher branch: ~mzanetti/unity8/dnd-and-quicklists | 13:03 |
| tsdgeos | mzanetti: ok, i see, i was thinking of the LVWPH first | 13:03 |
| tsdgeos | and was confused as we don't have displacement animations there | 13:04 |
| tsdgeos | :D | 13:04 |
| Saviq | mzanetti, few things: a) the quicklist should disappear as soon as you move the item out if its initial position (by a minmal threshold like 2dp or something) | 13:04 |
| sil2100 | Saviq: reviewing in a sec | 13:04 |
| Saviq | b) the space where the item is supposed to get back in should be the size of the item, not just a small gap, if the item is over the launcher | 13:05 |
| Saviq | small if its outside of the launcher (see unity7's behaviour here) | 13:05 |
| mzanetti | Saviq: not really according to design | 13:05 |
| mzanetti | ah ok | 13:05 |
| Saviq | mzanetti, when I drop it back in, it's folded at first and unfolds | 13:06 |
| mzanetti | Saviq: yeah. thats requested from design | 13:06 |
| Saviq | wha? | 13:06 |
| Saviq | but you're dragging it unfolded? | 13:06 |
| * Saviq no get it | 13:06 | |
| mzanetti | Saviq: let me forward the design video | 13:06 |
| Saviq | mzanetti, something weird is happening with the folded items at start/end - they get unfolded and refolded when you drop the item | 13:07 |
| Saviq | mzanetti, which, I believe, is a problem again with the small gap and unfolding item | 13:08 |
| mzanetti | Saviq: yeah... those are the things where I wanted to brainstorm | 13:08 |
| mzanetti | Saviq: but wait for the design video so we have a common starting point | 13:08 |
| Saviq | mzanetti, yeah | 13:08 |
| dandrader | dednick, updated https://code.launchpad.net/~dandrader/unity8/lp1116207/+merge/175163 | 13:11 |
| mzanetti | Saviq: http://ubuntuone.com/5LVsZIjJUxwSB3dT1pitJa | 13:15 |
| mzanetti | Saviq: I was told that they agreed on a combination of the first one and the second one | 13:16 |
| mzanetti | Saviq: which means the unfolding when dropping and with the small space | 13:16 |
| Saviq | jeez why is u1 so slow :/ | 13:16 |
| Saviq | 160kBps | 13:17 |
| mzanetti | Saviq: but yeah... I think I need more precise specs | 13:17 |
| Saviq | on a 60Mbps link... | 13:17 |
| mzanetti | yeah... took me quite a while to upload it | 13:17 |
| dednick | dandrader: qmenumodel-qml is part of the install deps for unity8. :( | 13:17 |
| Saviq | mzanetti, people.c.c seems much better recently | 13:17 |
| Saviq | mzanetti, (than u1, that is) | 13:17 |
| mzanetti | Saviq: ok. next time | 13:18 |
| * mzanetti feels slightly sick :/ | 13:18 | |
| Saviq | mzanetti, from all the beer and water you drank on Monday? | 13:18 |
| mzanetti | Saviq: I was fine yesterday... only started like an hour ago | 13:18 |
| mzanetti | but yeah... can't exclude that possibility | 13:19 |
| sil2100 | Saviq: looking at the branch - it's not urgent, but maybe indeed a gir Recommends might be welcome, but we should be temporarily fine without that | 13:21 |
| Saviq | sil2100, I'll add | 13:21 |
| Saviq | sil2100, will gir1.2-glib-2.0 be enough? | 13:22 |
| Saviq | sil2100, or something for python to support gir, too? | 13:22 |
| Saviq | sil2100, python-gi? | 13:23 |
| dednick | dandrader: gr.. ok missing from control source deps, it needs to be in the build-deps then. :( | 13:24 |
| sil2100 | Saviq: I guess we could add that too, since python-dbus recommends python-gi, which is being used by pthon-autopilot but it's best to have both | 13:25 |
| sil2100 | Saviq: so python-gi and gir1.2-glib-2.0 | 13:26 |
| Saviq | sil2100, pushed | 13:27 |
| dandrader | dednick, ermm.. missing what? | 13:27 |
| dednick | qmenumodel-qml | 13:27 |
| dednick | Saviq: if an external library is needed for unity8 tests, then it needs to be in build-deps right? | 13:28 |
| dednick | Saviq: CI qmluitests tests. | 13:28 |
| Saviq | dednick, yes, and runtime | 13:28 |
| dednick | dandrader: ^ can you add qmenumodel-qml to the Source dependencies of debian/control and remove the mock code? should fix the problem. | 13:30 |
| Saviq | dednick, actually | 13:30 |
| Saviq | dednick, I wonder if we should add it to the job directly | 13:30 |
| Saviq | mzanetti, what's your say? | 13:31 |
| Saviq | mzanetti, runtime deps for qmluitests? | 13:31 |
| dednick | Saviq: bzr bd wont work though. | 13:31 |
| dednick | ? | 13:31 |
| dednick | or does it only go though unit tests? | 13:31 |
| Saviq | dednick, is it a qmltest or a qmluitest? | 13:31 |
| mzanetti | Saviq: huh? why would that be required? | 13:31 |
| greyback | Saviq: standup | 13:31 |
| * greyback suspects Saviq secretly enjoys taking notes | 13:32 | |
| mzanetti | lol | 13:32 |
| dednick | Saviq: i'm guessing it's a qmluitest. | 13:33 |
| kgunn | tsdgeos: can you describe a little more "flaky" | 13:34 |
| kgunn | mterry: you forgot to mention you'll support 3 diff optional configs for 3 months ;) | 13:36 |
| sil2100 | Saviq: one small thing before approving globally! | 13:37 |
| mterry | kgunn, :) | 13:37 |
| kgunn | mterry: which btw...i'm only a fan of the one (greeter as regular client) | 13:38 |
| sil2100 | Saviq: could you just add some XXX: comment in the fn_auto_brightness check? | 13:38 |
| tsdgeos | kgunn: apps randomly closing sometimes, and stuff like that | 13:38 |
| sil2100 | Saviq: so that it would be directly visible that it's a workaround | 13:38 |
| kgunn | tsdgeos: oh...wow...yeah, that'd fall in to the category of "flaky" | 13:38 |
| mzanetti | dammit... unity8 still keeps on freaking out on the Nexus4... 80% CPU all the time :( | 13:39 |
| dednick | Saviq: i'm presuming you meant qmlunittest vs qmluitest? | 13:42 |
| tsdgeos | kgunn: after a reboot all is better, i'm guessing that it was the phone was "dirty" after a day of using if for all kind of weird development stuff | 13:43 |
| dandrader | dednick, ok, will try that | 13:43 |
| mterry | greyback, did lp:~unity-team/unity/unity8-mir/ get moved somewhere? | 13:45 |
| greyback | mterry: yep, is now lp:unity-mir | 13:45 |
| mterry | greyback, OK | 13:45 |
| dandrader | dednick, done | 13:46 |
| Saviq | dednick, can you get back on mumble for a sec? | 13:47 |
| mterry | greyback, hrm, hard to merge from it, after having merged from old unity8-mir now that unity8-mir is deleted (bzr can't recreate history) | 13:49 |
| greyback | mterry: oh sorry, I didn't read your message properly | 13:50 |
| === dandrader is now known as dandrader|lunch | ||
| greyback | mterry: lp:unity-mir is a library+qml plugins which unity8 will use. lp:~unity-team/unity8/unity8-integrate-mir/ i spin of unity8 which use unity-mir | 13:51 |
| greyback | mterry: sorry for the change, but this should stabilize now | 13:51 |
| mterry | greyback, ah... ok. the unity8-integrate-mir branch used to be out of date in favor of unity8-mir, IIRC. Now it's back in vogue | 13:51 |
| * mterry 's head spins | 13:51 | |
| Saviq | dednick, yeah, unit ones are run in debhelper's autotest, ui ones are not | 13:51 |
| dednick | dandrader|lunch: sorry to dick about. We want to have it mocked. | 13:52 |
| greyback | mterry: confusion understood, sorry about that | 13:52 |
| mterry | greyback, no worries, I get that we're in flux | 13:52 |
| dandrader|lunch | dednick, ok, will just rollback my last commit then | 13:55 |
| Saviq | sil2100, yeah, doing | 13:55 |
| nic-doffay | Saviq, can you get in touch when you have a moment. | 13:55 |
| Saviq | sil2100, pushed | 13:56 |
| Saviq | nic-doffay, 'fraid it's gonna be in at least an hour, going into a meeting now | 13:57 |
| sil2100 | Saviq: thanks! | 13:57 |
| Saviq | nic-doffay, but write away, if it's a simple one I might push it through in the mean time | 13:57 |
| nic-doffay | Saviq, no problem. It's not too simple sadly. | 13:57 |
| nic-doffay | Can crack on with the selector MP | 13:58 |
| dednick | larsu: how goes qmenumodel ? :) | 14:00 |
| larsu | dednick: reviewing my code from back then right now. MR will come today. | 14:04 |
| larsu | doesn't look like there's much missing | 14:04 |
| larsu | until you look at it I assume :D | 14:04 |
| olli | greyback, Saviq nice video | 14:09 |
| olli | thanks to everybody involved | 14:10 |
| olli | racarr, I guess too | 14:10 |
| greyback | olli: thanks. Working on making it even better | 14:10 |
| olli | greyback, we should get tthat into the test build | 14:11 |
| olli | soon | 14:11 |
| olli | :) | 14:11 |
| Saviq | greyback, you get a slap for not CC'ing olli on the email yesterday ;) | 14:11 |
| * olli will bug saviq and kgunn in a bit about that | 14:11 | |
| dednick | larsu: \o/ | 14:11 |
| greyback | olli: Saviq: I was respecting the chain of command :) | 14:12 |
| Saviq | lol | 14:12 |
| olli | yeah, I get respect | 14:12 |
| olli | d'oh ;) | 14:12 |
| mterry | kgunn, aw crap, I forgot about launching the camera and phone apps in the greeter | 14:14 |
| mterry | kgunn, that may be a blocker for client-only greeter | 14:15 |
| mterry | duh, I'm not used to actually launching those, forgot we do that in greeter session rather than user's | 14:16 |
| seb128 | mterry, hey, does the greeter have an option to make sound on lock/unlock atm? if not is that on the roadmap? | 14:21 |
| mterry | seb128, does not make a sound right now. I don't believe that's on the design mocks. katie ? | 14:22 |
| seb128 | mterry, the system settings mockups have the option: https://wiki.ubuntu.com/Sound?action=AttachFile&do=get&target=phone-settings-sound.png | 14:23 |
| seb128 | mterry, bottom item there | 14:23 |
| katie | mterry, seb128 its not in the design mocks... there is, will be a sound in the future | 14:23 |
| mterry | katie, so not for 13.10? | 14:23 |
| seb128 | hum | 14:23 |
| katie | mterry, seb128 let me find out | 14:24 |
| seb128 | katie, thanks | 14:24 |
| seb128 | we either need to implement it or to drop the item from the system settings for 13.10 | 14:24 |
| Cimi | mm weird | 14:25 |
| Cimi | Saviq, I removed crossfadeimage, added import Ubuntu.Components 0.1 to the tst_CrossFadeImage.qml we have in the shell, just to cross-test | 14:26 |
| Cimi | Saviq, it complains about line 27, "Invalid alias location" | 14:26 |
| Cimi | property alias crossFade: crossFadeImage.crossFade | 14:26 |
| Cimi | but I read SDK code, and crossFade is a public property of CrossFadeImage | 14:27 |
| * Cimi epic fail | 14:27 | |
| Cimi | price to pay when you have too many files opened and you were looking at the wrong one | 14:28 |
| olli | dandrader|lunch, ping | 14:29 |
| katie | seb128, mterry, there are no sounds at the moment.. there will be at some point in the future - that's all I can tell you! | 14:30 |
| Saviq | Cimi, ;) | 14:31 |
| Saviq | mzanetti, tsdgeos can you guys do https://code.launchpad.net/~diegosarmentero/unity8/unity-scope-data/+merge/176274 | 14:31 |
| mzanetti | Saviq: ack | 14:31 |
| mzanetti | was just searching for one I could do | 14:31 |
| Saviq | mzanetti, tsdgeos I'll still look through it, just don't want to block gatox | 14:31 |
| seb128 | mpt, ^ what katie said ... it would be useful to figure out of the "lock sound" is on the roadmap for v1 or not | 14:33 |
| Cimi | Saviq, I realised the SDK has less properties | 14:33 |
| Cimi | Saviq, shall we add them to the SDK? | 14:34 |
| === boiko_ is now known as boiko | ||
| Saviq | Cimi, dunno, you tell me | 14:35 |
| Saviq | Cimi, since the CFI was taken from us, it was removed for a reason, probably? | 14:35 |
| Cimi | Saviq, it's simply removes two properties that were controlling some corner cases | 14:36 |
| Cimi | mzanetti, CFI in SDK lack of crossFade and fadeInFirst properties, you think they are important? | 14:36 |
| Saviq | Cimi, not me you should talk to about those, remember? ;) | 14:36 |
| Cimi | mzanetti, it behaves like with crossFade: false | 14:36 |
| Cimi | mzanetti, and fadeInFirst: false | 14:36 |
| Saviq | Cimi, I think mterry might know, too ↑ | 14:37 |
| mzanetti | Cimi: yeah. they are needed otherwise the Greeter will look weird at startup | 14:37 |
| Cimi | ok | 14:37 |
| sil2100 | greyback: oh noes! | 14:37 |
| Cimi | will ask SDK to add them | 14:37 |
| greyback | sil2100: what??!! | 14:37 |
| mzanetti | Cimi: I'm a bit confused about that testImage you added in the Shell.qml here: https://code.launchpad.net/~unity-team/unity8/unity8.background_gsettings/+merge/174958 | 14:37 |
| mzanetti | Cimi: can't see any reason why this is all needed | 14:38 |
| sil2100 | greyback: hi! I wanted to test some new packaging changes to unity-mir but again there seems to be a FTBFS, I suspect an API change | 14:38 |
| greyback | sil2100: correct, I'm working on it. Gimme an hour | 14:38 |
| sil2100 | <o> | 14:38 |
| sil2100 | greyback: excellent! | 14:38 |
| greyback | sil2100: in then, have a lie down. Nothing to worry about :) | 14:38 |
| Cimi | mzanetti, to fallback when the image is broken? | 14:38 |
| greyback | s/in/until/ | 14:39 |
| mzanetti | Cimi: still don't see why the CrossFade image wouldn't be enough for that | 14:39 |
| Cimi | mzanetti, what? | 14:39 |
| Cimi | mzanetti, we're talking on two different things | 14:39 |
| mzanetti | yes | 14:39 |
| Cimi | mzanetti, one is the branch for gsettings | 14:39 |
| Cimi | mzanetti, one is I am looking into removing crossfadeimage from shell | 14:40 |
| mzanetti | Cimi: yeah. I'm talking about the gsetting branch | 14:40 |
| mzanetti | anyways, I'll check it out and test myseldf | 14:40 |
| mzanetti | -d | 14:40 |
| Cimi | mzanetti, we fallback to the default background | 14:40 |
| Cimi | mzanetti, when the image is broke | 14:40 |
| Cimi | I thought it was a good idea might be wrong | 14:41 |
| mzanetti | Cimi: seems like a rather dirty hack to me... but there could well be things I don't see yet... gimme a few minutes to check details | 14:41 |
| mterry | Cimi, (forgive me if I missed this in scrollback, but) crossfade is used in greeter | 14:42 |
| Cimi | mterry, indeed | 14:42 |
| kgunn | mterry: hmmm, wondering....would camera app be any different than rendering infographic/launcher/pin screen....in a way, its just another window | 14:42 |
| Cimi | mterry, we were wondering if the crossfadeimage in the sdk is enough | 14:42 |
| kgunn | mterry: i don't think this kills the greeter-as-normal-mir-client concept | 14:42 |
| mterry | Cimi, probably. I'm not super familiar, but we don't use anything special from ours | 14:43 |
| mterry | kgunn, camera app is different because it's a separate process | 14:43 |
| mterry | kgunn, we *could* go down the road of making bits of the camera app re-usable in the greeter as native widgets | 14:44 |
| kgunn | mterry: its what i was thinking....but yeah...kinda gives you heartburn thinking about it | 14:44 |
| kgunn | mterry: what you really want it seems is a special way to load camera into greeter process...at least the rendering bits | 14:45 |
| mterry | kgunn, like xembed! ;) | 14:46 |
| mzanetti | Cimi: is there a way to set the background image through command line? | 14:46 |
| kgunn | mterry: surely there's a qt version | 14:47 |
| Cimi | mzanetti, probably through dcong | 14:47 |
| Cimi | dconf | 14:47 |
| kgunn | e.g. just sounds like a problem that would;ve come up enough to do something about | 14:47 |
| mterry | kgunn, I wouldn't be surprised if not. xembed was mostly reviled as a hack | 14:47 |
| kgunn | mterry: one man's hack is another man's much needed soln ;) | 14:48 |
| mterry | kgunn, I mean, we have a solution for "showing a window inside a session" and we call it mirserver, eh? :) | 14:48 |
| kgunn | mterry: true | 14:49 |
| mterry | kgunn, if we want to make camera and phone apps giant qml plugins with the barest of main() wrappers around them, we could re-use them as special cases in the greeter | 14:50 |
| mterry | kgunn, that wouldn't work later when we want to support more apps, but could work for 13.10 | 14:50 |
| kgunn | mterry: yeah | 14:50 |
| kgunn | mterry: i was trying to think...what reasons | 14:50 |
| mzanetti | *shrug* The infographics looks quite bad with a non-purple background | 14:50 |
| kgunn | we had for not wanting to be server side...and only one i can come up with | 14:50 |
| Saviq | jeez what is it, security breach week or something? | 14:50 |
| mzanetti | Saviq: what happened? | 14:51 |
| Saviq | mzanetti, ubuntu forums, OVH, now Simple Machines forums | 14:51 |
| kgunn | is adding a bunch of naff api's to the shell/internal client api of mir | 14:51 |
| kgunn | mterry: or was there something else? | 14:51 |
| kgunn | racarr: ^ | 14:51 |
| mzanetti | Saviq: not to forget developer.apple.com | 14:51 |
| Saviq | mzanetti, didn't know that, not there ;) | 14:51 |
| * Saviq likes him a Password Hasher | 14:52 | |
| mterry | kgunn, hold on one moment | 14:52 |
| kgunn | racarr: we forgot about greeter needing to launch camera app...so we're discussing whether or not we can still go "regaular mir client" with the greeter | 14:52 |
| mterry | kgunn, you're asking why we didn't put the greeter in u-s-c? or why we didn't want to be a mirserver ourselves like the shell? | 14:53 |
| kgunn | mterry: i might need re-education....i thot out of 3 choices, there was 1) greeter in shell (security killer), 2) greeter "like shell" server side of u-s-c's mir, 3) greeter as regular client to u-s-c's mir | 14:55 |
| kgunn | mterry: if this is correct, i assume we're talking about choosing between #2 & 3 | 14:56 |
| mterry | kgunn, there was a fourth option (greeter in u-s-c itself) that was also a security killer | 14:56 |
| mterry | kgunn, so "server side" is a confusing term (in u-s-c or a mirserver talking to u-s-c) | 14:57 |
| mterry | kgunn, but we didn't want to be #2 because there is risk of not getting multiple simultaneous mirservers performant | 14:57 |
| mterry | kgunn, we may *have* to go #2 though | 14:58 |
| === dandrader|lunch is now known as dandrader | ||
| kgunn | mterry: sorry...u-s-c doesn't really do anything but launch a mir server....so, when you say "in usc" i assume you mean the mir it just launched | 14:59 |
| dandrader | olli, pong | 14:59 |
| sil2100 | Saviq: hmm, CI seems a bit irritated with your branch? | 15:00 |
| sil2100 | Saviq: https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-saucy/768/consoleFull | 15:00 |
| Saviq | sil2100, it hanged | 15:00 |
| mterry | kgunn, I'm going to make a quick drawing | 15:00 |
| Saviq | sil2100, it should merge fine | 15:00 |
| sil2100 | Saviq: it's still autolanding, but hm | 15:00 |
| sil2100 | Saviq: ok | 15:00 |
| kgunn | mterry: thanks! needed i think | 15:00 |
| olli | dandrader, is there any chance my magic trackpad can do 2 finger horizontal swipes | 15:01 |
| olli | dandrader, like I can scroll vertically, but not horizontally | 15:02 |
| olli | 13.10 | 15:02 |
| bregma | I don't believe the synaptics driver provides horizontal scrolling | 15:03 |
| Saviq | olli, hmm mine only does with shift | 15:03 |
| dandrader | olli, +1 on what bregma said | 15:04 |
| Saviq | kgunn, you joining? | 15:04 |
| Saviq | greyback, do you remember the google doc where we discussed the orientation? | 15:04 |
| Saviq | greyback, it was some "window management apis" or something | 15:05 |
| greyback | Saviq: not really. Am looking | 15:06 |
| Saviq | greyback, it was your review of the app manager apis | 15:07 |
| greyback | Saviq: https://docs.google.com/a/canonical.com/document/d/1A0ZmFpVdIhkz7zwmdee7749RjdoKiz7erwytbPz4UoE/edit | 15:07 |
| Saviq | uh | 15:07 |
| greyback | had very little to do with orientation | 15:08 |
| mterry | kgunn, shared doc with you | 15:08 |
| kgunn | mterry: will take a look....(busy for a next hour or so...we'll talk more later) | 15:08 |
| mterry | kgunn, k | 15:09 |
| tsdgeos | mzanetti: can you do https://code.launchpad.net/~diegosarmentero/unity8/unity-scope-data/+merge/176274 ? I have the phone setup for unity-mir and going back to "regular unity" it's like 2 hours forth and back at least | 15:11 |
| mzanetti | tsdgeos: ack | 15:11 |
| mzanetti | Cimi: I'd have a IMHO cleaner proposal for this. You ok with me pushing to your branch? | 15:24 |
| mzanetti | Cimi: in case you don't agree you can revert it ofc | 15:24 |
| Cimi | mzanetti, obviusly | 15:25 |
| Cimi | mzanetti, that's why I push with unity-team | 15:26 |
| Cimi | mzanetti, obviusly | 15:26 |
| Cimi | ops | 15:26 |
| mzanetti | Cimi: still I think its not nice to push to someones branch without asking first | 15:28 |
| mzanetti | Cimi: pushed | 15:28 |
| mzanetti | Cimi: I hope I didn't miss some corner cases | 15:28 |
| mzanetti | Cimi: the sourceSize thing is gone, but I think your's didn't work either because CrossFadeImage's sourceSize property is readonly for some reason | 15:29 |
| Cimi | mmm was working for me | 15:29 |
| Cimi | nevermind | 15:29 |
| mzanetti | Cimi: ah right... the backgroundImage was a regular image before... I just changed it to be a CrossFadeImage | 15:31 |
| mzanetti | Cimi: with your latest revision only the Greeter would crossfade, but not the background image | 15:31 |
| Cimi | yes | 15:32 |
| Cimi | mzanetti, and in theory is fine | 15:32 |
| Cimi | mzanetti, because you change the bg from the settings app | 15:32 |
| Cimi | mzanetti, so you won't see the crossfade | 15:32 |
| mzanetti | Cimi: what if the settings app runs in the side stage? | 15:32 |
| mzanetti | Cimi: or windowed on the desktop (in the future) | 15:32 |
| Cimi | mzanetti, I don't have a nexus 10 :P | 15:32 |
| mzanetti | right... | 15:32 |
| Cimi | you're right | 15:33 |
| mzanetti | the easiest way to deal with a problem is to ignore it | 15:33 |
| mzanetti | :P | 15:33 |
| Cimi | which problem? | 15:33 |
| Cimi | hah | 15:33 |
| mzanetti | :D | 15:33 |
| Cimi | bb in a bit | 15:34 |
| Cimi | taking the bus to the office | 15:34 |
| olli | kgunn, bregma, Saviq ... quick follow up thought from the u8/main discussion | 15:50 |
| olli | we have been discussion our opinion whether asac will proceed of getting a FFe or not, but not really what the impact is on us if U8 lands in main | 15:51 |
| olli | Saviq indicated that there ain't none, other than the time it would take to do the watermark | 15:51 |
| olli | as for us it doesn't matter if we are in (Main & FFe) or PPA | 15:52 |
| olli | for touch images | 15:52 |
| Saviq | +1 | 15:52 |
| olli | is that right? | 15:52 |
| kgunn | olli: right....cause we can basically ignore all bugs | 15:52 |
| Saviq | olli, we will just stop releasing into main on FF | 15:52 |
| olli | Saviq, unless asac pulls out the FFe (which we are doubtful of) | 15:52 |
| bregma | so, like doing an upstream release and freezing that version in distro? | 15:53 |
| Cimi | Saviq, filed https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1204565 | 15:53 |
| ubot5 | Launchpad bug 1204565 in Ubuntu UI Toolkit "CrossFadeImage needs properties to control crossfade and fade" [Undecided,New] | 15:53 |
| olli | bregma, I guess and then continue in PPA if we don't have a FFe | 15:53 |
| Saviq | s/main/distro/ | 15:54 |
| Saviq | olli, yup | 15:54 |
| olli | Saviq, and the point about having a better experience in few weeks... if we get a FFe, we can still improve it also for the desktop (basically for free) but if not, we will just take what we have for the desktop | 15:56 |
| olli | but this isn't impacted by or impacting landing u8 in main either, is it? | 15:56 |
| Saviq | olli, no, as long as we're not blocked by FF to work on unity8 or any of its dependencies | 15:57 |
| Saviq | paulliu, hey, with http://pastebin.ubuntu.com/5908021/ I can enable home, but the generic preview fails sometimes with http://pastebin.ubuntu.com/5908027/ | 15:58 |
| Saviq | paulliu, could you have a look tomorrow? | 15:58 |
| paulliu | Saviq: sure | 15:58 |
| olli | Saviq, bregma, kgunn, so to conclude this topic: U8 is being pulled from a PPA today for the touch build, pushing u8 into main will increase the build quality, in the worst case (i.e. no FF for u8 and all its dependencies) we switch back to use a PPA at FF which for us is not an issue... is that a fair statement? | 16:00 |
| Saviq | olli, yes | 16:00 |
| bregma | olli, agreed | 16:00 |
| olli | looking for a +/- 1 from all of you, don't want to override what we just discussed, but I think we discussed the wrong question | 16:00 |
| olli | kgunn, up to you now ;) | 16:01 |
| kgunn | olli: agree | 16:01 |
| Saviq | biab o/ | 16:01 |
| olli | kgunn, Saviq, bregma the only impact/question is... in what position are we with regards to daily landing/daily image tests | 16:02 |
| olli | are we prepared to be green on the dashboards when we land u8 in main | 16:03 |
| Saviq | olli, yes, the three platform-api bugs I posted yesterday have fixes (merged or MR'd at least) | 16:03 |
| Saviq | olli, the occasional crash (about 2% of runs) I'm investigating is in Qt, need to check whether 5.1 helps there | 16:04 |
| Saviq | sil2100, didrocks can you guys push the button on another unity8 test run? | 16:04 |
| sil2100 | Saviq: it's rolling now | 16:05 |
| Saviq | sil2100, ah, awesome | 16:05 |
| sil2100 | Saviq: I already re-deployed and re-ran the stack, waiting for builds to finish | 16:05 |
| Saviq | sil2100, what's the "source" jenkins for it? can I access it through the VPN? | 16:06 |
| sil2100 | Saviq: yes, let me give you the link to the stack | 16:08 |
| sil2100 | greyback: I see your merge to fix the FTBFS in unity-mir! | 16:21 |
| greyback | sil2100: no you don't | 16:21 |
| sil2100 | :( | 16:22 |
| greyback | sil2100: /almost/ there | 16:22 |
| sil2100 | ;) | 16:22 |
| didrocks | sil2100: Saviq: passed \o/ | 16:35 |
| didrocks | Saviq: do you still want blocking publication? | 16:35 |
| didrocks | (in next) | 16:35 |
| greyback | sil2100: quick fix for FTBFS landed, no point blocking you | 16:37 |
| === om26er is now known as om26er_afk | ||
| === om26er_afk is now known as om26er | ||
| dandrader | mzanetti, is autolanding disabled, broken or something of the like? | 17:25 |
| dandrader | my MP is consistently and utterly failing https://code.launchpad.net/~dandrader/unity8/lp1116207/+merge/175163 | 17:27 |
| mzanetti | dandrader: /tmp/buildd/unity8-7.81.3+13.10.20130718ubuntu.unity.next/tests/qmltests/tst_Shell.qml: bad whitespace in line 194 | 17:29 |
| dandrader | mzanetti, excellent! (I'm surprised you're still on duty) where did you find this line? | 17:30 |
| dandrader | mzanetti, nevermind. got it. I should check all those different urls... | 17:30 |
| dandrader | bad dandrader | 17:31 |
| mzanetti | dandrader: cd .bazaar && make isntall | 17:31 |
| mzanetti | dandrader: cd .bazaar && make install | 17:32 |
| dandrader | mzanetti, right, your magic bazaar plugin. thanks | 17:35 |
| dandrader | well, such false alarms should no longer happen :) | 17:35 |
| mzanetti | dandrader: the latest version of the bazaar plugin is really usable imo | 17:36 |
| mzanetti | dandrader: I understand that the first version was way too annoying for anyone to actually use it | 17:37 |
| mzanetti | dandrader: but now it only checks for such nasty mistakes as whitespaces which makes it really fast | 17:37 |
| dandrader | mzanetti, yes, just tried it. works fine | 17:37 |
| dandrader | mzanetti, it simply issues "make test", right? | 17:38 |
| mzanetti | dandrader: yeah. and if it fails, it backups your commit message so you can easily uncommit, fix and commit -F message.txt | 17:38 |
| mzanetti | dandrader: so you don't have to type the message again | 17:38 |
| dandrader | hmm, interesting | 17:38 |
| dandrader | EOD | 17:39 |
| sil2100 | Saviq: \o/ did you see the results? | 17:47 |
| mzanetti | cyphermox: ping | 17:47 |
| sil2100 | Saviq: the check job is green, all tests passed it seems | 17:48 |
| sil2100 | Saviq: sadly, Didier is away so I can't ask him if we have permission to publish the stack | 17:48 |
| mzanetti | sil2100: if it compiles, ship it! | 17:48 |
| mzanetti | :P | 17:48 |
| sil2100 | pff ;p | 17:49 |
| * Saviq reads all the pings... | 18:06 | |
| Saviq | sil2100, yeah, we don't want that yet | 18:16 |
| Saviq | greyback, hey, I asked Jamie to file the bugs against unity-mir as well, so that we make sure we have them fixed/not applicable | 18:18 |
| Saviq | greyback, feel free to reassign if needed https://bugs.launchpad.net/unity-mir | 18:18 |
| greyback | Saviq: ack | 18:18 |
| kgunn | mterry_: ok...i added mir's to your picture & think we are totally thinking the same | 18:23 |
| kgunn | also, in the instance of option4 - i think there are other issues besides security | 18:24 |
| kgunn | that is...what does window management | 18:25 |
| kgunn | acually scratch that | 18:25 |
| kgunn | that's an issue in both 3 & 4 | 18:25 |
| mterry_ | kgunn, yup, looks good. And yeah, window management is a problem. I had previously thought #3 would work because I forgot that the greeter will have clients for 13.10 | 18:26 |
| kgunn | mterry_: so phone and camera... | 18:30 |
| kgunn | mterry_: how does the launcher work? is the shell technically a client ? | 18:31 |
| kgunn | of greeter that is | 18:32 |
| mterry_ | kgunn, no... | 18:36 |
| mterry_ | kgunn, the greeter acts like its own shell. And the launcher widget itself is just a widget, built into the shell (so shell and greeter can share the code, but each have their own launcher) | 18:36 |
| kgunn | mterry_: | 18:37 |
| kgunn | ah | 18:37 |
| mterry_ | kgunn, that's why the launcher and indicators are not a problem, they are just internal widgets | 18:37 |
| mterry_ | kgunn, but obviously phone and camera are different | 18:37 |
| kgunn | mterry_: right...i guess, in order to avoid | 18:37 |
| kgunn | taking in camera/phone components | 18:38 |
| kgunn | we would need camera/phone to | 18:38 |
| kgunn | create a thin main as you were suggesting earlier | 18:38 |
| kgunn | allowing us to "widgetize" them | 18:38 |
| mterry_ | kgunn, yeah | 18:38 |
| mterry_ | have the bulk of their code be in a plugin form, that the greeter could load | 18:39 |
| kgunn | mterry_: i don't really see a way around it | 18:39 |
| mterry_ | kgunn, well, we could do the original option #2 | 18:39 |
| mterry_ | which has its own risks | 18:39 |
| kgunn | mterry_: i actually think tvoss is right on that one tho.... | 18:39 |
| kgunn | mainly we will have performance issues for a while | 18:39 |
| kgunn | as we have deprioritized android bypass | 18:40 |
| kgunn | (+ even if we reprioritize android bypass....its not obvioulsy easy because we use | 18:40 |
| kgunn | binaries and there's lots of assumptions under the hood on many of these hw platforms) | 18:40 |
| kgunn | also...memory | 18:40 |
| kgunn | that's just too damn many framebuffer sized memory chunks floating around | 18:41 |
| mterry_ | kgunn, :-/ | 18:43 |
| mterry_ | kgunn, what about 14.04? Do we think we can go back to option #2 then? | 18:45 |
| kgunn | mterry_: maybe Saviq or others have maybe another idea besides widgetizing | 18:45 |
| kgunn | mterry_: wrt going option#2 for 14.04...possibly | 18:45 |
| kgunn | its still kinda not the most effecient i think...but if bypass is there | 18:46 |
| * Saviq reads backlog | 18:46 | |
| kgunn | then yeah | 18:46 |
| * kgunn shares option diagram with saviq | 18:46 | |
| Saviq | mterry_, kgunn I think I assumed that "greeter" apps would be launched in a guest session | 18:47 |
| Saviq | but then assumed we'd have bypass... | 18:48 |
| cyphermox | mzanetti: pong? | 18:48 |
| mterry_ | Saviq, (a) that's a tad slower and (b) would still introduce another Mir server floating around | 18:48 |
| Saviq | mterry_, kgunn "widgetizing" camera and phone would be good for those, maybe a few other core/trusted apps | 18:50 |
| Saviq | mterry_, kgunn but it's supposed to be possible for all apps to have an unlocked mode | 18:50 |
| mterry_ | Saviq, not for 13.10, but yeah | 18:50 |
| Saviq | mterry_, kgunn like, for example, you can create notes in... notes, events in calendar | 18:51 |
| mterry_ | and even then, theoretically only those that have added explicit support for it. So that could mean this widgetization process | 18:51 |
| Saviq | mterry_, but that would mean running arbitrary code in greeter | 18:51 |
| Saviq | mterry_, I can tell you already security will nix it ;) | 18:51 |
| mterry_ | Saviq, greeter isn't root | 18:52 |
| Saviq | mterry_, but it could still crash it | 18:53 |
| Saviq | mterry_, and do stuff which apps shouldn't be able to do, if it's in the same process | 18:53 |
| mterry_ | Saviq, true, which sucks. But that's a design issue not a security one | 18:53 |
| mterry_ | Saviq, but I agree there are problems with things being in-process | 18:54 |
| mterry_ | Saviq, kgunn: long term, if we want the "arbitrary app can run unlocked in greeter" mode, we'll want the greeter to be a real mirserver | 18:55 |
| Saviq | mterry_, or for it to launch a guest session, right? | 18:56 |
| mterry_ | (or run them in greeter, which is another mirserver anyway) | 18:56 |
| mterry_ | *guest | 18:56 |
| Saviq | mterry_, we could think of a stripped down, no-shell session that would launch almost instantly | 18:57 |
| kgunn | Saviq: you mean "no-shell" session for the apps in question? | 18:58 |
| Saviq | kgunn, yeah, if app is launched in unlocked mode | 18:58 |
| Saviq | kgunn, the app could get launched in a minimal shell | 18:58 |
| Saviq | kgunn, where greeter would still handle launcher and panel | 18:58 |
| Saviq | kgunn, overlaid over the user session (although I understand this may be costly) | 18:59 |
| Saviq | so if people tell me that's not feasible - that's ok | 18:59 |
| mterry_ | Saviq, tough for 13.10 for sure :) | 18:59 |
| Saviq | mterry_, weren't we talking long-term? ;) | 19:00 |
| Saviq | mterry_, for 13.10 I'm good with widgetizing just the core apps | 19:00 |
| Saviq | +few | 19:00 |
| kgunn | Saviq: is that something we should take on? (to minimize external deps :) | 19:00 |
| kgunn | or ask first... | 19:00 |
| Saviq | kgunn, TBH it's QML... | 19:01 |
| mterry_ | kgunn, who is in charge of camera and phone apps? | 19:01 |
| Saviq | mterry_, bfiller | 19:01 |
| mterry_ | Saviq, thanks | 19:01 |
| Saviq | kgunn, so it's already "widgetized" | 19:01 |
| Saviq | kgunn, as long as we set the environment up the way QML expects it, you can just load the app's main QML and be done with it | 19:02 |
| * kgunn loves it when we catch a break | 19:02 | |
| Saviq | QML of the app expects it, I mean | 19:02 |
| Saviq | so it might mean a) fixing the apps to not do stuff in their main() if possible | 19:02 |
| mterry_ | Saviq, depends how easy their qml makes it I imagine | 19:02 |
| Saviq | mterry_, if their main()s are heavy it's wrong anyway | 19:03 |
| === mterry_ is now known as mterry | ||
| Saviq | mterry, and if everything is in plugins - we're done | 19:03 |
| kgunn | Saviq: mterry_ shouldn't the environ be set up proper i mean we are using it for infographic, launcher, pin screen | 19:03 |
| Saviq | kgunn, what I mean by that is that apps may be doing stuff in their main() | 19:03 |
| Saviq | kgunn, like setting some context properties | 19:03 |
| Saviq | kgunn, initializing some stuff | 19:04 |
| Saviq | kgunn, so either we need to do the same in Greeter's main() - but that'd not be nice since we'd be doing it regardless of whether you actually load the app in the greeter or not | 19:04 |
| Saviq | kgunn, or move those out of main() into plugins | 19:04 |
| kgunn | Saviq: gotcha | 19:05 |
| Saviq | kgunn, at which point you just load the QML of the app and you're done | 19:05 |
| Saviq | kgunn, only thing is, of course, that's insecure | 19:05 |
| mterry | Saviq, insecure in that we're loading "arbitrary" qml? | 19:06 |
| Saviq | kgunn, but would be fine for some core apps (even long-term - for them to be faster) | 19:06 |
| Saviq | mterry, yes | 19:06 |
| kgunn | right...but we trust these guys | 19:06 |
| Saviq | mterry, and whatever that QML brings with it | 19:06 |
| mterry | Saviq, not arbitrary, and we're already relatively untrusted | 19:06 |
| Saviq | mterry, with core apps that's not arbitrary - of course | 19:06 |
| kgunn | yea! we're back to greeter as a regular mir client | 19:06 |
| Saviq | mterry, that's why I said it can be fine for core apps | 19:06 |
| kgunn | racarr: ^ | 19:06 |
| mterry | Saviq, yar | 19:06 |
| Saviq | mterry, but long-term that's not going to cut it | 19:07 |
| Saviq | IMO | 19:07 |
| * mterry starts working on that pure-client branch again | 19:07 | |
| Saviq | did you see guys? we've passed the $5M mark a while ago | 19:07 |
| mterry | Saviq, yeah... if we ever want 3rd party apps to do that, I agree | 19:07 |
| Saviq | $40k ago, to be exact | 19:07 |
| mterry | $32 million is so much | 19:07 |
| Saviq | mterry, that's not an if, AFAIK :D | 19:07 |
| Saviq | mterry, it is | 19:07 |
| Saviq | mterry, but the 2.5 days look promising | 19:08 |
| Saviq | btw, just got the Firefox OS phone | 19:08 |
| Saviq | will put out a bigger report later about my feelings | 19:08 |
| mterry | interesting | 19:08 |
| Saviq | but if anyone wants to know anything in particular, ping me | 19:08 |
| Saviq | it's *cheap* for sure... but it's ~€100 with no contract... | 19:08 |
| racarr | kgunn: Err. 5 minutes sorry | 19:09 |
| racarr | almost finished this input stuff | 19:09 |
| kgunn | racarr: no worries...was just telling you we're back to greeter not needing to sully up those internal client i/f's | 19:09 |
| racarr | kgunn: Just to see I understand | 19:11 |
| racarr | the greeter, is running apps, etc (i.e. CAmera in unlocked mode), and they aren't running in a guest session | 19:12 |
| racarr | and are integrated with the greeter UI | 19:12 |
| racarr | so the thought was gthe greeter may have to be a mir compositor | 19:12 |
| racarr | but instead | 19:12 |
| racarr | send around QML for now? | 19:12 |
| kgunn | racarr: bingo | 19:14 |
| kgunn | racarr: basically....those apps being widgets to the greeter | 19:16 |
| racarr | Ok sounds good | 19:18 |
| racarr | I actually have a secret fondness that dates back to college for using javascript as an IPC protocol :p | 19:18 |
| mzanetti | cyphermox: is the pong still valid? | 19:25 |
| cyphermox | mzanetti: yes. the alternative is really boring debugging of bluez | 19:25 |
| mzanetti | cyphermox: ah... thats exactly the topic :) | 19:25 |
| cyphermox | :) | 19:26 |
| cyphermox | mzanetti: what's up? | 19:26 |
| mzanetti | cyphermox: what do I need to do to get the bluetooth chip enabled on the Nexus 4? | 19:26 |
| cyphermox | ah! this is really cool :) | 19:26 |
| cyphermox | mzanetti: take this branch (https://code.launchpad.net/~mathieu-tl/phablet-extras/brcm-rename) and build it on the device, then install the bluetooth-touch package it will create | 19:27 |
| cyphermox | you'll need build-essential debhelper bzr bzr-builddeb | 19:27 |
| cyphermox | and when installing the package you also need rfkill | 19:27 |
| mzanetti | right | 19:28 |
| cyphermox | it's just a few upstart jobs to poke the right things | 19:28 |
| mzanetti | ok... kinda in the middle of something right now (EOD already and this is spare time activity) but I'll probably bug you again in a few if I run into troubles. | 19:28 |
| mzanetti | cyphermox: what I want to do is to check out if QtBluetooth works as expected on our device | 19:29 |
| cyphermox | cool | 19:29 |
| cyphermox | I suspect it probably does, but yes it's a very valuable test | 19:29 |
| cyphermox | what device are you going to try? | 19:29 |
| cyphermox | I'd favor a mouse or headset | 19:29 |
| cyphermox | I'm seeing some weird crashes with a keyboard, which I'm quickly debugging while I do other stuff | 19:30 |
| mzanetti | cyphermox: my use case is mostly a2dp for my car and the stereo headset for running | 19:30 |
| cyphermox | perfect | 19:30 |
| cyphermox | a2dp does work with bluez, so if QtBluetooth uses bluez you should be good | 19:30 |
| cyphermox | mzanetti: feel free to ask if you want pointers on how to link devices from the command line | 19:31 |
| mzanetti | QtBluetooth is not involved in a2dp actually... I'm interested in QtBluetooth because I have been the one porting it from Qt4 to Qt5 back then when I was at Nokia | 19:31 |
| cyphermox | ok | 19:31 |
| mzanetti | and as we never shipped a device with Qt5 I'm still not perfectly sure how good I did :D | 19:31 |
| mzanetti | ok... bbiab | 19:32 |
| Saviq | mterry, kgunn three more things about greeter - "widgetizing" - I'd refrain from trying to support more than QML in the long run, unless we go for multiple processes - surfaces - and simply a mirserver | 19:41 |
| Saviq | mterry, kgunn QML has the added benefit that we can set QML2_IMPORT_PATH to supply the same interface, but a different implementation (proxy, write-only or whatnot) for "locked" apps | 19:42 |
| Saviq | mterry, kgunn, and IIUC greeter/lightdm would still remain a mirserver for the system compositor, right? controlling session surfaces? | 19:43 |
| mterry | Saviq, yeah, plus our greeter client | 19:43 |
| Saviq | mterry, right, so lightdm would be mirserver for system compositor, and greeter and sessions would be its clients? | 19:44 |
| Saviq | mterry, assuming here that greeter is a special kind of client? or is sessions geometry management built into lightdm? | 19:45 |
| mterry | Saviq, lightdm would talk to u-s-c, which would be the system mirserver | 19:46 |
| mterry | Saviq, greeter and sessions would be u-s-c's clients | 19:47 |
| mterry | Saviq, I think greeter would be normal sort of client (the same way a session is a normal client that happens to also be its own server for subclients) | 19:47 |
| Saviq | mterry, yeah, but something needs to control sessions geometry | 19:47 |
| Saviq | mterry, so something needs to tell u-s-c what to do | 19:48 |
| Saviq | mterry, or is that built into u-s-c | 19:48 |
| Saviq | mterry, and in that case, why can't greeter be u-s-c, same as unity8 is session-compositor? | 19:48 |
| mterry | Saviq, that bit I don't know | 19:48 |
| mterry | Saviq, security in that case, since u-s-c is root | 19:48 |
| Saviq | mterry, right | 19:48 |
| Saviq | mterry, so we need a mini-shell inside u-s-c to deal with those, or a protocol between greeter and u-s-c I'd say | 19:50 |
| Saviq | mterry, who can we clarify that with? | 19:50 |
| mterry | Saviq, that sounds like a u-s-c job | 19:51 |
| mterry | Saviq, but robert_ancell would know for sure | 19:51 |
| Saviq | mterry, ok, I'll grab him when he comes on | 19:53 |
| tvoss | mterry, let's assume usc would not require root | 19:54 |
| mterry | Saviq, u-s-c is only guy in picture I can imagine doing that. Out of scope for greeter and lightdm, I'd think (though lightdm does talk to u-s-c to help it know who is on top) | 19:54 |
| tvoss | mterry, then greeter could be the system-level shell on top of usc | 19:54 |
| Saviq | mterry, yeah, but then it's the greeter that know that it's supposed to slide away and animate the underlying session | 19:54 |
| Saviq | tvoss, yeah, that's what I thought would happen, otherwise we introduce the same process split we prevented for user session | 19:55 |
| mterry | Saviq, yes and no. lightdm and u-s-c will probably between them mark the greeter as special or "on top" and when transitions happen, u-s-c can do the animations | 19:55 |
| Saviq | mterry, that's a difficult split to make | 19:56 |
| Saviq | mterry, see that panel is not supposed to be swiped away on greeter unlock | 19:56 |
| Saviq | mterry, do you know why u-s-c needs to be root? | 19:56 |
| mterry | tvoss, Saviq: as for why u-s-c is root... I'm guessing because it controls hardware? | 19:56 |
| tvoss | mterry, we can control that, so no reason it _has_ to be root | 19:57 |
| Saviq | mterry, it probably just needs to write access to some devices | 19:57 |
| mterry | Saviq, right, on greeter unlock we make the greeter semi-transparent and the session beneath bleeds through | 19:57 |
| Saviq | mterry, so facls should give us enough granularity | 19:57 |
| tvoss | mterry, is that still the active blur? | 19:57 |
| mterry | tvoss, it's the "something" blur | 19:58 |
| mterry | doesn't need to be active, but needs to be periodic at least | 19:58 |
| mterry | i.e. active with a really slow pulse :) | 19:58 |
| tvoss | mterry, ah okay. at any rate, that would require a special flag on the surface (I don't like that) or the greeter to be able to control the compositing iiuc | 19:58 |
| tvoss | mterry, can we have something that at least is calcutable in one pass? | 19:59 |
| mterry | tvoss, the way we had been talking with mir folks was that the lightdm process has to name all the sessions for u-s-c anyway. So it can name the greeter as "Greeter" or some such, so that u-s-c knows to treat it different | 19:59 |
| tvoss | mterry, sure, we can do that, not talking about technical feasibility here | 20:00 |
| mterry | tvoss, as for one-pass, I'm not familiar with the various blur algorithms. Haven't researched that much. mzanetti was last person to investigate blur performance I think | 20:01 |
| mterry | tvoss, but you don't like the idea of u-s-c treating greeter specially? | 20:01 |
| tvoss | mterry, I think it separates logic where it shouldn't. But you already know that I'm a huge fan of the greeter being a system-level shell | 20:02 |
| mterry | tvoss, well, let's ask robert_ancell why/if u-s-c needs root | 20:03 |
| mterry | tvoss, that would enable greeter to be in u-s-c if we wanted, from a security standpoint anyway... | 20:03 |
| Saviq | mterry, I agree with tvoss here that I always envisioned greeter to be to the system compositor what unity8 is to the session compositor | 20:06 |
| Saviq | mterry, so to *be* the system compositor, as unity8 is the session compositor | 20:06 |
| Saviq | ok, I think I didn't eat anything today, is it a good time for breakfast? | 20:07 |
| mterry | Saviq, :) | 20:10 |
| tvoss | Saviq, enjoy :) | 20:12 |
| Saviq | tvoss, oh, good, was waiting for someone to actually *reply* mterry :P | 20:12 |
| Saviq | didn't know whether it was a good time | 20:12 |
| Saviq | it was a valid question, you know! | 20:12 |
| tvoss | which one | 20:12 |
| Saviq | tvoss, which one what? | 20:13 |
| tvoss | which question was valid? | 20:13 |
| Saviq | tvoss, the one whether it was a good time for breakfast | 20:13 |
| tvoss | Saviq, ah :) | 20:13 |
| * Saviq is gonna go now, probably has some sugar-level-related brain issues | 20:14 | |
| Saviq | jeez $5M... | 20:14 |
| Saviq | two days... | 20:14 |
| Saviq | if only we can keep it up :) | 20:14 |
| Saviq | tvoss, btw, got a Firefox OS phone today, if you have any particular questions | 20:15 |
| Saviq | will do a bigger report of my feelings (objective, of course) | 20:15 |
| Saviq | tvoss, and will bring to IoM | 20:15 |
| tvoss | Saviq, oh that's great | 20:15 |
| Kaleo | Saviq: is it any good? | 20:15 |
| Saviq | Kaleo, not from the first impressions :/ | 20:16 |
| Saviq | Kaleo, http://pastebin.ubuntu.com/5908811/ my first-5-minutes notes | 20:17 |
| Kaleo | ok | 20:17 |
| mterry | Is there a PPA with unity-mir in it? | 20:54 |
| mterry | aha! ~phablet-team/+archive/mir | 20:55 |
| mterry | robert_ancell, good morning | 20:55 |
| robert_ancell | mterry, hello | 20:56 |
| === racarr is now known as racarrlunch | ||
| mterry | robert_ancell, oh, I had some questions for ya | 21:03 |
| * mterry digs around | 21:03 | |
| mterry | robert_ancell, ah yes, why does u-s-c need to be root? | 21:05 |
| mterry | Saviq, tvoss ^ | 21:05 |
| tvoss | robert_ancell, hey there :) | 21:05 |
| robert_ancell | mterry, to get the DRM device I believe. | 21:05 |
| Saviq | robert_ancell, o/ | 21:05 |
| tvoss | robert_ancell, we could theoretically work around that, couldn't we? | 21:05 |
| Saviq | we're not banding against you at all ;) | 21:05 |
| robert_ancell | tvoss, According to RAOF we can't yet. It's the same reason X has to run as root. | 21:06 |
| mterry | robert_ancell, (this is in service of maybe putting the greeter in-process with u-s-c to avoid having the greeter run another mir server) | 21:06 |
| robert_ancell | I'd love it not to be root | 21:06 |
| tvoss | robert_ancell, okay, can you check with RAOF? | 21:06 |
| robert_ancell | tvoss, I'll ask again, but last time I asked it wasn't something we could work around | 21:06 |
| robert_ancell | Putting the greeter in the system compositor will break some assumptions in lightdm | 21:07 |
| tvoss | robert_ancell, what are those? | 21:07 |
| robert_ancell | mterry, what's wrong with running it as a Mir client? Or what's wrong with running it as a Mir server? Note it will be a nested Mir server, so it wont be as heavy as u-s-c (won't have to access hardware directly) | 21:07 |
| robert_ancell | tvoss, that lightdm launches greeters like normal sessions whenever it wants | 21:08 |
| mterry | robert_ancell, running as a mirserver is just the standard worries about performance | 21:08 |
| tvoss | robert_ancell, it's still overhead on the phone that we could save from my pov | 21:08 |
| robert_ancell | Are we sure this is a problem yet? | 21:08 |
| mterry | robert_ancell, running as a mir client we realized today will hit some problems when we want to launch some apps like camera or phone in greeter mode | 21:08 |
| robert_ancell | yes | 21:09 |
| tvoss | robert_ancell, I can tell you we need to optimize Mir even without a system-compositor on the phone | 21:09 |
| mterry | robert_ancell, not sure, but likely. I think the work to fix it got de-prioritized (according to kgunn) | 21:09 |
| robert_ancell | tvoss, obviously we need to optimise. But both u-s-c and the shell are going to get this performance hit. Is special casing the greeter going to give us any benefit? | 21:09 |
| tvoss | robert_ancell, it would close the loop on a system-level shell and a session-level shell | 21:10 |
| mterry | robert_ancell, if we can't run u-s-c as non-root, our current thinking is to have the greeter be a normal client, but run camera and phone in-process as local qml plugins... | 21:10 |
| tvoss | robert_ancell, iiuc, the greeter apps need to run in some sort of session | 21:10 |
| Saviq | robert_ancell, who controls sessions' geometry? | 21:10 |
| robert_ancell | tvoss, yes, or be hacked like mterry said | 21:10 |
| tvoss | robert_ancell, out of curiosity: could lightdm talk to just one greeter? | 21:11 |
| Saviq | tvoss, long run, yes, we need a session for them, short run we'll build them into the greeter | 21:11 |
| robert_ancell | Saviq, Mir will detect geometry (in u-s-c) and pass that to the shell/greeter. Then those pass policy back up the chain and u-s-c applies the policy of the active session | 21:12 |
| tvoss | Saviq, sure, but if they are qt-apps, they could as well be clients of the usc (system-level shell, if it's a full-blown shell) | 21:12 |
| robert_ancell | tvoss, yes, in theory. But it would be a non-trivial amount of work | 21:12 |
| Saviq | robert_ancell, how do we animate the session coming in? or its opacity / scaling? | 21:12 |
| robert_ancell | Saviq, the compositor in u-s-c does the animation | 21:12 |
| Saviq | robert_ancell, yeah, so that's the problem from my PoV | 21:12 |
| tvoss | robert_ancell, how do we implement that? with a custom toolkit? | 21:12 |
| robert_ancell | When not animating, u-s-c is just running in bypass | 21:12 |
| Saviq | robert_ancell, as the greeter needs to sync its own animation (swiping away) with the session coming in animation | 21:13 |
| kgunn | we won't have android bypass for 13.10 | 21:13 |
| mterry | Saviq, as I mentioned before, we are thinking of handling that via telling u-s-c which session is next and it stacks them | 21:14 |
| robert_ancell | what mterry said | 21:14 |
| Saviq | mterry, robert_ancell, but that's a one-time thing | 21:14 |
| mterry | and the top session will be partly transparent | 21:14 |
| robert_ancell | kgunn, really? I thought that would be a blocker on the phone? | 21:14 |
| mterry | Saviq, one-time? | 21:14 |
| Saviq | mterry you put your finger on the right edge, start swiping left | 21:14 |
| kgunn | robert_ancell: well...the more we "need" it depending on the outcome of this discussion that might be true | 21:15 |
| Saviq | mterry, the animation of the greeter going away and the session coming in behind it | 21:15 |
| robert_ancell | tvoss, the UI implementation of the greeter in u-s-c wouldn't be hard, but it's a matter of making the link with the daemon and handling the concept of the greeter not being launched and owned by the daemon | 21:15 |
| Saviq | mterry, they need to be synchronized | 21:15 |
| mterry | Saviq, yeah, but u-s-c has both surfaces and can sync them | 21:15 |
| kgunn | but if we are 10% worse than we could be under load....maybe we could live with it | 21:15 |
| Saviq | mterry, it's not about surfaces | 21:15 |
| kgunn | in the end we want it...but its an optimization post 13.10 at this point | 21:15 |
| Saviq | mterry, because the greeter's surface can't move | 21:15 |
| Saviq | mterry, because the panel needs to be drawn all the time | 21:15 |
| Saviq | mterry, it's not supposed to be swiped away | 21:16 |
| Saviq | mterry, although I agree there's a conflict there | 21:16 |
| Saviq | mterry, because how do we transition between the greeter panel and the session panel | 21:16 |
| tvoss | mterry, robert_ancell I'm afraid that the compositing logic in usc if we do it without qt will take significant effort | 21:16 |
| robert_ancell | tvoss, why can't we use qt in u-s-c? | 21:17 |
| mterry | Saviq, interesting point about the panel | 21:17 |
| tvoss | robert_ancell, hmmm, I thought that was one of the reasons to keep the greeter out of the usc | 21:17 |
| Saviq | mterry, robert_ancell, tvoss I'm afraid of more of the same that we're now facing with syncing two scenegraphs... | 21:17 |
| mterry | Saviq, I had assumed panel would be animated too, but I'm guessing you're right that mockups don't show panel moving | 21:17 |
| Saviq | mterry, yeah, and that's how it's implemented now | 21:18 |
| robert_ancell | tvoss, no, the greeter is out of u-s-c because a) that's the way display management traditionally works (to avoid the cost of supporting that) and b) security benefits (greeter is unprivileged user, we can destroy / recreate it and ensure it has safe state) | 21:18 |
| mterry | robert_ancell, tvoss: qt in u-s-c is partly bad because of security issues, which are only true if u-s-c is root | 21:18 |
| robert_ancell | mterry, do we have security concerns with Qt? | 21:19 |
| mterry | Saviq, well, how it's implemented now was just convenience, not because that was the final word | 21:19 |
| Saviq | mterry, sure, that's why we're discussing it at all ;) | 21:19 |
| mterry | robert_ancell, we just don't typically run it as root | 21:19 |
| robert_ancell | Obviously, the less we put in u-s-c the safer from security and stability, but I don't see other issues | 21:19 |
| Saviq | robert_ancell, both a) and b) don't convince me when we run u-s-c out of root | 21:19 |
| Saviq | robert_ancell, we had the same discussion for user session | 21:19 |
| mterry | robert_ancell, but it's not just qt as root that's the problem, it's running the whole greeter as root | 21:19 |
| robert_ancell | Saviq, a) doesn't come for free | 21:20 |
| tvoss | robert_ancell, what do we gain from the traditional approach? trying to understand that | 21:20 |
| Saviq | robert_ancell, that unstability is an issue | 21:20 |
| Saviq | robert_ancell, which we shot down | 21:20 |
| robert_ancell | tvoss, not having to rewrite a whole bunch of code | 21:20 |
| robert_ancell | Finishing in time for 13.10! | 21:20 |
| Saviq | robert_ancell, I think we're trying to look beyond 13.10 | 21:20 |
| Saviq | robert_ancell, at least I am | 21:20 |
| mterry | Saviq, I'm mostly looking at 13.10 :) | 21:21 |
| robert_ancell | Sure, but do we have to solve this immediately? Do we even know there's a performance problem yet? | 21:21 |
| Saviq | robert_ancell, mterry, what's possible for 13.10 is one thing - and cutting corners is fine | 21:21 |
| Saviq | robert_ancell, not a performance one | 21:21 |
| Saviq | robert_ancell, but a complexity one - from my PoV - yes | 21:21 |
| robert_ancell | Saviq, implementing design? | 21:21 |
| Saviq | robert_ancell, yes, implementing the design in a split u-s-c/greeter is going to be difficult | 21:22 |
| mterry | Saviq, handling the panel transition? | 21:22 |
| robert_ancell | Saviq, right, which is why I thought the greeter would be in the shell for 1.0 | 21:22 |
| Saviq | mterry, switching between greeter apps, too | 21:22 |
| robert_ancell | That's the only way you're going to have true flexibility for complex transitions, at the security cost | 21:22 |
| robert_ancell | Ultimately wherever you put the greeter process, if it's going to be run as a different user then there's going to be complexity in doing a transition | 21:23 |
| Saviq | robert_ancell, sure, but we're adding another level of complication for no security benefit, IIUC | 21:23 |
| mterry | Saviq, well, that is something either the normal shell code handles or we do manually if we've got core-app qml plugins | 21:23 |
| kgunn | robert_ancell: i think its pretty firm we're not gonna have greeter in shell | 21:23 |
| Saviq | mterry, assuming all greeter apps run in a single guest session - which might be ok | 21:24 |
| robert_ancell | kgunn, right, so that's why I don't think there's an easy solution for this. Putting the greeter in u-s-c is not going to make things significantly easier than having it in a separate process. | 21:24 |
| Saviq | mterry, and probably is better for performance reasons | 21:24 |
| mterry | Saviq, or more likely for 13.10, the greeter's own session | 21:24 |
| tvoss | mterry, tbh, both approaches seem to be hacky | 21:24 |
| Saviq | robert_ancell, it is, IMO | 21:24 |
| Saviq | tvoss, you'd see a session per-greeter-app? | 21:25 |
| robert_ancell | Saviq, I'm not seeing an argument here showing what will be easier | 21:25 |
| tvoss | Saviq, nope, I would like them to be clients of the usc/system-level-shell | 21:26 |
| Saviq | robert_ancell, session management is not going to be split between greeter and u-s-c | 21:26 |
| tvoss | Saviq, in my ideal world, admittedly | 21:26 |
| Saviq | tvoss, that means running under the greeter user | 21:26 |
| Saviq | tvoss, which might not be desirable | 21:26 |
| Saviq | tvoss, even if it doesn't run as root | 21:26 |
| tvoss | Saviq, fair point, so you are thinking about a guest session? | 21:26 |
| Saviq | tvoss, yes, at least one - or even one per greeter app | 21:26 |
| robert_ancell | Saviq, what part exactly of session management | 21:26 |
| kgunn | Saviq: i'm thinking like tvoss...but i've missed why its be undesirable | 21:27 |
| Saviq | robert_ancell, geometry, applying effects, transitions, animations | 21:27 |
| kgunn | i know something about panel handling....but i don't understand | 21:27 |
| mterry | Saviq, seems to be complicating things even more to have each app run as a different user | 21:27 |
| mterry | than the greeter | 21:27 |
| Saviq | mterry, I agree it might be overkill - a single session would probably suffice | 21:28 |
| Saviq | kgunn, panel - look at your device, swipe the greeter away | 21:28 |
| mterry | Saviq, even there, we've now got apps in greeter running as a different user than the greeter. We've already got a complicated setup before that... | 21:28 |
| Saviq | kgunn, panel stays in place | 21:28 |
| tvoss | Saviq, let's assume the greeter user is not root. apps would be severely restricted/confined | 21:28 |
| Saviq | kgunn, if u-s-c treats greeter and any other session the same way | 21:28 |
| tvoss | Saviq, don't see the benefit of a separate user session | 21:28 |
| Saviq | kgunn, swiping the greeter away would mean swiping the panel away | 21:29 |
| robert_ancell | Saviq, when you say "panel stays in place" you mean the panel shown in the greeter and the panel in the session | 21:29 |
| Saviq | robert_ancell, yes, which is actually conflicting slightly | 21:29 |
| mterry | Saviq, u-s-c knows which is greeter. It could animate the rest of the screen and ignore the panel pixels... | 21:29 |
| Saviq | robert_ancell, as user session can have more indicators than system "session" | 21:29 |
| mterry | Saviq, and then swap into normal session indicators after animation is done, "instantly" changing the set of indicators | 21:30 |
| Saviq | mterry, see? exactly my point ;) | 21:30 |
| mterry | Saviq, it is? | 21:30 |
| Saviq | mterry, for ever such exception (sure - with current design I can only think of one now) we'll be dealing weird things between greeter and u-s-c | 21:30 |
| Saviq | mterry, but design isn't set in stone, I'm afraid ;) | 21:31 |
| Saviq | as we've learned | 21:31 |
| robert_ancell | Saviq, both panels are owned by different processes and different users in any case - so the transition is always going to be hard | 21:31 |
| robert_ancell | Unless you put the greeter in shell | 21:31 |
| kgunn | mterry: so is panel like launcher while greeter is shown? | 21:31 |
| mterry | Saviq, OK... but we can adjust as we go. As long as u-s-c knows about the greeter, we can treat it special | 21:31 |
| Saviq | mterry, which is exactly something I want to avoid | 21:31 |
| mterry | kgunn, what? | 21:31 |
| Saviq | I dunno, I feel like we're having the same discussion again | 21:32 |
| kgunn | mterry: widgestized | 21:32 |
| mterry | Saviq, but... special-greeter solves several problems. You want to avoid it because you think it is overcomplicated architecture? | 21:32 |
| Saviq | unity8 at least has some control over surfaces | 21:32 |
| mterry | kgunn, yeah, panel and launcher are separate widgets, shared between unity and greeter code | 21:32 |
| Saviq | geometry, opacity and whatever we say is needed | 21:32 |
| Saviq | with greeter, you seem to be moving even that away from the greeter | 21:33 |
| === racarrlunch is now known as racarr | ||
| Saviq | and treat is as a dumb application, shoe-horning some exceptions like for the panel etc. | 21:33 |
| tvoss | mterry, how do you envision greeter and usc to communicate? | 21:33 |
| Saviq | IMO it's going to be a huge pain | 21:33 |
| kgunn | mterry: so when you swipe....panel stays in place...but shell takes over ? (e.g. new render is from shell process) | 21:33 |
| mterry | tvoss, actually lightdm and u-s-c communicate, and they already have a channel for it | 21:33 |
| Saviq | kgunn, there needs to be some transition | 21:34 |
| Saviq | kgunn, it could be just a cross-fade synchronized with how far you've dragged the greeter | 21:34 |
| tvoss | mterry, so greeter talks to lightdm, lightdm talks to usc and vice versa on what is essentially a side-channel? | 21:34 |
| Saviq | kgunn, there actually isn't design for it, 'cause all design assumes they're going to be the same (which actually might still be the case) | 21:34 |
| mterry | tvoss, for this sort of stuff, we don't need to add anything more to the greeter<->lightdm channel | 21:35 |
| Saviq | kgunn, i.e. the indicators are going to look the same, just their contents may be different for greeter (like no messages, just their count, for example) | 21:35 |
| mterry | tvoss, but lightdm and u-s-c do talk on a side channel right now | 21:35 |
| Saviq | kgunn, so there's no visible transition between the two - so as soon as the user session is unlocked - we'd just flip the greeter one "off" | 21:35 |
| tvoss | mterry, how do we synchronize to the right edge swipes? | 21:35 |
| tvoss | mterry, who is the leader in this scenario? usc, greeter or lightdm? | 21:36 |
| mterry | tvoss, the plan so far was to have the greeter be semi-transparent and the session below would bleed through | 21:36 |
| mterry | tvoss, u-s-c is the "leader" I'd guess? Not sure what you mean by that | 21:36 |
| kgunn | brb | 21:36 |
| Saviq | mterry, which is inconsistent with visual design | 21:36 |
| tvoss | mterry, who controls the operatoin? who controls what happens when? | 21:36 |
| mterry | Saviq, how is that inconsisten? | 21:37 |
| tvoss | and I guess the control flow | 21:37 |
| Saviq | mterry, or by "bleed through" you mean that the whole greeter is swiped away | 21:37 |
| Saviq | mterry, and the session is just there? | 21:37 |
| mterry | tvoss, lightdm tells u-s-c when the user changes and thus which session to place underneath the greeter; u-s-c can manage the transitions | 21:37 |
| tvoss | mterry, who tells lightdm that the user has changed? | 21:38 |
| mterry | Saviq, right. so the greeter marks the section on the right as transparent. u-s-c places the next session beneath the greeter. So you'll see the session underneat | 21:38 |
| Saviq | mterry, so u-s-c is going to have handle input as well to follow the finger when swiping the greeter away, right? | 21:38 |
| mterry | tvoss, greeter does (like it does now on desktop) | 21:38 |
| Saviq | -have | 21:38 |
| mterry | Saviq, no... it just puts the session beneath | 21:38 |
| mterry | Saviq, greeter is animating itself moving out of the way, thus making more and more of itself transparent | 21:39 |
| Saviq | mterry, ok, who scales the session in and un-darkens it? | 21:39 |
| mterry | Saviq, maybe you and I have seen different mockups for this | 21:39 |
| Saviq | mterry, no I think that's actually fine | 21:39 |
| tvoss | Saviq, it's working like that on the phone right now, isn't it? | 21:39 |
| Saviq | tvoss, yes, until that point that's correct | 21:40 |
| mterry | Saviq, but regardless, u-s-c can scale and modify the session surface, since it owns it | 21:40 |
| Saviq | mterry, yes, who tells u-s-c what scale and darkening / opacity to apply at any given time? | 21:40 |
| Saviq | mterry, and by what means? | 21:40 |
| mterry | Saviq, we could build it in, we could have a config file, we could make it part of the protocol between lightdm and it... I hadn't thought that was a big problem | 21:41 |
| mterry | Saviq, oh you mean during the animation? | 21:41 |
| Saviq | mterry, yes | 21:41 |
| mterry | Saviq, again, I feel like you are operating on a different mockup than I have. I imagine the current greeter right now, which just shows the session below | 21:42 |
| Saviq | mterry, what this means to me is that we need a protocol that will, for each frame, communicate from the greeter to u-s-c what geometry, scale, opacity, and any other effects, to apply on the session surface | 21:42 |
| Saviq | mterry, no it doesn't | 21:42 |
| Saviq | mterry, don't unlock with password | 21:42 |
| Saviq | mterry, or pin | 21:42 |
| Saviq | mterry, drag away | 21:42 |
| mterry | Saviq, ah yes, you are right | 21:42 |
| Saviq | mterry, and even with a button | 21:42 |
| Saviq | mterry, there's a progressive transition of the "session" coming in | 21:42 |
| mterry | Saviq, I so rarely get past the greeter, my memory was fuzzy. Did we change that, or have I always been so unobservant :) | 21:43 |
| Saviq | mterry, it was always like that | 21:43 |
| Saviq | mterry, it isn't when app's in focus | 21:43 |
| Saviq | mterry, which is a bug, I think | 21:43 |
| Saviq | otherwise we have a problem of syncing the greeter/u-s-c *and* user session | 21:43 |
| mterry | Saviq, that does complicate things a bit more yeah | 21:43 |
| Saviq | but that could actually be ok, if we just pass a 0.0 ÷ 1.0 progress value from the greeter to the session | 21:44 |
| Saviq | I don't expect that we'd need anything more than that | 21:44 |
| tvoss | Saviq, but still: it is a side-channel we are opening up | 21:45 |
| robert_ancell | Saviq, mterry, we did discuss that with the input from the greeter being converted into a transition percentage and being given to u-s-c | 21:45 |
| mterry | Saviq, sure | 21:45 |
| mterry | robert_ancell, yar | 21:45 |
| Saviq | tvoss, yes, but I don't think we can avoid it completely, but we should try and minimize it | 21:45 |
| mterry | tvoss, that side channel already exists, but yeah, it would be using it more | 21:46 |
| Saviq | robert_ancell, yeah, but IMO it's different if we're talking about that between greeter and session, which obviously have a huge boundary between them - and that's correct | 21:46 |
| Saviq | robert_ancell, and different when we've split u-s-c and greeter | 21:46 |
| mterry | So what's the outcome here? We continue with greeter-as-usc-client for 13.10... We can handle transitions in usc by marking greeter and talking to it? | 21:48 |
| mterry | For 14.04 maybe we can make greeter a real mirserver, assuming performance is ok... | 21:49 |
| mterry | Or a hail-mary of being able to run usc as non-root | 21:49 |
| robert_ancell | I agree with mterry. We don't know of performance problems yet, the complexity is manageable, the risk is lowest continuing with what we have. And we have options up our sleeve if we need them | 21:51 |
| mterry | robert_ancell, well, I was mentioning trying to make greeter a pure-client for 13.10, and go back to a mirserver for 14.04 | 21:52 |
| Saviq | mterry, robert_ancell, I'm game with that for 13.10, I'm just asking for an open mind (and paths) for the future :) | 21:52 |
| mterry | robert_ancell, but either way, performance needs to be investigated | 21:52 |
| robert_ancell | mterry, It has no effect on me if it's a client or a server - it just makes it more complex for you if you need to launch apps from the greeter | 21:53 |
| mterry | robert_ancell, yup. I'd rather it is mirserver, that is far easier to implement | 21:53 |
| mterry | robert_ancell, but tvoss and kgunn are worried about the performance there, since we won't have bypass it sounds like | 21:54 |
| Saviq | robert_ancell, racarr, on another topic: | 21:55 |
| Saviq | mirserver/mir/default_server_configuration.h: No such file or directory | 21:55 |
| Saviq | are we missing a build dep? or was something not yet released? | 21:55 |
| mterry | sounds like missing libmirserver-dev | 21:56 |
| Saviq | mterry, yeah, that's what I thought | 21:57 |
| robert_ancell | kernel panic, please repeat anything directed at me since "robert_ancell, yup. I'd rather it is mirserver, that is far easier to implement" | 21:58 |
| Saviq | robert_ancell, but tvoss and kgunn are worried about the performance there, since we won't have bypass it sounds like | 21:58 |
| Saviq | robert_ancell, ↑ that was mteryy | 21:58 |
| Saviq | mterry, even | 21:59 |
| robert_ancell | Saviq, ta | 21:59 |
| mterry | Also: | 21:59 |
| mterry | <Saviq> robert_ancell, racarr, on another topic: | 21:59 |
| mterry | <Saviq> mirserver/mir/default_server_configuration.h: No such file or directory | 21:59 |
| mterry | <Saviq> are we missing a build dep? or was something not yet released? | 21:59 |
| mterry | <mterry> sounds like missing libmirserver-dev | 21:59 |
| Saviq | mterry, yeah, and that, didn't think it was needed ;) | 21:59 |
| mterry | robert_ancell might have some deep insights! | 22:00 |
| robert_ancell | Saviq, are you using pkg-config? | 22:00 |
| robert_ancell | also, full log? | 22:00 |
| Saviq | robert_ancell, this is the unity-mir integration effort, not cleaned up enough, yet | 22:00 |
| Saviq | robert_ancell, https://launchpadlibrarian.net/145781977/buildlog_ubuntu-saucy-armhf.unity8_1%3A7.81.3%2B13.10.20130718ubuntu.unity.next-0%2B201307241850~129_FAILEDTOBUILD.txt.gz | 22:01 |
| * Saviq tries to sbuild | 22:01 | |
| robert_ancell | Saviq, oh, that's the wrong include | 22:04 |
| robert_ancell | it should be <mir/default_server_configuration.h> and the include path set by pkg-config | 22:05 |
| Saviq | robert_ancell, wrong as in it won't work? or wrong as it shouldn't be used? | 22:05 |
| Saviq | robert_ancell, ok, so that's different - we're just missing a build dep | 22:05 |
| Saviq | robert_ancell, we'll be cleaning this up later | 22:05 |
| robert_ancell | but it appears to be <mirserver/mir/default_server_configuration.h> | 22:05 |
| robert_ancell | It works because the file is /usr/include/mirserver/mir/default_server_configuration.h | 22:06 |
| robert_ancell | sure | 22:06 |
| Saviq | robert_ancell, yeah, noted | 22:06 |
| Saviq | robert_ancell, ok, needs to be fixed now, as the includes inside there fail anyway | 22:07 |
| robert_ancell | Saviq, lp:unity-mir? | 22:08 |
| Saviq | robert_ancell, no, that's lp:~unity-team/unity8/unity8-integrate-mir/ | 22:08 |
| Saviq | or is it | 22:09 |
| Saviq | robert_ancell, yes, lp:unity-mir, actually | 22:09 |
| Saviq | robert_ancell, and it seems to be missing libmirserver-dev dependency | 22:09 |
| robert_ancell | Saviq, that would do it :) | 22:09 |
| robert_ancell | Saviq, in the .pro files? It does have it in debian/control | 22:10 |
| Saviq | robert_ancell, only for build | 22:10 |
| Saviq | robert_ancell, not for runtime | 22:10 |
| Saviq | robert_ancell, which it needs for anyone building against it | 22:11 |
| Saviq | robert_ancell, there's no unity-mir-dev package split yet | 22:11 |
| Saviq | robert_ancell, and *that's* what should have the dep | 22:11 |
| robert_ancell | Oh the binary unity-mir needs a dep on libmirserver-dev? | 22:11 |
| robert_ancell | binary package unity-mir | 22:11 |
| Saviq | robert_ancell, yes, because it doesn't have -dev split out of it | 22:11 |
| robert_ancell | and does shlibs not work? It has a bunch of explicit dependencies on libraries | 22:12 |
| Saviq | robert_ancell, libraries, shlibs will never add a -dev dep, will it? | 22:12 |
| Saviq | robert_ancell, -dev packages usually depend on -dev ones explicitly, IIRC | 22:12 |
| robert_ancell | Saviq, no, but it should add the dependency on libmirsever0 | 22:12 |
| robert_ancell | Saviq, correct | 22:12 |
| Saviq | robert_ancell, ok, but the build in question (the failed one) | 22:13 |
| Saviq | robert_ancell, is unity8 | 22:13 |
| Saviq | robert_ancell, *against* unity-mir | 22:13 |
| robert_ancell | Saviq, if unity-mir is a dev package it should be called libunity-mir-dev or similar | 22:13 |
| robert_ancell | ah | 22:13 |
| Saviq | robert_ancell, of course | 22:13 |
| Saviq | robert_ancell, and it needs the -I for mirserver in the .pc | 22:13 |
| Saviq | hmm it doesn't seem to have a .pc at all | 22:14 |
| robert_ancell | Saviq, it needs the dependency on the libmirserver .pc file, not an explicit -I | 22:14 |
| robert_ancell | yeah, just noticed that too :) | 22:14 |
| Saviq | robert_ancell, or that, indeed | 22:14 |
| * Saviq adds | 22:14 | |
| Saviq | robert_ancell, ah, it actually generates one | 22:16 |
| robert_ancell | kgunn, oh, nice diagram of the greeter options btw. Just saw it now | 22:19 |
| kgunn | anything settled in my short hiatus ? | 22:20 |
| Saviq | robert_ancell, hum http://pastebin.ubuntu.com/5909168/ | 22:22 |
| Saviq | robert_ancell, that's the .pc it generates | 22:22 |
| Saviq | robert_ancell, so it's looking good, not sure why it doesn't pick up the Requires :/ | 22:23 |
| robert_ancell | kgunn, did you see from <mterry> So what's the outcome here...? | 22:24 |
| kgunn | robert_ancell: nope | 22:24 |
| robert_ancell | Saviq, it shouldn't require the mircommon, but otherwise looks correct | 22:24 |
| robert_ancell | kgunn, See http://irclogs.ubuntu.com/2013/07/24/%23ubuntu-unity.html | 22:25 |
| robert_ancell | I tried to copy and paste it, but it only wants to copy one line for some reason | 22:25 |
| robert_ancell | Saviq, what does a manual pkg-config --cflags show? | 22:26 |
| Saviq | robert_ancell, yeah, it's right, I'm trying to build now | 22:26 |
| mterry | robert_ancell, do you know where "Failed to load platform plugin "ubuntumir"." message is coming from? (it lists ubuntumir as one of the available platforms, trying to find why it didn't load) | 22:27 |
| Saviq | robert_ancell, might be something was b0rked in my sbuild | 22:27 |
| Saviq | robert_ancell, yeah, seems to build fine now, verifying | 22:27 |
| robert_ancell | mterry, no, racarr knows perhaps? Sounds like something in the Qt layer | 22:27 |
| Saviq | robert_ancell, http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/revision/20 looks sane? | 22:38 |
| robert_ancell | Saviq, yes | 22:40 |
| Saviq | robert_ancell, how about http://pastebin.ubuntu.com/5909228/ | 22:45 |
| robert_ancell | Saviq, the compile line doesn't have the -I includes in it for Mir | 22:46 |
| robert_ancell | So looks like a build system issue | 22:46 |
| Saviq | robert_ancell, right, I wonder why it at all wants to include it, though... | 22:47 |
| Saviq | robert_ancell, actually, that's -j9 | 22:47 |
| Saviq | robert_ancell, so the message probably doesn't really count.. | 22:47 |
| * Saviq tries -j1 | 22:47 | |
| robert_ancell | Saviq, if the code is as it was, it's explictly including default_server_configuration.h using the whole path (bad) and that needs the header from mircommon. But since the -I/usr/include/mircommon is not on the command line (should be provided by pkg-config) it fails | 22:48 |
| Saviq | robert_ancell, ok, let me fix those includes, then | 22:49 |
| mterry | robert_ancell, so where are we with the create-surface-with-session-pointer branch? | 22:58 |
| robert_ancell | mterry, otp, will get back to you | 22:58 |
| mterry | k | 22:58 |
| Saviq | robert_ancell, d'oh... stupid cmake doesn't fail if pkgconfig's requires are not met... we were missing libplatform-api1-dev and that caused pkgconfig to crap out, but cmake let it go through - never setting cflags up | 23:07 |
| mterry | mzanetti, oh btw, did I point you at the ofono backend branch I started? | 23:10 |
| Saviq | asac, see the pass rate for unity8 in http://91.189.93.67/staging/daily/ ? ;) | 23:15 |
| robert_ancell | mterry, so the short answer as I understand it is "will be better solved once the scene graph work is completed". There was a suggestion which was the initial method I was planning to use (grudgingly) of watching the surfaces be created and creating the mapping yourself. Do you think that is feasible as a stop gap? | 23:22 |
| robert_ancell | mterry, I've also talked with racarr, and hopefully he might be able to help out with the mir side of u-s-c next week | 23:23 |
| mterry | robert_ancell, what is the scene graph work? | 23:25 |
| robert_ancell | mterry, https://lists.ubuntu.com/archives/mir-devel/2013-July/000307.html | 23:26 |
| mterry | robert_ancell, watching the surfaces be created is what I was originally trying to do, but we don't have a connection to the session at surface creation time... | 23:26 |
| mterry | robert_ancell, will read that link. I'm about to go out door | 23:26 |
| robert_ancell | mterry, ok, talk to you more tomorrow | 23:27 |
| robert_ancell | mterry, the solution might be to have the link in the creation method, not in the object (as it can go out of scope) | 23:27 |
| mterry | robert_ancell, that's exactly what my branch does, I thought... | 23:27 |
| robert_ancell | mterry, oh, I'll re-check it | 23:28 |
| robert_ancell | mterry, yes, you pass it to creation, but you also store it in mir::shell::Surface | 23:33 |
| mterry | robert_ancell, ah.... to pass it on? I don't remember. I didn't make an accessor for it or anything I don't thin | 23:33 |
| mterry | k | 23:33 |
| mterry | but yah, we shouldn't store it. I can clean that up | 23:34 |
| mterry | unless we have to store it to pass it on... | 23:34 |
| === qengho_ is now known as qengho | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
