| bschaefer | RAOF, hey, so a few questions on the review for attestable cookie (also my test is failing now). Cant read the keyboard udev file any more or rather no events | 00:10 |
|---|---|---|
| bschaefer | RAOF, also, when it comes to a platform such as libinput/x11 how does that tie into mir server it self? | 00:10 |
| bschaefer | does it replace the android backend? | 00:10 |
| RAOF | Yes, ish. | 00:11 |
| RAOF | But not the bits you touched. | 00:11 |
| bschaefer | RAOF, so either way we still use the low level android stuff that talks to the kernel? | 00:12 |
| RAOF | No, we replace the low level stuff. | 00:12 |
| RAOF | But not the IPC stuff. | 00:12 |
| bschaefer | RAOF, trying to read anpok branch on libinput and how to add a configuration, but his branch only has platform changes | 00:12 |
| bschaefer | RAOF, hmm IPC? | 00:13 |
| bschaefer | inter process com? | 00:13 |
| bschaefer | add an API so U-S-C can set things needed for a barrier (similar to how unity7 works with xinput2) | 00:14 |
| bschaefer | RAOF, also i dont think main is fixed yet for protobuf :( | 00:14 |
| RAOF | So, we absolutely should not add an API to U-S-C providing barrier-like behaviour. | 00:15 |
| bschaefer | RAOF, i think its to add an API to umm set settings like | 00:15 |
| bschaefer | speed of cursor | 00:15 |
| bschaefer | or some things that is needed to be set in libinput | 00:15 |
| RAOF | Yeah, I think that's also incorrect to use USC for. | 00:15 |
| bschaefer | hmm | 00:15 |
| RAOF | We *should* have Unity8 in charge of drawing the pointer. | 00:15 |
| bschaefer | :( | 00:15 |
| RAOF | (Whether or not we need to, as a short-term hack, introduce such an API is left as an exercise for the reader) | 00:16 |
| bschaefer | RAOF, right hmm, was just under the impression that letting U-S-C render the cursor since greyback didnt want unity8 to draw the cursor | 00:16 |
| RAOF | greyback is wrong. At least long-term. | 00:17 |
| * bschaefer cant see long term very well atm | 00:17 | |
| bschaefer | mainly because im missing a lot of context | 00:17 |
| bschaefer | RAOF, so in the short team, this shouldnt be to hard ... my main issue is not even knowing how an API should be set up like this since the only thing | 00:18 |
| bschaefer | the branch touches is things in src/platforms, meaning i would have to write a C API to touch the platform bits? | 00:18 |
| bschaefer | ie. set the cursor device configurations? | 00:18 |
| bschaefer | unless U-S-C gets access to a separate C++ API im not aware of | 00:19 |
| bschaefer | but either way, im not super familiar with exposing things from the platform --> client | 00:19 |
| bschaefer | RAOF, is it platform --> server --> client? | 00:20 |
| bschaefer | and back down? platform <--- server <--- client? | 00:20 |
| RAOF | Yeah, platform → server → client. | 00:20 |
| bschaefer | alright, so mainly i just need to figure out how to send simple data down the RPC | 00:21 |
| bschaefer | RCP? | 00:21 |
| * bschaefer can never remeber the right letter order | 00:21 | |
| bschaefer | rpc | 00:21 |
| bschaefer | RAOF, that'll at lease be a good start, the only thing im worried about is short term tends to be long term :( | 00:21 |
| bschaefer | RAOF, whats the ideal solution for this? | 00:22 |
| RAOF | There are a number of plausible options. | 00:24 |
| RAOF | One would be to pass the evdev fds down to the nested compositor and manage switching via EVIOCREVOKE. | 00:25 |
| bschaefer | that way they can change the device settings them selfs? | 00:26 |
| RAOF | Right; then the nested compositor has a full input platform and can go to town. | 00:26 |
| bschaefer | that would be a small impact in mir...and would require some work in U-S-C | 00:27 |
| bschaefer | but i cant imagine it being crazy | 00:27 |
| bschaefer | RAOF, well small impact in the sense that i have no clue what it would require besides 1 function :) | 00:27 |
| RAOF | It'd be mostly easy. It'd be easier if we didn't have to pretend that USC was a normal Mir server and U8 was a normal Mir client :) | 00:28 |
| bschaefer | haha ... i suppose that complicates things... | 00:29 |
| RAOF | Eh, it just makes things a little messy. | 00:29 |
| bschaefer | RAOF, i was mainly just going off what was talking about and the card | 00:29 |
| bschaefer | err what was talked* | 00:29 |
| RAOF | Yeah. | 00:30 |
| * bschaefer would rather do it the right way vs a hack that will be shoved into mir | 00:30 | |
| bschaefer | then it'll happen again and again and you're left with x11v2 :) | 00:30 |
| RAOF | :) | 00:31 |
| bschaefer | RAOF, ill try to talk about it tomorrow at the stand up to see any other ideas | 00:31 |
| RAOF | We could also potentially expose various bits of currently-internal libinput handling. | 00:33 |
| bschaefer | RAOF, such as the device it self? So settings can be manually changed in U-S-C? | 00:33 |
| * bschaefer has been reading through the libinput code | 00:34 | |
| bschaefer | and it just seems to turn everything from a device into a mir event | 00:34 |
| bschaefer | now ... i dont even know what *settings/configuration* needs to changed/set yet :) | 00:34 |
| RAOF | So the nested compositor (ie: unity8) can twiddle the behavioural tweaks itself. | 00:34 |
| bschaefer | but from what i understand its mainly the cursor/pointer | 00:34 |
| bschaefer | right, that might be better then adding a full blown API like mir_platform_set_cursor_speed(int speed); | 00:35 |
| bschaefer | RAOF, that would make U-S-C explicit on the platform though right? | 00:35 |
| RAOF | That's not a full-blown API :) | 00:35 |
| * bschaefer haha... well thats kind of what i imagined i would attempt to add in the api (from what that card says) | 00:36 | |
| bschaefer | then figure out how to change libinput | 00:36 |
| RAOF | A full-blown API is something like mir_input_get_device_properties() mir_input_set_device_properties() :) | 00:36 |
| bschaefer | to what they want | 00:36 |
| bschaefer | o | 00:36 |
| bschaefer | hmm | 00:36 |
| bschaefer | RAOF, well... what if for now i just went through and figured out every function that would be needed | 00:36 |
| RAOF | From which you receive arbitrary blobs of data, and to which you push arbitrary blobs of data :) | 00:36 |
| bschaefer | then just add function support for that? | 00:36 |
| bschaefer | would make it easier to remove i suppose | 00:36 |
| * RAOF is not serious about that; that's pretty much the worst possible API. | 00:36 | |
| bschaefer | haha | 00:37 |
| RAOF | I'll make some coffee while thinking. | 00:37 |
| bschaefer | alright i've asked far to many questions this early for you haha | 00:37 |
| bschaefer | RAOF, o also this if for the pocket PC so i can imagine it having some priority | 00:45 |
| RAOF | It's not all *that* early :) | 00:45 |
| bschaefer | all the settings: https://wiki.ubuntu.com/MouseAndTouchpad#prompting | 00:45 |
| * bschaefer has no clue if those are even *real* settings | 00:46 | |
| bschaefer | in libinput | 00:46 |
| bschaefer | mainly i see this: http://paste.ubuntu.com/12076130/ | 00:46 |
| bschaefer | looking at http://wayland.freedesktop.org/libinput/doc/0.21.0/libinput_8h_source.html | 00:47 |
| RAOF | http://wayland.freedesktop.org/libinput/doc/latest/group__config.html | 00:47 |
| RAOF | Is the relevant bit for HEAD. | 00:47 |
| bschaefer | RAOF, oo sweet thanks | 00:47 |
| bschaefer | right i see we are more after device configuration | 00:48 |
| RAOF | So, our relevant design constraints are: | 00:55 |
| RAOF | a) We ideally don't want to have to expose every input device property (for every input device type) in an API. | 00:57 |
| RAOF | b) We ideally preserve the opportunity for the system-compositor to act on input without worrying about a nested compositor also handling that input. | 00:57 |
| bschaefer | RAOF, input porperty mouse/keyboard? | 00:58 |
| RAOF | Mouse, keyboard, joystick, $RANDOM_NON_EVDEV_THING_THAT_WE_MIGHT_NEED_TO_SUPPORT. | 00:58 |
| bschaefer | o i see yeah | 00:58 |
| RAOF | c) The users' shell needs access to various device input properties. | 00:59 |
| bschaefer | o right ... yeah they'll need to get_* them as well so they can display the value | 00:59 |
| RAOF | Correct. | 00:59 |
| bschaefer | that doubles what i thought needed to be done :) | 01:00 |
| bschaefer | RAOF, now B)... | 01:00 |
| bschaefer | we need to let U-S-C connect with these devices to listen to events out side of mir? | 01:00 |
| bschaefer | or provide a way for U-S-C to get events | 01:00 |
| bschaefer | but not eat them | 01:00 |
| RAOF | u-s-c already has a way to do that (as does U8) | 01:02 |
| bschaefer | RAOF, o i see, hmm and wouldnt we ideally want to make sure all the libinput stuff is hidden? | 01:02 |
| bschaefer | ie. have an API with generic get/set for these types of properties* | 01:02 |
| bschaefer | RAOF, thats if done how the card is proposed atm | 01:02 |
| RAOF | Right; that runs into desire (a) :) | 01:03 |
| bschaefer | right hmm | 01:03 |
| bschaefer | RAOF, hmm soo it just sounds like the only way to do this well is to expose libinput stuff | 01:05 |
| bschaefer | and have U-S-C handle whats missing | 01:05 |
| RAOF | So, I think probably the *nicest* solution is to have u-s-c hand off input fds to the U8. | 01:05 |
| RAOF | So the nested compositor has a full input platform, and U8 can poke it directly without needing a client API. | 01:06 |
| bschaefer | then that would make u8 have to poke the API here right? http://wayland.freedesktop.org/libinput/doc/latest/group__config.html | 01:07 |
| bschaefer | based on the FD | 01:07 |
| RAOF | Correct. | 01:07 |
| bschaefer | RAOF, you did mention that would be ideal if U-S-C and U8 were setup correctly (in the fact that U8 is a mir client etc) | 01:08 |
| RAOF | But that would be an internal, mirserver API, and that's far more malleable than a client API (which then needs RPC support and such). | 01:08 |
| bschaefer | RAOF, what problems would that cause us in how things are set up now? | 01:08 |
| RAOF | This also has the added benefit of reducing input latency somewhat, as U8 doesn't need to wait for usc to wake up, process the input event, write it to U8's socket, and then U8 wakes up. | 01:08 |
| bschaefer | RPC support sounds annoying, but there was a mention of dbus to libinput? | 01:08 |
| RAOF | That's the sideband option, yes :) | 01:08 |
| bschaefer | so we could just skip from a client api --dbus> platform (libinput) | 01:09 |
| RAOF | That option is: U-S-C exposes a DBus API for prodding these things. | 01:09 |
| bschaefer | but that still means we would need an API in mir which would need a list of device properties | 01:09 |
| RAOF | That basically just replaces the mirclient RPC component with a DBus RPC component. | 01:09 |
| bschaefer | and libinput it self hooks up to? | 01:10 |
| bschaefer | by passing a client api? | 01:10 |
| bschaefer | right | 01:10 |
| bschaefer | RAOF, i suppose that would make things more ... platform independent | 01:10 |
| RAOF | Well, not really. | 01:10 |
| * bschaefer has no context on the idea of having multiple platforms | 01:10 | |
| bschaefer | for mir at lease | 01:11 |
| RAOF | It has exactly the same problems as a mir client API :) | 01:11 |
| bschaefer | since i see an X11 platform (which just uses libinput) | 01:11 |
| RAOF | Except that dbus is a nicer RPC mechanism than ours ;) | 01:11 |
| bschaefer | yeah as each platform could have its own quirks | 01:11 |
| bschaefer | that 1 api couldnt rule over | 01:11 |
| RAOF | Right. | 01:11 |
| bschaefer | RAOF, o ... and U-S-C IS the MIR SERVER | 01:12 |
| bschaefer | right? | 01:12 |
| bschaefer | ie. | 01:12 |
| bschaefer | platform --> USC --> client? | 01:12 |
| bschaefer | rather | 01:12 |
| bschaefer | platform --> USC --> U8? | 01:12 |
| RAOF | usc is *a* mir server, yes. | 01:12 |
| bschaefer | i see, i just now understood that part... | 01:12 |
| RAOF | Platform is entirely hidden from USC by libmirserver. | 01:12 |
| bschaefer | so platform --> libserver --> USC? | 01:12 |
| bschaefer | in how things would have to talk? | 01:13 |
| bschaefer | or does libmirserver even have a public API? | 01:13 |
| RAOF | Oh, absolutely. | 01:13 |
| RAOF | It's the API that USC uses. | 01:13 |
| bschaefer | i see ok | 01:13 |
| RAOF | Mostly it's mir::Server | 01:13 |
| bschaefer | so the client API would sit between USC and U* | 01:13 |
| bschaefer | U8 | 01:13 |
| RAOF | Right. | 01:13 |
| RAOF | U8 is *also* a Mir server. | 01:14 |
| bschaefer | so then the client API would expose a FD | 01:14 |
| bregma | what's wrong with having a D-Bus API for enumerating devices and their settinsg (and maybe changing some as appropriate)? | 01:14 |
| bschaefer | o...geez right | 01:14 |
| bschaefer | since its a *nested* server | 01:14 |
| RAOF | bregma: Mainly that you now need to abstract over your input platforms, and leak that abstraction through to a client. | 01:15 |
| bschaefer | bregma, like a DBUS API for mouse settings (get/set) and keyboard (get/set)? | 01:15 |
| RAOF | bregma: You also need to be able to identify *which* client, as a multi-user system is going to have different configuration for different users. | 01:16 |
| bregma | RAOD, it's going to need that abstraction somewhere | 01:16 |
| RAOF | bregma: Absolutely; but the less that abstraction is exposed the easier it is to change. | 01:17 |
| bregma | also, there is an arbitrary number of input devices and types and attrubites and settings and most of them are hot-pluggable, and D-Bus is ideal for that | 01:17 |
| bregma | D-Bus decouples everything so nicely | 01:17 |
| * bschaefer needs to learn dbus better | 01:18 | |
| RAOF | Yeah, but ‘arbitrary number and types of attributes’ is just pushing complexity on to the client. | 01:18 |
| RAOF | I mean, it makes it easier to have code that *builds*, but more difficult to have code that *works*. | 01:18 |
| bregma | well, it's complex and only the client really understand what it wants to do with the input | 01:18 |
| RAOF | Correct! Which is why it should be doing the input processing :) | 01:19 |
| bschaefer | RAOF, why cant we give the client already in use devices? ie. a list of all connected devices in which they can get/set info to? (im missing a lot of context here) :( | 01:19 |
| RAOF | See-also: pointer barriers ;) | 01:19 |
| bschaefer | in such a way where we enum over the connected devices rather then potential devices | 01:19 |
| bregma | we're going to need something like pointer barriers sooner rather than later, because of the whole press-the-left-edge-to-reveal-the-Launcher thing going on | 01:20 |
| RAOF | Yes. That should be implemented by the shell, *not* by USC. | 01:20 |
| RAOF | Having it implementable by the shell is one of the major architectural motivations for Mir-like things! | 01:21 |
| bregma | probably... I lack the architectural view of some of this stuff | 01:21 |
| bregma | RAOF, you're thinking the best thing to do would be to pass an evdev fd through a C api to the client and let it worry about doing settings things itself? | 01:22 |
| RAOF | Yes. | 01:22 |
| bregma | hmmm | 01:22 |
| bschaefer | RAOF, which i think we all agree on, the only thing we are trying to figure out is how to get configuration changes to libinput;... | 01:22 |
| bschaefer | which right ... theres all these different ways to do this :) | 01:23 |
| * bschaefer talking about having the shell implement barriers | 01:23 | |
| bregma | that sort of implies sticking to libinput exclusively in the future, no? Or is it an evdev-level fd that bypasses libput? | 01:23 |
| RAOF | It's an evdev-level fd that bypasses libinput. | 01:23 |
| RAOF | I guess it's not even necessarily an evdev fd; it's just *an* fd. | 01:24 |
| bschaefer | wouldnt they still need their own input platform which connects directly to libinput? | 01:24 |
| RAOF | Yes. | 01:24 |
| bregma | I though some of the settings being passed were libinput settings, not evdev settings | 01:24 |
| bschaefer | right, at lease that can be abstracted | 01:24 |
| RAOF | It just so happens that we don't currently have any input devices that *don't* use evdev, but I'm not sure that's something we can reliably bake in. | 01:24 |
| bschaefer | bregma, well i think you get an FD device then use it to change libinput | 01:24 |
| bschaefer | settings | 01:24 |
| RAOF | You give the fd to libinput. | 01:24 |
| bschaefer | so sometime in the future when libinput isnt around, you would just pass the fd to w/e handles input at that point? | 01:25 |
| bregma | I'm just thinking things like pointer acceleration is a libinput thing, not an evdev thing | 01:25 |
| * bschaefer just thought you would pass the fd to libinput then change the acceleration your self in the shell | 01:26 | |
| bschaefer | from the evdev FD | 01:26 |
| RAOF | Right. This does need libinput to be extended with the ability to create a device from an evdev fd rather than a path. | 01:27 |
| RAOF | bschaefer: Exactly. The nested compositor has an input platform, which will be libinput, and adds devices based on the fds it receives. | 01:28 |
| bschaefer | RAOF, it sounds nice, i just dont 100% know all the details in this :) | 01:28 |
| bregma | maybe anpok can add that with his other upstream changes | 01:28 |
| bschaefer | that would be nice... | 01:28 |
| * bschaefer kind of assume you could get a evdev FD from a libinput device | 01:28 | |
| bschaefer | already | 01:28 |
| RAOF | You can't, no. | 01:28 |
| bschaefer | o :( | 01:29 |
| RAOF | But we create libinput devices from evdev fds (or, rather, from /dev/input/* paths), so that's fine. | 01:29 |
| bschaefer | i can at lease start making the API for that is suppose ... should just really be a function to mir_platform_get_fd? | 01:29 |
| bregma | is that a sadface with a little hat? | 01:29 |
| bschaefer | bregma, haha maybe | 01:29 |
| bschaefer | o:( | 01:29 |
| bschaefer | <:( | 01:30 |
| bschaefer | RAOF, right now i think i understand the supppppper broad picture, i think ill generate more questions in the details | 01:30 |
| bschaefer | the only thing that seems to block this is actually getting a evdev fd | 01:31 |
| bschaefer | from the device to send to the Shell | 01:31 |
| bregma | just so you know, anpok is off until the 20th (and I'm off until next Tuesday) | 01:31 |
| bschaefer | yeah ...my goal was to try to do as much as i could until he got back :) | 01:31 |
| bschaefer | bregma, enjoy your time off! Is it still summer there? | 01:32 |
| RAOF | I think the API would actually be something like mir_surface_set_raw_input_handler(), which would set up the callback to handle the fds sent. | 01:32 |
| bschaefer | then the function pointer would just be | 01:32 |
| RAOF | bregma: But you're not on holiday today? | 01:32 |
| bschaefer | (int fd) | 01:32 |
| RAOF | :) | 01:32 |
| bschaefer | void* ctx | 01:32 |
| bregma | bschaefer, I've got tickets to a Broadway show in NYC, I understand it's 32 and sticky there | 01:32 |
| bschaefer | bregma, o geez! But awesome! I think you told me you had those | 01:32 |
| bschaefer | or are you going again? | 01:32 |
| bschaefer | its 28C here now :( | 01:33 |
| * bschaefer does not do well in hot weather | 01:33 | |
| RAOF | bschaefer: You'd need a bit more than just int fd; although possibly just int[] fd, int num_fds. | 01:33 |
| bregma | no, this is it, my wife's 50th birthday presemt | 01:33 |
| bschaefer | bregma, awesome, well that sounds like a fun trip | 01:33 |
| bschaefer | RAOF, a list of FDs? I was thinking each FD would get sent individually but idk why :) | 01:34 |
| bschaefer | which is fine | 01:34 |
| RAOF | Either is probably fine; a list probably makes it a bit easier. | 01:34 |
| bschaefer | RAOF, that function would get called....when an input came down on the fd? | 01:34 |
| RAOF | That function would get called each time: | 01:35 |
| RAOF | a) A new input device was added | 01:35 |
| bschaefer | or one removed | 01:35 |
| RAOF | b) The surface received focus (and so a set of input device fds need to be sent) | 01:35 |
| bschaefer | oo that makes sense, was thinking that would be independent of surfaces | 01:35 |
| bschaefer | but i guess surfaces can filter what devices work on it? | 01:36 |
| RAOF | Yeah, it can't really be. | 01:36 |
| bschaefer | or something? | 01:36 |
| RAOF | This is the bit where having an explicitly different system-compositor→nested compositor would make a whole lot of sense. | 01:36 |
| bschaefer | which is what we have now? | 01:36 |
| bschaefer | with USC->U8? | 01:36 |
| RAOF | Which is not what we have now. | 01:37 |
| * bschaefer needs to learn how to draw that arrow | 01:37 | |
| RAOF | Any API that U8 needs is also available to an arbitrary other cilent. | 01:37 |
| bschaefer | o i see | 01:37 |
| bschaefer | since its the server/client | 01:37 |
| RAOF | (Modulo permission bits enforced by USC) | 01:37 |
| bschaefer | at the same time | 01:37 |
| RAOF | Right. | 01:37 |
| bschaefer | eww | 01:37 |
| RAOF | U8 *is* a Mir client :){ | 01:37 |
| bschaefer | hmm yeah | 01:37 |
| bschaefer | RAOF, so far this is making sense but i know as soon as i start to write any code my mind will go blank :) | 01:38 |
| bschaefer | but so far that makes sense | 01:38 |
| RAOF | The reason we need to send device fds on surface focus is that we will *revoke* those fds on surface unfocus. | 01:38 |
| bschaefer | RAOF, fds are specific to each surface? | 01:39 |
| RAOF | Yeah. | 01:39 |
| bschaefer | i see, didnt know that i thought it was more server specific | 01:39 |
| bschaefer | and a surface on the server it self would have the same FD/devices | 01:39 |
| bschaefer | soo thats a part that will have to be touched in the server, when a surface is released to send that off | 01:40 |
| RAOF | http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c7dc65737c9a607d3e6f8478659876074ad129b8 is the relevant bit. | 01:40 |
| bschaefer | RAOF, duh, that makes a lot more sense from the first sentence haha | 01:40 |
| bschaefer | RAOF, cool thanks for all the info! Ill be sure to have more questions come next week | 01:41 |
| RAOF | :) | 01:41 |
| * bschaefer tries to write everything down so far coverd | 01:41 | |
| bschaefer | RAOF, o also there was some questions on the attestable cookie MP when ever you get a chance to read though | 01:50 |
| RAOF | Yeah, I'm looking through it. | 01:51 |
| bschaefer | (one being about providing a way to produce cookies public wise) | 01:51 |
| bschaefer | RAOF, cool thanks! | 01:51 |
| === c74d is now known as Guest68804 | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| alan_g | alf: @mir-on-x-grab-keyboard - am I missing some incantation to activate the grab? "$bin/mir_demo_server --launch-client bin/mir_demo_client_multiwin" and try various key combinations. | 09:02 |
| alf | alan_g: what works for me is explicitly setting the input platform --platform-input-lib=lib/server-modules/server-mesa-x11.so.4 | 09:31 |
| alan_g | alf: that helps. Thanks | 09:39 |
| === greyback__ is now known as greyback | ||
| === pete-woods1 is now known as pete-woods | ||
| alan_g | WTF?! "static inline std::chrono::nanoseconds seconds_to_nanoseconds(std::chrono::nanoseconds secs)" | 10:31 |
| === chihchun is now known as chihchun_afk | ||
| === alan_g is now known as alan_g|lunch | ||
| === MerryChristmas is now known as benonsotfware | ||
| === benonsotfware is now known as benonsoftware | ||
| === alan_g|lunch is now known as alan_g | ||
| attente | hi. unity-system-compositor is crashing for me with: "/usr/sbin/unity-system-compositor: relocation error: /usr/sbin/unity-system-compositor: symbol _ZN3mir6Server24add_configuration_optionERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_NS_10OptionTypeE, version MIR_SERVER_32 not defined in file libmirserver.so.32 with link time reference" | 13:25 |
| alan_g | attente: that's a g++5/g++4 mismatch. (Part of the "gcc5 transition") | 13:27 |
| attente | alan_g: oh... is there any temporary workaround for it? | 13:29 |
| alan_g | Well, I've just avoided updating anything from archive. | 13:30 |
| alan_g | What stack are you seeing this on? | 13:31 |
| attente | alan_g: just did an update on wily | 13:31 |
| alan_g | Your using unity-system-compositor on a desktop? | 13:33 |
| alan_g | *you're | 13:33 |
| attente | alan_g: yes, was trying to run u8 | 13:33 |
| alan_g | You've likely downloaded a bizarre mix of g++4.9/g++5 packages. So... | 13:34 |
| alan_g | You could try finding an 4.9 build of USC and reinstalling, but you're likely to run into other (similar) problems depending what's in archive. | 13:35 |
| alan_g | FWIW The "__cxx1112basic_string" is g++5's new string implementation. So USC is built with g++5 and libmirserver isn't. | 13:36 |
| attente | alan_g: ok, thanks. do you think rebuilding the mir packages with g++5 would work? | 13:43 |
| alan_g | attente: maybe. It depends what 4.8/5 mix of libs you now have. (e.g. boost and protobuf) | 13:44 |
| attente | alan_g: ok, i'll try it anyways | 13:45 |
| === alan_g is now known as alan_g|EOW | ||
| popey | kgunn: what's the state of silo 0, is it still broken? Any ETA for it not being? | 20:03 |
| ted | popey, patches welcome! ;-) | 20:32 |
| popey | ted: you don't want my patches :) | 20:38 |
| ted | popey, Perhaps, but we're talking about kgunn here — he knows how to translate from "Old English" to American. ;-) | 20:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!