| RAOF | kdub: Hey, is mir_connection_set_display_config_change_callback hooked up all the way through Mir? | 00:37 |
|---|---|---|
| kdub | wellll :) after ~kdub/mir/connect-display-request it will be | 00:38 |
| kdub | but it's not quite done yet, because the clients do not get the updated configuration after the display change yet | 00:39 |
| kdub | like, you can request, and check the error code, and the display should be changed, but there's still some hooking up and testing left to be done | 00:40 |
| RAOF | kdub: Ah, ok. | 00:42 |
| RAOF | So I shouldn't be concerned when XMir's handler doesn't actually get called on hotplug events ☺ | 00:42 |
| duflu | robert_ancell: Are PPAs still required for saucy at all? | 01:53 |
| duflu | Given... https://launchpad.net/ubuntu/+source/mir | 01:53 |
| robert_ancell | duflu, the staging PPA is handy as it contains a per commit build | 01:53 |
| duflu | robert_ancell: So handy but not required? | 01:53 |
| robert_ancell | the archive only contains per day builds, and only then if they pass integration tests | 01:53 |
| robert_ancell | yes | 01:53 |
| duflu | Kay | 01:53 |
| robert_ancell | no reason to get rid of them | 01:53 |
| duflu | Wow. What? How? It seems several times recently when I comment in LP, the email with my comment arrives in under 1 second later. That's incredible. | 02:43 |
| racarr | duflu: My life: 1. Make comment on launchpad 2. Zone out 3. Wait half a second, computer dings for new email, remember that its me commenting on launchpad 4. Phone makes sound, check it, it's me commenting on launchpad 5. repeat | 02:54 |
| duflu | racarr: Too many connected devices... You have a choice :) | 02:54 |
| duflu | ... unless they're all Ubuntu in which case you *should* have more | 02:56 |
| racarr | Haha | 02:57 |
| racarr | and they should all sync up over networked dbus or ubuntu one or whatever | 02:57 |
| racarr | so they realize not to notify me multiple times for the same event | 02:57 |
| racarr | anyyy day now | 02:57 |
| duflu | And have eye tracking to know which device you already saw it on | 02:58 |
| racarr | duflu: They should transfer us to design | 02:58 |
| duflu | I'm pretty sure we already have designers with big ideas. | 02:59 |
| duflu | Also, I don't do scarves | 02:59 |
| racarr | engineering it is then | 02:59 |
| smartboyhw | Mir guys: HELP http://paste.ubuntu.com/5964829/ | 03:23 |
| smartboyhw | I know what sort of problem is it, but since I'm not in the Mir team I can't fix:P | 03:24 |
| smartboyhw | mlankhorst, ^ | 03:24 |
| RAOF | Um, when did we bump mirserver ABI? | 03:26 |
| RAOF | That's a filthy lie. | 03:26 |
| RAOF | Gah. | 03:28 |
| RAOF | smartboyhw: I'll fix it. You know how to work around that, right? | 03:32 |
| duflu | RAOF: Because the switch branch landed. And accidentally using the old libmirserver would cause strange and hideous bugs | 03:33 |
| RAOF | duflu: Ok. But libmirserver0 wasn't parallel-installable-ready. | 03:34 |
| duflu | RAOF: Oh, that sucks. But I would still prefer error messages to strange bugs (and inexplicable test failures) | 03:35 |
| RAOF | Well, if you're using the packages we had that covered already :) | 03:35 |
| duflu | RAOF: I was using the packages. That's the problem... the ABI actually changed and it would pick up the old libs by mistake | 03:36 |
| duflu | ... when building Mir locally | 03:36 |
| RAOF | Right; only an issue then. :) | 03:36 |
| smartboyhw | RAOF, I know the fix, I don't know the workaround:P | 03:49 |
| RAOF | smartboyhw: Oh; dpkg --install --force-overwrite /var/cache/apt/archives/libmirserver1*.deb | 03:50 |
| smartboyhw | RAOF, thanks | 03:51 |
| RAOF | duflu: https://code.launchpad.net/~raof/mir/fix-mir_connection_get_display_info/+merge/179316 should fix that. | 04:02 |
| duflu | RAOF, ta | 04:18 |
| RAOF | Huh. No Robert. | 04:33 |
| smspillaz | how long is | 05:03 |
| smspillaz | MirWaitHandle! | 05:03 |
| smspillaz | guarunteed to live for | 05:03 |
| duflu | smspillaz: Depends on the class that gave it to you. Generally for as long as the object which gave it to you | 05:04 |
| duflu | Which is annoying. It means to avoid leaks, some repeated operations always need to reuse the same handle. | 05:06 |
| smspillaz | okay, so if I do mir_wait_for (surface_next_buffer_handle) and the surface already got its next buffer, it just waits for the next one correct? | 05:08 |
| smspillaz | so I can atomically set it to NULL in the callback and know from the main thread that we already got our next buffer | 05:08 |
| duflu | smspillaz, yeah it should recycle the same handle from inside the client surface object and always just wait for the next one | 05:10 |
| smspillaz | excellent | 05:10 |
| duflu | smspillaz: Of course, you're not meant to *know* each call returns the same handle | 05:11 |
| smspillaz | duflu: it doesn't really matter in my case | 05:11 |
| duflu | Sadly we can't even free a handle after it has been waited because (1) sometimes multiple threads will wait on one handle; and (2) the client API is designed such that waiting is optional and may never happen | 05:12 |
| smspillaz | I just need to be able to set the wait handle to NULL in the callback thread atomically and then check it for NULL atomically in the main thread | 05:12 |
| smspillaz | duflu: does mir_wait_for return after the callback in the other thread completes or before it completes? | 05:16 |
| RAOF | After | 05:18 |
| smspillaz | excellent | 05:18 |
| RAOF | Yeah, it's sensible :) | 05:18 |
| smspillaz | yeah I was a bit worried that I might have to lock the data I plan to modify during the callback while the main thread checks to see if it is pending or availaable | 05:19 |
| * duflu hope that's true for all operations | 05:19 | |
| smspillaz | *available | 05:19 |
| alf__ | RAOF: @preferred mode, it turned out I was checking the wrong struct field, there is indeed only one preferred mode as expected | 05:22 |
| RAOF | Ok. Let's see if this approach to one-window-per-output works... | 05:36 |
| didrocks | RAOF: hey! | 05:38 |
| didrocks | RAOF: are you as amazed than I am that the issue went away a little bit magically? (it's a good Friday news I guess at least ;)) | 05:39 |
| didrocks | RAOF: seems to be the -ati or hybris issue, I have the package versions diff, but still a little bit puzzled TBH :) | 05:39 |
| tvoss | good morning :) | 05:46 |
| didrocks | hey tvoss! how are you? | 05:50 |
| RAOF | didrocks: Yes. | 05:53 |
| RAOF | didrocks: Although given how odd the problem was, hybris seems a perfectly fitting cause :) | 05:53 |
| didrocks | RAOF: yeah, but why intel is more resistant to that? | 05:53 |
| RAOF | No idea. | 05:54 |
| tvoss | didrocks, pretty good :) how are you? | 05:55 |
| didrocks | tvoss: I'm thrilled to see the Mir issue on ati fixed for now :) | 05:56 |
| tvoss | didrocks, \o/ what fixed the issue? | 05:56 |
| RAOF | alf__: Oh, I do have another question for multi-monitor — how do I specify the output a surface is on? | 05:57 |
| alf__ | RAOF: you just place at the correct coordinates | 05:58 |
| didrocks | tvoss: that's part of the mystery, from the installed packaged diff, there are two culpurits: the -ati driver (but the diff seems thin) or the "hybris picked up by mesa" issue | 05:58 |
| didrocks | tvoss: the second sounds more plausible, but it would mean that intel can cope with that, not the ati card | 05:58 |
| RAOF | alf__: You do know that there's no way for a client to position a surface, right? | 05:59 |
| alf__ | RAOF: hmm, right, this is something we need to add... | 06:00 |
| tvoss | alf__, absolute positioning is something we definitely want to avoid. | 06:01 |
| RAOF | Well, except we don't really want to do that. | 06:01 |
| tvoss | alf__, I would propose a surface_{move,associate}_to_output | 06:01 |
| RAOF | I'd probably put it in the creation struct, but something like that, yes. | 06:02 |
| RAOF | didrocks: Oh, you might want to look at https://code.launchpad.net/~raof/mir/fix-mir_connection_get_display_info/+merge/179316 | 06:03 |
| didrocks | #ubuntu-desktop | 06:05 |
| alf__ | tvoss: what are the semantics of surface_move_to_output? | 06:07 |
| tvoss | alf__, move is the wrong verb, associate is a better term | 06:08 |
| RAOF | Another option is surface_fullscreen_for_output | 06:09 |
| alf__ | tvoss: in a multimonitor scenarios, where surfaces can span outputs, even association is a bit fuzzy. | 06:09 |
| RAOF | Which I think might make more sense again. | 06:09 |
| alf__ | RAOF: yes, I think that's better | 06:09 |
| alf__ | RAOF: tvoss: although, since we don't have resize support yet, it probably needs to be a creation option? | 06:10 |
| RAOF | alf__: Oh, I'd prefer it as a creation option anyway :) | 06:10 |
| RAOF | Which would have quite substantial semantics - can't be moved, will only be resized if the underlying output changes mode, is fullscreen. | 06:11 |
| tvoss | RAOF, alf__ +1 on creation option | 06:12 |
| alf__ | RAOF: I am not sure how resizing, even in this scenario, will work yet. Perhaps for the time being you will need to destroy/recreate surfaces when the mode changes. | 06:12 |
| RAOF | For now that's fine. | 06:13 |
| alf__ | RAOF: although it is a bit more complex than that... for example when two outputs are mirrored you don't need to create two surfaces, just one and place it appropriately. | 06:14 |
| RAOF | alf__: Well, I'd just create a surface and associate it to one of the clones. | 06:18 |
| alf__ | RAOF: right | 06:20 |
| alf__ | RAOF: tvoss: Do we want surface_fullscreen_for_output to be an unprivileged operation? | 06:21 |
| RAOF | I think so, yes. | 06:21 |
| RAOF | It's something reasonable clients will want to do. | 06:21 |
| RAOF | (Hello, presentation apps!) | 06:21 |
| tvoss | alf__, yes, but the semantics might be a little more complex than just saying: go fullscreen. Ideally, I would want that call to return a FullscreenSession object | 06:21 |
| tvoss | RAOF, or games | 06:22 |
| alf__ | tvoss: on the client side? | 06:23 |
| tvoss | alf__, yup | 06:23 |
| RAOF | tvoss: Isn't a "session" roughly the same as "a client connection"? | 06:23 |
| alf__ | tvoss: what will that FullscreenSession object do? | 06:24 |
| RAOF | If so, we very much *don't* want this to imply a FullscreenSession, as having one fullscreen and one normal window will be a pretty common use-case. | 06:24 |
| tvoss | RAOF, yes and no: in the general case, session is connection, yes. But in the special case of fullscreen, it is not equivalent | 06:25 |
| tvoss | RAOF, obviously, an app can have more than one surface on one connection | 06:25 |
| RAOF | I'm unclear as to what a FullscreenSession does, then. | 06:25 |
| tvoss | alf__, RAOF my idea there is that the lifetime of the session marks fullscreen enter and leave, plus attributes. The attributes could contain information like associated output, requested resolution, whether apps allow shell chrome to be put on top etc. | 06:28 |
| tvoss | alf__, RAOF the attributes would be passed when entering the fullscreen session, and some of them might be mutable during the fullscreen session | 06:28 |
| tvoss | alf__, RAOF so bundling them makes a lot of sense | 06:29 |
| tvoss | obviously from myp ov :) | 06:29 |
| RAOF | They sound like attributes on the surface; I'm still not sure what the session abstraction is for? | 06:31 |
| tvoss | RAOF, it accounts for: "fullscreen is a state with attributes, and the set of attributes can change per fullscreen session" | 06:34 |
| RAOF | But we can already set attributes on surfaces? | 06:39 |
| RAOF | duflu: Re: mir_wait_for_one - is there any guarantee that the "one" you're waiting for is the thing which triggers the unwait? | 06:43 |
| duflu | RAOF: I would have to refresh my memory and read the docs to answer that | 06:43 |
| RAOF | duflu: My recent reading of the code suggests "no", which makes it rather unuseful? | 06:44 |
| tvoss | duflu, congrats on the switch branch being landed :) | 06:46 |
| duflu | RAOF: I think wait_for_one returns as soon as there is any result. So no -- you can't know which thread's result you got a result for. In that case you should be using different MirWaitHandles | 06:46 |
| duflu | tvoss: Thanks, I think. | 06:47 |
| RAOF | I guess we do mostly allocate new MirWaitHandles for things that we might want to wait on. | 06:47 |
| duflu | RAOF: I think this is another good case for MirWaitHandle being thread-aware. That would also eliminate the need for two wait functions. | 06:48 |
| duflu | RAOF: Wait, no... | 06:48 |
| duflu | RAOF: Because the "result" gets signalled in a different thread. You can't ever know which client thread is destined to handle it | 06:49 |
| dholbach | good morning | 06:49 |
| RAOF | duflu: But we *should* be able to guarantee that mir_wait_for(mir_do_something()); waits until this particular mir_do_something() request has been processed, regardless of what other threads are doing, right? | 06:54 |
| RAOF | Or, to rephrase: we MUST be able to guarantee that... | 06:54 |
| RAOF | Not that this affects me at the moment, as X is single-threaded. | 06:54 |
| duflu | RAOF: It is guaranteed so long as only one thread ever sees that MirWaitHandle. Unfortunately our "reuse" of handles makes that tricky | 06:55 |
| RAOF | Right; the extent to which this is not guaranteed is a bug. | 06:55 |
| duflu | RAOF: It's a design bug. We would have to change the API to ever resolve it. | 06:59 |
| duflu | the client API... | 06:59 |
| * RAOF obviously thinks we should make that break | 07:06 | |
| RAOF | As it is we can't *actually* be used in multithreaded programs | 07:07 |
| smspillaz | duflu: RAOF: can't this just be solved from the client side though? | 07:09 |
| smspillaz | just atomically set the handle to NULL once the operation has completed | 07:09 |
| RAOF | smspillaz: How do you know that the operation has completed? | 07:10 |
| smspillaz | RAOF: mir_wait_for | 07:10 |
| smspillaz | RAOF: so the pattern I'm doing at the moment is | 07:10 |
| RAOF | Tells you that *all* the operations have completed, and isn't safe in the presence of multiple threads. | 07:11 |
| smspillaz | if (atomic_pointer_get (&wait_handle)) | 07:11 |
| duflu | RAOF: To do everything properly, you would return a new MirWaitHandle on every call, and then unfortunately being C (no destructors) would have to make it the client's job to mir_free_wait_handle() every time, even when the client doesn't care about the handle | 07:11 |
| smspillaz | mir_wait_for(wait_handle) | 07:11 |
| smspillaz | RAOF: erm ... mir_wait_for_one then ? | 07:11 |
| RAOF | smspillaz: And that doesn't guarantee that the operation you meant to wait for has occurred. | 07:11 |
| RAOF | That guarantees that *some* operation has occurred on the wait handle. | 07:11 |
| RAOF | But if that handle is shared, then… | 07:12 |
| smspillaz | RAOF: wait_handle is set to NULL once the operation completes | 07:12 |
| RAOF | smspillaz: libmirclient will give you the same wait handle for some calls | 07:12 |
| RAOF | eg: there's only one wait handle for mir_connection_drm_auth_magic, for example. | 07:13 |
| smspillaz | RAOF: I know. The idea is that the client, inside the callback, sets the wait_handle to NULL atomically | 07:13 |
| duflu | smspillaz: Your idea I guess | 07:13 |
| smspillaz | RAOF: the pointers to the wait handles themselves become unique identifiers of completeness | 07:14 |
| RAOF | Hm. Yeah, I think that works. | 07:14 |
| smspillaz | so you can have struct MyOperationData { MirWaitHandle *handle; } | 07:14 |
| duflu | So long as you keep in mind, the uniqueness is only unique to the tuple [connection, surface, operation] | 07:14 |
| smspillaz | then opdata->handle = mir_do_whatever (callback, &opdata); | 07:15 |
| RAOF | duflu: No, in this case it's unique to just operation. | 07:15 |
| smspillaz | and then in the callback | 07:15 |
| smspillaz | ... atomic_set (&opdata->handle, NULL); | 07:15 |
| smspillaz | Yay client side everything! | 07:15 |
| smspillaz | oh wait I forgot this isn't #wayland | 07:15 |
| duflu | RAOF: I meant otherwise, but it depends how you define operation :) | 07:15 |
| RAOF | smspillaz: Oh, but then you actually need to loop on mir_wait_for_one. | 07:16 |
| smspillaz | RAOF: loop ? | 07:16 |
| duflu | Yeah, loop if you expect a particular number. Otherwise mir_wait_for() to gobble all results in one go | 07:16 |
| RAOF | smspillaz: You can't use mir_wait_for because only one thread will ever escape from that. | 07:16 |
| RAOF | smspillaz: And mir_wait_for_one doesn't guarantee that your operation has completed. | 07:17 |
| smspillaz | oh I see | 07:17 |
| RAOF | smspillaz: So you need to while (atomic_pointer_get(&wait_handle)) mir_wait_for_one(wait_handle); | 07:17 |
| smspillaz | while (atomic_pointer_get (&opdata->handle) { mir_wait_for_one(wait_handle); } | 07:18 |
| duflu | RAOF: It does guarantee your operation has completed if you ensure [connection, surface, operation] are only used together in one known place, one thread | 07:18 |
| smspillaz | beat me to it | 07:18 |
| RAOF | duflu: Right. But the vast majority of clients will have exactly one connection, and not all operations operate on a surface; for those operations you're saying "make sure you only ever use one thread", which is not exactly the goal of a threadsafe API :) | 07:19 |
| duflu | RAOF: You will get a unique wait handle for each unique pairing of [surface, operation] | 07:20 |
| duflu | There is no confusion unless you do similar operations on a single surface from multiple threads | 07:20 |
| RAOF | Right. As long as [operation] *operates* on a surface. | 07:20 |
| RAOF | For operations which do *not* operate on surfaces you're restricted to one thread. | 07:20 |
| duflu | RAOF: I think so yes. That limitation originates from racarr's original client API design | 07:22 |
| duflu | See also https://bugs.launchpad.net/mir/+bug/1194384 | 07:22 |
| ubot5 | Launchpad bug 1194384 in Mir "Mir client callbacks are not thread-safe" [Medium,Triaged] | 07:22 |
| RAOF | I suspect we might be in violent agreement. | 07:24 |
| duflu | Yes, mediums such as this one often result that way | 07:27 |
| duflu | media? | 07:27 |
| RAOF | Indeed | 07:31 |
| tsdgeos | Guys, can't install some mir stuff | 08:29 |
| tsdgeos | http://paste.ubuntu.com/5965595/ | 08:29 |
| tsdgeos | any idea what's wrong? | 08:29 |
| duflu | tsdgeos: The mirserver ABI bumped last night. I think a fix is landing soon | 08:31 |
| tsdgeos | ok :-/ :-) | 08:31 |
| tvoss | didrocks, ping | 08:37 |
| didrocks | tvoss: pong | 08:37 |
| tvoss | didrocks, hey :) I see libmirserver1 in the daily-build ppa, but not yet in the archive | 08:38 |
| tvoss | didrocks, any idea when we will switch that over? | 08:38 |
| didrocks | tvoss: right | 08:38 |
| didrocks | tvoss: packaging issue | 08:38 |
| didrocks | see latest MP | 08:38 |
| tvoss | didrocks, ack | 08:38 |
| didrocks | tvoss: will be rerun today | 08:38 |
| tvoss | didrocks, is that the fix-mir_connection_get_display_info? | 08:39 |
| didrocks | tvoss: https://code.launchpad.net/~raof/mir/fix-mir_connection_get_display_info/+merge/179316 | 08:40 |
| didrocks | tvoss: we need that one merged | 08:40 |
| tvoss | didrocks, ack | 08:40 |
| didrocks | seems it's not approved anymore though | 08:40 |
| tvoss | alan_g can you give https://code.launchpad.net/~raof/mir/fix-mir_connection_get_display_info/+merge/179316 a review? | 08:41 |
| * alan_g looks... | 08:42 | |
| tvoss | didrocks, want me to top-approve? | 08:53 |
| didrocks | tvoss: please do | 08:53 |
| tvoss | didrocks, done | 08:53 |
| didrocks | thx | 08:57 |
| duflu | Alright, I need to run momentarily. Any last requests for the week? :) | 09:18 |
| alf__ | duflu: enjoy your weekend! | 09:19 |
| duflu | alf__: That request I can handle. Thanks, you too | 09:19 |
| tvoss_ | didrocks, when is the earliest that we can see libmirserver1 in the archive? | 09:55 |
| didrocks | tvoss_: is it merged? I'm on 100 subjects again | 09:55 |
| tvoss_ | didrocks, nope, can you retrigger CI? seems like we have a flaky test | 09:56 |
| didrocks | tvoss_: a link will help me with less context switch :) | 09:57 |
| seb128 | tvoss_, you can usually re-approve if that's a mr | 09:57 |
| seb128 | CI is going to be retried | 09:57 |
| tvoss_ | seb128, didrocks re-approved https://code.launchpad.net/~raof/mir/fix-mir_connection_get_display_info/+merge/179316 | 10:02 |
| seb128 | tvoss_, great | 10:04 |
| === jibel_ is now known as jibel | ||
| smspillaz | yay, garbage on the screen! | 10:25 |
| smspillaz | next step: make it display not garbage | 10:25 |
| smartboyhw | MIr developers: The thing I most want you to fix is typing:P | 10:27 |
| === greyback is now known as greyback|lunch | ||
| === greyback|lunch is now known as greyback | ||
| tvoss | didrocks, http://bazaar.launchpad.net/~mir-team/mir/trunk/revision/950 | 11:40 |
| tvoss | didrocks, that is: packaging fix has landed | 11:40 |
| === alan_g is now known as alan_g|lunch | ||
| NikTh | OK! Good news arriving ~ It seems like the major problem has been resolved, after the latest updates. A noticeable delay in typing, but this seems so small in front of a completely unusable desktop !! | 11:56 |
| NikTh | https://bugs.launchpad.net/mir/+bug/1196355 (new logs added ~ you should examine them and change the state of the bug accordingly, because I'm not very sure) | 11:57 |
| ubot5 | Launchpad bug 1196355 in XMir "After the latest updates, no desktop session - Ubuntu 13.10 (2013/07/01) - XMir dies with signal 6" [High,Incomplete] | 11:57 |
| NikTh | Keep Up the good work devs.. I trust you :-) Cheers ! | 11:58 |
| tvoss | NikTh, thanks :) a fix for the delay is on its way | 12:08 |
| davmor2 | hey guys I'm doing a saucy update this morning and got the following error paste.ubuntu.com/5966202 suado apt-get install -f doesn't correct it, is it just a case of remove libmirserver0 and install libmirserver1 ? or is this a fix needed? | 12:14 |
| davmor2 | s/suado/sudo | 12:14 |
| === alan_g|lunch is now known as alan_g | ||
| alan_g | davmor2: have you tried "dist-upgrade"? | 12:25 |
| davmor2 | alan_g: yeap no joy I might give it half an hour and retry incase there is a package still uploading | 12:26 |
| ogra_ | looks like a missing conflicts/replaces in a transition | 12:27 |
| didrocks | davmor2: you are using any ppa? | 12:28 |
| alan_g | davmor2: are you using the current ppa? http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html | 12:28 |
| didrocks | ogra_: yeah, typical things we protected by manual publication | 12:28 |
| davmor2 | didrocks: I am I have the mir and unity8 ppas | 12:29 |
| didrocks | davmor2: that's why | 12:29 |
| davmor2 | didrocks: ah sorry no I think it is just mir let me double check that | 12:29 |
| didrocks | it is Mir | 12:30 |
| didrocks | distro is safe | 12:30 |
| didrocks | not the mir ppa :) | 12:30 |
| davmor2 | didrocks: yeap so it's just mir ppa + pinning for it ala the instructions on the mir wiki page | 12:31 |
| olli_ | didrocks, ping | 12:38 |
| olli_ | kgunn, ping | 12:39 |
| didrocks | olli_: pong | 12:39 |
| olli_ | kgunn, ping | 13:08 |
| kgunn | olli_: pong | 13:17 |
| kgunn | didrocks: so what's the configuration under retest ? update on main + u-s-c- from daily-build ppa ? (as usual) | 13:31 |
| didrocks | kgunn: right | 13:31 |
| didrocks | (with a packaging transition) | 13:31 |
| kgunn | mlankhorst: ^ if you could on your local ati...could you run ? | 13:31 |
| didrocks | libmirserver0 -> libmirserver1 | 13:31 |
| didrocks | kgunn: tests pass on intel/ati/nvidia | 13:31 |
| kgunn | mlankhorst: just looking for more data points | 13:31 |
| didrocks | (just one unity test failing on ati can be because Mir is slower or a flacky one) | 13:32 |
| kgunn | bregma: ^ could you also run ? | 13:32 |
| didrocks | not enough to stop everything :) | 13:32 |
| kgunn | didrocks: yeah...its the perils of getting a moving train into archive :) | 13:33 |
| kgunn | wrt mir server bump | 13:33 |
| mlankhorst | kgunn: my ati is failing because of a nasty kernel corruption, so nothing in userspace would fix it | 13:34 |
| didrocks | yeah, we just delayed a little bit to fix the packaging bits | 13:34 |
| kgunn | alan_g: alf__ kdub racarr .....if any of you have spare machines it would be good to hear if you are able to boot/run unity7 as usual.....config is saucy main + u-s-c from daily-build ppa (or build it local from trunk) | 13:35 |
| kgunn | https://launchpad.net/~ubuntu-unity/+archive/daily-build | 13:36 |
| robotfuel | mir failed to start on my benchmark tests last night, u-s-c was installed from the s-c-t ppa, do I need to update a config file in lightdm now for xmir to run? | 13:37 |
| kgunn | robotfuel: for s-c-t, i wouldn't think you needed to do anything....can you verify that the /etc/lightdm/lightdm.conf.d/10-unity-system-compositor has the type=unity commented in ? | 13:41 |
| kgunn | robotfuel: can you paste bin /var/log/lightdm/lightdm.log & u-s-c.log | 13:42 |
| robotfuel | kgunn: there is no u-s-c.log, I'll pastebin lightdm.log | 13:42 |
| kgunn | robotfuel: did you sudo apt-get install u-s-c.....sounds like it wasn't there | 13:43 |
| kgunn | ? | 13:43 |
| robotfuel | kgunn: dpkg -l shows it's installed | 13:43 |
| kgunn | also....check to see if xserver-xorg-xmir is installed | 13:44 |
| robotfuel | kgunn: that looks like the issue: iU xserver-xorg-xmir 2:1.14.2-0ubuntu9 | 13:47 |
| robotfuel | u in the second column is unpacked if I remember correctly, it will be i if it's installed | 13:48 |
| kgunn | robotfuel: ok...the other day bschafer & i had to install....not sure why...but not ur problem obviously | 13:49 |
| kgunn | robotfuel: lightdm log ? | 13:50 |
| kgunn | robotfuel: also....xorg.0...old | 13:50 |
| robotfuel | kgunn: lightdm http://pastebin.ubuntu.com/5966452/ | 13:51 |
| kgunn | robotfuel: and the xorg log in /var/log | 13:51 |
| robotfuel | http://pastebin.ubuntu.com/5966455/ | 13:53 |
| robotfuel | from /var/log http://pastebin.ubuntu.com/5966457/ | 13:54 |
| olli_ | didrocks, kgunn, I am back | 13:56 |
| olli_ | :) | 13:56 |
| olli_ | kgunn, there is a certain input lag | 13:57 |
| olli_ | notable | 13:57 |
| robotfuel | kgunn: it's a packaging problem unity-system-compositor : Depends: libmirserver1 (>= 0.0.8+13.10.20130808.2bzr948saucy0) but it is not going to be installed | 13:57 |
| didrocks | olli_: at least, you're back :) | 13:57 |
| kgunn | olli_: yeah...input lag is killing me!!! | 13:57 |
| kgunn | robotfuel: maybe main would be better than s-c-t ppa :P | 13:58 |
| robotfuel | kgunn: is u-s-c in main now? | 13:58 |
| olli_ | kgunn, is this a known issue? | 13:58 |
| olli_ | I thought that was fixed recently | 13:58 |
| kgunn | robotfuel: no....you still have to pull it from https://launchpad.net/~ubuntu-unity/+archive/daily-build | 13:58 |
| kgunn | olli_: nope....https://bugs.launchpad.net/mir/+bug/1199450 | 13:59 |
| ubot5 | Launchpad bug 1199450 in Mir "[xmir] Inputs slowing, last event of a stream of events greatly delayed" [Critical,In progress] | 13:59 |
| kgunn | olli_: duflu's switch branch is supposed to fix it according to tvoss.....which i approved yesterday...not sure if its in yet | 14:00 |
| olli_ | kgunn, ok | 14:00 |
| olli_ | my bad | 14:00 |
| olli_ | so, I have it back on xmir, no issues besides the lag | 14:00 |
| kgunn | olli_: it should be the #1 now that we're getting in | 14:02 |
| kgunn | #1 bug the lag that is | 14:02 |
| olli_ | didrocks, kgunn I won't be ready with the comms in time for the meeting in 30min | 14:05 |
| olli_ | didrocks, do you have some more time or are you headed towards weekend soonish? | 14:05 |
| didrocks | olli_: that's fine, we can delay a little bit :) | 14:11 |
| didrocks | (like 2h) | 14:11 |
| bregma | well, an upgrade on my Intel test machine went smoothly, I now have both libmirserver0 and libmirserver1 installed (can't tell which one is in use), Unity 7 runs as well as yesterday (input still suxxors) | 14:12 |
| kgunn | bregma: thanks....and no doubt....input enuf to drive you to drink | 14:18 |
| ogra_ | dont drink and drive :) | 14:19 |
| bregma | except I can't get the drink in because I move my hand one too many mouths to the left | 14:19 |
| === alan_g is now known as alan_g|afk | ||
| olli_ | didrocks, shall we meet 15past? | 14:50 |
| olli_ | i.e. 5:15pm for you? | 14:51 |
| didrocks | olli_: good to me :) | 14:51 |
| didrocks | bregma: there is a missing conflicts in addition to the replaces | 15:04 |
| didrocks | bregma: can wait but would be nice to fix :) | 15:04 |
| didrocks | bregma: unity7 just passed tests btw (16 failures on each) | 15:04 |
| bregma | 16 is about normal these days (at least 5 are known problems with fixes in the queue) | 15:06 |
| robotfuel | kgunn: I pinned u-s-c from https://launchpad.net/~ubuntu-unity/+archive/daily-build and I still have conflicts, what other package should I pin from daily-build all of the xmir stuff that use to be in the s-c-t ppa? | 15:07 |
| bregma | robotfuel, try not pinning anything | 15:08 |
| === alan_g|afk is now known as alan_g | ||
| robotfuel | bregma: is u-s-c in main now? | 15:10 |
| bregma | no, so you need the daily-build PPA in your sources, but everything else is in main... but if you pin the PPA you will know grief | 15:11 |
| kgunn | robotfuel: sorry....racing against a clock on something....i'll come back and "play" in a bit :) | 15:12 |
| didrocks | olli_: will be 5 minutes late | 15:15 |
| olli_ | me too | 15:15 |
| olli_ | didrocks, still writing the AC wiki | 15:15 |
| didrocks | olli_: ok, ready, just ping me :) | 15:21 |
| olli_ | didrocks, kgunn, need 10 more min | 15:22 |
| olli_ | sorry | 15:22 |
| didrocks | no worry | 15:22 |
| olli_ | didrocks, kgunn I am ready | 15:32 |
| didrocks | olli_: any link? | 15:34 |
| olli_ | let me start a hangout | 15:36 |
| kgunn | mlankhorst: any chance you could do a clean 13.10 xmir test (no kernel mods :).....just looking for another ati data point | 15:42 |
| kgunn | bregma was yours ati ? or intel ? | 15:42 |
| bregma | Intel | 15:42 |
| mlankhorst | kgunn: just pretend it works on ati, my other ati cards worked | 15:54 |
| kgunn | mlankhorst: :)) | 15:54 |
| kgunn | gee thanks....filled with confidence | 15:54 |
| mlankhorst | hey I know the one ati fails because of a kernel corruption, th other ones worked :P | 15:55 |
| mlankhorst | and regardless of whether mir triggers it, it's a kernel bug causing the corruption. | 15:56 |
| kgunn | mlankhorst: cool | 16:13 |
| === alan_g is now known as alan_g|EOW | ||
| Debolaz | Is there an Ubuntu iso where xmir is used by default? | 18:04 |
| ogra_ | Debolaz, no, but the xubuntu community made a xubuntu mir image somewhere | 18:18 |
| skellat | Debolas ogra_ : See: http://vanir.unit193.tk/mir/ | 18:28 |
| kdub | whats this? https://code.launchpad.net/~ps-jenkins/mir/latestsnapshot-0.0.8+13.10.20130809.4-0ubuntu1/+merge/179520 | 19:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!