| === maclin1 is now known as maclin | ||
| === davidcalle_ is now known as davidcalle | ||
| tsdgeos | Mirv: ping | 09:56 |
|---|---|---|
| Mirv | tsdgeos: pong | 10:03 |
| tsdgeos | Mirv: was speaking with Saviq about the audiorole issues with Qt 5.5 | 10:04 |
| tsdgeos | given that QML doesn't have ifdefs | 10:04 |
| tsdgeos | it would be cool if we could make our vivid Qt support the new roles | 10:04 |
| tsdgeos | and maybe even probably the W+1 Qt 5.5 support the old roles for a while | 10:04 |
| tsdgeos | to have a proper deprecation process | 10:04 |
| tsdgeos | otherwise it's very hard for us to have code that works both in w+1 and in vivid/overlay | 10:05 |
| Saviq | it's not even about QML not having ifdefs, but the fact that we'd break apps setting the old property name | 10:06 |
| Mirv | tsdgeos: oh right, you're thinking about the dual landing aspect? but I guess changing the audio roles in vivid could be seen as a risk. | 10:06 |
| tsdgeos | that to | 10:06 |
| tsdgeos | Mirv: i don't want to change them | 10:06 |
| tsdgeos | Mirv: i want to add the new ones | 10:06 |
| Saviq | we need to support both ones | 10:06 |
| tsdgeos | yep | 10:06 |
| Mirv | tsdgeos: ok. so how to eventually drop the support for non-upstream ones? | 10:06 |
| Saviq | in both vivid+overlay (which won't get Qt 5.5 will it?) and wily | 10:06 |
| Saviq | Mirv, we'd need to follow a deprecation process like the SDK does | 10:07 |
| Mirv | Saviq: well in an ideal world we could upgrade vivid+overlay to Qt 5.5. after some sunny day I get to publish 5.5 to wily+1, I can create a PPA to see how it looks there. | 10:07 |
| Saviq | yeah I meant wily+1 | 10:07 |
| Saviq | Mirv, sure, but that's not a target, yet, so when we land 5.5, we need to make sure stuff works there, too | 10:08 |
| Mirv | tsdgeos: so, I think the supporting of dual roles in qtmultimedia is actually the first thing that should be landed, so that you can continue shipping unmodified Unity 8 to both | 10:08 |
| Saviq | yup | 10:08 |
| Mirv | tsdgeos: can you come up with a patch for qtmultimedia that works on top of the current Qt 5.5 branch? maybe then we can switch the 5.4 qtmultimedia to the same set of patches (new upstream ones + yours filling up the old support) | 10:08 |
| Saviq | we need to coordinate with SDK guys | 10:08 |
| Mirv | dual landing silos can now be done for manual upload packages too, so we could have one silo to land to both wily+vivid overlays | 10:09 |
| Saviq | Mirv, OTOH, https://developer.ubuntu.com/api/apps/qml/sdk-15.04.1/QtMultimedia.Audio/ does not publish the Role prop... | 10:09 |
| tsdgeos | Saviq: what needs coordination with the SDK? | 10:10 |
| Mirv | Saviq: yeah, I don't think anyone is using it as it's only been there since summer | 10:10 |
| Saviq | tsdgeos, deprecation process | 10:10 |
| Mirv | in order to land to vivid overlay we'd need to not deviate wily from it, so I think first up is landing qtmultimedia 5.4.2 (wily) and 5.4.1 (vivid) and just keep the 5.5 PPA up-to-date too | 10:11 |
| Saviq | Mirv, tsdgeos, if it's not a public prop, maybe we don't need to jump through those hoops, but rather just backport the new patch to 5.4 | 10:11 |
| Saviq | bzoltan_, ping | 10:11 |
| tsdgeos | id' we fine with that | 10:12 |
| Saviq | would definitely be easier | 10:12 |
| tsdgeos | ./usr/share/click/preinstalled/com.ubuntu.clock/3.5.364/share/qml/alarm/AlarmSound.qml: audioRole: MediaPlayer.alert | 10:13 |
| tsdgeos | seems the clock at least is using it? | 10:13 |
| tsdgeos | ./usr/share/ubuntu/settings/system/qml-plugins/sound/SoundsList.qml: audioRole: MediaPlayer.alert | 10:13 |
| tsdgeos | and ↑ whatever it is | 10:13 |
| Mirv | Saviq: tsdgeos: but just backporting the new patch to 5.4 would still mean we need to upgrade qtubuntu-media, qtubuntu-camera and unity8 in vivid-overlay | 10:13 |
| Mirv | tsdgeos: ok, I guess it was announced then somewhere and started to be used | 10:14 |
| Saviq | Mirv, yes | 10:14 |
| Saviq | tsdgeos, well, clock and settings we'd have to update | 10:14 |
| Mirv | sounds like the original proposal is needed, otherwise this is expanding a bit too much | 10:14 |
| Mirv | however you wish. if only 5.4 backport is needed, I can handle that and give you a silo to put wily+vivid unity8 etc in | 10:14 |
| Saviq | but indeed without a new framework we won't be able to publish a new version of them | 10:15 |
| tsdgeos | Saviq: i'm just scared it may be used outside "our stuff" | 10:15 |
| Saviq | tsdgeos, well, that's the question - if it's used without being public, not really our fault | 10:15 |
| * Mirv creates a silo anyway for a new dual landing | 10:16 | |
| Saviq | we can't keep stable APIs of stuff we didn't commit to | 10:16 |
| Saviq | Mirv, tsdgeos, let's not do anything just yet and find out what's the real status of it | 10:16 |
| Saviq | if it's only been built in for internal use, maybe we can deal with that | 10:16 |
| tsdgeos | oki | 10:16 |
| * tsdgeos puts the work on this on a halt | 10:16 | |
| Mirv | tsdgeos: fix for 5.5 anyway welcome, it's a bit annoying to edit QML files by hand | 10:17 |
| Saviq | yeah we can have an MP up for 5.5 compatibility anyway | 10:18 |
| Saviq | as that's where we wanna get in any case | 10:18 |
| Mirv | jhodapp should know how the audio role API came to be, is it supposed to be public and what usage is there | 10:18 |
| Mirv | jhodapp: mostly we're interested if we did commit to the old API already, ie do we need do keep compatibility with both the old and new one until the old one is properly deprecated | 10:19 |
| Saviq | Machines vs. Machines has it commented out | 10:20 |
| Saviq | didn't find it anywhere else | 10:20 |
| * Saviq emailthreads | 10:20 | |
| === marcusto_ is now known as marcustomlinson | ||
| Saviq | Mirv, so this output https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1493851/comments/8 is from 5.5? | 10:26 |
| ubot5` | Ubuntu bug 1493851 in qtubuntu-media (Ubuntu) "Port to upstreamed versions of Audio Role patch" [High,In progress] | 10:26 |
| Saviq | FWIW they don't advertise the role property in upstream 5.5 docs either http://doc.qt.io/qt-5.5/qml-qtmultimedia-audio.html | 10:26 |
| Mirv | Saviq: yes, or strictly speaking it's a backport of Qt 5.6's upstream patch that we was submitted by us. the point is that it's better to switch earlier than linger it later... one option of course would be to postpone it and remove the patches until 5.6. but by then we might have more usage of the old API.. | 10:27 |
| Saviq | oh right | 10:27 |
| tsdgeos | i think the best would be supposrt both for 5.5 | 10:27 |
| tsdgeos | since technically it's not there yet | 10:27 |
| tsdgeos | and then remove it for 5.6 | 10:28 |
| tsdgeos | but yeah needs input from bzoltan_ & SDK | 10:28 |
| Saviq | tsdgeos, so what got renamed actually? the enums? | 10:28 |
| tsdgeos | Saviq: yep | 10:29 |
| Saviq | ack | 10:29 |
| tsdgeos | ah no | 10:29 |
| tsdgeos | both enum and property | 10:29 |
| tsdgeos | role instead of audioRole | 10:29 |
| Saviq | rly http://doc-snapshots.qt.io/qt5-5.6/qml-qtmultimedia-audio.html#audioRole-prop ? | 10:29 |
| tsdgeos | hmmm | 10:30 |
| tsdgeos | ok i guess what happenend is not that the audioRole is now part of 5.5 import | 10:31 |
| tsdgeos | not of 5.4 import | 10:31 |
| tsdgeos | that's going to be a mess | 10:31 |
| tsdgeos | we need the 5.0 import to still work for vivid | 10:31 |
| Saviq | so for 5.0 and 5.4 we'd need to support the old enum values | 10:32 |
| Saviq | and leave 5.5 be | 10:33 |
| Saviq | but then we can't make 5.4 forward-compatible | 10:33 |
| Saviq | so we need a new framework for 5.5 anyway | 10:33 |
| Saviq | it seems for as long as we want to support vivid/5.4 we'll need to make the 5.0 and 5.4 imports work | 10:49 |
| Saviq | no need for new enums in 5.0 or 5.4 import, though | 10:51 |
| Saviq | /food | 10:53 |
| tsdgeos | Mirv: ping#2 | 10:56 |
| tsdgeos | Mirv: unping for now | 10:57 |
| Mirv | hmm | 11:07 |
| Saviq | greyback_, please merge lp:~dandrader/qtmir/mousePointer in multimonitor | 11:07 |
| greyback_ | bah conflicts | 11:08 |
| greyback_ | Saviq: conflicts resolved, prob ok, but will build to make sure | 11:10 |
| tsdgeos | Mirv: ok, ping again, i can't seem to install silo 12 and get a bootable phone | 11:12 |
| tsdgeos | Mirv: have you tried lately? | 11:12 |
| Mirv | tsdgeos: "did you read the manual"? | 11:13 |
| greyback_ | Saviq: yeah builds ok | 11:13 |
| tsdgeos | Mirv: probably not | 11:13 |
| Mirv | tsdgeos: https://wiki.ubuntu.com/Touch/QtTesting | 11:13 |
| Mirv | tsdgeos: and yes, yesterday I think the last time | 11:14 |
| Mirv | tsdgeos: because of wily overlay pinning is now needed on wily too.. plus using it makes the 012 less likely to break. but citrain tool won't (ever) work. | 11:15 |
| Saviq | greyback_, tx | 11:57 |
| Saviq | Mirv, robru just tried a different approach in citrain tool (sent email around last night), still won't work? | 11:58 |
| === alan_g is now known as alan_g|lunch | ||
| Mirv | Saviq: yeah I think robru's new method should work (I checked the MP), so once it's in archives I can update the instructions | 12:05 |
| Mirv | since apt install without archives being disabled should also install the new depends, and citrain already does pinning | 12:05 |
| Saviq | yup | 12:06 |
| === JMulholland_ is now known as JMulholland | ||
| jhodapp | Mirv, as long as the new roles map to the same old role inside of pulse audio it doesn't matter | 12:27 |
| tsdgeos | Mirv: i have a black screen following the instructions on an areale | 12:37 |
| tsdgeos | ah because notifications | 12:37 |
| tsdgeos | obsiously | 12:37 |
| Mirv | jhodapp: ok, you can reply to Saviq's e-mail too to make the answer as verbose as possible. the thing is we have at least internal apps that use the old API that would break if not updated or if both API:s would be supported together for some time | 12:52 |
| Mirv | tsdgeos: obviously | 12:52 |
| Saviq | dandrader, hey, can you please merge lp:~gerboland/qtmir/multimonitor → lp:~dandrader/qtmir/surviveEmptyTexture → lp:~dandrader/qtmir/multimonitorNext | 12:53 |
| * greyback_ really wants a staging branch | 12:53 | |
| Saviq | greyback_, it wouldn't help that much this time, too many projects involved | 12:54 |
| jhodapp | Mirv, sure, moving to the new API is fine as long as they use the equivalent new role...but yeah I'll reply | 12:54 |
| Saviq | greyback_, at least half of MPs in silo 22 depend on other projects to go with, which means they shouldn't be staged | 12:56 |
| === alan_g|lunch is now known as alan_g | ||
| greyback_ | Saviq: unless those projects also had a staging branch.. | 12:56 |
| Saviq | greyback_, no, because at that point you introduce a requirement for both stagings to get released at the same time | 12:57 |
| greyback_ | which the train could do | 12:57 |
| Saviq | greyback_, not what I mean, if one of the projects' staging could not be released for whatever reason, the other one's blocked | 12:58 |
| greyback_ | Saviq: I'm not meaning a general staging branch for other projects, but unity8 could have a qtmir-staging branch, with only the changes qtmir needs | 12:59 |
| Saviq | greyback_, not sure what's the difference between individual MPs at that point | 13:00 |
| Saviq | but maybe | 13:00 |
| greyback_ | Saviq: no need to chain branches | 13:00 |
| greyback_ | that's the only benefit | 13:00 |
| greyback_ | not major, but might help for these mammoth silo situations | 13:00 |
| Saviq | greyback_, you need to chain stagings ;) | 13:01 |
| Saviq | because unity8/staging will conflict with unity8/qtmir-staging | 13:01 |
| dandrader | Saviq, done | 13:01 |
| Saviq | dandrader, thanks | 13:01 |
| greyback_ | Saviq: we'd only release one at a time. I try to only release unity8 & qtmir changes combined | 13:02 |
| Saviq | dednick, can you please merge lp:~dandrader/qtmir/multimonitorNext → lp:~nick-dedekind/qtmir/remove-dpkg-CMAK_INSTALL_PREFIX → lp:~unity-team/qtmir/touch_tracing | 13:02 |
| Saviq | greyback_, well, that's not the case in this mammoth silo, we're releasing everything for unity8 and qtmir together | 13:02 |
| dednick | Saviq: hm. thought i did that already | 13:04 |
| Saviq | dednick, you did, but we had a change up the chain | 13:04 |
| Saviq | that we need down the chain... | 13:04 |
| Saviq | ok I can't flash mako over usb any more :[ | 13:04 |
| dednick | Saviq: ah. k | 13:04 |
| dednick | Saviq: i don't see any conflicts. | 13:05 |
| Saviq | dednick, nope | 13:06 |
| dednick | Saviq: ah. didnt think that was necessary if no clnflicts | 13:06 |
| dednick | Saviq: done | 13:06 |
| Saviq | dednick, there are some down the chain, but couldn't get bzr to comply | 13:06 |
| Saviq | ltinkl, ↑ you can merge wheelEvent | 13:06 |
| ltinkl | Saviq, against what? | 13:23 |
| Saviq | ltinkl, against the prerequisite | 13:25 |
| Saviq | ltinkl, lp:~lukas-kde/qtmir/wheelEvent | 13:25 |
| ltinkl | Saviq, lp:~unity-team/qtmir/touch_tracing right? | 13:26 |
| ltinkl | (that's the prereq currently) | 13:26 |
| Saviq | ltinkl, yup | 13:27 |
| Saviq | ltinkl, that should have the fixed MouseButtons bit | 13:27 |
| ltinkl | Saviq, ye, on it | 13:27 |
| ltinkl | Saviq, merged | 13:37 |
| Saviq | ltinkl, ack | 13:38 |
| tsdgeos | Saviq: Mirv: commented at https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1502883 | 13:43 |
| ubot5` | Ubuntu bug 1502883 in qtdeclarative-opensource-src (Ubuntu) "Impossible to pull to refresh scopes with Qt 5.5" [Undecided,New] | 13:43 |
| tsdgeos | i'd say we just wait for Qt 5.5.1 | 13:44 |
| Saviq | tsdgeos, ack | 13:44 |
| tsdgeos | since once i updated the files regarding the flickable it went back to normal | 13:44 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === Guest77290 is now known as balloons | ||
| Saviq | ltinkl, GAH, you got green CI, how'd you do it!? ;) | 14:53 |
| ltinkl | \o/ | 14:53 |
| ltinkl | waiting for https://code.launchpad.net/~lukas-kde/unity8/fixLogin1Tests/+merge/272493 rebuild | 14:53 |
| ltinkl | hopefully it will also be green :) | 14:53 |
| * Saviq tempted to rebuild just to see if you cheated | 14:54 | |
| ltinkl | Saviq, btw is there a CI job that runs on trunk? | 14:54 |
| Saviq | ltinkl, we can trigger one on demand | 14:55 |
| Saviq | ltinkl, we could trigger it on push to trunk, but that's too late, 'innit ;) | 14:58 |
| ltinkl | ye | 14:58 |
| Saviq | I hope at some point we'll have them run in silo | 14:58 |
| tsdgeos | yeah | 15:06 |
| tsdgeos | that's particularly useful for MRs that require unity-api | 15:06 |
| tsdgeos | where CI is all failures | 15:06 |
| Saviq | tsdgeos, oh for that we need smarter CI that can take prerequisites from other projects into account | 15:07 |
| tsdgeos | Saviq: or just run on silos :D | 15:08 |
| tsdgeos | so at least we can run all the tests in a silo | 15:08 |
| Saviq | tsdgeos, sure, we need both, really | 15:08 |
| ltinkl | having a CI-enabled would also prevent breakages that don't happen in isolated MPs | 15:14 |
| ltinkl | like, 2 individual MPs might be fine but when combined together it would fail | 15:14 |
| Saviq | bbl | 15:16 |
| Saviq | whoo Mir 0.17 landed, means we might even think of landing 22 tomorrow | 15:17 |
| Mirv | tsdgeos: thanks, 5.5.1 should be fiiinally out tomorrow, hopefully. hopefully it fixes ~everything, but at least that bug.. | 15:27 |
| tsdgeos | Mirv: are there many issues? | 15:27 |
| Mirv | tsdgeos: still unresolved some UITK, some FTBFS:s, https://bugs.launchpad.net/bugs/+bugs?field.tag=qt5.5 - and no-one else besides me has tried it out or filed bugs so there might be more (and probably is) | 15:32 |
| tsdgeos | i see | 15:34 |
| tsdgeos | Mirv: regarding https://bugs.launchpad.net/ubuntu/+source/u1db-qt/+bug/1447182 | 15:51 |
| ubot5` | Ubuntu bug 1447182 in u1db-qt (Ubuntu) "u1db-qt FTBFS with Qt 5.5" [High,Triaged] | 15:51 |
| tsdgeos | $ LC_ALL=C apt-cache policy u1db-qt | 15:51 |
| tsdgeos | N: Unable to locate package u1db-qt | 15:51 |
| tsdgeos | ?¿ | 15:51 |
| tsdgeos | ah it's not the name of the pacakge | 15:52 |
| tsdgeos | my fault sorries | 15:52 |
| === dandrader|afk is now known as dandrader | ||
| dandrader | greyback_ greyback__ sorted out the surface resize threading issues. but it will need tripple buffering | 18:18 |
| dandrader | greyback__ only way I see of doing it with double buffering is using a non-threaded qsg renderer | 18:18 |
| greyback__ | dandrader: that's not ideal | 18:18 |
| greyback__ | but I can see why that would be an option | 18:19 |
| dandrader | greyback__, or using a "crop or pad" resize method | 18:19 |
| greyback__ | which no-one else in the world does, and we don't do either | 18:20 |
| dandrader | greyback__, this is actually what unity 7 does | 18:20 |
| greyback__ | dandrader: who needs to be triple buffered, the compositor and/or client? | 18:20 |
| dandrader | greyback__, but it's worse. it's more like a "crop or pad with random memory" | 18:20 |
| dandrader | greyback__, client | 18:21 |
| greyback__ | dandrader: ok, well doing better than unity7 would be best | 18:21 |
| greyback__ | dandrader: could you document your reasoning please? | 18:22 |
| greyback__ | this is something where looking at code won't obviously explain your approach | 18:22 |
| greyback__ | and a picture or two would help a lot | 18:22 |
| greyback__ | duflu could have insights on this too | 18:22 |
| robru | Saviq: Mirv did you try the new tool? I think it's not perfect but I think I know how to make it perfect, will experiment more today | 18:29 |
| Saviq | robru, I replied to the CFT email | 18:43 |
| robru | Saviq: thanks | 18:43 |
| dandrader | greyback__, branches are up for review: https://code.launchpad.net/~dandrader/qtmir/surfaceItemFillMode/+merge/274449 | 19:23 |
| === dandrader is now known as dandrader|afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!