| === maclin1 is now known as maclin | ||
| === nudtrobert1 is now known as nudtrobert | ||
| === zbenjamin_ is now known as zbenjamin | ||
| tsdgeos | ah funny | 09:09 |
|---|---|---|
| tsdgeos | the qmluitests in tableStage pass here | 09:10 |
| tsdgeos | meh the autopkg tests branch has degraded into tests not passing again | 09:29 |
| tsdgeos | at least one i know what it is | 09:31 |
| ltinkl | tsdgeos, https://code.launchpad.net/~lukas-kde/unity8/globalshortcuts/+merge/269608 merged and conflicts resolved | 09:31 |
| tsdgeos | ltinkl: ok, i'll let daniel continue the review | 09:32 |
| ltinkl | tsdgeos, it had been approved already | 09:32 |
| tsdgeos | ah right | 09:32 |
| ltinkl | tsdgeos, by mzanetti too | 09:33 |
| ltinkl | tsdgeos, thx | 09:35 |
| === greyback__ is now known as greyback | ||
| === alan_g is now known as alan_g|llunch | ||
| tsdgeos | wops, testNotifications broke | 10:09 |
| * tsdgeos fixes | 10:09 | |
| tsdgeos | Saviq: was speaking with someone yesterday that had exactly the same issue with the cropped images as we do | 10:25 |
| tsdgeos | maybe after a bit of testing we can propose the CroppedImageMinimumSourceSize up to the SDK? | 10:26 |
| Saviq | tsdgeos, I'd rather we propose a change to the Qt APIs | 10:26 |
| tsdgeos | Saviq: what would you propose? | 10:26 |
| Saviq | tsdgeos, not sure yet, sourceSize: minimumSize(200, 300) or something of the sort | 10:26 |
| Saviq | Qt.minimumSize I mean | 10:26 |
| Saviq | would be backwards compatible | 10:27 |
| tsdgeos | i guess it might work | 10:28 |
| kgunn | pstolowski: hey there, i'm trying to untangle a mess | 10:43 |
| kgunn | so i understand lp:unity-api and lp:unity-api/trunk-15.04 are different | 10:43 |
| kgunn | was hoping to just merge trunk15.04 differences into lp:unity-api | 10:43 |
| kgunn | but heard you might not think that's kosher | 10:44 |
| kgunn | is there any reason these are being maintained seperately ? | 10:44 |
| tsdgeos | :/ qmltestrunner::ShellWithPin::test_longLeftEdgeDrags is unstable | 11:04 |
| pstolowski | kgunn, hey, | 11:41 |
| pstolowski | kgunn, that happened during gcc5.0 mayhem. tbh i'm not sure anymore why i branched off unity-api since it doesn't have symbols, we could use a single tree (but we can't have single tree for e.g. shell plugin) | 11:44 |
| pstolowski | kgunn, having said that, both trunks are equal feature-wise, may have different revisions and commits as i cherry-picked | 11:45 |
| pstolowski | kgunn, ah, afair it had to do with needing to land stuff for ota6 while dual landing was not possible due to gcc5 | 11:49 |
| === alan_g|llunch is now known as alan_g | ||
| Saviq | pstolowski, so we could reconcile now? why is it not possible to have a single tree for the shell plugin? can't do some #ifdefs? | 12:23 |
| Saviq | pstolowski, they're built separately for wily and v+o after all? | 12:24 |
| Saviq | or is it about the .symbols file differing between the two? | 12:24 |
| pstolowski | Saviq, due to symbols | 12:24 |
| Saviq | that feels dumb, but I feel the pain | 12:25 |
| === MacSlow is now known as MacSlow|lunch | ||
| Saviq | pstolowski, even if separate branches, landing can be done in sync, right? so it's not like there's actual code differences | 12:26 |
| pstolowski | Saviq, we can probably try to merge unity-api trunks back (i'm not sure if it poses any problems wrt citrain, but they are probably easy to work out) | 12:26 |
| Saviq | I mean that the fact that you need two branches there doesn't mean any dependants need to have two | 12:26 |
| Saviq | pstolowski, that'd be ideal, I'll compile a list of tasks for this to happen | 12:27 |
| Saviq | thanks | 12:27 |
| pstolowski | Saviq, correct - but you need to have separate MPs for unity-api, meaning you cannot just dual land | 12:27 |
| pstolowski | Saviq, okay. for shell plugin it's not easily doable though | 12:28 |
| pstolowski | Saviq, we have similar problem in unity-scopes-api (symbols) | 12:28 |
| Saviq | pstolowski, as long as the two (wily and v+o) changes land in sync, we're fine | 12:28 |
| pstolowski | Saviq, michi has been working on a single-tree beanch for unity-scopes-api, it's huge effort | 12:28 |
| Saviq | pstolowski, it's only a problem when one lags behind the other | 12:28 |
| pstolowski | Saviq, yeah. we just need two MPs as before with rtm | 12:29 |
| pstolowski | feature-wise all trunks should be the same | 12:29 |
| pstolowski | alecu, ho? | 12:33 |
| tsdgeos | anyone feels like reviewing https://code.launchpad.net/~aacid/unity8/autopilot_test_search_workaround/+merge/269769 ? | 12:48 |
| tsdgeos | mterry: https://code.launchpad.net/~aacid/unity8/fixTestNotifications/+merge/269876 | 12:48 |
| mterry | tsdgeos, whoops, will review that :) | 12:49 |
| mzanetti | mterry, good morning | 12:50 |
| mterry | mzanetti, hello! | 12:50 |
| mzanetti | mterry, when you get a chance, please merge your reboot branch | 12:50 |
| mterry | mzanetti, will do | 12:50 |
| mzanetti | ta | 12:50 |
| kgunn | Saviq if i followed your convo with pstolowski correctly , i think this just needs to be landed in wily first | 12:59 |
| kgunn | https://code.launchpad.net/~unity-team/unity-api/fwdport-mirsurfaceitem/+merge/269881 | 12:59 |
| kgunn | then...src sync that to vivid+o | 12:59 |
| kgunn | well...plus qtmir trunk into wily with that unity-api mp ^ | 12:59 |
| kgunn | i'll leave it with you... | 12:59 |
| Saviq | kgunn, something like that, I need to see the what the actual direction (wily to v+o or the other way round) will be, but in truth we just need the next landing to be dual-targeted and then push to trunks and drop the additional branches | 13:00 |
| tsdgeos | greyback: any idea of what may be causing the failures in https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/939/consoleFull ? | 13:00 |
| tsdgeos | greyback: the tabletStage ones | 13:01 |
| greyback | Saviq: fyi seems tags have infected qtmir somehow | 13:01 |
| tsdgeos | greyback: search for "fail!" | 13:01 |
| Saviq | greyback, yeah, mzanetti told me | 13:01 |
| mzanetti | still not sure how tho :D | 13:01 |
| Saviq | yikes | 13:01 |
| Saviq | "reached maximum number of OpenGL contexts supported by UbuntuShape" | 13:01 |
| greyback | tsdgeos: "fail!" ? | 13:01 |
| tsdgeos | greyback: without the quotes | 13:02 |
| Saviq | and that in DDA test?? | 13:02 |
| tsdgeos | Saviq: SDK | 13:02 |
| mzanetti | lol | 13:02 |
| tsdgeos | Saviq: it's already fixed they just need to land it | 13:02 |
| greyback | tsdgeos: yeah, firefox not seeing it. Ah matching case, sorry | 13:02 |
| Saviq | ah so that's not the fail you're looking for | 13:02 |
| * greyback waves hand | 13:02 | |
| tsdgeos | Saviq: no since that's not on the phablet stage ;) | 13:02 |
| tsdgeos | Saviq: this is the one for the DDA one https://code.launchpad.net/~aacid/ubuntu-ui-toolkit/betterConnectForAboutToBeDestroyed/+merge/268454 | 13:03 |
| Saviq | ktxbai | 13:03 |
| greyback | tsdgeos: we had this same problem like 2 weeks ago, no? | 13:04 |
| tsdgeos | greyback: did we? | 13:04 |
| greyback | yeah. UbuntuShape doing something funky | 13:04 |
| greyback | I thought there was a fix somewhere, looking | 13:04 |
| tsdgeos | greyback: yes yes, i'm not speaking about the ubuntushape | 13:04 |
| Saviq | greyback, look for further fail! | 13:04 |
| greyback | ah sorry | 13:04 |
| tsdgeos | greyback: i'm speaking about the tabletstage fails | 13:04 |
| tsdgeos | greyback: which obviously i can't reproduce here | 13:05 |
| greyback | tsdgeos: hmm the test makes sense too | 13:07 |
| greyback | something racey maybe | 13:08 |
| greyback | tho this is all single thread I think | 13:08 |
| greyback | tsdgeos: only thing I can suspect is switchToApp - it looks quite solid tho | 13:11 |
| tsdgeos | yeah :/ | 13:11 |
| tsdgeos | and is used in other places too i think | 13:11 |
| greyback | dandrader: good morning, there is a multimonitor update for you | 13:11 |
| greyback | tsdgeos: I see it used in 2 tests, both are the ones which fail | 13:12 |
| tsdgeos | ah | 13:12 |
| tsdgeos | right | 13:12 |
| tsdgeos | ^_^ | 13:12 |
| tsdgeos | maybe it's that then | 13:12 |
| dandrader | greyback, ok | 13:12 |
| greyback | just a guess tho, it runs fine here annoyingly | 13:13 |
| tsdgeos | i'll try to investigate from there | 13:13 |
| greyback | would be lovely to get videos of test fails | 13:13 |
| greyback | ilke AP does | 13:13 |
| Saviq | greyback, I've a thing doing that in my pipeline | 13:15 |
| Saviq | as in mostly implemented | 13:15 |
| greyback | Saviq: glad to hear it. Would be extra super nice if it visualize the cursor/gestures | 13:16 |
| Saviq | greyback, I'm just using recordmydesktop, should be possible to replace that with something smarter, if that doesn't do it | 13:16 |
| Saviq | greyback, ah but for QML tests we'd need something in the qmlscene doing that | 13:17 |
| Saviq | since there's no real input | 13:17 |
| Saviq | next step | 13:17 |
| greyback | yeah | 13:17 |
| greyback | a custom qmlscene might be needed | 13:18 |
| greyback | anyhoo, video will help muchos | 13:18 |
| mterry | tsdgeos, you might have some insight on bug 1489076? | 13:18 |
| ubot5 | bug 1489076 in unity8 (Ubuntu) "clicking on active call banner and indicators with mouse" [Critical,New] https://launchpad.net/bugs/1489076 | 13:18 |
| tsdgeos | mterry: hmmm think you want dandrader for that? | 13:19 |
| tsdgeos | i haven't really done much DDA nor windowed work | 13:19 |
| mterry | tsdgeos, yup, I think I mentally swapped you two :P | 13:19 |
| tsdgeos | ok :D | 13:20 |
| mterry | tsdgeos, which is weird because dandrader even has "DandD" in his name | 13:20 |
| mterry | dandrader, anyway ^ | 13:20 |
| dandrader | :) | 13:21 |
| Saviq | mterry, dandrader, shouldn't we just have a MouseArea there for onClicked? DDA doesn't care about mouse events anyway? | 13:22 |
| dandrader | mterry, I would have to investigate the bug to be able to provide any decent insight | 13:22 |
| dandrader | Saviq, define "there" | 13:22 |
| Saviq | dandrader, wherever the DDA is, really | 13:23 |
| Saviq | wherever we want the click to act ;) | 13:23 |
| mterry | Saviq, does it pass them through? that might work then, to extend the MouseArea from the left of the panel to all along the panel, underneath the indicators | 13:23 |
| dandrader | the indicators bar already has a MouseArea | 13:23 |
| mterry | dandrader, yeah but it doesn't extend underneath the indicators, as I recall | 13:23 |
| dandrader | which is why you're able show the indicators panel by simply clicking on the bar | 13:24 |
| dandrader | mterry, there might be a MouseArea "input eater" over there, I don't lnow | 13:24 |
| dandrader | know | 13:24 |
| mterry | dandrader, the indicators panel shows with a click? ok, good... Then *something* is eating the mouse event / my quick investigation was wrong | 13:25 |
| Saviq | mterry, in any case, DDA shouldn't be involved with mouse events | 13:25 |
| Saviq | there's obviously the problem of mouse events being converted to touch, and vice versa... | 13:26 |
| mterry | Saviq, (why not? it conceptually makes sense that it could handle a mouse drag -- just work we haven't done or is it something we think shouldn't be done?) | 13:26 |
| Saviq | but as long as you accept the event, it shouldn't happen | 13:26 |
| dandrader | mterry, what do you mean by "indicators panel"? it that this narrow bar at the top of the thing you get when you expand it | 13:26 |
| Saviq | mterry, mouse gestures need to be different than touch | 13:26 |
| dandrader | mterry, dednick added a MouseArea in the indicator bar a while ago to handle this call thingy I think | 13:26 |
| mterry | dandrader, I specifically meant the IndicatorsMenu object | 13:27 |
| mterry | dandrader, yeah, but it only is on left of IndicatorsMenu | 13:27 |
| * dandrader not very familiar with the indicator components terminology | 13:27 | |
| mterry | Saviq, yeah but it would be nice if we had a class that abstracted that for us | 13:27 |
| mterry | and without looking at it's API, DDA strikes me as a possible fit for that | 13:28 |
| mterry | dandrader, then I meant "the row of icons" | 13:28 |
| tsdgeos | mterry: https://code.launchpad.net/~aacid/unity8/fixTestNotifications/+merge/269876/comments/679272 up to you, do i do it? | 13:29 |
| Saviq | mterry, sure, but it wouldn't be DDA but something above it, including a MouseArea, likely ;) | 13:29 |
| * Saviq away otp | 13:29 | |
| mterry | tsdgeos, I think it's a cleaner branch if we do it. But I feel bad asking you to do it, since it's my mistake in the first place. I can propose a merge into your MP today | 13:30 |
| tsdgeos | mterry: no no, i'll do it | 13:30 |
| tsdgeos | don't worry | 13:30 |
| tsdgeos | i'm on test failure hunting today | 13:31 |
| tsdgeos | mzanetti: can you do https://code.launchpad.net/~aacid/unity8/stabilize_shellwithpin_test/+merge/269913 ? | 13:31 |
| mzanetti | tsdgeos, sure | 13:32 |
| tsdgeos | mterry: setStatus pushed | 13:46 |
| mterry | k | 13:47 |
| mterry | tsdgeos, that was a few calls indeed :) | 13:48 |
| mzanetti | tsdgeos, this seems to have the ability to mess up with the state machine... doesn't it? | 13:51 |
| tsdgeos | mzanetti: not really i mean the problem is that for some reason we're using a timer to set the state | 13:52 |
| tsdgeos | so if you do | 13:52 |
| tsdgeos | starttimer that changes state, change state | 13:52 |
| tsdgeos | you really need to stop the timer first | 13:52 |
| tsdgeos | otherwise you may not get the state you wanted | 13:52 |
| mzanetti | yes, but we don't do "change state" | 13:52 |
| mzanetti | do we? | 13:52 |
| tsdgeos | mzanetti: if you we do, i can move that down on the animation code if you prefer | 13:53 |
| mzanetti | let me understand it better... | 13:53 |
| mzanetti | tsdgeos, we do... you're right | 13:53 |
| mzanetti | ok... seems fine then | 13:54 |
| tsdgeos | maybe it makes more sense to stop the timer just before the | 13:54 |
| tsdgeos | root.state = ""; | 13:54 |
| tsdgeos | ? | 13:54 |
| tsdgeos | on the ScriptAction { ? | 13:54 |
| tsdgeos | i don't mind either | 13:54 |
| mzanetti | probably... so we don't run into this again | 13:54 |
| tsdgeos | k, will move it down there | 13:54 |
| mzanetti | if someone else starts the fadeOut() , which admittedly is unlikely | 13:54 |
| tsdgeos | i don't even think you can reproduce this in the real world | 13:55 |
| mzanetti | probably | 13:55 |
| === MacSlow|lunch is now known as MacSlow | ||
| tsdgeos | mzanetti: moved down | 14:18 |
| mzanetti | tsdgeos, ta | 14:19 |
| kgunn | greyback: mzanetti how do twins currently work ? it's been a while...do i have to manually update watch file still ? | 14:27 |
| kgunn | or just have an mp for -gles and build it in the silo ? | 14:27 |
| mzanetti | kgunn, yeah, no change | 14:28 |
| greyback | kgunn: yep | 14:28 |
| mzanetti | kgunn, debian/watch for the silo number and debian/changelog for the version | 14:28 |
| kgunn | mzanetti: ack no change except those, got it | 14:28 |
| greyback | and keep eye out for new dependencies | 14:28 |
| kgunn | greyback: so compare the control files ? between the twins | 14:29 |
| * kgunn always wants to think parent-child vs twins | 14:29 | |
| greyback | kgunn: yeah, just in case the 'parent' has something added | 14:29 |
| mzanetti | if the branch you're releasing changes the control, copy the changes over | 14:30 |
| kgunn | easy nuff | 14:30 |
| mzanetti | @unity: standup | 14:30 |
| kgunn | mzanetti: i'll miss | 14:30 |
| kgunn | todays | 14:30 |
| === dandrader_ is now known as dandrader | ||
| Saviq | @unity, kgunn, pstolowski: here's what I believe we should do to resync trunks between wily and vivid, anything I'm missing? http://pastebin.ubuntu.com/12253846/ | 14:48 |
| Saviq | kgunn, vivid has mir 0.14.1, wily has 0.15.1, what's the plan there? | 14:48 |
| pstolowski | Saviq, looks good overall, but i think citrain will reject the first step (land a src rebuild of lp:unity-api/trunk-15.04 to wily) without some changelog hackery? | 14:51 |
| Saviq | pstolowski, I think it shouldn't, the version is higher than what's there in wily | 14:52 |
| Saviq | pstolowski, ultimately we can skip the train altogether and just upload the package to proposed directly | 14:53 |
| pstolowski | Saviq, the ...+15.04 part of version string will confuse it | 14:53 |
| Saviq | pstolowski, don't think it looks that closely, we were dual-landing to rtm and distro before | 14:54 |
| Saviq | without the -rtm suffix | 14:54 |
| Saviq | and it was fine | 14:54 |
| pstolowski | Saviq, ok, we will see :), i fought with something like that not long ago | 14:55 |
| pstolowski | Saviq, i guess we just need to try | 14:55 |
| mzanetti | Saviq, looks good to me | 14:56 |
| Saviq | pstolowski, yup | 14:56 |
| Saviq | back in ~2.5h | 14:57 |
| tsdgeos | Saviq: overlay has 0.15 too, no? | 14:58 |
| tsdgeos | Saviq: ah no, ignore me | 14:58 |
| mzanetti | greyback, kgunn: what's the ETA for silo0 things to land? I cannot reproduce bug 1488828 but I don't have slimport support and silo0 is out of date | 15:40 |
| ubot5 | bug 1488828 in qtmir (Ubuntu) "incoming call nexus4 windowed mode goes nuts and reboots" [Undecided,Incomplete] https://launchpad.net/bugs/1488828 | 15:41 |
| greyback | mzanetti: silo0 more a demo silo than full of actually landable things | 15:42 |
| greyback | mzanetti: we're taking things a piece at a time | 15:42 |
| mzanetti | greyback, sure. I'm particularly interested in the slimport support | 15:42 |
| greyback | mzanetti: well that's probably a bit of https://code.launchpad.net/~gerboland/qtmir/multimonitor/+merge/269906 | 15:43 |
| mzanetti | ah ok | 15:43 |
| greyback | but there's also some magic in silo0 to automatically use desktop mode if >1 screens available | 15:44 |
| greyback | which you'll not have | 15:44 |
| greyback | maybe convert to desktop mode by attaching BT mouse & keyboard, then emulate the call? | 15:44 |
| dednick | dandrader, mterry: I've commented on 1489076, but need a UX decision. | 15:46 |
| mzanetti | greyback, that's fine... I can do that | 15:48 |
| mzanetti | greyback, I've done incoming calls in desktop mode very often lately and didn't have a crash | 15:48 |
| mzanetti | so the only thing that's different here is the missing slimport | 15:48 |
| greyback | mzanetti: then it must be silo0 specific | 15:48 |
| mzanetti | let me try to do the exact same phonesim steps first (I usually use a real phone call) | 15:49 |
| tsdgeos | mterry: in exchange for fixing the notification thing can you review https://code.launchpad.net/~aacid/unity8/autopilot_test_search_workaround/+merge/269769 ? ;) | 15:49 |
| mterry | tsdgeos, :) sure | 15:49 |
| tsdgeos | cool | 15:50 |
| tsdgeos | meh all the qmluitests jobs are stuck | 15:58 |
| tsdgeos | http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-vivid/ :/ | 15:58 |
| tsdgeos | mzanetti: anyone we can ping? ↑ | 15:59 |
| mzanetti | tsdgeos, cihelp in #ubuntu-ci-eng | 15:59 |
| tsdgeos | k, need to do paperwork | 16:00 |
| * tsdgeos runs | 16:00 | |
| syeh | Hi, newbie Unity question, how do I check out the code for 14.04? I think the version I want is 7.2.5+14.04.20150603-0ubuntu1 | 16:38 |
| syeh | I've done a "bzr branch lp:unity" and got a version of source | 16:39 |
| syeh | But for some reason that version won't start after I've make and "make install" | 16:40 |
| dednick | syeh: if you want the source for the version which you are currently running, "apt-get source unity" | 16:48 |
| syeh | dednick: I am trying to fix a defect, and so I need to get the tree, test it, then push it | 16:49 |
| dednick | syeh: "bzr branch lp:unity/7.2" | 16:51 |
| dednick | syeh: https://code.launchpad.net/~unity-team/unity/trusty | 16:52 |
| syeh | dednick: Thanks! Trying that now. | 16:52 |
| === dandrader is now known as dandrader|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
| syeh | ChrisTownsend: in unityshell.cpp, is UNITY_LOW_GFX_MODE supposed to be an override in the case that it is set to "0" | 18:35 |
| ChrisTownsend | syeh: Right, so if you set UNITY_LOW_GFX_MODE=1 before starting unity, then unity will be started in low graphics mode. | 18:37 |
| syeh | what if I set it to 0, can I force it to not be in low gfx mode? | 18:37 |
| syeh | The current code won't allow that, but I'm wondering if that's the intention | 18:37 |
| ChrisTownsend | syeh: Oh, I see. If it's being forced into low graphics mode without UNITY_LOW_GFX_MODE being set, it's due to your hardware configuration. Setting UNITY_LOW_GFX_MODE=0 will not force non-low graphics mode. | 18:40 |
| syeh | Right, so would it be okay if I make it so that a user can force it to *not* go into low gfx mode? | 18:41 |
| syeh | A couple of drivers are now reporting "LLVM" in their renderer string. | 18:41 |
| syeh | I'm working on a Unity patch to fix that, and maybe providing a way to override the behavior if necessary | 18:42 |
| ChrisTownsend | syeh: Hmm, are they really LLVM drivers or is it a case they just happen to use that string and Unity is not accounting for that? | 18:43 |
| ChrisTownsend | syeh: I just want to make sure 3d is not enabled for real LLVM drivers and the user experience will be terrible. | 18:43 |
| syeh | Gallium drivers have a fall back path for certain draw operations (if they need it) | 18:45 |
| syeh | and the Gallium Draw module can use LLVM if it is available | 18:46 |
| syeh | it is different from the llvmpipe driver, which is a SW driver | 18:46 |
| syeh | So I think Unity should check for "llvmpipe" not "LLVM" | 18:47 |
| ChrisTownsend | syeh: Sure, that makes sense. | 18:48 |
| syeh | ok. What about the override path for UNITY_LOW_GFX_MODE = 0? | 18:48 |
| syeh | Does that make sense or should I leave it the way it currently is? | 18:49 |
| ChrisTownsend | syeh: I think you should do one merge proposal for the LLVM vs. llvmpipe change. Then you could do a second one for the override and see if it be accepted. I no longer work on Unity, so others will have to decide if it should be taken or not. You may want to discuss that will Trevinho when he's available. | 18:56 |
| syeh | ok. Will do. Thanks. | 18:57 |
| kgunn | Saviq hey so i'm not getting my way on working around that little unity-api/qtmir | 19:09 |
| kgunn | any eta on when i might be able to dual land a qtmir again ? | 19:10 |
| Trevinho | syeh: I'm currently travelling in China so I'll be more reachable next week. If you have a MP ready would be nice. | 19:21 |
| syeh | Trevinho: I can't get through the firewall to push my branch, so I've attached it here: | 19:22 |
| syeh | https://bugs.launchpad.net/unity/+bug/1491555 | 19:22 |
| ubot5 | Ubuntu bug 1491555 in Unity "Unity unnecessarily goes to low graphics mode" [Undecided,New] | 19:22 |
| Saviq | kgunn, I want to prepare a silo with what I wrote in the pastebin tomorrow | 19:36 |
| Saviq | kgunn, but that might very well be a dual-landing of qtmir, too | 19:37 |
| Saviq | or well, *will* be, we can add commits to it if you want | 19:41 |
| kgunn | SAviq i think so...just need to stay in sync with bregma and camako, but yeah, it prolly makes sense to use this | 20:19 |
| kgunn | https://code.launchpad.net/~mir-team/mir/released-rebuild-for-vivid-overlay/+merge/269918 | 20:19 |
| kgunn | and then there's one for usc | 20:20 |
| kgunn | or one would need to be made rather.... | 20:21 |
| kgunn | bregma: ^ this is the unity-api sorting, since it's all just no change rebuilds for mir/usc/qtmir this could be done in one shot | 20:23 |
| bregma | assuming unity-api is fixed properly | 20:24 |
| kgunn | bregma: precisely the point of Saviq's landing...."it just might work"tm | 20:30 |
| bregma | we'll get it straightened out while you're gone | 20:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!