| racarr | namespace mgeglm = mir::graphics::egl::mesa? | 00:01 |
|---|---|---|
| racarr | I just wanted to share how happy I was to type mgeglm | 00:01 |
| RAOF | ??? | 00:17 |
| racarr | RAOF: I just think it's a funny combination of letters | 00:43 |
| racarr | ignore me... | 00:43 |
| RAOF | No, that just seems like a surprisingly nested namespace. | 00:43 |
| smspillaz | racarr: hmm, this could get fun | 00:58 |
| RAOF | smspillaz: What are you up to? :) | 00:59 |
| smspillaz | namespace compiz::objects::central::keyboard | 00:59 |
| racarr | I don't get it ;) | 00:59 |
| RAOF | :P | 00:59 |
| smspillaz | RAOF: me? mostly eating popcorn | 01:00 |
| duflu | robert_ancell: We have logs if you're interested :) https://bugs.launchpad.net/mir/+bug/1109957 | 01:29 |
| ubot5 | Launchpad bug 1109957 in Mir "lightdm with type=mir causes raring to freeze on boot. plymouth stuck at 100% progress." [Critical,New] | 01:29 |
| robert_ancell | duflu, ta | 01:31 |
| duflu | Wow, seems Alexandros likes to finish things without any fanfare. This is now DONE(!): https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-glmark2 | 01:36 |
| duflu | Except that we can't get any useful numbers out of it till we fix Mir's eglSwapInterval(0) | 01:36 |
| robert_ancell | duflu, can you look out for a notification for "TEST BUG" against Mir? | 02:32 |
| duflu | robert_ancell: Could you please update the subscription to ensure mir-team gets bug comments too? | 02:32 |
| robert_ancell | duflu, did that before this | 02:32 |
| robert_ancell | comments? | 02:32 |
| robert_ancell | I think people should opt-in for comments | 02:32 |
| duflu | robert_ancell: I disagree. Someone has to answer comments. And if the dev team has not subscribed then that will usually be no one | 02:33 |
| robert_ancell | no, that's just spamming people. If you want to do that then subscribe yourself. Otherwise people should only subscribe to bugs that are relevant to them | 02:34 |
| duflu | robert_ancell: Umm, Mir bugs are relevant to Mir developers. More generally developers need a kick in the pants to pay more attention to their own bugs | 02:35 |
| robert_ancell | duflu, you are automatically subscribed to your own bugs, and you can subscribe people to bugs you think they should look at | 02:35 |
| duflu | robert_ancell: "own bugs" means bugs you caused, not logged | 02:36 |
| robert_ancell | duflu, then subscribe them when you read it | 02:36 |
| robert_ancell | duflu, bugs can easily become a distraction from actual work - the goal is not to empty the bug tracker | 02:36 |
| duflu | robert_ancell: True, but you can't release anything if you have a pile of High's and Criticals | 02:37 |
| robert_ancell | you can | 02:37 |
| === jono is now known as Guest2834 | ||
| * duflu is scared at that prospect | 02:37 | |
| robert_ancell | duflu, it depends who set them to high and critical - we have an open tracker | 02:39 |
| duflu | robert_ancell: It's not meant to be a matter of opinion. There are clear definitions of the severities here: https://wiki.ubuntu.com/Bugs/Importance | 02:42 |
| duflu | Though that's not to say those are followed accurately | 02:42 |
| robert_ancell | duflu, bingo | 02:44 |
| smspillaz | robert_ancell: I get the impression that this page is good for determining bug severity if you're a kernel | 02:53 |
| smspillaz | it would be good to have bug guidelines per-project | 02:53 |
| duflu | It's hard enough having one standard. I'm not sure we want multiple standards | 02:53 |
| smspillaz | sure, its just that the examples are not very applicable to some projects | 02:54 |
| smspillaz | "causes data corruption" <- let me know when that happens in a display server | 02:54 |
| RAOF | We can *totally* do that. | 02:55 |
| smspillaz | RAOF: was that a challenge accepted ? | 02:55 |
| RAOF | We just need to set up the GPU memory maps appropriately :) | 02:55 |
| smspillaz | RAOF: I think that's fudging with the definition of "data" | 02:55 |
| duflu | Surely you can mmap some memory to an important file | 02:56 |
| smspillaz | right, I just didn't think that fell within the usecase of a display server | 02:56 |
| RAOF | Set the GPU memory maps appropriately so that they overlap with the kernel's VFS cache. | 02:56 |
| smspillaz | RAOF: oh, heh | 02:56 |
| duflu | Evil | 02:56 |
| smspillaz | RAOF: does mir run as root ? | 02:57 |
| RAOF | I don't think we know. | 02:57 |
| smspillaz | (its a stupid question, I've not run it in months) | 02:57 |
| smspillaz | haha | 02:57 |
| smspillaz | yikes | 02:57 |
| duflu | smspillaz: Not normally, but it can | 02:57 |
| RAOF | The system-compositor probably will, but the sessions won't. | 02:57 |
| smspillaz | you guys are going to have lots of fun | 02:57 |
| RAOF | Of course! | 02:58 |
| robert_ancell | duflu, you had a branch that was going to add a mircommon-dev right? What happened to that? | 03:22 |
| duflu | robert_ancell: It landed. And I see it in the PPA already | 03:22 |
| robert_ancell | duflu, oh right, I hadn't updated | 03:22 |
| duflu | robert_ancell: Is it bad for lightdm that mir has no upstart config? | 03:31 |
| robert_ancell | duflu, mir is started by lightdm so upstart is not involved | 03:32 |
| duflu | robert_ancell: Fair enough. But there is often a small delay in the socket becoming available. Does lightdm sleep a little before looking for it? | 03:32 |
| duflu | Or poll for it and eventually time out? | 03:33 |
| robert_ancell | duflu, yeah, there's a hack currently but we will need the system compositor to notify lightdm when the socket is ready | 03:33 |
| robert_ancell | poll | 03:33 |
| duflu | Damn. No easy explanations | 03:33 |
| duflu | You and your forethought | 03:34 |
| robert_ancell | the way X does this is using a unix signal. We can easily pick that up, though it's a bit yuck. The cleaner way is to pass a fd to the compositor and have it write to it when ready | 03:34 |
| duflu | robert_ancell: Signals sound might simpler. Why yuck? | 03:34 |
| duflu | -might +much | 03:35 |
| robert_ancell | duflu, because they're kind of hard to handle in the receiver. But we have all the work for X done so we can live with it | 03:35 |
| robert_ancell | also potentially we want more information than a signal can provide | 03:35 |
| duflu | I guess a signal necessitates knowing a process ID to send to :( | 03:36 |
| robert_ancell | duflu, children can emit a signal on themselves and the parent picks it up | 03:36 |
| RAOF | We want to pass an fd from lightdm to the system-compositor *anyway*; we might as well signal readiness on it. | 03:37 |
| tvoss | RAOF, ping | 06:03 |
| RAOF | tvoss: Pong. | 06:03 |
| tvoss | RAOF, good afternoon :) quick question about hw cursors: do we have a work item for that? | 06:04 |
| RAOF | Hm. I suspect that we might want a parallel server-side buffer age so we can optimise out sending buffers we know the client has. | 06:04 |
| RAOF | tvoss: Heh. Yes, someone set alf_ as owning that work item today. | 06:05 |
| RAOF | client-1303-mir-converged | 06:05 |
| tvoss | RAOF, cool, we have the first iteration of input mostly landed, and rendering a cursor might prove helpful :) | 06:05 |
| RAOF | We don't have keyboard input landed at all, right? | 06:06 |
| tvoss | RAOF, an english keyboard should work :) | 06:06 |
| tvoss | RAOF, ah, just observing your comments on receive-input-in-client | 06:07 |
| RAOF | What about https://code.launchpad.net/~robertcarr/mir/receive-input-in-client/+merge/155368 | 06:07 |
| tvoss | RAOF, that's what I was referring to, I thought it had landed yesterday | 06:08 |
| RAOF | :) | 06:08 |
| tvoss | RAOF, anyway, once that lands, generic keyboard support is there. Then keymapping is the next topic | 06:11 |
| RAOF | Cool. | 06:11 |
| RAOF | daniels will be interested to hear where libkeymap fails to support our needs :) | 06:12 |
| tvoss | RAOF, I guess not at all :) we just need to take a look at it | 06:14 |
| tvoss | RAOF, got a link for me? | 06:14 |
| RAOF | It's libxkbcommon :) | 06:16 |
| tvoss | RAOF, I'm confused now :) | 06:16 |
| RAOF | He was just complaining that he mis-named it, and it should really be called libkeymap. | 06:16 |
| tvoss | RAOF, I guess I'm all in for that | 06:16 |
| tvoss | mmrazik, I was wondering if there is any documentation on fence_cdu | 06:38 |
| mmrazik | tvoss: do you have account on magners? | 06:39 |
| tvoss | mmrazik, not sure :) | 06:39 |
| mmrazik | tvoss: let me pastebin --help | 06:39 |
| mmrazik | I don't think there is much more than that. Maybe something on wiki.canonical.com | 06:39 |
| tvoss | mmrazik, ack | 06:39 |
| mmrazik | tvoss: http://pastebin.ubuntu.com/5651494/ | 06:40 |
| mmrazik | tvoss: its a python script so I guess we can modify if need something | 06:40 |
| tvoss | mmrazik, ack | 06:41 |
| mmrazik | and I _think_ (didn't check) its using ssh to access the power strips | 06:41 |
| tvoss | mmrazik, I was thinking about writing a google test fixture for setting up the multi-monitor setup | 06:41 |
| RAOF | Huh. GTest really does call *0 = 1; to die in this case. | 06:48 |
| RAOF | Grr. What the hell, gdb? | 06:55 |
| tvoss | RAOF, what's up? | 06:56 |
| RAOF | My changes to not leak fds in GBMClientBuffer have broken the acceptance-tests; a couple of them now segfault. | 06:57 |
| RAOF | However, for some reason gdb doesn't seem to find DefaultDisplayServerTestFixture_client_library_accesses_and_advances_buffers::TestBody(), so I can't attach gdb at the right place. | 06:58 |
| RAOF | Because obviously I need to be tracing the _child_, which means I need to set follow-fork-mode just before it forks. | 06:59 |
| duflu | RAOF: gdb doesn't find it cos it's in a child process. You need to enable tracing into childten | 06:59 |
| duflu | *children | 06:59 |
| duflu | Yeah what you said | 06:59 |
| * RAOF → Zoë bath; back later to be annoyed at gdb further. | 07:00 | |
| * duflu reverts the day's work and starts again. Lost in class dependency spaghetti | 07:00 | |
| RAOF | Hah. Don't accidentally recurse infinitely. | 07:55 |
| RAOF | Hm, no, that's not going to work. Looks like I really do need to make the server not uselessly send buffers the client already has. | 07:59 |
| RAOF | kdub: Hey, you send fds for buffers out over the wire - how come android clients don't crash after not very long for exhausting their fd space? | 08:09 |
| duflu | RAOF: I believe it's past 1am for kdub | 08:11 |
| RAOF | Yeah, that would be right. | 08:12 |
| RAOF | He's on in our *morning* :) | 08:12 |
| * RAOF suspects the answer to his question is ‘if we had any non-trivial demo clients, they *would* crash after not very long by exhausting their fd space’ | 08:12 | |
| duflu | Heh | 08:13 |
| duflu | In time | 08:13 |
| === alan_g is now known as alan_g|afk | ||
| === alan_g|afk is now known as alan_g | ||
| duflu | Night all | 10:47 |
| === mmrazik is now known as mmrazik|afk | ||
| alf_ | alan_g: @composite-on-demand, what do you think about on_change_call(...) instead of e.g. set_change_callback(...) | 12:38 |
| alf_ | alan_g: or on_changed_call() | 12:38 |
| alan_g | alf_: this is actually a case where I tend like "set" - largely because it isn't otherwise clear that it overwrites any existing callback (as opposed to "add...") | 12:40 |
| alan_g | alf_: but I think any of the above would be an improvement | 12:41 |
| alf_ | alan_g: ok | 12:42 |
| alan_g | alf_: there's also "on_change_invoke()" | 12:43 |
| smspillaz | install_change_callback () is another potential one I guess | 12:53 |
| alf_ | alan_g: smspillaz: I like how render_view.on_change_invoke(...) reads, but I will go with set_change_callback() since its semantics are clearer | 12:54 |
| smspillaz | +1 | 12:54 |
| alf_ | smspillaz: I think install_change_callback() suffers from the same problem (as discussed above) | 12:55 |
| smspillaz | yeah I was thinking that too | 12:56 |
| === alan_g is now known as alan_g|lunch | ||
| kgunn | alf_: are the gl bench #s being dumped somewhere to show a trend chart? or are they individually buried in jenkins test results? | 13:24 |
| alf_ | kgunn: I don't think there is a job for running glmark2 on mir, just on a traditional ubuntu system, but I don't know where the results end up. | 13:36 |
| === alan_g|lunch is now known as alan_g | ||
| kdub | morning | 15:07 |
| alan_g | Hello! | 15:09 |
| kdub | status, working on integrating hwc device, hit a snag where (i think) the gpu clocks are not turned on all the way | 15:11 |
| alan_g | status: got run_mir working properly, MP's a better MessageProcessorReport, and started wondering about glog again | 15:13 |
| kdub | alan_g, yeah, waiting to clear that needs fixing on the scripts change :/ | 15:14 |
| * alan_g nags kdub | 15:15 | |
| alf_ | status: Amending composite-on-demand MP, started investigating mir shutdown regression (i.e. we don't return to a properly configured console sometimes) | 15:23 |
| === alan_g is now known as alan_g|afk | ||
| === alan_g|afk is now known as alan_g | ||
| sturmflut | What is the status of the input subsystem? I read in the commit logs that input events are now passed down to the client, but how much of the whole system is implemented? Would it be possible to write a demo client which accepts keyboard/mouse events? | 15:47 |
| smspillaz | sturmflut: ask racarr when he wakes up | 15:50 |
| alan_g | sturmflut: we're getting closer - racarr is the one to ask | 15:50 |
| sturmflut | smspillaz, alan_g: Okay | 15:50 |
| smspillaz | racarr: wake up! | 15:50 |
| sturmflut | haha | 15:51 |
| smspillaz | he'll probably be around in 10 minutes :) | 15:51 |
| smspillaz | sturmflut: if I end up moving to SFO later this year for a possible internship I'll make sure to knock on his door | 15:52 |
| tvoss | sturmflut, once the last branch lands: yes, you could start writing a client. racarr actually planned something cool :) | 15:54 |
| tvoss | sturmflut, but best talk to him | 15:54 |
| sturmflut | I also noticed that my minimal client has to #include <mir/client/mir_toolkit/mir_client_library.h> but the /usr/include/mir/client/mir_toolkit/mir_client_library.h header file provided by the PPA packages tries to #include "mir_toolkit/c_types.h" which does not work. Is this because the Header files are still being shuffled around? | 15:55 |
| tvoss | sturmflut, I'm pretty sure that is the reason, yes | 16:00 |
| tvoss | alan_g, can you look into what sturmflut just mentioned? | 16:00 |
| alan_g | sturmflut: I too am a bit confused about what's happening there. (It isn't what I expect.) Can you temporarily add [/usr/include/]mir/client to your project include path. | 16:00 |
| alan_g | tvoss: I discussed it with robert_ansell yesterday and was assured it does work. But it seems I'm not the only one of a different opinion. | 16:01 |
| tvoss | alan_g, ack. sturmflut can you file a bug please? | 16:02 |
| sturmflut | alan_g: If i add it to my include path it works, as one would expect. | 16:02 |
| alan_g | sturmflut: use that as a workaround. (But please raise the bug.) | 16:03 |
| sturmflut | alan_g: Will do | 16:03 |
| alan_g | kdub: tvoss kgunn (anyone interested) I'm creating a canonical [no pun intended] example of a useful logging reporter. I'd appreciate comments on https://code.launchpad.net/~alan-griffiths/mir/improved-MessageProcessorReport/+merge/155746 | 16:08 |
| === alan_g is now known as alan_g|vt | ||
| === alan_g|vt is now known as alan_g | ||
| racarr | I exist | 16:45 |
| racarr | smspillaz: :) | 16:45 |
| racarr | sturmflut: It's possible to write a demo client which receives keyboard events using the outstanding event ~robertcarr/mir/receive-input-in-client | 16:46 |
| racarr | your guess of the status in trunk so far is good though, input is sent up to clients | 16:46 |
| racarr | but not all received yet | 16:46 |
| racarr | (and pointer input isnt finished) | 16:46 |
| katie | hi racarr | 16:58 |
| racarr | Hi katie | 16:59 |
| katie | how's things? want to have a catch up? | 16:59 |
| racarr | things are good, not sure I have anything | 17:00 |
| katie | me neither | 17:00 |
| racarr | katie: Ok let's skip this week then | 17:02 |
| katie | racarr: great | 17:02 |
| katie | i mean, i love our meetings, but good to have some time back :) | 17:03 |
| racarr | katie: I feel the same :) | 17:03 |
| racarr | actually right now I feel very little other than disdain for android::Looper but if I had normal feelings that would be it | 17:04 |
| racarr | status: Iterating on receive-input-in-client...tried to port the client side input machinery to android::Looper to get rid of the short timeouts | 17:05 |
| racarr | (plus fixing RAOF's other comments) | 17:05 |
| racarr | got it "working" but acceptance tests fails intermittently with the looper on the client side | 17:05 |
| kdub | drivers work better when they don't load their firmware all the time | 17:05 |
| racarr | then back to finishing off inprocess EGL branch from yesterday | 17:05 |
| tvoss | racarr, can you put a fixme there that notes down that we ideally want to associate it to the same event loop | 17:05 |
| tvoss | kdub, ? :) | 17:06 |
| racarr | kdub: Actually mythbusters did a show on that, drivers work best when loading their firmware all the time! | 17:06 |
| racarr | :p | 17:06 |
| racarr | tvoss: What do you mean? | 17:06 |
| racarr | i.e. assosciate all input and everything else to the same event loop? | 17:06 |
| kdub | tvoss, just a fun bug i caused during hwc development | 17:08 |
| tvoss | kdub, ah :) | 17:08 |
| tvoss | racarr, we have a looper in the client api anyway, it's an io_service. We might want to reuse that for the input channel, too | 17:09 |
| racarr | tvoss: Boost::asio is not a good replacement for epoll I think as we saw in | 17:10 |
| racarr | Looper.h | 17:10 |
| racarr | well | 17:10 |
| racarr | I dunno it can be adapted of course | 17:11 |
| tvoss | racarr, I do disagree, I think it's a very sane replacement, it just does not fit the Looper model or we haven't looked into it deeply enough | 17:11 |
| tvoss | racarr, just leave a note in the code :) | 17:11 |
| kdub | RAOF, to answer the backscroll... we don't exhaust the fd space because the kernel keeps a mapping of pid's to fd's and pops the same one out on the client side on every message | 17:14 |
| racarr | so weird...the android::Looper version of the client, sometimes it indefinitely hangs in pollOnce in the acceptance test | 17:29 |
| racarr | if I add the fd to the looper in the first call to next_event instead of in the constructor | 17:29 |
| racarr | it never fails (well, out of 1000 runs, whereas the other failed ~1/10) | 17:29 |
| racarr | what is happening...-.- | 17:30 |
| alan_g | racarr: when things don't make sense it is time to look at something else for 20min | 17:31 |
| racarr | alan_g: You mean instead of continuing to blunder around in nonsense? Novel idea. | 17:41 |
| alan_g | I mean that breaking focus helps see what you missed | 17:42 |
| alan_g | racarr: ^ | 17:42 |
| === alan_g is now known as alan_g|life | ||
| racarr | alan_g|life: Hehe I know what you mean :) | 18:08 |
| sturmflut | alan_g|life: https://bugs.launchpad.net/mir/+bug/1161064 | 18:51 |
| ubot5 | Launchpad bug 1161064 in Mir "Mir client header files seem to be incorrect" [Undecided,New] | 18:51 |
| racarr | sturmflut: Thanks! I am about to go on lunch | 18:58 |
| racarr | but I will process that later today...I think you are right! | 18:58 |
| sturmflut | racarr: Input processing on the server side currently concentrates on Android, am I right? Or is there a branch which handles other platforms | 18:58 |
| racarr | so we should just land a fix asap | 18:58 |
| racarr | sturmflut: No it works on desktop | 18:58 |
| racarr | some of the naming is misleading because it uses | 18:58 |
| racarr | large pieces of the android input stack :) | 18:58 |
| sturmflut | ah | 18:58 |
| racarr | so the mir::input::android namespace is the android-input based implementation of mir::input but not the android...platform? | 18:59 |
| racarr | confusing...need better names :) | 18:59 |
| racarr | sturmflut: https://code.launchpad.net/~robertcarr/mir/receive-input-in-client/+merge/155368 if you look aronud l363 you can see an example using it :) | 19:00 |
| racarr | got distracted by finishing inprocess egl XD...just need to find the right abstraction for the display validation now and should be good to go | 19:24 |
| racarr | but now lunch for real | 19:24 |
| === racarr is now known as racarr|lunch | ||
| robert_ancell | tvoss, hello | 20:02 |
| tvoss | robert_ancell, hey there :) | 20:02 |
| tvoss | robert_ancell, wanna sync up? I have got nothing urgent on my side | 20:02 |
| robert_ancell | tvoss, yeah, just a quick one | 20:02 |
| tvoss | ack, gimme two :) | 20:02 |
| === ernsthaft_ is now known as sturmlfut | ||
| === sturmlfut is now known as sturmflut | ||
| kdub | meeting "mir team 2"? | 21:02 |
| RAOF | Yeah, for those of us for whom “mir team 1’ was stupid'o'clock. | 21:02 |
| kgunn | kdub: RAOF :) happening now | 21:04 |
| RAOF | kdub: Is that pid→fd mapping an android-specific thing? Because when *I* send fds over the pipe I get a shiny new one each time at the client. | 21:48 |
| kdub | might be, surfaceflinger does the same thing with its binder transactions | 21:49 |
| kdub | i can look into it, maybe its an android kernel thing | 21:50 |
| RAOF | Eh. | 21:50 |
| RAOF | I'm going to fix things up so we don't send needless fds, so it doesn't really matter. | 21:51 |
| kdub | that would be better | 21:51 |
| robert_ancell | RAOF, how are you for pkg-config/include directories? | 22:30 |
| RAOF | robert_ancell: You mean, would I like to weigh in on the include-directory-structure thread, or do I have enough headers? | 22:32 |
| robert_ancell | RAOF, I just need a second opinion on https://code.launchpad.net/~robert-ancell/mir/mir-common-headers/+merge/155660 - This is just standard stuff to me or is it confusing? | 22:32 |
| sturmflut | CMake Error at cmake_install.cmake:44 (FILE): | 23:11 |
| sturmflut | file INSTALL cannot find "/mnt/datengrab/mir/build/doc/html". | 23:11 |
| sturmflut | What the heck | 23:11 |
| sturmflut | As of lately all accelerated clients segfault in XGetXCBConnection () from /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 . I tried it with the packages from the PPA and by building Mir manually. Happens with the included examples and glmark2. The unaccelerated demo client still works. | 23:18 |
| RAOF | sturmflut: You need to have doxygen installed for make install to work. | 23:29 |
| RAOF | sturmflut: We should probably fix that :) | 23:30 |
| sturmflut | RAOF: doxygen is installed | 23:30 |
| RAOF | Hm. Was it installed when you first ran cmake? | 23:30 |
| RAOF | Oh, you might *also* have to specifically enable docs. | 23:30 |
| sturmflut | RAOF: Yes, I even wiped the whole build/ folder and ran cmake again | 23:30 |
| RAOF | sturmflut: Segfault in XGetXCBConnection means that Mesa hasn't detected the right EGL platform, and has uselessly defaulted to X11 which segfaults if you're not *in* X11. | 23:31 |
| RAOF | sturmflut: We've recently gone through a transition for mesa which would have caused that, but the mesa in github (and I hope the PPA by now) should work with Mir trunk. | 23:31 |
| sturmflut | RAOF: On the doc issue: I had to manually set BUILD_DOXYGEN to ON, then it worked | 23:32 |
| sturmflut | Dunno why it was off in the first place | 23:32 |
| RAOF | Because we hate you, I think :) | 23:33 |
| sturmflut | Thank you, sir, I will remember that | 23:33 |
| RAOF | We should really fix that. | 23:33 |
| RAOF | To either (a) turn on the docs automatically when doxygen is installed, or (b) not fail to install when the docs haven't been built. | 23:33 |
| RAOF | Or possibly even (c) both of the above. | 23:33 |
| RAOF | Equally, Mesa defaulting to the X11 EGL platform is stupid and should be fixed. | 23:34 |
| sturmflut | How do I find out if my Mesa package is on par with the github version? Seems like most of my Mesa packages are version 9.1~rc2-0ubuntu0+mir2-jenkins17 | 23:36 |
| RAOF | sturmflut: Hm. Mesa in the PPA hasn't been rebuilt since the changes landed in github, so it won't work. | 23:36 |
| RAOF | thomi: How do we prod jenkins to build & upload a new mesa? | 23:37 |
| thomi | RAOF: to a PPA you mean? It should happen automatically as part of the autolanding process | 23:37 |
| * thomi investigates | 23:38 | |
| RAOF | thomi: mesa isn't autolanded. | 23:38 |
| thomi | ahh, in that case, It's probably as simple as rebuilding a jenkins job | 23:38 |
| thomi | RAOF: http://10.97.0.6:8080/job/mesa-egl-platform-mir-raring-dput/ was last run 20 days ago - does that sound about right? | 23:39 |
| RAOF | That'd match the timestamp in the PPA; there are new changes in the git branch though that'll make sturmflut's mesa actually work, though. | 23:39 |
| thomi | ahh, I see the git polling script is throwing an error, I'll rebuild it manually for now, and look in to why it's failing | 23:40 |
| sturmflut | Now this is what I call Platinum Support | 23:40 |
| cgoldberg | gource visualization of Mir codebase: http://youtu.be/7grEFrTBzus | 23:43 |
| thomi | RAOF: OK, the problem is that the git plugin we're using in jenkins is rather old, and requires a workspace on the slave (which isn't available). I'll file and RT to upgrade the plugin to a newer version, where this issue is fixed | 23:45 |
| sturmflut | cgoldberg: Looks nice | 23:47 |
| RAOF | Yeah, very puurdy. | 23:47 |
| cgoldberg | sturmflut, i love making visualizations when I'm bored... just popped in to have a look at Mir :) | 23:48 |
| kdub | cool cgoldberg | 23:51 |
| sturmflut | thomi: Is it safe to build my own Mesa from github? Or should I wait for the packages | 23:56 |
| thomi | sturmflut: I don't know about "safe", sorry. those packages have been dput'ed, so they shouldn't be too far away | 23:57 |
| thomi | sturmflut: you can see the build progress here: https://launchpad.net/~mir-team/+archive/staging/+packages | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!