racarrkillall mir_stress;00:14
racarrfun to write ;)00:14
racarrfeel very close to this stress bug00:19
racarrbut need to go help build a dome00:19
racarrback later :)00:19
RAOFracarr: Yo00:33
racarrRAOF: Hi! Sorry. I am about to leave (I literally have to go help build a dome)00:36
RAOFThat's ok.00:36
racarrbut, I will be around...was hoping we could have a hangout later00:36
racarrI am jumping more on the xmir train (WHISTLE WHISTLE SCREEEEEECH)00:36
RAOFWooo wooo!00:36
racarrand have a few items I want to sync with you on and just in general00:37
racarrOk play time!00:44
=== racarr is now known as racarr|themanbur
=== racarr|themanbur is now known as racarr
racarraww truncated00:45
racarr*runs in shame*00:45
RAOFWhat the whatting what? My perfectly valid DrawablePtr gets mangled in the process of calling xmir_dri2_drawable_can_bypass. Are there two different definitions of struct _Drawable or something?01:05
RAOFThere must be! What the whatting what?01:09
RAOFWell, that's moderately terrible. Always #include <xorg-config.h>, lest your structures magically change layout!01:22
* duflu includes <xorg-config.h> in all files from now on01:46
dufluOh kdub, you put conflicts in all my code today :)01:58
dufluWorse than conflicts... classes don't exist any more . Hmm...02:11
kgunnso does gdb have known issues with xmir ?03:31
duflukgunn: X in general is not GDB friendly. You always have to GDB from an ssh login03:39
dufluor remote shell of choice...03:40
RAOFI'm happily gdbing XMir right now.03:41
RAOFFSVO “happily”03:41
kgunngot it03:44
RAOFI should have remembered the unofficial X motto.03:59
RAOF“X: More difficult than you think”03:59
dufluX: Solve everything for...04:00
RAOFAlright. That's enough GLX bypass for now. Upstreaming!04:04
dufluthomi: Sorry to bug you late in the day but any idea about... https://jenkins.qa.ubuntu.com/job/mir-clang-saucy-amd64-build/1222/console05:00
didrockshey kgunn!05:25
kgunnhey didrocks !05:25
didrockswaow, you are using French punctuation (space before ! : and ; )05:26
didrockskgunn: I confirm that u-s-c depends on libmirserver FYI05:27
didrocks Depends: libboost-program-options1.53.0, libboost-system1.53.0, libc6 (>= 2.9), libgcc1 (>= 1:4.1.1), libmirserver0 (= 0.0.7+13.10.20130716ubuntu.unity.next-0ubuntu1), libstdc++6 (>= 4.6)05:27
didrocks(this dep is automatically resolved by the linker)05:28
kgunndidrocks: hmmm,  i know  it uses a "shared" header...but it must actually end up being in libmirserver05:29
didrockssrc/system_compositor.h:#include <mir/default_server_configuration.h>05:29
didrocksyeah, should be that ^05:29
kgunnthat be the one05:30
didrockskgunn: so, +1 on the virtual package, created by a soname (in cmake) which creates a config.h file (#define)?05:31
kgunndidrocks: wanna join our team meeting ?....we can get all our stuff out of the way & ping you to join05:31
racarrdidrocks: It's really fun. you know you want to05:31
didrocksracarr: ahah :p05:31
didrockskgunn: oh sure, when is it? (I thought your meetings were on Thursday)05:31
kgunnnope tonight05:32
kgunnor this morning sorry05:32
didrocksI was able to translate :-)05:32
didrockshow long from now?05:32
kgunnwe start in 1/2 hour05:32
didrocksok, just time to get the coffee ready then!05:33
kgunnoh sure05:33
* racarr jealous05:34
racarrIf I had coffee there would be no going back05:34
didrocksracarr: caffein-free tea? :)05:34
racarrdidrocks: One step ahead XD05:34
racarrit's the caffeine I want. it's just the caffeine I dont want in 1 hour05:34
RAOFdidrocks: Incidentally, how do we work out when the ABI has changed for that?05:48
didrocksRAOF: you mean, how do you see the ABI changed? Yeah, you have to notice that your change did that05:48
didrocksRAOF: the integration tests will tell you that quickly I think :p05:48
RAOFAh, ok.05:49
thomiduflu: hey, I missed your message before05:54
thomiduflu: it looks like possibly a bzr bug? Did you retry the build?05:54
dufluthomi: No, I don't think I have the VPN set up any more05:55
thomiduflu: OK05:55
thomiduflu: I've just kicked it off again, we'll see if it works this time.05:57
dufluthomi: Ta05:57
thomiduflu: and I'll file a bug against bzr builder and see what the devs say05:57
* duflu wonders if the VPN setup instructions are any simpler tnow05:57
thomiI'm not sure they're any simpler... but I set it up once, and have never had to touch it again05:58
duflu... because I tend to wipe my machines between releases05:58
thomiI recommend using the network-manager-applet instructions05:58
thomiI haven't done that for a few years now05:58
thomiduflu: perhaps you have a router that's VPN capable? Although that's not very secure, depending on who has access to your personal network05:59
robert_ancellthomi, hikiko, alf_ kgunn kdub meeting06:00
RAOFracarr: Are you still hankering for a hangout?06:41
didrockskgunn: RAOF: let me enlight your day/night and please approve https://code.launchpad.net/~didrocks/mir/remove-powerpc/+merge/175201 :)06:56
thomiduflu: looks like the re-run of that jenkins job worked. I've filed a bug against bzr-builder anyway07:03
dufluthomi: Yep thanks07:03
dholbachgood morning! :)07:09
thomiRAOF: Is a string like "Intel Corporation: 2nd Generation Core Processor Family Integrated Graphics Controller" useful enough to identify the graphics chipset for the xmir devices?07:12
thomiI as because that's all we get for the cert lab machines at the moment07:12
thomiBut I guess ideally we'd get the specific model number07:13
RAOFthomi: It's pretty good, but could be better.07:13
thomiok.. as long as it's not totally useless, I'll run with it for now07:13
RAOFIdeally we'd get a tuple of (gen, GT #).07:13
RAOFXorg.0.log should actually have the (gen, GT #) tuple in in.07:13
RAOFBut I can't tell at the moment, because btrfs has done it's "I'll just wedge for a couple of minutes, k" thing, and anything that hits the disc subsystem is going to hang in D state.07:14
RAOFAh, there we go! Hissy fit ended!07:14
RAOF[  6184.799] (--) intel(0): Integrated Graphics Chipset: Intel(R) Sandybridge Mobile (GT2)07:15
RAOFThat one's nice :)07:15
tvoss_didrocks, just let me know when I can have fun on the arm builders, happy to take a look07:17
didrockstvoss_: yeah, I pinged infinity, but no luck :/07:17
tvoss_didrocks, no pong or "no, you can't have fun on the builders"?07:17
didrocksno pong07:18
dufluI hate it when I wait a month for something to arrive, and then the wrong thing arrives07:22
dufluDay spoiled07:22
alf_duflu: :/07:23
duflualf_: You mentioned it's a problem when the ground moves under your feet and MPs become conflicted... Yes I experienced this today as I have many times already. I don't think it's a problem we can avoid completely while so many people are working on Mir simultaneously07:36
didrocksalf_: look at https://code.launchpad.net/~didrocks/mir/remove-powerpc/+merge/175201 for the first part I guess :)07:36
alf_didrocks: thanks07:36
alf_didrocks: Agreed. My point was that if we have too many such "disruptions", it will unavoidably slow down critical work, and it is a risk we should have in mind.07:38
alf_duflu: ^^07:38
alf_didrocks: sorry, wrong nick :)07:38
didrocksalf_: I started to think I hadn't enough coffee :p07:39
duflualf_: Yes. I guess then large changes must be justified and have high value for helping future work... which usually large changes do07:39
dufluFor example; a driver interface. It's a large change, but has high value07:40
=== alan_g|EOD is now known as alan_g
=== hikiko is now known as hik|afk
alan_gduflu: why do you think the graphics namespace might "go away"?08:23
duflualan_g: Because it makes no sense to designate part of Mir as "graphics" and other parts not graphics. It's all intended for graphics, so we should avoid the word08:24
duflualan_g: "platform" ?...08:25
alan_gduflu: I concede that it is possible you can persuade the team to rename "graphics" to <something else>, but the namespace will still exist.08:25
duflualan_g: How would it still exist if it was renamed?08:26
alan_gAs, for example, "platform"08:26
RAOFBut Mir is not all intended for graphics; there's input, too.08:26
alan_gIt will still have the same contents and role08:26
dufluRAOF: Almost all. The statement still holds :)08:26
RAOFIn put is *at least* as big as graphics.08:27
duflualan_g: Yes, true. Is your current proposal significantly different to just the namespace changes though?08:27
dufluI haven't looked at it all in detail08:27
alan_gyes, it moves stuff into that namespace08:28
tvoss_duflu, if we remove graphics, we should have a namespace platform08:28
alan_gWhich is part of having a delineated garphics/platform API we can take to vendors08:29
tvoss_duflu, we almost certainly end up with prefixes like Graphics* and that's what namespaces are for08:29
duflutvoss_, alan_g: Looking in more detail, I see we are moving things out of "compositor" that are platform independent. I don't think such things make sense in "platform" actually08:29
dufluMaybe "graphics" is just a stepping stone08:30
alan_g"graphics" is intentionally platform independent. That's why we have android and gbm implementations.08:32
alf_alan_g: ... which contradicts our moving platform independent code into it :/08:33
=== hik|afk is now known as hikiko
alan_galf_: how does ""graphics" is intentionally platform independent" contradict " moving platform independent code into it :/"08:34
alf_alan_g: sorry, I read graphics (thinking gbm/android) is platform *dependent*, my comment is invalid08:35
didrocksalf_: still no review on my branch?08:45
alf_didrocks: done08:49
didrocksthanks ;)08:49
* duflu goes stealth mode to avoid bugging Europe for the day (and vice versa)09:36
=== alan_g is now known as alan_g|afk
=== alan_g|afk is now known as alan_g
hikikoalf_, ping!10:28
alf_hikiko: pong10:28
hikikodo you have some time to ask you about the miron mir?10:28
alf_hikiko: sure10:30
hikikoI have this as a reference but I am not sure about my design:10:31
hikikomg::create_native_platform will be similar to current create_platform and leave in gbm/android10:32
hikikomg::create_nested_platform will be similar to create_platform and in nested_platform.cpp10:32
hikikoand the create_native_platform_nested will call both?10:33
hikikoif the native platform doesn't know anything about the nested platform10:34
alf_hikiko: @mg::create_nested_platform, as things have evolved, you can probably skip this function and instantiate NestedPlatform directly (because it will live in libmirserver)10:35
hikikoyes but where?10:35
hikikoif it's required that10:36
alf_hikiko: @mg::create_native_platform_nested, this will create a native platform configured for nested functioning (e.g. no drm, no vt)10:36
hikikosure but10:36
hikikomy question is:10:36
alf_hikiko: you can select which platform to create in DefaultServerConfiguration::the_graphics_platform()10:37
hikikoso I choose there to create the native_platform_nested and this does the rest10:40
hikikoI mean I just have to load the right callback10:41
alf_hikiko: at that point you should create either 1. the native platform: with mg::create_native_platform or 2. the nested platform: use the NestedPlatform class. We can start with NestedPlatform calling mg::create_native_platform_nested() internally to create the native platform in "nested" mode.10:44
hikikogot it :)10:47
hikikothanks alan_g10:48
alan_ghikiko: yw10:48
tvoss_greyback, ping10:52
greybacktvoss_: pong10:52
=== alan_g is now known as alan_g|lunch
=== alan_g|lunch is now known as alan_g
=== alan_g is now known as alan_g|tea
=== alan_g|tea is now known as alan_g
tvoss_something is flakey in our armhf tests15:21
tvoss_dear armhf machine, faster please15:25
bregmatvoss_, can you be more specific about the flakiness?15:26
* bregma is not disagreeing15:26
tvoss_bregma, I'm not entirely sure, but the file-based sync mechanism should be totally reliable albeit a bit unelegant :)15:27
tvoss_however, I do see the clients starting in strace and immediately exiting with 015:27
* bregma goes off to play with the synch mech15:29
tvoss_bregma, a pipe should help :)15:30
* tvoss_ thinks that he could help the armhf build machine a little in translating to assembler15:51
tvoss_bregma, I have something like http://pastebin.ubuntu.com/5884664/ in mind15:56
bregmamight want to epoll/signal in the wait to avoid a deadlock (does pipe() close if the writer exits without a shutdown()?)16:00
tvoss_bregma, should, feel free to adjust ... if you can take care of that sync mechanism in the acceptance tests, I willl look into the flakiness16:01
tvoss_I think it comes down to an unholy combination of buildd, kernel version, epoll and reactors16:01
tvoss_just triggered a rebuild16:01
bregmasure, but your rebuilds are still faster than mine16:02
tvoss_bregma, not sure :)16:02
alan_gsmspillaz: ?16:55
smspillazalan_g: older versions of byobu required you to select a screen session whenever you launched byobu16:56
smspillaznewer versions automatically resume your first16:56
smspillazSo I have a muscle-memory of byobu-1 which ends up in me saying "1"  a lot16:56
alan_gYes I guessed that16:57
alan_gAll change is bad16:57
=== alan_g is now known as alan_g|EOD
bregmad'oh, fork() and RAII do not mix well17:33
racarrHours of stress testing -> lunch18:47
tvoss_bregma, any more insight on your side?19:00
racarrAh! I had one more idea and failed to leave for lunch...and then now I think I finally found it19:02
racarr(stress test)19:02
racarrwell it finally makes sense why it crashes at least19:05
racarrNOW real lunch19:05
=== racarr is now known as racarr|lunch
kdubrvalue fun19:15
bregmatvoss_, I'm fairly certain there's a race condition when the socket is destroyed by multiple child processes in the tests, but I'm still looking for concrete proof .. good news is I can repro locally now (after a 6 hour build)19:46
bschaeferbregma, are you getting a pure virtual function called? Causing it to crash? (I've ran into that when attempting to close the mir server before...)19:47
bschaeferor close a connection to the server19:47
bregmabschaefer, there is a deadlock where the test case is waiting for a signal but the child (signaller) has exited beforre the wait begins (qhich itself is a sequencing problem)19:48
bschaeferbregma, oo different problem then :)19:48
bschaeferbregma, children should learn to wait!19:49
tvoss_bregma, \o/19:52
tvoss_bregma, I will EOD now19:52
=== racarr|lunch is now known as racarr
racarrthis stress-test race is a little deeper than just adding a mutex or something struggling a bit to find a solution even now that it's found20:27
racarrkdub: I feel like the general theme may interest you20:29
racarrmsh::Surface is almost impossible to use safely outside of the scope of the Session that owns it20:30
racarrbecause, say, when a surface is closed, so we have to find a new surface to focus, so we find it and get a shared_ptr<msh::Surface>20:31
racarrand then call surface.anything()20:31
racarrand then another thread closes the surface20:31
racarrso your msh::Surface pointer is stlil valid but surface.anything()20:32
racarrbecause the ms::Surface is gone20:32
racarrI guess, you need session to act as a synchronization point so rather than like20:33
racarrbla = session.default_surface()20:34
racarryou can do like session.take_input_focus_on_default_surface(targeter)20:35
racarrand the session will hold it's internal lock preventing a close_surface from being processed20:35
racarrbut this feels unsatisfying and unscalable20:36
racarrThe other immediate direction that comes to mind is exposing locks out of the session as API, i.e. msh::Session::Freeze f(session);, but this seems really error prone.20:39
racarrSo maybe what you really want, is some way to promote a surface pointer, i.e. surface.no_really_block_any_thread_that_is_trying_to_destroy_this_surface_until_the_return_value_of_this_function_is_destroyed20:40
racarrso now I start to think that these are transactions20:41
racarrand wonder what Alan's thoughts so far are on the new scenegraph model ;)20:41
racarrbecause these sort of inconsistencies, are what the hypothetical group-mind scenegraph model is supposed to be able to solve20:42
racarrAnother random API idea: session.transcation(std::function<void>())20:43
racarrwhich freees the session (with a recursive mutex)20:43
racarrand then invokes the callback20:43
racarrso this way you can write like20:43
racarrsession.transaction([&](Session& s) { auto surface = s.default_surface(); surface.take_input_focus(); }20:44
racarrand anything calling i.e. Session::destroy_surface20:44
racarrwill block until your transaction is complete20:44
racarrIt's not really a transaction20:45
racarrbecause it's not reapplicable, what is it...20:45
racarrit's like an atomic operation. but it's not clear what session.atomically_do means (atomic with respect to what?)20:47
robert_ancellracarr, can you merge lp:~robertcarr/mir/simplify-depth-assignment with trunk?20:50
racarrrobert_ancell: Yeah doing so now20:50
racarrrobert_ancell: I finally found the stress race :)20:50
racarrin a way that explained the weirdness from yesterday and everything20:50
racarrso uite happy20:50
robert_ancell\o/ awesome!20:50
robert_ancellme too :)20:51
racarrbut the solution is a little tricky20:51
robert_ancelland thomi too I expect20:51
racarr /unclear20:51
kgunnrobert_ancell: hope it clears some other stuff20:51
thomiracarr: cool!20:51
thomiracarr: when you have a branch with the fix, let me know and I'll review your MP and test it here20:52
thomiI seem to be able to trigger these things more easily than most people20:52
racarrXD I get it like20:52
kgunnhey, does anyone know any special fiddling required to run a system with both nvidia & intel gfx ?20:52
racarrwithin a second20:52
thomiapparently my CPU isn't just hyper-threaded, it's hyper-mega-awesome-threaded20:52
kgunni know RAOF said his ran20:52
thomiracarr: awesome :)20:52
kgunndo you just load nouveau for nvidia and everything else should he "happy happy happy" ?20:53
racarrkgunn: When I had hybrid graphics the special fiddling was always disable one in the BIOS ;) not sure if you are hoping to do more than that20:54
kgunnnope....dandrader was trying xmir and having issues...i'll share tht20:54
racarroh god. what an awful merge conflict20:55
kgunnracarr: thx for it20:56
kgunnracarr: dandrader was looking for something fun...i told him he'd get a couple of beers from me if he solves the input lag20:57
racarryou mean the output lag!20:57
racarror was that a dream20:57
racarrsometimes the team meeting is hard to remember20:57
kgunnracarr: right20:57
kgunnall depends....:)20:57
kgunnand i think most correctly...yet to be determined lag20:57
kgunnracarr: btw...i capture 2 other "please add api" tasks in the unity prep bp20:58
kgunn1 for osk surfacetype20:58
kgunnand 1 for greeter20:58
kgunni figure you know what they are....but if not....ping dandrader for osk & mterry for greeter20:59
racarrI think I do20:59
racarrsimplify-depth-assignment is the first part of the greeter fix20:59
racarrbuttttttttttttttttttttttttttttttttttttttttttttt the second part isn't clear to me yet21:00
racarrill make sure I don't lose track of them :)21:00
racarrrobert_ancell: Merging simplify-depth-assignemtn will take a while21:05
racarrsomething...strange landed21:05
racarrand I can't even understand how the tests pass in trunk21:05
robert_ancellracarr, np, was just checking you'd seen it21:05
racarrall the tests which are supposed to test depth ID21:05
racarrgot replaced with default_depth21:05
racarroh and then they pass because the expectations got reordered21:06
racarrto make them pass21:06
racarrall the surface stack ordering tests are broken21:31
racarrbecause they verify by comparing the reference to the rendering criteria and the buffer stream21:31
racarrbut they all use stub buffers that share the same21:32
racarrrendering criteria and buffer stream21:32
racarrso by broken I mean they always pass21:32
racarrI think I have decided on (at least for a first proposal) this msh::Session::perform_transaction(std::function)22:27
racarrThe test is difficult to design though.22:27
racarrthe, test should verify that during the body of the function argument to perform_transaction22:28
racarrcalls to create/destroy surface block22:28
racarrit should also not be a racy test ;)22:28
racarrone interesting possibility, requiring some serious pthread nastiness22:36
racarris first you have to pin your test thread to one core, and set pthread sched param to22:36
racarrthen you create a session, and a surface and call perform_transaction22:37
racarrin your body, you start a new thread, which calls session.destroy_surface22:37
racarroh and the new thread also needs to be pinned to the same core22:38
racarrso then after you strt the new thread, the test yields guaranteeing your surface destroying thread will run now22:38
racarrsince they are both pinned to the same core, and scheduling mode is SCHED_FIFO22:39
racarrthe thread is guaranteed to continue to run until it blocks or yields22:39
racarrso, in the test thread, right after you yield, you can check if the surface has been destroyed22:40
racarrif it has, then create_surface blocked (otherwise that thread would still be executing and will have finished destroying the surface)22:40
racarrerr, if it hasn't*22:41
racarrif it has, then clearly create_surface succeeded22:41
racarrand you have deterministic test results, i.e. create_and_destroy_surface_block_during_body_of_transaction22:41
thomirobert_ancell: I notice that u-s-c has no license file!?22:42
robert_ancellthomi, I guess. It has license headers22:43
robert_ancellfeel free to add one22:43
racarrI have the sick feeling that that test22:46
racarrwould never land22:46
thomirobert_ancell: will do22:47
thomirobert_ancell: https://code.launchpad.net/~thomir/unity-system-compositor/add-license-file/+merge/17542222:50
racarrI dont think it's even possible to use SCHED_FIFO without root XD22:51
racarrI'm not sure this test is even possible as a normal user22:55
racarrbecause threads and processes are the same to the linux scheduler22:55
racarrso any program that can guarantee a thread executes22:56
racarruntil it blocks22:56
racarrcan bring down a single core system :p22:56
racarrbut really I just want to guarantee, that another particular thread wont execute until that thread blocks22:56
racarrIt's not actually a realtime requirement, I don't care if the kernel lets other processes run22:57
thomirobert_ancell: for this autopilot test, what's the best way of figuring out what hardware is running?23:04
racarrwhat I need is PTHREAD_SCOPE_PROCESS23:29
racarrbut it's no tsupported on linux...23:29
RAOFReally? That's odd.23:34
racarrRAOF: Actually linux pthread implementation seems to be roughly23:35
racarrthe least expressive pthread implementation allowed by the specification23:36
racarrbecause of the lack of distinction between23:36
racarrthreads and processes.23:36
racarrI am not happy about pthreads atm if you can tell23:36
RAOFYou could probably rube-golberg up the behaviour you want with an extra thread, right?23:37
racarrRAOF: I can't figure out a way...23:38
RAOFie: a watchdog thread that monitors the thread you're interested in, and sets a flag when it's blocked.23:38
racarrdo that either in linux23:38
racarri.e. tell if a thread is blocked23:39
RAOFWhat do we mean by “blocked” in this case?23:39
racarrRAOF: voluntarily yielded23:39
racarrRAOF: So the idea is, I am developing this API like session.do_transaction(std::function)23:40
racarrfor solving...a series of other races, the stress test stuff23:40
racarrso, the semantics it needs to provide are23:40
racarrso as far as I can see, the only way to deterministically test that is to23:41
racarrstart a second thread from within your transaction callback, which tries to destroy a surface23:41
racarrand then guarantee that that thread runs until it blocks23:42
racarri.e. isn't preempted by your original thread23:42
racarrbecause otherwise, all you can say is "that thread hasn't gotten to destroy surface yet..." (or rather, whatever instruction in the implementation of destroy surface the lock is actually held on)23:43
RAOFYou should be able to parse /proc to assert that the thread isn't running?23:43
racarrbut whatever code does that23:43
racarrmight preempt the thread23:44
racarrand then it wont be running23:44
racarri.e. the thread might exhaust it's timeslice and be stopped from running beore it actually blocks23:45
racarrso, an easy fix is to use23:45
racarrand pin both threads to the same core23:45
racarrbut, because there is no PTHREAD_SCOPE_PROCESS23:45
racarrSCHED_FIFO requires root, and can bring down your entire system23:46
RAOFEh, it's a testsuite.23:46
RAOFThey're pretty much allowed to bring down your system ☺23:46
RAOFpiglit does all the time!23:46
racarryeah but can they run as root?23:46
racarr / with some weird RT capability flag23:46
RAOFWhy can't they?23:47
racarrI dunno23:47
racarrI guess I just kind of assume someone would object and stop that from landing23:48
racarrI don't mean anyone in prticular, I just mean it sounds really23:48
racarrBUG: Can't run tests as non root user!23:48
racarrhaha, I guess it can just be a disabled test.23:48
RAOFWe build the packages as root already, so setting the RT capability on the tests shouldn't be _too_ bad.23:48
racarrok, those are all very good points.23:49
racarrXD, Thank you23:50
racarrI was kind of spinning from "Can't use SCHED_FIFO"23:50
racarrand just going deeper down that line23:50
racarrand reading very strange websites about freebsd23:50
RAOFDamn it takes *forever* to build an Ubuntu kernel.23:50
RAOFYou try and add one piece of functionality to dma-buf, you're waiting hours for it to build!23:51

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