| === mibofra is now known as Guest39244 | ||
| robert_ancell | So, since mir_surface_set_event_handler has completely changed what's the correct method to ifdef this so code compiles on both versions of Mir? | 03:48 |
|---|---|---|
| robert_ancell | Yeah, so it looks like no-one is updating mir_toolkit/version.h | 04:09 |
| === chihchun is now known as chihchun_afk | ||
| robert_ancell | Same goes for MirEvent | 04:13 |
| === chihchun_afk is now known as chihchun | ||
| robert_ancell | RAOF, what's the correct way to handle Mir events in the main thread now? | 05:37 |
| robert_ancell | And if the answer is no change, how do I copy events now the structure is opaque? | 05:39 |
| === ljp is now known as lpotter | ||
| === mibofra is now known as Guest63244 | ||
| === chihchun is now known as chihchun_afk | ||
| === chunsang is now known as chunsang-away | ||
| === chihchun_afk is now known as chihchun | ||
| === alan_g is now known as alan_g|lunch | ||
| === chunsang-away is now known as chunsang | ||
| === chihchun is now known as chihchun_afk | ||
| === alan_g|lunch is now known as alan_g | ||
| alan_g | kdub: @"eglMakeCurrent(egldisplay, EGL_NO_SURFACE, EGL_NO_SURFACE, eglctx)" - I thought (probably wrongly) that eglctx was needed for updateAnimation() | 14:35 |
| kdub | looking again | 14:40 |
| kdub | alan_g, no, doesn't look like its needed for that | 14:41 |
| kdub | it probably doesn't hurt though, because if the context is still current, the lifetime is extended past eglDestroy context, until the context is no longer current | 14:42 |
| kdub | but... it doesn't call eglDestroyContext() anyways :) | 14:43 |
| === chihchun_afk is now known as chihchun | ||
| tsdgeos | guys | 14:51 |
| tsdgeos | what's up with mir_input_event_get_touch_event vs mir_input_event_get_touch_input_event ? | 14:52 |
| tsdgeos | which one should we be using? | 14:52 |
| tsdgeos | because qtubuntu seems to be using one but the other seems to exist | 14:52 |
| tsdgeos | there was a rename recently? | 14:52 |
| tsdgeos | kgunn: anyone that can know this stuff? ↑↑↑↑ | 14:54 |
| dandrader | tsdgeos, there was a refactoring in the input events, but it all landed a month ago or so | 14:58 |
| tsdgeos | dandrader: maybe we have not updated qtubuntu to use those correctly? | 14:58 |
| dandrader | tsdgeos, yes, maybe | 14:58 |
| tsdgeos | dandrader: i.e. can you build qtubuntu? | 14:58 |
| tedg | Seems that the autopkg tests for mir are all passed, does anyone know why Mir is still in wily proposed? | 14:59 |
| dandrader | tsdgeos, hmmm, actually qtubuntu should already be using the latest mir input api | 14:59 |
| alan_g | kdub: @eglInitialize do we need exactly major.minor == 1.4? Or std::tie(major, minor) >= std::tie(1, 4)? | 15:00 |
| kgunn | tsdgeos: yeah...so, just found out | 15:00 |
| kgunn | overaly doesn't have a check.... | 15:00 |
| AlbertA | tsdgeos: yes there was a rename, the first one is the one | 15:01 |
| kgunn | but archive does.... | 15:01 |
| tsdgeos | dandrader: build failed here | 15:01 |
| kgunn | so mir stuck | 15:01 |
| kgunn | tsdgeos: is this shell rotation on wily ? | 15:01 |
| kgunn | (i was assuming) | 15:01 |
| kdub | alan_g, the first one, its somewhat of an api check | 15:01 |
| tedg | kgunn, But it seems the checks are passed? No? | 15:01 |
| tsdgeos | kgunn: yes, well it's qtubuntu on vivid too | 15:01 |
| tsdgeos | it just doesn't build for me | 15:01 |
| tsdgeos | http://paste.ubuntu.com/11372143/ | 15:01 |
| tedg | http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mir | 15:01 |
| dandrader | tsdgeos, you mean vivid+overlay_ppa? | 15:02 |
| tsdgeos | thus qtubuntu on shell rotation doesn't build either | 15:02 |
| kgunn | tsdgeos: i'm about to add qtubuntu to our silo 30 | 15:02 |
| tsdgeos | dandrader: yep | 15:02 |
| kgunn | for wily | 15:02 |
| kgunn | right...so mir landed in vivid+overlay (which it sholdn't have) | 15:02 |
| kgunn | and i need to add qtubuntu to mir silo 30 for wily | 15:02 |
| kgunn | then go back and rebuild qtubuntu in overlay | 15:02 |
| tedg | kgunn, I don't think you can add to the silo after it is published? | 15:03 |
| tsdgeos | kgunn: ok | 15:03 |
| kgunn | tedg: don't worry...we're on it | 15:03 |
| tsdgeos | i'll EOD now since i did an early start this morning due to the jet lag | 15:03 |
| kgunn | o/ | 15:03 |
| tedg | K, just want to be able to test my silo, which built against Mir 0.13. | 15:04 |
| === dandrader is now known as dandrader|lunch | ||
| === sil2100_ is now known as sil2100 | ||
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| alan_g | kdub: cleanup pushed to unity-system-compositor/spinner-rework | 15:32 |
| kdub | thanks, looking again | 15:33 |
| kdub | alan_g, lgtm | 15:35 |
| === chihchun is now known as chihchun_afk | ||
| === dandrader|lunch is now known as dandrader | ||
| === alan_g is now known as alan_g|EOD | ||
| === Guest63244 is now known as mibofra | ||
| racarr | hmm | 17:35 |
| racarr | err whoops | 17:35 |
| racarr | Hi anyway though | 17:35 |
| racarr | Apparently theres a real launchpad bug being worked on :( | 17:35 |
| racarr | Lunch! be back in a bit...new-input-dispatcher pipeline fixed up...now doing some onomotopoeia required for platform-api changes that should have landed with 0.13 to land | 18:54 |
| racarr | P.S. Im still using the silo on my phone and that dash freeze hasnt shown up again | 18:57 |
| anpok | hm yes, gst-plugins-bad currently does not use papi, and might be better off when we have the new buffer api to do the buffer handling directly | 19:54 |
| anpok | there are just a fair amount of unused includes that pulled in papi in with that code that did not work with current mir | 19:55 |
| racarr | so I guess a fix needs to land in gst-plugins-bad to not use the include | 19:56 |
| anpok | it might also work by just fixing papi | 19:56 |
| racarr | what papi headers does it use | 19:57 |
| anpok | it pulls in application/ui/{window,options,display,session}.h | 19:58 |
| racarr | Yeah those are all dead | 20:01 |
| racarr | it needs to be fixed | 20:01 |
| racarr | papi is no longer a mir abstraction | 20:02 |
| racarr | ah | 20:54 |
| racarr | the qtubuntu changes are the respones required to duflus renames | 20:54 |
| racarr | I'll submit a branch after I escape emulator hell | 20:55 |
| racarr | if I do :p | 20:55 |
| kgunn | camako: do you know what day we landed mir0.13.0 in vivid+ ? | 20:55 |
| kgunn | camako: nvmd...i'll cross check | 20:56 |
| racarr | rsalveti: https://code.launchpad.net/~mir-team/platform-api/delete-deprecations/+merge/254170 its working now | 21:00 |
| rsalveti | that's a lot of removals | 21:04 |
| rsalveti | guess just needs ricmm's blessing | 21:04 |
| racarr | yeah if we get nervous we can just delete the mir implementation and keep the headers around ...e.g. slightly less delete than the initial proposal | 21:06 |
| racarr | but I'd be pretty happy to get rid of it... | 21:07 |
| racarr | so much dead code lol | 21:07 |
| racarr | mir_input_event_get_<NOUN> mir_keyboard_event_<NOUN> | 21:09 |
| * racarr rage | 21:09 | |
| racarr | anpok: What's going on with gst-plugins-bad did you propose a fix or should I figure out how? | 21:12 |
| racarr | https://code.launchpad.net/~mir-team/qtubuntu/track-mir-deprecations/+merge/260214 | 21:12 |
| racarr | here is the qtubuntu branch | 21:12 |
| racarr | needed | 21:12 |
| racarr | kgunn: What are the bug# for all this release breakage | 21:16 |
| racarr | fixes up for qtubuntu and platform-api...trying to digest gst-plugins-bad nmow | 21:16 |
| kgunn | racarr: so no bug# for qtubuntu...mir is just stuck in proposed for wily | 21:24 |
| kgunn | there is a bug for platform-api | 21:24 |
| kgunn | one sec | 21:24 |
| kgunn | racarr: this one | 21:25 |
| kgunn | https://bugs.launchpad.net/ubuntu/+source/platform-api/+bug/1458680 | 21:25 |
| ubot5 | Launchpad bug 1458680 in platform-api (Ubuntu) "platform-api FTBFS in wily (2.9.0+15.04.20150326-0ubuntu1)" [Undecided,New] | 21:25 |
| racarr | kgunn: Oh I see I already found that one this morning | 21:26 |
| racarr | sorry lol | 21:26 |
| racarr | ok I dont think anything more can be done until | 21:27 |
| racarr | 1. PAPI needs signoff from ricmm | 21:27 |
| racarr | 2. Qtubuntu update needs review | 21:27 |
| racarr | 3. Gst-plugins needs questions answered then port to mirclient (few hours of effort) | 21:27 |
| racarr | or delete | 21:27 |
| racarr | 4. Rerelease | 21:28 |
| camako | damn that's a lot | 21:28 |
| kgunn | yeah...whoa | 21:28 |
| kgunn | racarr: so this was an abi break yes ? | 21:28 |
| kgunn | or no....guess it was a hard api break | 21:28 |
| kgunn | cause papi failing | 21:28 |
| kgunn | how the heck did this ever land in vivid+ ? | 21:29 |
| * kgunn is confused | 21:29 | |
| racarr | kgunn: As far as I understand | 21:29 |
| racarr | things built against an old version of Mir | 21:29 |
| racarr | due to some sort of issue | 21:29 |
| racarr | and | 21:29 |
| racarr | well | 21:29 |
| racarr | lol | 21:29 |
| racarr | I guess we need a revision to our instructions | 21:30 |
| racarr | for the lander because | 21:30 |
| camako | kgunn: alan_g had this to say about why things worked : | 21:30 |
| racarr | it would have been obvious if there was a step like uh | 21:30 |
| camako | "<alan_g> OK the reason we didn't see problems is that we didn't force an uninstall of libmircommon3 so things just continued working" | 21:30 |
| racarr | "Think if what you are landing makes sense" lol | 21:30 |
| racarr | because we all knew we broke API so the fact that we werent releasing | 21:31 |
| racarr | PAPI should have been a huge red flag | 21:31 |
| kgunn | right, so we had old libs present to make things happy | 21:31 |
| racarr | I'm not sure we how we can encode that in to the release process... | 21:31 |
| * kgunn actually wondered at one point why there was no papi in the silo | 21:31 | |
| camako | we removed the server dependency | 21:31 |
| kgunn | just thot alan was being clever | 21:31 |
| racarr | :) I never looked. | 21:31 |
| racarr | mm | 21:31 |
| racarr | yeah | 21:31 |
| racarr | we should add a step to the doc where | 21:31 |
| racarr | the lander asks everyone if they think their expected branches | 21:32 |
| racarr | are in the silo | 21:32 |
| racarr | ...lol | 21:32 |
| racarr | more process | 21:32 |
| racarr | [I unno | 21:32 |
| * camako is still confused... PAPI doesn't depend on Mir server any more, so why should there have been a break? | 21:33 | |
| racarr | mirclient | 21:33 |
| racarr | multiple mirclient API and ABI breaks | 21:34 |
| racarr | 1. event.h is now private | 21:34 |
| racarr | 2. Event 2.0 symbols got renamed | 21:34 |
| racarr | 3. direct access of surface buffers etc is now deprecated and you have to use | 21:34 |
| racarr | buffer_stream_* | 21:34 |
| racarr | 4.....omg I just saw it | 21:34 |
| racarr | oh | 21:34 |
| racarr | set_event_handler now | 21:35 |
| racarr | takes callback, context intsead of | 21:35 |
| racarr | MirEventDelegate | 21:35 |
| camako | racarr, so this wasn't correct : "Mirclient ABI unchanged at 8" | 21:35 |
| racarr | camako: I don't see how it could be. | 21:37 |
| racarr | 1 and 3 Is just an API break | 21:37 |
| racarr | are just an API break | 21:37 |
| racarr | uh | 21:37 |
| racarr | 2...is technically an ABI break in libmircommon right | 21:37 |
| racarr | because the symbosl got moved from libmirclient to libmircommon | 21:38 |
| racarr | it seems like | 21:38 |
| racarr | #4 is just a plain old ABI break though | 21:38 |
| racarr | unless someone has done something clever | 21:38 |
| racarr | undoubtedly there are numerous API breaks | 21:38 |
| camako | racarr, on your still-to-do list above : | 21:42 |
| camako | 1- which MP needs signoff from ricmm | 21:42 |
| racarr | camako: I sent it in an email as well | 21:43 |
| racarr | but https://code.launchpad.net/~mir-team/platform-api/delete-deprecations/+merge/254170 | 21:43 |
| racarr | ugh | 21:43 |
| camako | oh ok thanks | 21:43 |
| racarr | omg its so big | 21:43 |
| camako | lol | 21:43 |
| racarr | Diff against target: 9656 lines (+48/-9073) 59 files modified | 21:43 |
| racarr | lol | 21:43 |
| racarr | I definitely know what all that code is *smiles and nods* | 21:43 |
| rsalveti | kgunn: can we work on a test, for mir, that would try doing a reverse builds for everyone in the reverse-build-dep list? | 22:36 |
| rsalveti | kgunn: just thinking on how we could avoid such platform-api breakage on the future | 22:36 |
| kgunn | rsalveti: please speak with camako | 22:36 |
| rsalveti | camako: ^? :-) | 22:37 |
| camako | rsalveti, we have abi-compliance checker to notify us of ABI breaks... I'm scratching my head how this would not have been caught by that | 22:37 |
| kgunn | i was just wondering the same | 22:38 |
| kgunn | but camako it would only tell you mir abi broke | 22:38 |
| kgunn | and you need to "do something" | 22:38 |
| kgunn | it was the "somethings" | 22:38 |
| rsalveti | afaik the change included removing headers and calls | 22:38 |
| kgunn | it wouldn't tell you | 22:38 |
| racarr | It was mostly API breaks anyway | 22:39 |
| rsalveti | right | 22:39 |
| racarr | we could have a "test"...but uh | 22:39 |
| racarr | preventing it is really easy lol | 22:39 |
| racarr | if Mir API breaks rebuild downstreams | 22:39 |
| rsalveti | my question is how could we systematically avoid that in the future | 22:39 |
| racarr | in the silo | 22:39 |
| racarr | and we failed to do that during release | 22:39 |
| rsalveti | right, which is why I want a check/test that would verify that automatically | 22:39 |
| kgunn | technically this did get caught in wily | 22:40 |
| rsalveti | and block the landing | 22:40 |
| rsalveti | did it? | 22:40 |
| kgunn | but didn't in our ghetto ass vivid+overlay | 22:40 |
| racarr | rsalveti: Yeah autopkgtests | 22:40 |
| racarr | catch it right | 22:40 |
| racarr | because they do this | 22:40 |
| racarr | reverse building | 22:40 |
| rsalveti | http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html | 22:40 |
| rsalveti | mir is a valid candidate in there | 22:40 |
| kgunn | rsalveti: one sec | 22:41 |
| AlbertA | racarr: libmirclient was still ABI compatible.... | 22:41 |
| AlbertA | but there is something yet not root caused | 22:41 |
| racarr | AlbertA: If nothing else the set_event_handler | 22:41 |
| racarr | was an ABI break right? | 22:41 |
| racarr | the others were just API breaks | 22:41 |
| racarr | afaics | 22:41 |
| AlbertA | racarr: there's an ABI compatible version of it though.... | 22:41 |
| AlbertA | racarr: but of course if a downstream needs rebuilding... | 22:42 |
| kgunn | rsalveti: it's still stuck on this check afaik | 22:42 |
| kgunn | http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt | 22:42 |
| AlbertA | then yes you would hit that | 22:42 |
| racarr | AlbertA: Right API break downstream needs rebuilding | 22:42 |
| racarr | OH | 22:42 |
| kgunn | so it may look ok, but it's still in proposed | 22:42 |
| racarr | I have an idea | 22:42 |
| rsalveti | kgunn: but there is nothing platform-api related in there | 22:42 |
| racarr | we told ourselves we didn't need to rebuild in the silos because we thought it was only an API break | 22:42 |
| rsalveti | right, I think something else blocked it | 22:42 |
| racarr | but | 22:43 |
| racarr | because its not API compatible the | 22:43 |
| kgunn | rsalveti: right, qtubuntu | 22:43 |
| racarr | autopkg tests that uh | 22:43 |
| racarr | build the rdeps for the proposed promotion (this is what happens right?) | 22:43 |
| racarr | of course fail | 22:43 |
| rsalveti | right, we might need an autopkg test in platform-api that would include such rebuild | 22:43 |
| rsalveti | and ideally the same for every mir client we care | 22:43 |
| rsalveti | but, this would only work for wily | 22:43 |
| kgunn | rsalveti: except aren't we trying to drop that ? | 22:43 |
| rsalveti | not for the ghetto silo | 22:44 |
| racarr | oh I guess I thought we had that and thats why it was failing in proposed | 22:44 |
| rsalveti | kgunn: are we? | 22:44 |
| rsalveti | I think we're trying to drop autopilot | 22:44 |
| kgunn | rsalveti: sorry..."that"...i thot racarr said we should drop the dependency from papi to mir | 22:44 |
| kgunn | qtubuntu will still have one on libmircommon | 22:44 |
| racarr | mirclient* | 22:45 |
| kgunn | oh...and client | 22:45 |
| racarr | but yes when delete-deprecations we | 22:45 |
| racarr | can drop the dependency | 22:45 |
| rsalveti | right, if we remove the mir dependency entirely, then we don't need to worry with it | 22:45 |
| camako | we can have all the tests/checks that we want.. if thy don't get run for the ghetto, then we ain't catching anything | 22:46 |
| racarr | I think if we're going to continue down this line we have to focus on | 22:47 |
| racarr | figuring out what happened first | 22:47 |
| camako | yeah we need to let alan_g do his thing with the release and then put checks/tests in place | 22:48 |
| camako | definitely more to be discussed tomorrow | 22:48 |
| racarr | I think | 22:48 |
| racarr | our ABI checker did its job but | 22:48 |
| racarr | because of the | 22:49 |
| racarr | rebuilding at the proposed gate | 22:49 |
| AlbertA | racarr: camako: yeah there's some subtle ABI break with the libmircommon dep | 22:49 |
| racarr | if we break API | 22:49 |
| AlbertA | that's not entirely obvious.... | 22:49 |
| kgunn | right, alan was saying what AlbertA just said ^ | 22:49 |
| racarr | we can't skip updating things | 22:49 |
| racarr | it doesn't seem like the ABI break is the problem though because | 22:49 |
| racarr | the packages work when you install them | 22:49 |
| kgunn | racarr: i'll repost here what alan shared | 22:50 |
| racarr | e.g. as we did in Dallas to test the hotfixes | 22:50 |
| racarr | okj | 22:50 |
| kgunn | forgive me if this doesn't work | 22:51 |
| kgunn | ah crap...lemme pastebin it | 22:51 |
| kgunn | racarr: AlbertA.... ok | 22:55 |
| kgunn | https://pastebin.canonical.com/132012/ | 22:55 |
| AlbertA | kgunn: right... | 22:56 |
| racarr | Yeah I guess part of the problem is we really did break ABI (though again...things seemed to work) | 22:56 |
| racarr | and then the other part is...we broke API and tried to avoid rebuilding downstreams | 22:57 |
| racarr | but we cant do this because they get rebuilt | 22:57 |
| racarr | in the archive | 22:57 |
| robert_ancell | speaking of breaking API and ABI... | 22:57 |
| racarr | so breaking API without breaking ABI isn't a real thing for us | 22:57 |
| robert_ancell | :P | 22:57 |
| kgunn | robert_ancell: glad to see things have progressed so far since you were playing with us :) | 22:57 |
| robert_ancell | kgunn, aha I was thinking everything stays the same! | 22:58 |
| AlbertA | racarr: right...so need to update release process | 22:58 |
| racarr | Yeah | 22:58 |
| racarr | lol its not more of the same | 22:58 |
| racarr | its a new situation that we've never run in to before | 22:58 |
| AlbertA | racarr: breaking API automatically needs rebuilt of all libmiclient rdeps | 22:58 |
| racarr | and we hopefully wont run in to again if we can figure out a sensible | 22:58 |
| racarr | process | 22:58 |
| kgunn | but, a result in trying to be clever | 22:58 |
| racarr | AlbertA: Yes. I think thats enough | 22:58 |
| robert_ancell | anpok, what does "TA" mean in https://code.launchpad.net/~robert-ancell/mir/buffer-stream-prototype/+merge/260094? | 22:58 |
| racarr | kgunn: Yeah you could spin this as a result of trying to be clever lol | 22:58 |
| kgunn | i always thot we should bump downstreams always | 22:58 |
| racarr | and or save time | 22:59 |
| racarr | Probably trying to save time more than being clever ;) | 22:59 |
| AlbertA | kgunn: well so far we have avoided breaking API in the client | 22:59 |
| AlbertA | until now | 22:59 |
| racarr | well and we've never tried to do an | 22:59 |
| AlbertA | precisely to avoid rebuilding all rdeps | 22:59 |
| kgunn | true | 22:59 |
| racarr | API break no ABI break | 22:59 |
| racarr | afaik | 22:59 |
| kgunn | all true | 22:59 |
| racarr | right because weve just | 22:59 |
| racarr | avoided API break since like | 22:59 |
| racarr | 0.6 | 22:59 |
| racarr | lol | 22:59 |
| kgunn | i know....we should break it more often to get used to it :-P | 23:00 |
| racarr | robert_ancell: It means top approve | 23:00 |
| robert_ancell | racarr, aha, thanks | 23:00 |
| AlbertA | kgunn: well that's what ryan suggested in a way... | 23:00 |
| racarr | robert_ancell: :D | 23:00 |
| robert_ancell | racarr, kgunn, so the API/ABI break issue I have is the new input functions and XMir. We want to get the new XMir running in vivid to keep kgunn happy for phone work but also want to get it into the wily archive. I've been updating the code to work in wily but there doesn't seem to be any way of ifdefing the code to handle both. | 23:03 |
| robert_ancell | Also using ifdefs will be a major PITA since the changes are quite significant. | 23:03 |
| robert_ancell | What was you intention (if any) for handling a case like this? | 23:04 |
| racarr | ugh...I see | 23:04 |
| racarr | robert_ancell: The intention was that the new input functions were already out | 23:04 |
| racarr | for a release and | 23:04 |
| racarr | the old way was deprecated in 0.12 already so you were supposed to be able to build against 0.12 and 0.13 | 23:05 |
| racarr | by using hte new API | 23:05 |
| robert_ancell | racarr, oh, should I be able to do all this in vivid currently? | 23:05 |
| kgunn | robert_ancell: so the deal is...we landed in vivid+overlay | 23:05 |
| kgunn | we're trying to sync to wily | 23:06 |
| racarr | robert_ancell: I think so | 23:06 |
| kgunn | when we discovered this little poop pile | 23:06 |
| robert_ancell | kgunn, yeah, so should I not be SRUing to vivid and just relying on a new Mir via an overlay? | 23:06 |
| racarr | lol sounds even better | 23:06 |
| racarr | maybe | 23:06 |
| kgunn | right...and as soon as we fix all this, it'll be in vivid+overlay and wily both | 23:06 |
| racarr | alan_g and raof have opinions on SRUing to vivid | 23:07 |
| racarr | that I wasnt able to understand | 23:07 |
| racarr | but they were discussing it :) | 23:07 |
| kgunn | at least mir0.13.0 (and eventually mir0.13.1) | 23:07 |
| robert_ancell | It's desirable to SRU to vivid to remove all traces of the old code and thus reduce the confusion from bug reports | 23:07 |
| kgunn | mmm | 23:07 |
| robert_ancell | kgunn, where is the overlay PPA? | 23:08 |
| kgunn | robert_ancell: do you really need it? or ...if you flash an image from a certain channel you'll get it | 23:10 |
| kgunn | on the device | 23:10 |
| robert_ancell | kgunn, I was just wondering how to get XMir into it | 23:10 |
| robert_ancell | With the API/ABI issues etc I'm thinking it will be best to target wily archive and overlay PPA for XMir and then look at vivid SRU as a target of opportunity. | 23:13 |
| kgunn | robert_ancell: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay | 23:13 |
| kgunn | camako: wait check this ^ | 23:13 |
| kgunn | see the warning at the top | 23:13 |
| camako | ok | 23:13 |
| kgunn | does that mean it's truly borked | 23:13 |
| kgunn | 13.1 didn't go in | 23:14 |
| kgunn | so not borked...nvmd | 23:14 |
| camako | kgunn, at the top where? | 23:14 |
| racarr | Mirv 0.13.1+15.04.20150520-0ubuntu1 CI Train Bot Account (2015-05-21) | 23:14 |
| racarr | ? | 23:14 |
| racarr | err | 23:14 |
| kgunn | camako: at the top of the web page | 23:14 |
| kgunn | for the overlay ppa | 23:14 |
| racarr | I don't get a warning | 23:14 |
| racarr | on that page | 23:14 |
| racarr | what does it say? | 23:14 |
| kgunn | Copying failed of mir (0.13.1+15.04.20150520-0ubuntu1) | 23:15 |
| camako | me neither | 23:15 |
| racarr | hahaha love that launchpad | 23:15 |
| racarr | anyway I see a Mir package in the list so *shrug* | 23:15 |
| camako | you mean this : https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages | 23:15 |
| racarr | Yeah I see it there | 23:16 |
| racarr | hmm | 23:16 |
| racarr | weird error | 23:16 |
| kgunn | racarr: camako ...yeah, maybe it's just latent...that's wrong, mir 13.1 is there it seems | 23:17 |
| camako | yea I see the pkg so ?? | 23:17 |
| camako | kgunn, so it landed on v+o | 23:17 |
| kgunn | yeah | 23:18 |
| camako | but didn't sync in wily yet | 23:18 |
| kgunn | sorry,i just freaked cause we had so many other issues | 23:18 |
| camako | yeah I don't know if we should all freak | 23:18 |
| kgunn | racarr: i know you already sent one...but if any other news/info rises on this...can you make sure to hand off to alan in an email ? | 23:20 |
| racarr | kgunn: Ok np on both | 23:27 |
| RAOF | robert_ancell: I don't know if racarr has answered you, but “mir_event_ref” is what you're after. | 23:29 |
| robert_ancell | RAOF, why does it have a big "DO NOT USE THIS" above it? | 23:29 |
| racarr | hahahahahahaha | 23:30 |
| racarr | robert_ancell: Because it's really mir_event_copy so the performance characteristics | 23:30 |
| racarr | are unpredictable | 23:30 |
| racarr | um | 23:30 |
| racarr | sigh | 23:30 |
| robert_ancell | * | 23:30 |
| robert_ancell | * !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! | 23:30 |
| robert_ancell | * _________________________ | 23:30 |
| robert_ancell | *< Don't use mir_event_ref > | 23:30 |
| robert_ancell | *------------------------- | 23:30 |
| robert_ancell | * \ ^__^ | 23:30 |
| robert_ancell | * \ (oo)\_______ | 23:30 |
| robert_ancell | * (__)\ )\/\ | 23:30 |
| robert_ancell | * ||----w | | 23:30 |
| robert_ancell | * || || | 23:30 |
| robert_ancell | * !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! | 23:30 |
| robert_ancell | * NOTICE: mir_event_ref and mir_event_unref are implemented in terms of copy until | 23:30 |
| robert_ancell | * such point whereas direct MirEvent access as deprecated. This means you must | 23:30 |
| robert_ancell | * use the return value as your new reference | 23:30 |
| robert_ancell | * | 23:30 |
| robert_ancell | */ | 23:30 |
| robert_ancell | ok | 23:31 |
| racarr | Its | 23:31 |
| racarr | perfectly safe to use imo but | 23:31 |
| racarr | duflu was being hyper pedantic on review imo and refused to let it through | 23:31 |
| racarr | so we ended up with this | 23:31 |
| robert_ancell | haha! | 23:31 |
| racarr | I hate | 23:31 |
| racarr | that im always blaming things | 23:31 |
| racarr | on other people | 23:31 |
| racarr | but thats what happened from my perspective | 23:31 |
| racarr | lala | 23:31 |
| robert_ancell | RAOF, I had a question regarding DRI2 and Xorg. Since we need DRI2 for XMir it's been copied across from hw/xfree86. I was looking to make it common like dri3 to avoid this but the PCI scanning code seems quite tricky to keep without copying too much of xfree86 across. Do you think it's possible to make it common? | 23:33 |
| robert_ancell | I'm guessing an XMir upstream proposal would get shot down for copying dri2. | 23:33 |
| RAOF | Hm. | 23:34 |
| RAOF | Yes. | 23:34 |
| robert_ancell | yes=it's possible or yes=it would get shot down | 23:35 |
| racarr | the mir_event_ref thing is an exact example of the kind of thing I was trying to outline in Dallas where we try and push for this false ideal of 100% correctness in reviews | 23:36 |
| racarr | leading to a bunch of noise (this comment) | 23:36 |
| RAOF | It's... probably? possible to make it common. | 23:36 |
| racarr | to prevent a situation which would never happen | 23:36 |
| racarr | (someone trying to use mir_event_ref in a performance critical way) | 23:37 |
| racarr | Then do we even reach the ideal of correctness...I can spot 4 or 5 errors in that comment alone (contraction in formal writing, failure to capitalize start of sentence, incorrect about at which point mir_event_ref and mir_event_ref will be reimplemented, use of personal pronouns) | 23:40 |
| racarr | lol | 23:40 |
| racarr | (and to be clear it's my comment...) | 23:41 |
| racarr | when this happens we just eventually hit a level of noise (e.g. in this case the Cow, or "StreamDepiction" in surface-buffer-access) | 23:41 |
| racarr | where the discussion stops making sense and the | 23:43 |
| robert_ancell | Also, I read the text below the cow over and over again and I'm still not 100% sure what it means. | 23:43 |
| racarr | revisions end, but not because of improvement but | 23:43 |
| racarr | just because of having sufficiently confused the reviewers | 23:43 |
| racarr | robert_ancell: lol... | 23:43 |
| racarr | robert_ancell: It means use the return value of mir_event_ref | 23:43 |
| AlbertA | robert_ancell: it should have read...don't use it as "ref" but as a copy.... | 23:44 |
| racarr | As your new reference :D | 23:44 |
| AlbertA | i.e. don't do mir_event_ref(event) | 23:44 |
| robert_ancell | ok | 23:44 |
| AlbertA | do event = mir_event_ref(event_orig) | 23:44 |
| racarr | which the compiler warns you about anyway :p | 23:44 |
| racarr | so really just don't worry | 23:44 |
| racarr | and have fun with mir_event_ref | 23:44 |
| AlbertA | which BTW was my original contention with mir_event_ref as opposed to mir_event_copy .... :) | 23:46 |
| racarr | lol | 23:47 |
| racarr | lol im soured for reviews now....EOD I think | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!