RAOFkdub: Hey, is mir_connection_set_display_config_change_callback hooked up all the way through Mir?00:37
kdubwellll :) after ~kdub/mir/connect-display-request it will be00:38
kdubbut it's not quite done yet, because the clients do not get the updated configuration after the display change yet00:39
kdublike, 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 done00:40
RAOFkdub: Ah, ok.00:42
RAOFSo I shouldn't be concerned when XMir's handler doesn't actually get called on hotplug events ☺00:42
duflurobert_ancell: Are PPAs still required for saucy at all?01:53
dufluGiven... https://launchpad.net/ubuntu/+source/mir01:53
robert_ancellduflu, the staging PPA is handy as it contains a per commit build01:53
duflurobert_ancell: So handy but not required?01:53
robert_ancellthe archive only contains per day builds, and only then if they pass integration tests01:53
robert_ancellno reason to get rid of them01:53
dufluWow. 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
racarrduflu: 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. repeat02:54
dufluracarr: Too many connected devices... You have a choice :)02:54
duflu... unless they're all Ubuntu in which case you *should* have more02:56
racarrand they should all sync up over networked dbus or ubuntu one or whatever02:57
racarrso they realize not to notify me multiple times for the same event02:57
racarranyyy day now02:57
dufluAnd have eye tracking to know which device you already saw it on02:58
racarrduflu: They should transfer us to design02:58
dufluI'm pretty sure we already have designers with big ideas.02:59
dufluAlso, I don't do scarves02:59
racarrengineering it is then02:59
smartboyhwMir guys: HELP http://paste.ubuntu.com/5964829/03:23
smartboyhwI know what sort of problem is it, but since I'm not in the Mir team I can't fix:P03:24
smartboyhwmlankhorst, ^03:24
RAOFUm, when did we bump mirserver ABI?03:26
RAOFThat's a filthy lie.03:26
RAOFsmartboyhw: I'll fix it. You know how to work around that, right?03:32
dufluRAOF: Because the switch branch landed. And accidentally using the old libmirserver would cause strange and hideous bugs03:33
RAOFduflu: Ok. But libmirserver0 wasn't parallel-installable-ready.03:34
dufluRAOF: Oh, that sucks. But I would still prefer error messages to strange bugs (and inexplicable test failures)03:35
RAOFWell, if you're using the packages we had that covered already :)03:35
dufluRAOF: I was using the packages. That's the problem... the ABI actually changed and it would pick up the old libs by mistake03:36
duflu... when building Mir locally03:36
RAOFRight; only an issue then. :)03:36
smartboyhwRAOF, I know the fix, I don't know the workaround:P03:49
RAOFsmartboyhw: Oh; dpkg --install --force-overwrite /var/cache/apt/archives/libmirserver1*.deb03:50
smartboyhwRAOF, thanks03:51
RAOFduflu: https://code.launchpad.net/~raof/mir/fix-mir_connection_get_display_info/+merge/179316 should fix that.04:02
dufluRAOF, ta04:18
RAOFHuh. No Robert.04:33
smspillazhow long is05:03
smspillazguarunteed to live for05:03
duflusmspillaz: Depends on the class that gave it to you. Generally for as long as the object which gave it to you05:04
dufluWhich is annoying. It means to avoid leaks, some repeated operations always need to reuse the same handle.05:06
smspillazokay, 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
smspillazso I can atomically set it to NULL in the callback and know from the main thread that we already got our next buffer05:08
duflusmspillaz, yeah it should recycle the same handle from inside the client surface object and always just wait for the next one05:10
duflusmspillaz: Of course, you're not meant to *know* each call returns the same handle05:11
smspillazduflu: it doesn't really matter in my case05:11
dufluSadly 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 happen05:12
smspillazI 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 thread05:12
smspillazduflu: does mir_wait_for return after the callback in the other thread completes or before it completes?05:16
RAOFYeah, it's sensible :)05:18
smspillazyeah 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 availaable05:19
* duflu hope that's true for all operations05:19
alf__RAOF: @preferred mode, it turned out I was checking the wrong struct field, there is indeed only one preferred mode as expected05:22
RAOFOk. Let's see if this approach to one-window-per-output works...05:36
didrocksRAOF: hey!05:38
didrocksRAOF: 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
didrocksRAOF: seems to be the -ati or hybris issue, I have the package versions diff, but still a little bit puzzled TBH :)05:39
tvossgood morning :)05:46
didrockshey tvoss! how are you?05:50
RAOFdidrocks: Yes.05:53
RAOFdidrocks: Although given how odd the problem was, hybris seems a perfectly fitting cause :)05:53
didrocksRAOF: yeah, but why intel is more resistant to that?05:53
RAOFNo idea.05:54
tvossdidrocks, pretty good :) how are you?05:55
didrockstvoss: I'm thrilled to see the Mir issue on ati fixed for now :)05:56
tvossdidrocks, \o/ what fixed the issue?05:56
RAOFalf__: 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 coordinates05:58
didrockstvoss: 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" issue05:58
didrockstvoss: the second sounds more plausible, but it would mean that intel can cope with that, not the ati card05:58
RAOFalf__: 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
tvossalf__, absolute positioning is something we definitely want to avoid.06:01
RAOFWell, except we don't really want to do that.06:01
tvossalf__, I would propose a surface_{move,associate}_to_output06:01
RAOFI'd probably put it in the creation struct, but something like that, yes.06:02
RAOFdidrocks: Oh, you might want to look at https://code.launchpad.net/~raof/mir/fix-mir_connection_get_display_info/+merge/17931606:03
alf__tvoss: what are the semantics of surface_move_to_output?06:07
tvossalf__, move is the wrong verb, associate is a better term06:08
RAOFAnother option is surface_fullscreen_for_output06:09
alf__tvoss: in a multimonitor scenarios, where surfaces can span outputs, even association is a bit fuzzy.06:09
RAOFWhich I think might make more sense again.06:09
alf__RAOF: yes, I think that's better06:09
alf__RAOF: tvoss: although, since we don't have resize support yet, it probably needs to be a creation option?06:10
RAOFalf__: Oh, I'd prefer it as a creation option anyway :)06:10
RAOFWhich would have quite substantial semantics - can't be moved, will only be resized if the underlying output changes mode, is fullscreen.06:11
tvossRAOF, alf__ +1 on creation option06: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
RAOFFor 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
RAOFalf__: Well, I'd just create a surface and associate it to one of the clones.06:18
alf__RAOF: right06:20
alf__RAOF: tvoss: Do we want surface_fullscreen_for_output to be an unprivileged operation?06:21
RAOFI think so, yes.06:21
RAOFIt's something reasonable clients will want to do.06:21
RAOF(Hello, presentation apps!)06:21
tvossalf__, 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 object06:21
tvossRAOF, or games06:22
alf__tvoss: on the client side?06:23
tvossalf__, yup06:23
RAOFtvoss: Isn't a "session" roughly the same as "a client connection"?06:23
alf__tvoss: what will that FullscreenSession object do?06:24
RAOFIf 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
tvossRAOF, yes and no: in the general case, session is connection, yes. But in the special case of fullscreen, it is not equivalent06:25
tvossRAOF, obviously, an app can have more than one surface on one connection06:25
RAOFI'm unclear as to what a FullscreenSession does, then.06:25
tvossalf__, 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
tvossalf__, RAOF the attributes would be passed when entering the fullscreen session, and some of them might be mutable during the fullscreen session06:28
tvossalf__, RAOF so bundling them makes a lot of sense06:29
tvossobviously from myp ov :)06:29
RAOFThey sound like attributes on the surface; I'm still not sure what the session abstraction is for?06:31
tvossRAOF, it accounts for: "fullscreen is a state with attributes, and the set of attributes can change per fullscreen session"06:34
RAOFBut we can already set attributes on surfaces?06:39
RAOFduflu: 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
dufluRAOF: I would have to refresh my memory and read the docs to answer that06:43
RAOFduflu: My recent reading of the code suggests "no", which makes it rather unuseful?06:44
tvossduflu, congrats on the switch branch being landed :)06:46
dufluRAOF: 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 MirWaitHandles06:46
duflutvoss: Thanks, I think.06:47
RAOFI guess we do mostly allocate new MirWaitHandles for things that we might want to wait on.06:47
dufluRAOF: I think this is another good case for MirWaitHandle being thread-aware. That would also eliminate the need for two wait functions.06:48
dufluRAOF: Wait, no...06:48
dufluRAOF: Because the "result" gets signalled in a different thread. You can't ever know which client thread is destined to handle it06:49
dholbachgood morning06:49
RAOFduflu: 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
RAOFOr, to rephrase: we MUST be able to guarantee that...06:54
RAOFNot that this affects me at the moment, as X is single-threaded.06:54
dufluRAOF: It is guaranteed so long as only one thread ever sees that MirWaitHandle. Unfortunately our "reuse" of handles makes that tricky06:55
RAOFRight; the extent to which this is not guaranteed is a bug.06:55
dufluRAOF: It's a design bug. We would have to change the API to ever resolve it.06:59
dufluthe client API...06:59
* RAOF obviously thinks we should make that break07:06
RAOFAs it is we can't *actually* be used in multithreaded programs07:07
smspillazduflu: RAOF: can't this just be solved from the client side though?07:09
smspillazjust atomically set the handle to NULL once the operation has completed07:09
RAOFsmspillaz: How do you know that the operation has completed?07:10
smspillazRAOF: mir_wait_for07:10
smspillazRAOF: so the pattern I'm doing at the moment is07:10
RAOFTells you that *all* the operations have completed, and isn't safe in the presence of multiple threads.07:11
smspillazif (atomic_pointer_get (&wait_handle))07:11
dufluRAOF: 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 handle07:11
smspillaz  mir_wait_for(wait_handle)07:11
smspillazRAOF: erm ... mir_wait_for_one then ?07:11
RAOFsmspillaz: And that doesn't guarantee that the operation you meant to wait for has occurred.07:11
RAOFThat guarantees that *some* operation has occurred on the wait handle.07:11
RAOFBut if that handle is shared, then…07:12
smspillazRAOF: wait_handle is set to NULL once the operation completes07:12
RAOFsmspillaz: libmirclient will give you the same wait handle for some calls07:12
RAOFeg: there's only one wait handle for mir_connection_drm_auth_magic, for example.07:13
smspillazRAOF: I know. The idea is that the client, inside the callback, sets the wait_handle to NULL atomically07:13
duflusmspillaz: Your idea I guess07:13
smspillazRAOF: the pointers to the wait handles themselves become unique identifiers of completeness07:14
RAOFHm. Yeah, I think that works.07:14
smspillazso you can have struct MyOperationData { MirWaitHandle *handle; }07:14
dufluSo long as you keep in mind, the uniqueness is only unique to the tuple [connection, surface, operation]07:14
smspillazthen opdata->handle = mir_do_whatever (callback, &opdata);07:15
RAOFduflu: No, in this case it's unique to just operation.07:15
smspillazand then in the callback07:15
smspillaz... atomic_set (&opdata->handle, NULL);07:15
smspillazYay client side everything!07:15
smspillazoh wait I forgot this isn't #wayland07:15
dufluRAOF: I meant otherwise, but it depends how you define operation :)07:15
RAOFsmspillaz: Oh, but then you actually need to loop on mir_wait_for_one.07:16
smspillazRAOF: loop ?07:16
dufluYeah, loop if you expect a particular number. Otherwise mir_wait_for() to gobble all results in one go07:16
RAOFsmspillaz: You can't use mir_wait_for because only one thread will ever escape from that.07:16
RAOFsmspillaz: And mir_wait_for_one doesn't guarantee that your operation has completed.07:17
smspillazoh I see07:17
RAOFsmspillaz: So you need to while (atomic_pointer_get(&wait_handle)) mir_wait_for_one(wait_handle);07:17
smspillazwhile (atomic_pointer_get (&opdata->handle) { mir_wait_for_one(wait_handle); }07:18
dufluRAOF: It does guarantee your operation has completed if you ensure [connection, surface, operation] are only used together in one known place, one thread07:18
smspillazbeat me to it07:18
RAOFduflu: 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
dufluRAOF: You will get a unique wait handle for each unique pairing of [surface, operation]07:20
dufluThere is no confusion unless you do similar operations on a single surface from multiple threads07:20
RAOFRight. As long as [operation] *operates* on a surface.07:20
RAOFFor operations which do *not* operate on surfaces you're restricted to one thread.07:20
dufluRAOF: I think so yes. That limitation originates from racarr's original client API design07:22
dufluSee also https://bugs.launchpad.net/mir/+bug/119438407:22
ubot5Launchpad bug 1194384 in Mir "Mir client callbacks are not thread-safe" [Medium,Triaged]07:22
RAOFI suspect we might be in violent agreement.07:24
dufluYes, mediums such as this one often result that way07:27
tsdgeosGuys, can't install some mir stuff08:29
tsdgeosany idea what's wrong?08:29
duflutsdgeos: The mirserver ABI bumped last night. I think a fix is landing soon08:31
tsdgeosok :-/ :-)08:31
tvossdidrocks, ping08:37
didrockstvoss: pong08:37
tvossdidrocks, hey :) I see libmirserver1 in the daily-build ppa, but not yet in the archive08:38
tvossdidrocks, any idea when we will switch that over?08:38
didrockstvoss: right08:38
didrockstvoss: packaging issue08:38
didrockssee latest MP08:38
tvossdidrocks, ack08:38
didrockstvoss: will be rerun today08:38
tvossdidrocks, is that the fix-mir_connection_get_display_info?08:39
didrockstvoss: https://code.launchpad.net/~raof/mir/fix-mir_connection_get_display_info/+merge/17931608:40
didrockstvoss: we need that one merged08:40
tvossdidrocks, ack08:40
didrocksseems it's not approved anymore though08:40
tvossalan_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
tvossdidrocks, want me to top-approve?08:53
didrockstvoss: please do08:53
tvossdidrocks, done08:53
dufluAlright, I need to run momentarily. Any last requests for the week? :)09:18
alf__duflu: enjoy your weekend!09:19
duflualf__: That request I can handle. Thanks, you too09:19
tvoss_didrocks, when is the earliest that we can see libmirserver1 in the archive?09:55
didrockstvoss_: is it merged? I'm on 100 subjects again09:55
tvoss_didrocks, nope, can you retrigger CI? seems like we have a flaky test09:56
didrockstvoss_: a link will help me with less context switch :)09:57
seb128tvoss_, you can usually re-approve if that's a mr09:57
seb128CI is going to be retried09:57
tvoss_seb128, didrocks re-approved https://code.launchpad.net/~raof/mir/fix-mir_connection_get_display_info/+merge/17931610:02
seb128tvoss_, great10:04
=== jibel_ is now known as jibel
smspillazyay, garbage on the screen!10:25
smspillaznext step: make it display not garbage10:25
smartboyhwMIr developers: The thing I most want you to fix is typing:P10:27
=== greyback is now known as greyback|lunch
=== greyback|lunch is now known as greyback
tvossdidrocks, http://bazaar.launchpad.net/~mir-team/mir/trunk/revision/95011:40
tvossdidrocks, that is: packaging fix has landed11:40
=== alan_g is now known as alan_g|lunch
NikThOK! 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
NikThhttps://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
ubot5Launchpad 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
NikThKeep Up the good work devs.. I trust you :-) Cheers !11:58
tvossNikTh, thanks :) a fix for the delay is on its way12:08
davmor2hey 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
=== alan_g|lunch is now known as alan_g
alan_gdavmor2: have you tried "dist-upgrade"?12:25
davmor2alan_g: yeap no joy  I might give it half an hour and retry incase there is a package still uploading12:26
ogra_looks like a missing conflicts/replaces in a transition12:27
didrocksdavmor2: you are using any ppa?12:28
alan_gdavmor2: are you using the current ppa? http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html12:28
didrocksogra_: yeah, typical things we protected by manual publication12:28
davmor2didrocks: I am I have the mir and unity8 ppas12:29
didrocksdavmor2: that's why12:29
davmor2didrocks: ah sorry no I think it is just mir let me double check that12:29
didrocksit is Mir12:30
didrocksdistro is safe12:30
didrocksnot the mir ppa :)12:30
davmor2didrocks: yeap so it's just mir ppa + pinning for it ala the instructions on the mir wiki page12:31
olli_didrocks, ping12:38
olli_kgunn, ping12:39
didrocksolli_: pong12:39
olli_kgunn, ping13:08
kgunnolli_: pong13:17
kgunndidrocks: so what's the configuration under retest ? update on main + u-s-c- from daily-build ppa ? (as usual)13:31
didrockskgunn: right13:31
didrocks(with a packaging transition)13:31
kgunnmlankhorst: ^ if you could on your local ati...could you run ?13:31
didrockslibmirserver0 -> libmirserver113:31
didrockskgunn: tests pass on intel/ati/nvidia13:31
kgunnmlankhorst: just looking for more data points13:31
didrocks(just one unity test failing on ati can be because Mir is slower or a flacky one)13:32
kgunnbregma: ^ could you also run ?13:32
didrocksnot enough to stop everything :)13:32
kgunndidrocks: yeah...its the perils of getting a moving train into archive :)13:33
kgunnwrt mir server bump13:33
mlankhorstkgunn: my ati is failing because of a nasty kernel corruption, so nothing in userspace would fix it13:34
didrocksyeah, we just delayed a little bit to fix the packaging bits13:34
kgunnalan_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
robotfuelmir 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
kgunnrobotfuel: 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
kgunnrobotfuel: can you paste bin /var/log/lightdm/lightdm.log & u-s-c.log13:42
robotfuelkgunn: there is no u-s-c.log, I'll pastebin lightdm.log13:42
kgunnrobotfuel: did you sudo apt-get install u-s-c.....sounds like it wasn't there13:43
robotfuelkgunn: dpkg -l shows it's installed13:43
kgunnalso....check to see if xserver-xorg-xmir is installed13:44
robotfuelkgunn: that looks like the issue: iU  xserver-xorg-xmir 2:1.14.2-0ubuntu913:47
robotfuelu in the second column is unpacked if I remember correctly, it will be i if it's installed13:48
kgunnrobotfuel: ok...the other day bschafer & i had to install....not sure why...but not ur problem obviously13:49
kgunnrobotfuel: lightdm log ?13:50
kgunnrobotfuel: also....xorg.0...old13:50
robotfuelkgunn:  lightdm http://pastebin.ubuntu.com/5966452/13:51
kgunnrobotfuel: and the xorg log in /var/log13:51
robotfuelfrom /var/log http://pastebin.ubuntu.com/5966457/13:54
olli_didrocks, kgunn, I am back13:56
olli_kgunn, there is a certain input lag13:57
robotfuelkgunn: it's a packaging problem unity-system-compositor : Depends: libmirserver1 (>= 0.0.8+13.10.20130808.2bzr948saucy0) but it is not going to be installed13:57
didrocksolli_: at least, you're back :)13:57
kgunnolli_: yeah...input lag is killing me!!!13:57
kgunnrobotfuel: maybe main would be better than s-c-t ppa :P13:58
robotfuelkgunn: is u-s-c in main now?13:58
olli_kgunn, is this a known issue?13:58
olli_I thought that was fixed recently13:58
kgunnrobotfuel: no....you still have to pull it from https://launchpad.net/~ubuntu-unity/+archive/daily-build13:58
kgunnolli_: nope....https://bugs.launchpad.net/mir/+bug/119945013:59
ubot5Launchpad bug 1199450 in Mir "[xmir] Inputs slowing, last event of a stream of events greatly delayed" [Critical,In progress]13:59
kgunnolli_: duflu's switch branch is supposed to fix it according to tvoss.....which i approved yesterday...not sure if its in yet14:00
olli_kgunn, ok14:00
olli_my bad14:00
olli_so, I have it back on xmir, no issues besides the lag14:00
kgunnolli_: it should be the #1 now that we're getting in14:02
kgunn#1 bug the lag that is14:02
olli_didrocks, kgunn I won't be ready with the comms in time for the meeting in 30min14:05
olli_didrocks, do you have some more time or are you headed towards weekend soonish?14:05
didrocksolli_: that's fine, we can delay a little bit :)14:11
didrocks(like 2h)14:11
bregmawell, 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
kgunnbregma: thanks....and no doubt....input enuf to drive you to  drink14:18
ogra_dont drink and drive :)14:19
bregmaexcept I can't get the drink in because I move my hand one too many mouths to the left14: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
didrocksolli_: good to me :)14:51
didrocksbregma: there is a missing conflicts in addition to the replaces15:04
didrocksbregma: can wait but would be nice to fix :)15:04
didrocksbregma: unity7 just passed tests btw (16 failures on each)15:04
bregma16 is about normal these days (at least 5 are known problems with fixes in the queue)15:06
robotfuelkgunn: 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
bregmarobotfuel, try not pinning anything15:08
=== alan_g|afk is now known as alan_g
robotfuelbregma: is u-s-c in main now?15:10
bregmano, 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 grief15:11
kgunnrobotfuel: sorry....racing against a clock on something....i'll come back and "play" in a bit :)15:12
didrocksolli_: will be 5 minutes late15:15
olli_me too15:15
olli_didrocks, still writing the AC wiki15:15
didrocksolli_: ok, ready, just ping me :)15:21
olli_didrocks, kgunn, need 10 more min15:22
didrocksno worry15:22
olli_didrocks, kgunn I am ready15:32
didrocksolli_: any link?15:34
olli_let me start a hangout15:36
kgunnmlankhorst: any chance you could do a clean 13.10 xmir test (no kernel mods :).....just looking for another ati data point15:42
kgunnbregma was yours ati ? or intel ?15:42
mlankhorstkgunn: just pretend it works on ati, my other ati cards worked15:54
kgunnmlankhorst: :))15:54
kgunngee thanks....filled with confidence15:54
mlankhorsthey I know the one ati fails because of a kernel corruption, th  other ones worked :P15:55
mlankhorstand regardless of whether mir triggers it, it's a kernel bug causing the corruption.15:56
kgunnmlankhorst: cool16:13
=== alan_g is now known as alan_g|EOW
DebolazIs there an Ubuntu iso where xmir is used by default?18:04
ogra_Debolaz, no, but the xubuntu community made a xubuntu mir image somewhere18:18
skellatDebolas ogra_ : See: http://vanir.unit193.tk/mir/18:28
kdubwhats this? https://code.launchpad.net/~ps-jenkins/mir/latestsnapshot-0.0.8+13.10.20130809.4-0ubuntu1/+merge/17952019:37

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!