[00:00] I have to go through the process now of extracting all these different little changes now [00:00] and figuring what fixes what and what goes in what branch [00:00] and it' brutal because I know im going to lock up my whole system 10 times in the process [00:00] XD [00:20] Well, that was an odd door-knock. [00:20] “Are there any Catholics in the house?” [00:23] RAOF, did then then break out some turntables and have some sort of Catholic rave? [00:23] Wika wika waaaaaow! [00:24] lol [00:26] robert_ancell: There's currently no infrastructure for lightdm to determine what type of session to run based on the result of a canary binary, is there? [00:26] Because it would be pretty easy to write a canary binary for ‘can unity-system-compositor possibly work’ [00:27] ok, dumb question: It seems the demo_server will render all surfaces at 0,0 right? Is it the responsibility of the shell to determine where things get rendered ? [00:31] thomi: Yes. [00:31] Well, it's the responsibility of the shell to do all the window managementy bits, of which ‘where should this window be’ is obviously one. [00:32] I see. So what will the demo server do when multiple surfaces are rendered? I assume the last one to render will be the one shown? [00:32] i.e.- it'll overwrite, not do any kind of alpha blending? [00:33] racarr? [00:34] My last understanding of the status was that exactly one surface would be non-hidden, so... :) [00:49] Yes at the moment [01:10] oh [01:10] that doesn't seem very friendly :) [01:35] RAOF, no [01:39] robert_ancell: Is it something you think would be reasonable to have? [01:40] RAOF, it doesn't really fit with the design, so I'm thinking it will be easiest to just make the "unity" seat type revert to VT switching if it wants to (it's not a lot of code, just need to copy the logic from src/seat-xlocal.c to src/seat-unity.c) [01:41] And long term we can drop the fallback from seat-unity.c probably [01:41] RAOF, do you know what sort of code we need to make the decision? If it's not too complex we can put it into seat-unity.c directly [01:42] robert_ancell: We need to iterate over the drm devices that udev iterates for us, then call drmModeIsSupported() on each. It's not a lot of code. [01:43] RAOF, also, I was wondering if we should just put the check into the system compositor, and the unity seat falls back to VT switching if the system compositor doesn't exist or starts (e.g. due to not having supported drivers) [01:50] That sounds reasonable. [01:53] RAOF, I'm making it support the VT fallback case now [01:53] Cool. [01:55] cool, there are ppl. here.. awesome.. preparing to install mir now. [01:55] I'll check that unity-system-compositor does the right thing. [01:55] does it work on nividia fx 5200? [01:56] Should do, as long as you're using nouveau. [01:57] so, i gotta switch back to noveau. [01:57] that's not a prob., just lose my s-video output.. :( [01:58] im quite interested in getting involved in development of mir.. [02:00] secret_ninja, awesome! :) [02:00] brb [02:02] secret ninja is hung up. im him. so, i gotta downgrade to nouveau.. [02:04] quiet in here === mycoguyco is now known as secret_ninja [02:05] Yeah, you need nouveau. We don't¹ run on the proprietary drivers. [02:06] ¹: But are working to make that happen. [02:06] RAOF: is there a higher level API to render to a surface than what's done in the unaccelerated demo? I mean, without using gl ;) [02:06] ok. i just lose svideo out.. [02:06] thomi: GL *is* the higher-level rendering API :) [02:06] im interested in development. [02:06] this project sounds very interesting. [02:06] RAOF: yeah... I guess I should just use that [02:06] thomi: Although you could probably also use Cairo and render using that. [02:07] will it compile with llvm? [02:07] was *vaguely* intersted in playing with llvm also. [02:12] pretty quiet in here [02:14] secret_ninja: It will complie with clang, but might not run. [02:14] secret_ninja: If you wanted a good project to start with, ferreting out why the unittests fail when built with clang would be nice :) [02:16] aight. might be byting off more than i should all at once, but why not.. [02:17] Fixing unit tests does at least give a very obvious means of checking progress ;) [02:19] i haven't yet played with llvm yet. much more fam. with gcc, but wanting to play with llvm.. [02:19] dont have high expectations.. :) [02:20] You should have. clang produces error messages about an order of magnitude better than g++ [02:22] really? heh, i liked g++ errors.. [02:29] more /etc/X11/Xsession.options [02:29] wrong window [02:38] :) [02:42] RAOF, https://code.launchpad.net/~robert-ancell/lightdm/unity-vt-fallback/+merge/166631 [03:43] Back for a while! [03:49] You midnight owl, you! [03:55] 8:55! [04:07] thomi: So not moving the cursor I can't reproduce any problems with trunk [04:08] racarr: ok, let me re-pull and re-build [04:09] thomi: That may be a complete lie [04:09] it may just be very intermittent [04:09] yeah ok ive still got a crash [04:09] racarr: it happens pretty frequently here... as in, within 10 seconds [04:09] now I can start applying fixes [04:10] cool [04:10] you're using mir-stress ? [04:10] yeah [04:11] atm I am eating indian food but at a later point I will be using mir-stress again [04:11] oh man, I'm jealous [04:11] although... it is "Fish and Chip Friday", so that's something to look forward to I guess [04:13] :) [04:13] I was obsessed with fish and chips when we lived in england when I was young [04:13] obsessed XD [04:14] New Zealand fish and chips are a little different [04:14] there's none of that malt vinegar shenanigans, for a start [04:15] I'm only in it for the batter. [04:18] the thing that still worries me about all this is I understand [04:18] the deadlock that shows up after I "Fix" the crash [04:18] but I can't find any possible set of circumstances where the race for this crash to happen [04:18] would happen [04:18] woohoo.. compiling llvm and clang [04:18] d/l'ing mir. [04:19] secret_ninja: Don't party too hard [04:19] ;) [04:19] blarg, gonna sleep through the compile and d/l. [04:20] Cya. [04:20] iim only getting 15k/sec on the d/l and it is 700 megs [04:20] 14 hrs left. [04:21] reminds me when i pirated digital unix for an alpha i had at home back in the 90's. [04:21] i was on isdn [04:21] took all wknd [04:45] quick llvm question...should i do an optimize or profiled build? [04:51] secret_ninja: Doesn't really matter. [04:53] wasn sure if profiling did anything arch specific [04:54] i just did optimized. damn, i specified arch x86_64 ( ive got amd 64 bit). won't be able to compile to other archs.. damn, i gotta start thinking more. [04:55] or, will i? guess ill find out. [04:58] I'm not quite sure why you'd want to build for other archs at this point. [04:59] You *can*, with a chroot or a cross-compiler or similar. [04:59] But that's not really interesting unless you want to deploy on a phone or somesuch [05:05] ok, that's what i was thinking when i installed, that i would just be compiling for this arch.. but, if i get into coding again, im gonna wanna check my code compiles for all archs. [05:05] even though i can't test resulting binary code [05:05] still compiling, still d/l'ing mir.. gonna be all night on the c/l.. dunno how long compile will take. [05:14] On a reasonable system Mir shouldn't take more than 10 minutes or so to build. [05:17] Generally speaking you don't need to care about having your code compile on different architectures. That's the compiler's job :) [06:10] lame shit.. didn't rename clang-3.2.src to clang and it didn't compile it by default.. [06:10] recompiling. [06:14] mir at 25%.. woot, woot. [06:29] Any particular reason why you didn't just install clang from the repositories? [06:29] Maybe you're not running Ubuntu? [07:27] i like to compile from source [07:27] Linux citadel 3.8.0-22-generic #33-Ubuntu SMP Thu May 16 15:17:14 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [07:29] leftover habit from openBSD days. [07:30] Heh. [07:31] been running linux since 94. [07:32] and, i gotta say, 13.04 is the best one ive seen yet. [07:33] this way, i know that the llvm and the clang are the correlating versions. [07:34] no /lib probs, etc [07:34] he's gonna need a temp ban. [07:35] it's still compiling.. === morphis|away is now known as morphis [07:36] morphis is away.. [07:36] no ops in here? [07:37] mir is 33% === gtklocke2 is now known as gtklocker [07:50] * RAOF wonders who has ops here === greyback|away is now known as greyback [09:45] good day [09:45] I was playing around with mir - got it from the ppa:mir-team/staging [09:46] it didn't install the unity-system-compozitor untill a couple of ours ago [09:46] then I forced it to get the latest mir-server that has been kept back [09:47] and now after a reboot I am stuck at the ubuntu loading screen [09:47] no login window [09:47] I've logged in and used 'startx' [09:47] and all seems to be fine [09:48] but I need it to work after the restart [09:48] I haven't changed the lightdm.cfg to start mir [09:48] so I'm a bit confused [09:48] can anyone help me ? === mmrazik is now known as mmrazik|afk [09:58] I'll be on a couple of hours [09:58] in case anyone here can help me [09:58] thanks in advance! [10:00] xrc I don't know what's happened on your system - FWIW mine runs fine without lightdm.cfg changes. But "forced it to get the latest mir-server" sounds like something I don't do. Could you expand on that? [10:00] alan_g, well, I was following this bug: https://bugs.launchpad.net/unity-system-compositor/+bug/1177722 [10:00] Launchpad bug 1177722 in Unity System Compositor "mir ppa : unity-system-compositor should be built against latest mir libraries" [High,Fix released] [10:01] alan_g, so today when I did a sudo apt-get update followed by sudo apt-get upgrade, all the packages seemed to install just fine [10:01] alan_g, I even got the unity-system-compositor installed [10:02] alan_g, then I noticed some packages that were not updated [10:02] alan_g, and they were libmirserver0 and mir-demos [10:03] alan_g, gimme a sec, I'll dig up the commands I used from history [10:05] alan_g, so basically I first did an update, then and upgrade [10:05] alan_g, it installed the new lightdm and unity-system-compositor and all that were not installed because of the bug above [10:05] xrc: that ought to work - you didn't override anything then? [10:06] alan_g, but it showed that libmirserver0 and mir-demos were held back [10:06] alan_g, so I forced them via 'sudo apt-get install libmirserver0 mir-demos' [10:06] * alan_g checks - he's not updated for a few days, so probably isn't running what's in the ppa today [10:08] alan_g, I guess the problem is that when I did force to install the new version - it killed lightdm (uninstall) [10:09] alan_g, and now lightdm can't be installed cause it tries to get the one from the mir server ppa, and that one won't install because of the broken dependencies issue [10:10] xrc: sounds possible. It is a development stack, and does break sometimes === ubot5` is now known as ubot5 [10:10] alan_g, how can I get the default lightdm from official ubuntu repositories to install? [10:13] xrc: Personally, I tend to reinstall to get to a known state. But it ought to be possible to force uninstalls and reinstalls with e.g. deselect (but when that doesn't work straight away it costs more time than a reinstall). [10:14] others here might have other ideas [10:15] alan_g, ok, I got lightdm reinstalled from the official ubuntu repositories [10:15] alan_g, now it's being held back from upgrade, because of the bug I mentioned before. This was the state of my machine for a few days ) [10:16] alan_g, as a side note - where can I register this nickname so when I'll log in into IRC on #ubuntu-mir it will represent only me? [10:17] xrc: http://freenode.net/faq.shtml [10:18] alan_g, thanks a lot! [10:18] xrc: yw === mmrazik|afk is now known as mmrazik === mmrazik is now known as mmrazik|afk === mzanetti is now known as mzanetti|lunch === mmrazik|afk is now known as mmrazik === alan_g is now known as alan_g|lunch === pete-woods is now known as pete-woods-lunch === mzanetti|lunch is now known as mzanetti === alan_g|lunch is now known as alan_g [13:42] alan_g: alf__ do we actually have blur algorithms in mir ? [13:42] kgunn: I'm not aware of any. (yet) [13:43] alan_g: go it...that's how i understood it "we may add" [13:44] * alan_g goes it [14:00] alan_g: :)) just saw it... [14:00] meant "got it" [14:03] kgunn: I guessed. Who wants a blur algorithm? [14:04] * alan_g wants the inverse - the "enhance" algorithm used on TV [14:05] alan_g: oh your team mates on the unity ui....talking about how qt's blur is expensive [14:05] and chatting as if they can just "try mir's" when it lands [14:05] :) [14:06] I guess that will be after they MP it. ;) [14:08] kgunn: what do they want to blur? [14:11] alf__: well, its more that design wants to blur ;) [14:12] alf__: at least 1 use case is the lock screen blur of the app behind it [14:12] which may very well be changing/updating visually [14:13] i think we'll prob end up doing semi-live blur (but not live as that's pretty expensive) [14:15] kgunn: sorry, had to reboot and missed your answer, could you repeat please? [14:15] alf__: well, its more that design wants to blur ;) [14:15] alf__: at least 1 use case is the lock screen blur of the app behind it [14:16] which may very well be changing/updating visually [14:16] i think we'll prob end up doing semi-live blur (but not live as that's pretty expensive) [14:17] we could call on nic-doffay for the algo work [14:21] kgunn: The shader/algo work is the least of our problems for blur :) It's how and where (in terms of the mir-unity stack) we integrate it that needs discussion. But let's leave that for when the time actually comes. [14:30] alf__: sure === mmrazik is now known as mmrazik|afk [14:37] alan_g, ping [14:38] kdub_: pong === alan_g is now known as alan_g|tea [14:56] kgunn, alf__ , there are other use cases for the blur: the hud, search results on the dash and media player.... just fyi ;) [14:57] swap use cases to uses [14:58] katie: ack [15:02] hey all, mp'd the swapper switcher, got partially through the new ipc capability, but got distracted by wanting to clean up some things [15:05] Morning! [15:05] g'morning al [15:05] l [15:06] im *almost* done d/l'ing mir, during the d/l, i got several gateway timeouts. how can i just get the files that didn't d/l? [15:07] anybody here? [15:08] secret_ninja: ?...you mean prebuilt bins? === alan_g|tea is now known as alan_g === mmrazik|afk is now known as mmrazik [15:12] its sort of funny how msh::Surface is a proxy class for ms::Surface, and has its own logic too [15:13] kgunn: im pretty sure source... [15:13] i can paste the line i used to get it, but i can't figure out what it is... [15:13] mk-build-deps --install --tool "apt-get -y" --build-dep debian/control [15:14] kdub_: I've questioning that for months. ;) [15:15] unless itis the bzr command.. not sure, guess ill have to wait for the d/l to finish.. was like 1.2 gigs. [15:17] secret_ninja: so you're downloading on the phone...yep....just suffer [15:17] secret_ninja: its just the build dependencies to build mir [15:18] alan_g, i'm tempted to clean up a bit... [15:18] how can you tell im d/l'ing on the phone? [15:18] i'll stop cleaning when the diff gets to be >1000 though :) [15:18] brb [15:19] kdub_: I've had related discussions with racarr recently, not sure if he's started something. Worth checking. [15:20] nothing yet :) [15:21] ah, ok. the first thing i'll probably hit is that ms::Surface has public member functions that aren't behind an interface [15:23] kgunn: question was, will i have to reget the whole source tree, or can i somehow just get the files that failed? [15:24] kdub_: also, ms::Surface has attributes for things that I think the shell should associate with the surface. [15:24] Get:152 http://us.archive.ubuntu.com/ubuntu/ raring/main texlive-font-utils all 2012.20120611-2 [1,681 kB] [15:25] secret_ninja: not sure how smart the tools are, i honestly don't know of any arg to ask for partial....but i would assume its smart [15:25] Err http://us.archive.ubuntu.com/ubuntu/ raring/main ttf-marvosym all 0.1+dfsg-2 [15:25] 504 Gateway Time-out [IP: 91.189.91.15 80] [15:25] crossing fingers.. ;0 [15:25] alan_g, right, i kinda detect that some shell state has been creeping in [15:29] kdub_: yeah, it is pretty unclear why it is there in that form - I'll be happy to see it cleaned up === mmrazik is now known as mmrazik|afk [15:33] secret_ninja: gonna have to run in a minute [15:33] but where are you trying to build ? [15:33] natively (on the phone) [15:33] or on your pc [15:34] secret_ninja: please keep the conversation in public as it might help others [15:35] alright. well, im not d/l'ing to my phone, im d/l'ing to my pc, using phone as gateway. [15:36] secret_ninja: what do you intend to do ? where do you want to compile ? [15:36] mostly seeing texlive right now, saw ruby earlier (in the download). it's a 1.2 G d/ll. prolly just going to restart the d/l after it is done and hope the tools are smart enough to just get the parts that failed.. [15:36] im going to compile on my pc.. [15:37] secret_ninja: ah...i get you now....so last one, emulated or cross compile ? [15:38] gotta run [15:38] am i in the correct place? going to run it on my pc as X replacement [15:38] nothing to do with phone.. [15:39] aight, have nice day. :) [15:39] I gess you are downloading the build depedencies? I don't know any magic to speed it up :) [15:40] not worried bout the time. worried bout several files that failed to d/l due to gateway timeout.. [15:40] d/l over 14 hours old. just woke up and saw several errors re: gateway timeout and d/l failures.. [15:41] only 94% done, but getting there [15:42] 1 line: https://code.launchpad.net/~robertcarr/mir/fix-default-surface-lock/+merge/166831 [15:45] p.s. if you are scared of deadlock mir_demo_server & sleep 45 && killall -9 mir_demo_server && chvt 7 is a great way to run mir [15:46] racarr: kgunn asked if i was going to build it natively, or on the pc, but im going to build it natively on the pc.. this is also supposed to run on pc's, right??? not just phones.. [15:46] Yep :) [15:46] uh-oh. [15:46] I think he thought you were building for the phone [15:47] so he was asking if you were cross compiling from PC or building [15:47] on phone [15:47] Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? [15:47] but its all good on desktop too :) [15:47] yes. [15:48] my d/l just quit on me with the above error..now i don't know what to do.. it was 94% and im *not* starting all over... anybody know where i put the --fix-missing option? [15:49] I don't think it will help [15:49] apt-get wont start all over [15:49] run apt-get update :) [15:49] apt-get won't start all over ("probably") [15:50] but it goes to apt-get I don't know how mk-build-deps calls that [15:52] phew, smart tools rock. [15:53] man, i was getting *so* pissy. glad it only has to get 90M this time.. [15:57] haha...I am just updating a test and one of the random test strings [15:57] is the song I am listening to now... [15:57] around and around...*facepalm* [16:06] secret_ninja: Keep in mind that you won't get anything really usable in terms of a desktop environment right now [16:19] Another small diff https://code.launchpad.net/~robertcarr/mir/improve-input-channels/+merge/166841 [16:26] racarr, good lead-in on the description :) [16:34] :) [16:34] thanks for quick review.. [16:35] trying to split out the ...4! things I found yesterday XD [16:36] kdub_: which egl implementation are we using in the android stack? I think I need to look at the code to figure out what's happening. [16:37] alan_g, i sort of want to answer 'egl 1.4', but don't know if thats what was being asked :) [16:38] kdub_: Probably the result of my thinking being unclear. [16:40] kdub_: for some reason, not obvious in mir code eglSwapBuffers() behaves differently with a CB mode server than a default one. But I'm not sure which repo to grab code from to look at. [16:41] well, to look at the egl code, its closed :( [16:42] /o\ [16:42] https://code.launchpad.net/~robertcarr/mir/fix-surface-stack-input-locking/+merge/166852 another smallish one [16:43] Maybe instead of the lock dance (there is another part of it coming up in the registrar) [16:43] alan_g, the interface the egl driver uses is in 3rd_party/android-deps/system/window.h [16:43] we should use r/w locks [16:43] i just wrote one! [16:44] a r/w lock? [16:44] racarr, yeah, in ~kdub/mir/swapper-swapper [16:44] its a writer biased one [16:45] kdub_: found that. OK, maybe tomorrow will bring inspiration. [16:45] mm interesting [16:45] what kind of bias do we want in the surface stack...I can almost convince myself either way [16:45] sounds more likely a reader bias right [16:46] who cares if we are updating a bunch if we never get to render [16:46] * alan_g remembers it is friday (and he's going to a dance) [16:46] Though something I learned from all the profiling on toyds [16:47] is that I have a 100% incorrect track record on guessing the effects of biased r/w locks :p [16:47] alan_g: Cheers :) enjoy [16:47] alan_g, maybe i'll write a mail about how to deal with the blob or something [16:47] there are a few inroads to investigate [16:47] r/w locks are tricky things [16:47] yeah [16:47] in toyds I had like [16:48] 10 different ideas for how I was convinced they were going to eliminate [16:48] probably why i didn't find a rw lock in the c++11 :) [16:48] all my contention and speed thing way up [16:48] and they all failed XD [16:48] kdub_: I think it is coming in C++14 [16:48] pthread has one [16:48] which I wonder if we should use over mutex/condition variable [16:49] I guess it's unbiased. [16:49] which is weird [16:49] kdub_: the absence of a rw lock in C++11 was deliberate [16:49] yeah, smarter to let people think hard about it for a while! [16:50] racarr, i had thought about that...but i said 'early optimization', and used the mutex/cv [17:01] kdub_: Good choice I think :) === alan_g is now known as alan_g|life [17:14] kdub_: racarr: I have pushed lp:~afrantzis/mir/client-lttng-wip in case you want to use it for any client/server measurements today. Have a great weekend! [17:15] alf__: Thanks! very cool cant wait to start getting full system input measurements [17:16] enjoy your weekend too :) [17:16] racarr: kdub_: don't forget to use: LD_PRELOAD=libmirclientlttng.so MIR_CLIENT_RPC_REPORT=lttng for the client [17:32] Sigh [17:32] this locking bit between the input and surface stack [17:32] is this huge like [17:32] hidden coupling [17:32] that can be commented or clarified [17:32] but I wish there were a clear way to express it in the API [17:32] I'm sure there is [17:32] I wish I could come up with it immediately [17:32] :p [17:37] racarr, i'm thinking in the same arena right now too [17:38] kdub_: Any ideas? [17:38] the one I am running in to, is for example this surface stack lock. Where the surface stack can't call out to the input registrar [17:38] while it's holding its own lock [17:39] because the input registrar, calls a function on the input dispatcher, which is locked by a lock that is shared with some InputDipatcher code run from another thread [17:39] that can block on the surface tack [17:39] But how can that be express in the API... [17:39] racarr, i'm currently driving out some coupling with some tests on the ms::Surface [17:39] which my hope is that it will chase out those sync issues [17:39] sometimes you can pass around a mutex to say you must have to hold a lock [17:40] but what's...the antipattern [17:40] lol [17:41] heh [17:43] you could pass [17:43] the mutex [17:43] and then the consumer has to be able to try_lock/unlock it [17:43] but that's [17:43] kind of absurd [17:50] https://code.launchpad.net/~robertcarr/mir/fix-input-registrar-locking/+merge/166864 [17:50] last one [17:50] :) [17:50] running the stress tests and thrashing the mouse around seems to work indefinitely [17:50] can i switch between X and mir with a reboot? [17:50] with all these [17:52] secret_ninja: You can without a reboot :) I'm not sure exactly what you are asking/expecting though [17:53] you can't run a full user session on mir yet (excluding XMir of course). Or at least not one that you could replace your desktop with [17:53] so normally we run mir on a vt and x on a vt and you can switch back and forth and everyone is happy :) [17:53] im *just* wanting to see what it looks like and how it runs. what apps it can use. and maybe help with development.. i dont know the status of the project, but want to play with it. [17:54] so, inside of Xwin, open an xterm and run mir.. ? [17:54] I understand :D [17:54] no from a virtual terminal, but you will want to run some clients too... [17:55] we can test one of the demo clients just to see if it's working [17:55] So, right now for VT switching to work you need to run it as root [17:55] ive worked in the industry for like 20 years as unix admin, was involved with original ide (intergrated drive electronics) hard drives at arcada software and seagate. [17:55] so in your mir build directory should have /bin/ [17:56] involved with linux since 94. [17:56] from a VT as root run bin/mir_demo_server [17:56] secret_ninja: Ehe great. I bet you have had lots of X headaches over the years ;) [17:56] then from another VT you can run say /bin/mir_eglplasma [17:56] (also as root, since Mir is root) [17:56] and switch back to the Mir VT [17:56] you should see some...flowing ubuntu colored plasma XD [17:57] I'm just about to run to the coffee shop though so be back in 5. [17:57] yea, multiple monitors, vid cards, serial terms (oh, the days of amber screens). [17:57] i gotta run to store also, ill bbl [17:57] cheer [17:57] s* [17:59] :) [18:01] gonna need lots of help, but also naturally good at puters. simple questions first. in build dir, run "cmake .." and it wants to use gcc. i would like to use clang [18:02] do i rename gcc and ln clang to gcc? [18:02] It's possibly fixed in clang trunk [18:02] but with clang from the packages there is a bug with their shared_ptr implementation [18:03] that prevents mir from running [18:03] secret_ninja: ^ [18:03] Sometimes we build with clang for the diagnostics, etc, you can ue [18:03] cmake .. CMAKE_CXX_COMPILER=/usr/bin/clang++ CMAKE_C_COMPILER=/usr/bin/clang [18:03] err [18:03] cmake .. -DCMAKE_CXX_COMPILER=/usr/bin/clang++ -DCMAKE_C_COMPILER=/usr/bin/clang [18:04] I heard you building clang and llvm earlier and thought of warning you but I thought maybe you were just building it for mesa XD [18:04] if you built clang from trunk, you should try running mir and then report back but quite possibly expect it to crash [18:04] a first step would be trying the tests with clang [18:04] you can run ctest [18:04] and if it fails, inspect individually /bin/unit-tests /bin/integration-tests /bin/acceptance-tests [18:04] ./bin* [18:06] aight, wasnt sure if i could set a variable for it or something.. :) i have clang from repository in /usr/bin/clang and have src for clang, but after i did the make for llvm, i couldn't find clang, that's when i did apt-get for it. [18:09] ah [18:09] yeah wont work sorry :( [18:10]