[19:19] <harlowja> smoser hopefully the commit should be ok now :-p
[19:19] <harlowja> can do schema stuff later
[19:19] <harlowja> u think schema stuff way to go?
[19:33] <smoser> harlowja, i like the 'validate'
[19:33] <smoser> and i'm fine with 'json-schema'
[19:33] <harlowja> cool
[19:33] <smoser> a module wouldn't have to use json-schema
[19:33] <smoser> but probaly would
[19:33] <smoser> (and could run the schema and then further test some stuff in its validate)
[19:34] <smoser> you tihnk it seems sane ? i hope?
[19:34] <smoser> and did you look at the opennebula stuff ?
[19:34] <smoser> i'm really leaning towards just pulling their stuff in.
[19:34] <harlowja> haven't check opennebula stuff recently
[19:34] <harlowja> :-/
[19:34] <harlowja> ya, no need for module to use json-schema, just provide its own validate() method
[19:34] <harlowja> that the cloud-init stages can call before running
[19:35] <smoser> why's it called 'json schema' ?
[19:35] <smoser> really its just 'dict, list, string, int' schema
[19:35] <smoser> right?
[19:36] <harlowja> ya
[19:36] <harlowja> :-p
[19:36] <harlowja> got me, i guess the RFC is for json , but not really limited to
[19:36] <harlowja> http://json-schema.org/
[19:37] <harlowja> sorry, not RFC, ' IETF published draft '
[19:37] <harlowja> *whatever that is, ha
[21:04] <smoser> harlowja,
[21:04] <smoser> http://paste.ubuntu.com/6085177/
[21:04] <smoser> adding that
[21:07] <smoser> harlowja, is there a better way to read /sys ?
[21:07] <smoser> should i use read_file_or_url there ?
[21:07] <smoser> for mocking / wrapping / test purposes
[21:09] <smoser> harlowja, please think, respond, and i'll update and merge your code and then we'll have "random seed" support on azure too
[21:09] <smoser> wee!
[21:15] <harlowja> haha
[21:16] <harlowja> weee
[21:18] <harlowja> smoser why not just load_file ?
[21:18] <harlowja> u can still mock load_file ot
[21:18] <harlowja> *out
[23:29] <smoser> duh. load_file. yeah.


 How did intel work?
[01:49] <RAOF> Because I do call xmir_submit_rendering_for_window there.
[01:50] <RAOF> robert_ancell: So, there'll be radeon -MM3 and nouveau -MM3 that are more likely to actually work in the PPA soon :)
[01:50] <robert_ancell> RAOF, cool, I'll give Jenkins a kick when they're ready
[01:59] <robert_ancell> does anyone know how we disable ppc builds of mir?
[01:59] <robert_ancell> Because u-s-c is waiting for libmirserver-dev to appear for PPC, and that's never going to happen
[02:00] <RAOF> robert_ancell: I think you need to modify the Architecture of u-s-c, right?
[02:01] <robert_ancell> RAOF, ah, true - thanks!
[02:02] <smspillaz> argh
[02:03] <smspillaz> australia tax
[02:03] <RAOF> ?
[02:03]  * RAOF needs to get his tax in order; there should be a juicy refund out of it.
[02:03] <smspillaz> RAOF: I need to buy new headlights for my car
[02:03] <smspillaz> there's like a 200% markup over shipping them from the UK
[02:03] <robert_ancell> RAOF, for your good deed, I present you with https://code.launchpad.net/~robert-ancell/unity-system-compositor/same-arch-as-mir/+merge/182240 in return
[02:04] <smspillaz> RAOF: but the shipping cost kinda negates buying them from there
[02:05] <RAOF> Oh, australia tax. Right.
[02:05] <smspillaz> RAOF: its like 7 pounds vs $AUD35
[02:05]  * RAOF now gets it.
[02:05] <robert_ancell> smspillaz, yeah, we get that too
[02:05] <robert_ancell> though, does Australia allow parallel imports?
[02:06] <RAOF> Starting to more, yh.
[02:06] <smspillaz> RAOF: I think so. Its more just the RRP here is much higher
[02:06] <smspillaz> erm, robert_ancell
[02:06] <robert_ancell> yeah, we're in the same boat there
[02:09] <RAOF> robert_ancell: Do we build mir on arm64?
[02:10] <robert_ancell> RAOF, copy and paste says yes
[02:10] <robert_ancell> perhaps it's just ignored for now
[02:10] <RAOF> Ok then.
[02:22] <thomi> hey RAOF, when you get a moment, I wonder if I could ask for your help with an X11 issue I'm having?
[02:23] <thomi> errr, not work related :-/
[02:23] <RAOF> thomi: Sure.
[02:51] <robert_ancell> RAOF, qa-testing2 is good for ati/nouveau testing?
[03:17] <RAOF> robert_ancell: qa-testing2 is good for ati/nouveau testing.
[03:33] <RAOF> Lunch time!
[03:57] <robert_ancell> RAOF, two of the radeon machines have completed on Jenkins, which is good
[03:57] <robert_ancell> RAOF, and confirmed that VT switching doesn't drop focus, :(
[04:32] <rsalveti> mir doesn't like my radeon :-(
[04:34] <rsalveti> [    34.161] (EE) Failed to map vb -2
[04:35] <rsalveti> that's the only error from xorg
[04:35] <robert_ancell> rsalveti, from ppa:mir-team/system-compositor-testing?
[04:35] <rsalveti> from dmesg: http://paste.ubuntu.com/6031250/
[04:35] <rsalveti> robert_ancell: yes
[04:35] <robert_ancell> rsalveti, yeah, ati and nouveau don't work in there yet
[04:36] <rsalveti> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV620/M82 [Mobility Radeon HD 3450/3470]
[04:36] <rsalveti> anything I can do for better debugging or a confirmed issue already?
[04:37] <robert_ancell> rsalveti, you could try the MM3 xserver-xorg-video-ati package from https://launchpad.net/~mir-team/+archive/qa-testing2
[04:38] <robert_ancell> that's the PPA we copied to ppa:mir-team/system-compositor-testing. It has updated ati and nouveau drivers
[04:38] <rsalveti> cool, let me give that a shot
[04:39] <robert_ancell> kgunn, RAOF, I think we should copy in the ati/nouveau drivers into the system-compositor-testing PPA given the existing ones don't work - any reason not to?
[04:42] <rsalveti> alright, let me try another reboot :-)
[04:42] <rsalveti> brb
[04:47] <tvoss__> duflu_, ping
[04:47] <tvoss__> olli_, ping
[04:51] <rsalveti> yeee, progress
[04:51] <rsalveti> robert_ancell: with mm3 I works better
[04:51] <rsalveti> I'm using xmir now, but while it works, had to use xfce
[04:51] <rsalveti> unity fails to load it seems
[04:51] <rsalveti> and it's quite a bit slower
[04:52] <duflu_> tvoss__: pong?
[04:54] <duflu> to the luncheon
[04:57] <robert_ancell> RAOF, looks like the new nouveau driver didn't work on Jenkins
[05:00] <rsalveti> cool, now with unity
[05:00] <rsalveti> just took a bit more to load, not sure why it failed when I tried it the first time
[05:01] <rsalveti> so it seems ati is working with mm3
[05:01] <rsalveti> at least single-monitor
[05:39] <RAOF> Why does no store in Hobart stock mDP → DP cables?
[05:39] <duflu> rsalveti: If you get the failure again, please take a copy of ~/.xsession-errors before logging out/in again and log a bug
[05:39] <duflu> RAOF: apple.com.au ?
[05:39] <duflu> That's what I use
[05:49] <RAOF> duflu: Apparently apple.com.au don't have mDP → DP cables?!
[05:49] <duflu> RAOF: Yeah just noticed. Only mDP to DVI
[05:50] <duflu> RAOF: Shipping from Perth :)  http://ple.com.au/ViewItem.aspx?InventoryItemID=609956&CategoryID=427
[05:51] <RAOF> I've ordered https://www.google.com.au/shopping/product/7302603727339146726?gs_rn=25&gs_ri=psy-ab&tok=z0nEokW4iYZnceCF5gU2YA&ds=sh&pq=google+shopping&cp=22&gs_id=2o&xhr=t&q=mini+displayport+to+displayport&pf=p&sclient=psy-ab&oq=mini+displyport+to+dis&pbx=1&bav=on.2,or.r_cp.r_qf.&bvm=bv.51156542,d.aGc&biw=1920&bih=994&tch=1&ech=22&psi=VT4cUvL_M4TriAedt4DoCg.1377582678489.3&sa=X&ei=Xj4cUqikHIXriAe5sYCgCA&sqi=2&ved=0CG8Q8wIwAA
[05:53] <duflu> RAOF: Oh. Actually would have only been $30 delivered from PLE
[05:53] <RAOF> It's $26 direct from lenovo.com
[05:53] <duflu> Ah yes
[05:54] <duflu> Supports all your 4K monitors ;)
[05:56] <rsalveti> bug 1217195
[05:56] <rsalveti> bug 1217199
[05:57] <rsalveti> multimonitor works here only in mirrored mode
[05:59]  * duflu also notes he's slightly closer to Lenovo factories (Shenzhen)... Seems the East is more isolated ;)
[06:10]  * duflu ignores the fact that his Lenovos are second-hand and came from the eastern states
[06:24] <mlankhorst> RAOF: did you figure out the issue yet?
[06:25] <RAOF> mlankhorst: Yup, failure to call xmir_submit_rendering_for_window.
[06:25] <mlankhorst> https://www.youtube.com/watch?v=zTHhwvTJyMU
[06:28] <RAOF> mlankhorst: Please feel free to try the new new nouveau; I've not seen testing of it.
[06:28] <duflu> Hey, I think I can reproduce the glitches with egltriangle. I was just testing the wrong dual monitor combo
[06:30] <RAOF> Woot!
[06:30] <RAOF> I was about to try a build of your timerless MM to see if that fixed it; shall I not do that now?
[06:35] <duflu> RAOF: It's worthwhile for MM even if it doesn't fix that bug.
[06:35]  * duflu builds on the *correct* machine this time
[06:36] <duflu> Excellent. I've lost the ability to VT switch. That's an annoying Mir/X bug that's happened before
[06:39] <duflu> RAOF: Nope. Still happens. But at least I seem to have a test case now
[06:47] <RAOF> duflu: Wow. Have you tried MM XMir on your timerless branch?
[06:47] <duflu> RAOF: No... ?
[06:48] <RAOF> It generates the most awesome visual artefacts ever!
[06:48] <duflu> RAOF: It includes bypass. You're sure that's not it?
[06:48] <RAOF> I guess it might be bypass?
[06:48] <duflu> RAOF: You mean single (short) line artefacts?
[06:49] <RAOF> But rendering comes in over a couple of frames in horizontal stripes.
[06:49] <RAOF> Yeah, I might mean that.
[06:49] <duflu> RAOF: Yeah I noticed that with qa-testing. Something about bypass+XMir
[06:49] <RAOF> That is really odd; I don't have any intuition for what the problem might be there.
[06:50] <duflu> RAOF: Same. Can you verify bypass does the same, and also with no buffer_age?
[06:52] <RAOF> Sure.
[06:59] <duflu> RAOF: Hmm, actually I am only seeing glitches which match up with the expected aliasing interval of the two different refresh rates. Still can't reproduce real lag using plain Mir
[07:02] <RAOF> duflu:Huh!
[07:02] <RAOF> Turns out I *have* been testing without buffer_Age
[07:06] <duflu> RAOF: Great. Still no leads on lag. Though the glitches seem to match up perfectly with (1.0 / (refresh_rate1 - refresh_rate2)) seconds
[07:07] <RAOF> Beat frequency!
[07:07] <duflu> At least for egltriangle
[07:07] <duflu> It's a beat alright
[07:07] <duflu> Only happens on the slower monitor
[07:10] <duflu> Back in a tick
[07:10] <duflu> Or a few beats
[07:23] <duflu> RAOF: Suggestions for avoiding beats? Sync to the slowest output instead?
[07:25] <duflu> Though I'm not too sure how such an algorithm would go...
[07:29] <mlankhorst> RAOF: oh btw tiling fail on nouveau
[07:29] <mlankhorst> bigtime :P
[07:30] <mlankhorst> and the screen is now reduced to random noise
[07:32] <mlankhorst> looks like freed b uff
[07:32] <mlankhorst> buffers are being copied to the screen, or something
[07:33] <mlankhorst> .. which might not be different from the ati case I was hitting..
[07:34] <duflu> mlankhorst: Running what?
[07:35] <mlankhorst> qa-testing2 on a single monitor setup
[07:38] <duflu> Hmm
[07:38] <RAOF> mlankhorst: Hrm. Works fine for me on ati single
[07:39] <RAOF> -monitor.
[07:40] <mlankhorst> RAOF: oops ati panicked on me, looks like I need to fix something first. I'm fairly sure nouveau was using freed memory at least :P
[07:40] <duflu> RAOF: Interestingly, each beat pops out to stdout from egltriangle as "61 FPS"
[07:43] <mlankhorst> I've poked upstream a bit about the vsync fixes I was working on
[07:43] <mlankhorst> they make glxgears a nice 65.4 fps :-)
[07:44] <duflu> mlankhorst: Sounds close to perfect. Seen any X/Compiz problem like I did?
[07:44] <mlankhorst> duflu: well considering my screen was overclocked to 65.4 it was perfect
[07:44] <duflu> mlankhorst, Sweet
[07:49] <mlankhorst> RAOF: hm radeon is correct now, I'll poke nouveau a bit more
[07:50] <RAOF> Ta.
[07:50] <RAOF> Actually, now that I think of it, radeon is probably broken for multi-monitor, care of references to the front buffer being invalid after xmir_resize :(
[07:53] <mlankhorst> single monitor resize worked, but I don't know if it resizes when lowering the resolution..
[07:55] <RAOF> Hm.
[07:56] <RAOF> Maybe only the dri2 code that we don't hit uses the front buffer reference...
[07:56] <mlankhorst> RAOF: did you push your nouveau changes?
[07:57] <RAOF> mlankhorst: I have now :)
[07:57] <mlankhorst> or the ati changes for that matter :P
[08:00] <duflu> That's new. My VT font is now only 8px high
[08:10] <alan_g> hikiko: good morning. How are things?
[08:12] <hikiko> hi alan_g
[08:12] <mlankhorst> RAOF: ..
[08:12] <hikiko> how are you?
[08:12] <mlankhorst> -+                                    damage_box->x1 - output_box->x1,
[08:12] <mlankhorst> -+                                    damage_box->y1 - output_box->y1,
[08:12] <hikiko> alan_g, did you see my MPs?
[08:12] <mlankhorst> why such a creative way of writing 0?
[08:13] <alan_g> hikiko: I see them. will review with all the others
[08:13] <hikiko> :)
[08:13] <alan_g> hikiko: we have an MP backlog - are you doing your reviews?
[08:13] <hikiko> what do you mean alan_g ?
[08:14] <alan_g> hikiko: All team members, including you, have a responsibility to review MPs
[08:14] <hikiko> you mean all the mps?
[08:15] <alan_g> hikiko: if no-one reviews them they don't land and we get a backlog
[08:16] <hikiko> where can I find this backlog?
[08:16] <hikiko> I wasn't aware to be honest
[08:16] <alan_g> hikiko: https://code.launchpad.net/mir/+activereviews
[08:17] <hikiko> ok, so I guess I have to start reviewing?
[08:18] <duflu> For reviews, just keep in mind this week the priorities are multi-monitor and bypass proposals
[08:19] <alan_g> hikiko: start with any easy ones (small & things you know) - it make the list smaller.
[08:21] <hikiko> ok
[08:21] <alan_g> duflu: what's the current rule about landing bypass?
[08:21] <duflu> alan_g: Top approval is deferred till more PPA testing I think
[08:23] <mlankhorst> RAOF: oh btw I'm worried about your handling of multi monitor, it seems to add yet another copy pass in the single monitor case..
[08:23] <alan_g> hikiko: If you're looking at mine, don't overlook the pre-requisites - if you top-approve they land too.
[08:41] <mlankhorst> RAOF: heh all that silly stuff about bo creation in nouveau.. there are easier ways to do so :P
[08:50] <RAOF> mlankhorst: I don't think it adds an extra copy for the single-monitor case?
[08:51] <RAOF> mlankhorst: damage_box->x1 - output_box->x1 is zero iff the damage occurs on a display with top-left at (0,0)
[08:51] <duflu> RAOF: OK, I've written a key repeat simulator native client. And no bugs. Still only happens in XMir ?!
[08:52] <RAOF> mlankhorst: On a display at (x, y), output_box->x1 will be x, but damage_box->x1 will be >= x
[08:53] <mlankhorst> RAOF: I mean that the current path requires always making a copy..
[08:54] <mlankhorst> oh hm this could explain why xorg didn't work..
[08:54] <mlankhorst> [   50.333352] nouveau E[  PGRAPH][0000:01:00.0] DATA_ERROR XY_OUT_OF_BOUNDS
[08:54] <mlankhorst> [   50.334335] nouveau E[  PGRAPH][0000:01:00.0]  DATA_ERROR
[08:54] <mlankhorst> [   50.334335] nouveau E[  PGRAPH][0000:01:00.0] ch 3 [0x003f9a4000 unity-system-co[1087]] subc 0 class 0x5039 mthd 0x0328 data 0x00000000
[08:54] <RAOF> Whoops.
[08:54] <RAOF> mlankhorst: The current path already requires always making a copy, though?
[08:55] <mlankhorst> RAOF: yeah but ideally it'd just be a flip
[08:56] <RAOF> Yeah, but we can't do that.
[08:56] <RAOF> Or, we could, but would require significant mir-side work to enable.
[08:56] <duflu> I think it's generally understood XMir will have copies, for now...
[08:57] <RAOF> Well, that's rather odd.
[08:57] <mlankhorst> RAOF: any idea where the XY_OUT_OF_BOUNDS is coming from at least?
[08:58] <RAOF> Ahem.
[08:59] <RAOF> 	pScreen->ModifyPixmapHeader(dst, dst_box->x2 - dst_box->x1,
[08:59] <RAOF> 								dst_box->y2 - dst_box->y1, pScrn->depth, pScrn->depth,
[08:59] <RAOF> 				    pScrn->virtualX, NULL);
[08:59] <RAOF> Spot the odd one out...
[08:59] <mlankhorst> RAOF: well I did get rid of it in my version
[08:59] <RAOF> Although for the single monitor case, pScrn->virtualX should be right.
[08:59] <mlankhorst> anbd it's unity-system-compositor failing, not xorg
[09:00] <mlankhorst> RAOF: http://paste.debian.net/30763/
[09:00] <RAOF> Woohoo!
[09:00] <duflu> ?
[09:01] <RAOF> Oh, it's just an implementation of copy_to_mir that doesn't go through EXA
[09:01] <mlankhorst> it's the default m2mf implementation for nouveau anyway, depends on hw which implementation it uses
[09:02] <mlankhorst> but unity-system-compositor is still complaining about XY_OUT_OF_BOUNDS.. Hmmz
[09:02] <RAOF> Yeah; that's odd.
[09:02] <RAOF> That couldn't be because xmir is submitting something strange?
[09:03] <mlankhorst> it's unity-system-compositor, not xorg complaining..
[09:03] <RAOF> duflu: Did you find that the crazy horizontal artefacts only occurred when you had two displays enabled?
[09:04] <RAOF> Yeah, but could unity-system-compositor be complaining because it's trying to access something that xorg screwed up?
[09:04] <RAOF> The other option is that usc is, in fact, doing something wrong.
[09:04] <duflu> RAOF: I think so. Because we all tested bypass XMir single monitor a while back and no one had any issues
[09:04] <RAOF> But I don't really know what that would be, particularly if other Mir clients work.
[09:05] <mlankhorst> RAOF: there is no command validation in the kernel, it's literally the hardware saying your parameters for M2MF transfer do not make sense :P
[09:05] <duflu> RAOF: I should have realized, but yes the crazy horizontal artefacts are multimonitor only AFAIK
[09:05] <duflu> Multimonitor+bypass I mean
[09:06] <RAOF> mlankhorst: Hrm. When you run regular Mir clients against usc things work?
[09:07] <mlankhorst> hm it does
[09:09] <mlankhorst> "Your x/y coords exceed the size of your surface."
[09:09] <mlankhorst> o.O
[09:10] <mlankhorst> oh right, not on 9.2 yet..
[09:10] <mlankhorst> I'll try mesa 9.2 first before digging further
[09:16] <alan_g> tvoss: is anything happening with https://code.launchpad.net/~thomas-voss/mir/fix-fd-sharing/+merge/180801?
[09:16] <sil2100> kgunn: hi! Any news on https://bugs.launchpad.net/unity-system-compositor/+bug/1216979 ?
[09:16] <duflu> sil2100: Good luck. He's at 4am I think
[09:17] <sil2100> kgunn: since right now it's blocking unity-system-compositor from releasing
[09:17] <sil2100> duflu: lovely, thanks
[09:18] <mlankhorst> RAOF: lol, fail in nv50_m2mf_transfer_rect
[09:18] <RAOF> What's it doing?
[09:19] <mlankhorst> not setting X/Y at all
[09:19] <mlankhorst> ;D
[09:20] <RAOF> Ahem. Yeah, that doesn't seem particularly likely to work :)
[09:20] <RAOF> That's clearly not something that I did. Yay!
[09:24] <duflu> Might work at defaulting to 0,0 on some machines, if you're lucky
[09:26] <duflu> RAOF: Was there any technical reason (other than performance) why XMir couldn't be switched to being a dumb Mir software client?
[09:26] <RAOF> No
[09:26] <duflu> RAOF: Because I'm starting to think that would be nice to test
[09:26] <RAOF> But "other than performance" is a pretty big "other than"
[09:28] <RAOF> We could whip up a sw-rendering DDX reasonably quickly.
[09:28] <alan_g> hikiko: https://code.launchpad.net/~hikiko/mir/mir.gbm-buffer-allocator-modifications/+merge/182049 is pretty trivial to fix. Want to do that quickly?
[09:28] <duflu> RAOF: Yeah, I mean just for debugging. Smells like some issues still lurk in XMir trying to be super fast
[09:29] <duflu> RAOF: Yes please. Otherwise I may well end up trying to learn it and do it myself
[09:31] <hikiko> I did it already alan_g I am building before I push
[09:33] <duflu> RAOF: BTW, my key repeat simulator runs glitch-free in USC over the top of XMir. XMir's the only client with the glitches still :(
[09:33] <mlankhorst> RAOF: it's probably not a usc bug anyway, even if feeding invalid date the state tracker is supposed to deal with it
[10:03] <mlankhorst> oops, nouveau has betrayed me :P
[10:03] <mlankhorst> it was xserver after all
[10:04] <mlankhorst> yeah there we go, all working now.. mostly
[10:04] <asac> hi
[10:04] <asac> i am testing MM
[10:05] <asac> here on my x220 in a dock and the external monitor being the primary
[10:05] <asac> i get wrong resolution (that of the front screen) stretched
[10:10] <duflu> asac: Yes we have a bug logged for that. I get it too
[10:14] <asac> duflu: cool. once fixed can you ping me? happy to give it a try :)
[10:15] <duflu> asac: Probably best if you just subscribe: https://bugs.launchpad.net/xmir/+bug/1216224
[10:15] <duflu> asac: Though once logged in you can change the resolution
[10:17] <mlankhorst> RAOF: well that was easy to fix once I caught the kernel module lying about the source :P
[10:17] <asac> duflu: i can? how?
[10:17] <asac> wait ... cant copy/paste here anymore :((
[10:18] <mlankhorst> RAOF: http://paste.debian.net/30796/ --- enjoy!
[10:18] <duflu> asac: Log in and look on the right hand side of https://bugs.launchpad.net/xmir/+bug/1216224 where you will find subscription links
[10:23] <asac> duflu: was asking how to change resolution, but found that it can be done with just the normal preferences dialog
[10:23] <asac> something is really tslow though
[10:24] <duflu> asac: Slow? Yes there's at least one bug for that too
[10:25] <asac> i think its better now
[10:25] <asac> after reboot
[10:25] <asac> still, movig windows is a bit laggy
[10:25] <asac> but so far i can survive... cool
[10:28] <asac> seems i also get some texture artifacts while moving windows
[10:28] <asac> as if the window is split up in multiple pieces and they move out of sync :)
[10:30] <duflu> asac: You may wish to comment on the issues: https://bugs.launchpad.net/xmir/+bugs?field.tag=multimonitor
[10:35]  * duflu goes to organise dinner
[10:36] <RAOF> mlankhorst: Heh. Stride Strikes Again!
[10:36] <RAOF> asac: That sounds pretty cool!
[10:39] <asac> yeah i am happy :)
[10:39] <mlankhorst> RAOF: yes :P
[10:39] <asac> bleeding edge :)
[10:39] <RAOF> mlankhorst: I don't suppose you tried copying just the region that's damaged?
[10:40] <mlankhorst> RAOF: hm is it clipped against the output? :P
[10:40] <mlankhorst> but I guess I could..
[10:40] <RAOF> Yeah.
[10:41] <RAOF> region is always fully contained within dst_box (we do the intersection in the xmir module)
[10:42] <RAOF> So it's not *wrong* to always copy dst_box, but it's a wasteful.
[10:42] <mlankhorst> hm sure
[10:43] <mlankhorst> RAOF: is it guaranteed to be non-zero?
[10:43] <mlankhorst> eg no 0x0,0x0 copy
[10:43] <RAOF> Yes
[10:43] <mlankhorst> kk
[10:44]  * RAOF has weeded out all of these cases by testing on Intel, which uses region :)
[10:44] <RAOF> Man, the NVAccelM2MF declaration is not exactly self-documenting code :)
[10:45] <mlankhorst> it is
[10:46] <mlankhorst> the ofs refers to offset from start of bo, in case of scratch bo usage
[10:46] <RAOF> Aaah.
[10:46] <RAOF> And the rest you can mostly guess.
[10:47] <mlankhorst> source domain, source pitch, source height, x/y
[10:47] <RAOF> source_depth, source_pitch, source_height, source_x, source_y
[10:47] <mlankhorst> domain not depth :p
[10:47] <RAOF> Hah, source *domain*.
[10:48] <RAOF> What does M2MF stand for? Something like Mem 2 Mem copy with Format?
[10:49] <mlankhorst> memory to memory function was my guess, but yours is just as good I suppose
[10:49] <mlankhorst> hm format is probably the right one
[10:49] <mlankhorst> it can convert some formats to others and do some swizzling
[10:51] <mlankhorst> RAOF: oh btw what coordinates is damage_box in then?
[10:51] <RAOF> Screen coordinates.
[10:51] <mlankhorst> so same coordinate system as damage_box ?
[10:52] <RAOF> dst_box? Yes.
[10:52] <RAOF> Hm. We may have been confusing there :)
[10:52] <mlankhorst> you don't say!
[10:52] <RAOF> _region_ is in the same coordinate space as dst_box :)
[10:52] <RAOF> And region is the damage region.
[10:53] <RAOF> Both are in the window coordinate space of the window.
[10:54] <mlankhorst> http://paste.debian.net/30803/
[10:55] <mlankhorst> just guessing.. I'll give it a shot
[10:56] <RAOF> That looks roughly right?
[10:57] <mlankhorst> even seems to draw correctly
[10:57] <RAOF> Hm. I think you might have some things the wrong way around, but that might be because I've been using Exa->Copy too much.
[10:57] <RAOF> Ah, well. If it works, it's clearly not that wrong :)
[10:57] <RAOF> The ideal test client is an xterm on a raw X session.
[10:59] <mlankhorst> hm let me find a mouse for that machine, it didn't put focus on the xterm :P
[10:59] <RAOF> Fire up metacity?
[11:02] <mlankhorst> hm xterm -e 'find /' works
[11:04] <mlankhorst> RAOF: first client for x works, but if I kill it and screen returns to black the next client does not..
[11:04] <RAOF> mlankhorst: Yeah, loss of the sole client triggers a server regeneration, and XMir doesn't handle that well at all.
[11:05] <RAOF> Fortunately that should only hit people like us, who test clients on raw X.
[11:05] <RAOF> And, obviously, KDE, should they feel like porting. :)
[11:05] <mlankhorst> RAOF: oh and a major derp was not using damage_box->x1 for src :P
[11:06] <mlankhorst> hm and then not removing dst_box from dst coordinates
[11:06] <RAOF> Ah, right.
[11:06] <RAOF> Yes, I did wonder a bit about that :)
[11:07] <mlankhorst> http://paste.debian.net/30811/ this version is more correct right?
[11:08] <RAOF> Yeah, that looks like what I'd expect.
[11:08] <RAOF> Particularly: it looks like the radeon code :)
[11:11] <tsdgeos> ricmm: tvoss: there?
[11:12] <tsdgeos> ricmm: tvoss: unping
[11:12] <tvoss__> tsdgeos, ;)
[11:15] <mlankhorst> RAOF: odd, does compiz always do full-screen repaints then?
[11:15] <RAOF> mlankhorst: I think compiz is mostly doing glXSwapBuffers now (although you can turn that off)
[11:16] <RAOF> And SwapBuffers implies full-screen repaints.
[11:16]  * RAOF wonders whether it'd be worth teaching Compiz about swap_buffers_with_damage
[11:16] <mlankhorst> it's also very nice for bypass though :P
[11:16] <RAOF> mlankhorst: Indeed.
[11:17] <RAOF> It means that, once we actually implement the sucker, our normal-case overhead is going to be just protocol overhead.
[11:18] <mlankhorst> RAOF: but I'm mostly worried about the vblanking timestamp stuff, I still want accurate vblank on video
[11:19] <RAOF> Yeah, we need to hook that up.
[11:19] <RAOF> I was planning on doing it as a part of glx bypass, where it'd naturally fall out, but it's not necessary to do it there I guess.
[11:20] <RAOF> You don't get scanline accuracy out of it, but you can approximate vblank with buffer-received.
[11:21] <mlankhorst> that's not accurate vblank :p
[11:21] <RAOF> Yeah, that requires more involved compositor support :)
[11:21] <RAOF> Which I want to do, but is obviously a "not now" thing :/
[11:22] <mlankhorst> the drivers can get that information directly without going through the compositor..
[11:22] <RAOF> Only if the compositor isn't compositing, though?
[11:22] <mlankhorst> they just need to have the correct drm fd for the crtc, and the crtc id..
[11:23] <RAOF> And where on the crtc the window is, yes?
[11:23] <RAOF> And that'll only give you an accurate vblank signal; it won't tell you when the window is actually displayed, which is more interesting, right?
[11:23] <mlankhorst> not really, they just need to know for scheduling decisions
[11:24] <RAOF> As in: what-client-should-get-GPU-time-next decisions?
[11:26] <mlankhorst> I mean something like a media player might want to see the time of the last vblank, know exactly when the next vblank is going to happen, and queue a frame 1 or 2 vblanks in advance to sync on the correct frame
[11:26] <RAOF> mlankhorst: Right, but that really wants compositor support.
[11:27] <RAOF> Because the compositor might introduce a delay
[11:27] <mlankhorst> what about the case of fullscreen bypass?
[11:28] <RAOF> Then can do it, yes.
[11:28] <RAOF> Which is, I agree, a common case.
[11:31] <RAOF> But it's also the case that a client doesn't know if it's bypassed or not.
[11:32] <mlankhorst> RAOF: hm crash when I plugged in a second monitor to ati :P
[11:32] <RAOF> mlankhorst: Yeah. Need to implement a SetScreenPixmap hook for ATI to update info->front*
[11:32] <RAOF> As far as I can tell nouveau doesn't do anything annoying like that.
[11:32] <RAOF> Good job!
[11:33] <mlankhorst> lol
[11:33] <mlankhorst> nvidia does everything in hardware where it can..
[11:36] <alan_g> hikiko: what are you working on?
[11:51] <RAOF> mlankhorst, tvoss: Nouveau uploaded to qa-testing2 PPA. Happy multi-monitor testing!
[11:55] <hikiko> alan_g, I am looking at your branch + I am trying to find out where we get the crash if we add gbm/drm in native platform
[11:56] <alan_g> hikiko: ack
[11:56] <hikiko> alan_g, is there any way to check the changes in the display?
[11:56] <alan_g> hikiko: I'm not sure what you're asking
[11:56] <hikiko> or we have to fully implement the native/nested platform first?
[11:59] <alan_g> hikiko: we should be writing tests for the functionality we are working on
[12:00] <hikiko> alan_g, ok but let's first add the functionality :)
[12:01] <hikiko> I have a question on your branch actually
[12:01] <hikiko> + make_current(); // This duplicates what Eleni's original code did - but is it needed?
[12:01] <hikiko> what do you mean?
[12:01] <hikiko> do we swap buffers elsewhere?
[12:04] <alan_g> hikiko: I'm not sure why we'd do this when constructing the object (as opposed to when we render to it)
[12:04] <hikiko> I guess that if we don't we ll see nothing
[12:04] <hikiko> because we render to the back surface
[12:04] <hikiko> and we have to make it current
[12:05] <hikiko> let me see
[12:05] <alan_g> hikiko: rendering calls "make_current()"
[12:06] <hikiko> let me see what make_current does 1 sec
[12:07] <hikiko> make_current binds the context to the current rendering thread
[12:07] <hikiko> and to the draw and read surfaces
[12:09] <mlankhorst> RAOF: erm you failed somewhere
[12:09] <mlankhorst> ;P
[12:10] <mlankhorst> that src pixmap is definitely not covering the entire screen on my multimonitor setup
[12:10] <mlankhorst> proof..
[12:10] <mlankhorst> #0  NVAccelM2MF (pNv=pNv@entry=0x7f160085fc60, w=w@entry=1280, h=h@entry=1024, cpp=4, srcoff=srcoff@entry=0, dstoff=dstoff@entry=0,
[12:10] <mlankhorst>     src=0x7f1600895280, sd=sd@entry=1, sp=5120, sh=sh@entry=1024, sx=sx@entry=1440, sy=sy@entry=0, dst=dst@entry=0x7f1600baf510, dd=dd@entry=1,
[12:10] <mlankhorst>     dp=dp@entry=5120, dh=dh@entry=1024, dx=dx@entry=0, dy=dy@entry=0) at ../../src/nouveau_exa.c:49
[12:10] <mlankhorst> eg pitch = 5120, 1280 * 4
[12:10] <alan_g> hikiko: I have to go make lunch - back in an hour
[12:11] <mlankhorst> but the rects are this:
[12:11] <mlankhorst> [   829.877] (II) NOUVEAU(0): copying pixmap: (1440,0),(2720,1024) with damage (1440,0),(2720,1024)
[12:11] <hikiko> me too :) see you later alan_g|lunch
[12:11] <mlankhorst> and src is this:
[12:11] <mlankhorst> (gdb) print *src
[12:11] <mlankhorst> $1 = {drawable = {type = 1 '\001', class = 0 '\000', depth = 24 '\030', bitsPerPixel = 32 ' ', id = 0, x = 0, y = 0, width = 1280, height = 1024,
[12:11] <mlankhorst>     pScreen = 0x7f1600880700, serialNumber = 2234}, devPrivates = 0x7f16008efca8, refcnt = 1, devKind = 5120, devPrivate = {ptr = 0x0, val = 0,
[12:11] <mlankhorst>     uval = 0, fptr = 0x0}, screen_x = 0, screen_y = 0, usage_hint = 0, master_pixmap = 0x0}
[12:12] <mlankhorst> so I guess your assumption about 1 pixmap to cover everything is wrong ;P
[12:12] <mlankhorst> https://www.youtube.com/watch?v=zTHhwvTJyMU
[12:14] <mlankhorst> 2 screens, first one 1440x900 and the second one 1280x1024
[12:16] <tvoss__> olli_, ping
[12:22] <smspillaz> RAOF: It'd be quite trivial to get compiz working with swap_buffers_with_damage
[12:22] <smspillaz> RAOF: s_b_w_d would need to be implemented in GLX though
[12:22] <smspillaz> and I have no idea if it is
[12:33] <derEremit> hi, can i assume that any support for optimus via bumblebee will be severely broken once the switch to mir is complete
[12:34] <tvoss__> derEremit, well, you can always fallback to vanilla X plus prop drivers in 13.10
[12:36] <derEremit> and probably will have to do that.
[12:36] <derEremit> ;)
[12:41] <tvoss__> derEremit, if you rely on that functionality, yes. However, would be great if you could try the system-compositor, too :)
[12:51] <derEremit> yeah had no positive results this far
[12:53] <tvoss__> derEremit, did you try it from the archive, yet?
[12:53] <derEremit> ppa?
[12:54] <derEremit> well today had other problems
[12:54] <derEremit> started my laptop and couldn't login anymore
[12:54] <derEremit> purged X and mir completely, now it works again ;)
[12:54] <derEremit> i think bumblebee is kind of in the way
[13:12] <tvoss__> RAOF, mlankhorst ping
[13:13] <mlankhorst> pong
[13:13] <mlankhorst> and no, I don't think mir has any support for crtc's that do not belong to the rendering graphics card..
[13:21] <frothnicator> I saw the recent request for testers for the multi-monitor support.  Would a live CD/USB/NetBoot be an appropriate route to test?
[13:25] <balloons> frothnicator, would you be running on real hardware?
[13:31] <alan_g> tvoss__: bypass is top-approved
[13:31] <tvoss__> alan_g, why?
[13:32] <tvoss__> alan_g, please revert that
[13:32] <alan_g> tvoss: ack
[13:32] <alan_g> tvoss: I thought we'd discussed
[13:33] <alan_g> tvoss: I thought we'd discussed doing that
[13:33] <tvoss__> alan_g, nope
[13:34] <alan_g> tvoss__: Misunderstanding then. Sorry
[13:34] <tvoss__> alan_g, ack, no worries
[13:41] <frothnicator> balloons: sorry, stepped out for a minute: yes.
[13:41] <frothnicator> one without discrete graphics card, even.
[13:48] <frothnicator> balloons: So if I were to use a daily saucy (with real hardware), that would be a good for y'all?
[13:49] <tvoss__> frothnicator, that would already help us, yes :)
[13:50] <frothnicator> tvoss__: okay.  Smiley face implies "yes it would help", but I don't understand what you mean by "already"?
[13:50] <kgunn> alan_g: i need to review the numbers w olli first....sorry bout that
[13:50] <tvoss__> frothnicator, the call for testing was referring to ppa:mir-team/system-compositor-testing for multi-monitor
[13:52] <mlankhorst> I thought qa-testing2? :P
[13:53] <frothnicator> tvoss__: thank you.  That was a detail that I apparently missed in the email.
[13:53] <frothnicator> I will work do so this evening.
[13:54] <tvoss__> mlankhorst, no, we copied over to system-compositor-testing iirc, kgunn, can you please cross-check?
[13:55] <kgunn> tvoss: mlankhorst frothnicator ....system-compositor-testing
[13:55] <kgunn> qa-testing2 is still live action
[13:56] <mlankhorst> ah
[13:56]  * mlankhorst is behind then!
[13:57] <frothnicator> kgunn: apologies, I've been out development for a few years, while getting my degree.  I'm not up with what "still live action" means?
[13:58] <kgunn> frothnicator: sorry...i just meant that qa-testing2 was still being used by dev team last night, packages being updated
[13:58] <kgunn> which can sometimes mean "trouble"....package mismatch or some such...
[13:59] <kgunn> whereas system-compositor-testing is static....nothing going in
[13:59] <frothnicator> kgunn: gotcha.  So bottom line is that I should use ppa:mir-team/system-compositor-testing when I get home to test.
[13:59] <kgunn> frothnicator: yes sir
[14:00] <frothnicator> kgunn: quick worflow: Saucy Daily + add-apt-repository ppa... + restart lightdm?
[14:00] <frothnicator> or quantal livecd + add-apt-repository paa... + restart lightdm?
[14:01] <kgunn> frothnicator: instructions here https://wiki.ubuntu.com/Mir/MultiMonitorTesting
[14:01] <kgunn> frothnicator: quantal ?....we're all saucy...so, as long as you get to saucy recent....
[14:03] <frothnicator> kgunn: you know, I missed the first email in that thread, so I'll bet you spelled all this out. With that last link, I htink I'm good to go.  However, I note that one of the instructions is to reboot: that implies a hard install rather than a LiveCD, or is that step fungible?
[14:04] <kgunn> frothnicator: you can also "restart lightdm" rather than reboot
[14:05] <kgunn> frothnicator: someone else gave me a hard time about that too :)
[14:05] <kgunn> frothnicator: i just reboot
[14:05] <kgunn> frothnicator: so my instructions just ended up being what i do :)
[14:06] <frothnicator> kgunn: Heh, roger.  From my perspective, I'm not heavy in to distro development, so all I have to test with are machines that I actually use.  Ergo, a temporary measure (i.e., LiveBoot) is what I need.
[14:06] <frothnicator> kgunn: Okay.  I'll report to Launchpad anything I find tonight.  Thanks for the help.
[14:07] <kgunn> frothnicator: thanks!
[14:10] <frothnicator> kgunn: not knowing how many "people like me" who might drop in, you might consider updating that wiki page to say just "Restart LightDM".  I would think that most folks would know that rebooting restarts the display manager automatically, whereas the reverse is not true.  I tend to associate "necessary rebooting" with "new kernel only".  Just a thought.  Cheers.
[14:11] <kgunn> frothnicator: thanks...i'll have to poke someone...it was editable...then some jake-leg made it immutable...geeze
[14:11] <kgunn> balloons: ^
[14:11] <kgunn> balloons: can we update the instructions to include "restart lightdm" ?
[14:12] <frothnicator> kgunn: hah.  I know the feeling.  The vicissitudes of working with other people.  :-)
[14:12] <kgunn> :)
[14:12] <kgunn> well-intentioned i'm sure
[14:14] <frothnicator> absolutely.
[14:14] <frothnicator> alright, I'm out.  Thanks again.
[14:14] <balloons> kgunn, sure thing.. you mean restarting lightdm after install?
[14:14] <balloons> perhaps that didn't end up on the wiki
[14:15] <kgunn> balloons: right
[14:15] <kgunn> i know someone spoke to me about it...i thot i added it....
[14:15] <kgunn> but i think it got moved in some edits when olli was going for twd
[14:16] <balloons> I do see it in there.. I remember adding the command to it
[14:16] <balloons> and indeed, it's in there
[14:16] <balloons> look in setup
[14:32] <frothnicator> balloons: I was the one suggesting to be consistent if you didn't need to fully restart the machine.  The specific line in setup is "Reboot and re-verify you are running Xmir."  I think I described my thought process fairly well about 22 minutes ago.
[14:33] <frothnicator> (but if I didn't, or if doesn't matter, feel free to tell me to move along.)
[14:34] <balloons> frothnicator, no, I agree just lightdm should be noted.. but I don't see where the line of reboot and re-verify is at
[14:35] <frothnicator> balloons: can you not find (via search, perhaps?) in the page what I just quoted (which I copy/pasted)?
[14:35] <frothnicator> balloons: maybe we're talking about different pages?  https://wiki.ubuntu.com/Mir/MultiMonitorTesting
[14:36] <balloons> frothnicator, k, I'll search again :-)
[14:36] <balloons> ahh, ok
[14:36] <frothnicator> balloons: I know, I know.   I just missed the line before.. i'm quite human and do such things I assure you
[14:38] <balloons> take a look now
[14:39] <frothnicator> balloons: heh, sometimes helps to clear ones cache: three reloads and on Ctrl+Shift+R later, I see the update!  Cheers.
[14:40] <balloons> excellent, thanks for pointing it out!
[14:40] <frothnicator> np.
[15:03] <hikiko> alan_g, kgunn +anyone else available meeting?
[15:58] <kgunn> bschaefer: hey...i really need your help
[15:59] <bschaefer> kgunn, what up? (I forgot about vUDS...)
[16:02] <kgunn> bschaefer: i have a blocker for unity (you prob heard?)
[16:02] <kgunn> https://bugs.launchpad.net/unity-system-compositor/+bug/1216979
[16:03] <bschaefer> kgunn, yup, thats what im working on right now!
[16:03] <kgunn> bschaefer: could you take a look ?
[16:03] <kgunn> oh great
[16:03] <kgunn> thank you
[16:03] <bschaefer> kgunn, yupp!
[16:03] <bschaefer> kgunn, np! Its a strange failure, as I can get manually use it...soo no regression from what i see...
[16:03] <bschaefer> as I can manually*
[16:09] <tvoss> bschaefer, please check if keycodes are correct, according to pitti, something changed in that respect
[16:10] <bschaefer> tvoss, yeah, I was just reading that email... that would explain the x error
[16:12] <tvoss> bschaefer, yeah, please see if you can track it down
[16:12] <bschaefer> tvoss, will do, good think is I can at lease manually use it, so no regression, just a very strange problem
[16:13] <bschaefer> thing*
[16:13] <bschaefer> ...
[16:13] <tvoss> bschaefer, ack
[16:14] <tvoss> bschaefer, got a link to that mail?
[16:14] <bschaefer> tvoss, hmm a recent one? no
[16:15] <bschaefer> tvoss, also this happens outside of xmir as well
[16:15] <tvoss> bschaefer, ?
[16:15] <kgunn> bschaefer: i was thinking just that...
[16:16] <kgunn> input not in xmir...input is left to the traditional x path
[16:16] <bschaefer> tvoss, as I don't have xmir running right now, and I still have the failure
[16:16] <bschaefer> kgunn, ^
[16:16] <tvoss> bschaefer, ack, thx
[16:16] <bschaefer> sooo whats causing this is some sort of update somewhere...which could be the new ibus update, or the email pitti sent out
[16:16] <bschaefer> tvoss, np!
[16:17] <tvoss> bschaefer, can you please update the issue report/bug report accordingly?
[16:17] <bschaefer> tvoss, yup!
[16:17] <tvoss> bschaefer, thx
[16:17] <bschaefer> np
[16:22] <bschaefer> tvoss, moved the bug blame to unity, as im still not sure where the problem came from and marked invalid for u-s-c
[16:25] <kgunn> bschaefer: : thank you for taking care....is there someone we should manually poke on ?
[16:26] <kgunn> as i understand its a stopper
[16:26] <bschaefer> kgunn, me :), i did most of that implementation in unity/nux plus most of the AP tests....
[16:26] <tvoss> thomi, can you please help bschaefer tracking down the issue? we are blocking a lot of releases right now
[16:26] <kgunn> bschaefer: please allow yourself to ...poke....yourself
[16:26] <bschaefer> kgunn, will do!
[16:26] <kgunn> :)
[16:26] <bschaefer> bschaefer, get to work!
[16:27] <kgunn> :))
[16:35] <thomi> tvoss: sure, I can lend my sleep-deprived brain to the cause.
[16:35] <thomi> bschaefer: what do you need?
[16:35] <bschaefer> thomi, sooo Multi_Key doesn't match any keybod
[16:35] <bschaefer> keycode in autopilot?
[16:36] <bschaefer> possibly removed, or somehow worked before?
[16:36] <thomi> errr... we're using the X11 keyboard?
[16:37] <bschaefer> hmm now we are getting a 0 from the x11 keyboard?
[16:40] <bschaefer> thomi, this is where its failing:
[16:40] <bschaefer> get_display().keysym_to_keycode(keysym)
[16:41] <thomi> hmmm
[16:41] <bschaefer> the keysym seems about right: 65312, ill double check
[16:41] <bschaefer> sooo it can't find the key on the keyboard
[16:41] <bschaefer> which would explain  the error...
[16:41] <thomi> bschaefer: indeed
[16:41] <bschaefer> thomi, at the end of this, ill push a branch to give some sort of error if that returns 0
[16:41] <thomi> this is the issue with the X11 bindings
[16:42] <bschaefer> right, soo i wonder if its due to keyboard layouts? I swear this worked before though...
[16:42] <bschaefer> on a normal X keyboard
[16:42] <bschaefer> err
[16:43] <bschaefer> normal english US keyboard
[16:43] <thomi> bschaefer: presumably that's the keymap you're using as well though, right?
[16:44] <bschaefer> thomi, and yup getting the right keysym:
[16:44] <bschaefer> #define XK_Multi_key                     0xff20
[16:44] <bschaefer> thomi, yes, but when I wrote the tests I do remember it working :)
[16:44] <bschaefer> thomi, i've also tried french layout though
[16:44] <bschaefer> which does have the multi key, and it does work manually
[16:45] <thomi> hmmm
[16:45] <thomi> what happens if you manually set the keycode?
[16:45] <bschaefer> thomi, hmm isn't the keycode dependent on the hardware? ie. its not always the same for each key?
[16:46] <bschaefer> thomi, but ill try to get it from some x tool I forgot the name of
[16:46] <thomi> ahh, sorry, I misunderstood.. keysym vs keycode :-/
[16:47] <bschaefer> xev, but hmm I think I might be missing up multi key vs composite key?
[16:48]  * bschaefer now does not remember where the hell the multi key is...
[16:49] <thomi> bschaefer: the composite key can be bound to some other key on your KB. perhaps the multi key can as well
[16:49] <bschaefer> thomi, right, I think I've confirmed the composite key is working, not the multi key though (testing through xev)
[16:50] <bschaefer> as if I can find the mutlikey on the keyboard through xev, we should have a keycode but now im wondering if its missing?
[16:50] <thomi> yeah, I dunno
[16:51] <bschaefer> :), yeah I just have to refresh my self on how to type it, sine I don't use it regularly
[16:52] <bschaefer> thomi, hmm I wonder if the OSK would have a nice button that we could press...
[16:52] <bschaefer> if it doesn't exist it *might* cause it to crash... or spit some error out
[16:54] <thomi> bschaefer: I think it would be instructive to get someone with a french keyboard to try this
[16:54] <bschaefer> thomi, it would be helpful
[16:54] <bschaefer> seb128, ping
[16:54] <seb128> bschaefer, hey
[16:54] <bschaefer> seb128, can you confirm the multi is on your keyboard through xev?
[16:54] <bschaefer> multi key*
[16:55]  * bschaefer is unable to find it on any keyboard layouts
[16:55] <seb128> what is "the multi key"?
[16:55] <bschaefer> seb128, thats what im trying to figure out :), I remember it being like the dead key...but its been a while now...
[16:55] <seb128> I've no clue about those things...
[16:55] <bschaefer> seb128, no worries! Thanks :)
[16:57] <seb128> bschaefer, sorry for not being able to help, but feel free to ping if you have more specifics
[16:57] <bschaefer> thomi, hmm it seems the composite key is the multi key?
[16:57] <seb128> bschaefer, http://www.linuxhowtos.org/Tips%20and%20Tricks/compose.htm
[16:57] <seb128> seems to indicator it's the composite key indeed
[16:57] <bschaefer> seb128, no worries, right, but I can't get the multi key sym to come up
[16:57] <bschaefer> #define XK_Multi_key                     0xff20
[16:57] <bschaefer> seb128, which is what we are asking python to enter
[16:58] <thomi> hmmm
[16:58] <bschaefer> but it doesn't seem to exist on the keyboard...
[17:01] <bschaefer> thomi, haha, im seeing the "compose key" as disabled... in the new text entry chart?
[17:01] <thomi> what's that?
[17:01] <bschaefer> err
[17:02] <bschaefer> thomi, go to your keyboard indicator, Text Entry Settings
[17:02] <bschaefer> thomi, then select your layout (french possibly), then press keyboard settings
[17:02]  * bschaefer tests if this is the problem
[17:03] <thomi> I have "Compose Key" set to Caps lock
[17:03] <bschaefer> thomi, then the test should ... *should* pass for you
[17:03] <thomi> what's the test id?
[17:03] <bschaefer> thomi, autopilot run unity.tests.test_dash.DashMultiKeyTests.test_multi_key_copyright
[17:04] <seb128> bschaefer, thomi: that test works for me on saucy
[17:04] <seb128> (session is running since yesterday)
[17:05] <bschaefer> thomi, worked :)
[17:05] <bschaefer> seb128, soo it seems the composite key is disabled by default now in the keyboard layout?
[17:05] <thomi> bschaefer: so I'm doing the autopilot 1.4 development, which means my system is full of 1.4 packages, so I can't run those tests, but I think we found the issue anyway
[17:05] <bschaefer> seb128, but im not sure if it was ever enabled though...for US en keyboard I don't think it even exists...
[17:05] <thomi> bschaefer: I suggest making the unity AP test set the compose key at the start of the test
[17:06] <bschaefer> thomi, right, that'll be fun to figure out
[17:06] <thomi> bschaefer: shouldn't be too hard :)
[17:06] <seb128> bschaefer, yeah, I'm not sure, I can't see why that would have changed recently
[17:06] <bschaefer> thomi, hopefully :)
[17:07] <bschaefer> seb128, yeah...this is why im wondering why all of sudden things have changed...as I don't remember having to set this before...
[17:07] <seb128> bschaefer, or it might be a fallout of the new g-s-d/ibus/indicator-keyboard ... though that happened a week ago and test starting failing more recently
[17:08] <bschaefer> seb128, hmm possibly, but now to figure out to set that in python...
[17:08] <bschaefer> tvoss, kgunn found problem, now to just find the fix
[17:08] <bschaefer> tvoss, kgunn composite key is disabled, causing it to not exist on the keyboard, ie. x key code error
[17:09] <seb128> bschaefer, system("setxkbmap -option compose:rwin")? ;-)
[17:09] <thomi> bschaefer: there's support for gsettings in unity module I believe
[17:09] <thomi> seb128: s/system/subprocess/ at least :)
[17:09] <bschaefer> seb128, that would work, but Ill look for a gsettings fix first
[17:09] <bschaefer> seb128, unless we want to get a fix out
[17:09] <seb128> thomi, right, I was not suggesting code, just giving the idea
[17:09] <thomi> seb128: yep :)
[17:09] <bschaefer> then get a better fix in..
[17:10] <seb128> bschaefer, well, mir stack and unity-system-compositor are being stucked until we resolve that
[17:10] <seb128> bschaefer, I'm sure the mir team is going to get angry soon
[17:10] <bschaefer> right which makes me want to get this out ASAP
[17:10] <bschaefer> yeeah...
[17:11] <thomi> so maybe seb128's idea is the fastest
[17:11] <bschaefer> thomi, yeah, hmm umm
[17:11] <bschaefer> thomi, let me just add that to the ctor for multi key tests...
[17:11] <bschaefer> then get a real fix in later today
[17:11] <thomi> bschaefer: you mean in setUp?
[17:11] <bschaefer> thomi, well thats the ctor right?
[17:12]  * bschaefer does to much c++
[17:13] <thomi> heh. I thought you meant __init__
[17:13] <bschaefer> thomi, nope, the constructor for the multi key class :)
[17:13] <seb128> bschaefer, I can confirm the test failing in a guest session, I'm going to try to figure out what changed
[17:13] <thomi> seb128: I'm reasonably sure that the compose key used to be set to something by default
[17:14] <seb128> right, but where/by what
[17:14]  * bschaefer is unsure but shouldn't have relied on that...
[17:14] <thomi> that I don't
[17:14] <bschaefer> we should have set our own, then reset the default...but yes
[17:15] <bschaefer> thomi, soo subprocess for python, using popen?
[17:16] <bschaefer> as i can confirm this is fixing it when its turned off: setxkbmap -option compose:rwi
[17:16] <bschaefer> n
[17:16] <bschaefer> setxkbmap -option compose:rwin*
[17:16] <thomi> bschaefer: so you can run something like:
[17:16] <bschaefer> thomi, I just want to make sure I at lease get this quick fix working :)
[17:16] <thomi> subprocess.call(["setxkbmap", "-option", "compose:rwin*"])
[17:17] <bschaefer> thomi, thanks let me test that out!
[17:17] <bschaefer> thomi, also the * was for my spelling mistake :)
[17:17] <bschaefer> missing the n in win
[17:26] <bschaefer> thomi, confirmed working...
[17:26] <bschaefer> just pushed a branch
[17:28] <bschaefer> thomi, seb128 https://code.launchpad.net/~brandontschaefer/unity/enable-compose-key/+merge/182454
[17:28] <seb128> bschaefer, I'm not going to nitpick on the empty lines changes :p
[17:28] <bschaefer> seb128, yeeah I know thomi loves them being removed
[17:28] <bschaefer> soo I have it set up to remove python empty lines :)
[17:29] <seb128> bschaefer, approved
[17:29] <bschaefer> seb128, thanks, and sorry about not getting this fixed yesterday!
[17:29] <thomi> bschaefer: LGTM
[17:29]  * bschaefer wasn't aware it was blocking yesterday...
[17:29] <bschaefer> thomi, thanks
[17:29] <seb128> bschaefer, no worry, thanks for fixing it today ;-)
[17:29] <bschaefer> seb128, you welcome, now to find a correct fix :)
[17:30] <bschaefer> your*
[17:30] <bschaefer> my keyboard likes leaving off keys...
[17:30] <bschaefer> kgunn, tvoss MP to quickly fix here:
[17:30] <bschaefer> https://code.launchpad.net/~brandontschaefer/unity/enable-compose-key/+merge/182454
[17:30] <seb128> bschaefer, "you're*" you mean :p
[17:30] <seb128> bschaefer, I'm trying to diff build logs between the working and non working version, I would like to figure out what update created the issue
[17:30] <bschaefer> seb128, yup haha...
[17:31]  * bschaefer has to many things going on...
[17:32] <bschaefer> seb128, though you seem to have a much better handle on multiple conversations :)
[17:32] <seb128> lol, you get used to it (or not) ;-)
[17:32] <bschaefer> haha
[17:32] <bschaefer> hopefully soon!
[19:43] <om26er> is there a way to turn off the screen on mako while using Mir ?
[19:43] <cub> How long during tomorrow will the multi-monitor test run?
[19:48] <cub> as per https://wiki.ubuntu.com/Mir/MultiMonitorTesting .
[21:10] <kgunn_> robert_ancell mornin
[21:10] <robert_ancell> kgunn_, hey
[21:10] <robert_ancell> kgunn_, robotfuel do you want just bypass or bypass + MM?
[21:11] <kgunn_> robert_ancell bypass
[21:11] <robotfuel> robert_ancell: let me know when it's ready so I can start tests
[21:11] <robert_ancell> kgunn_, ok, we've never had just bypass before, but can spin that up - is there any need for bypass+MM anymore? I'll reuse qa-testing if that's OK
[21:11] <kgunn_> robert_ancell at least mm+bypass didn't seem to work on Ati
[21:12] <kgunn_> robert_ancell to be clear qa-testing not qa-testing2
[21:12] <robert_ancell> kgunn_, so qa-testing has always been bypass+mm, I'll convert it to just bypass
[21:13] <robert_ancell> and qa-testing2 stays unchanged at mm
[21:13] <kgunn_> robert_ancell ah might be true for mir part
[21:13] <kgunn_> robert_ancell just need a working bypass
[21:13] <robert_ancell> ok, will do
[21:14] <kgunn_> robert_ancell I didn't try qa-testing on intel - maybe it works
[21:14] <kgunn_> ?
[21:15] <kgunn_> robert_ancell thanks
[21:16] <kgunn_> robotfuel so is archive xmir working on that machine ?
[21:16] <kgunn_> might be good to verify that
[21:16] <robotfuel> kgunn_: on which machine?
[21:16] <robotfuel> kgunn_: the radeon webcam machine?
[21:19] <robotfuel> it worked this morning http://<IP_ADDRESS>:8080/view/openarena/job/openarena-benchmark-ps-radeon-hd5750-le-xmir/43/
[21:22] <robotfuel> robert_ancell: http://<IP_ADDRESS>:8080/job/qa-ppa-guitoolkits-ps-intel-3000/ intel worked with the qa-testing ppa
[21:22] <robotfuel> kgunn: ^
[21:26] <robert_ancell> robotfuel, kgunn, ppa:mir-team/qa-testing is being converted to bypass only. Will take ~40 mins
[21:33] <kgunn> robert_ancell: thanks....hmmm, just wondering....earlier there were xorg packages there with latest ati drivers...wonder if those were the issue ??
[21:34] <kgunn> robert_ancell: since no one has seen mm on ati yet...just thinking aloud
[21:38] <robert_ancell> kgunn, right, they were needed for mm support and they didn't work. There are updated drivers in qa-testing2 that do work
[21:39] <robert_ancell> kgunn, right, rsalveti was using the MM3 ati driver from qa-testing2 and it worked for single monitor, but I don't think he had any success with multi-monitor
[21:42] <rsalveti> just in mirrored mode, booting with both monitors connected
[21:42] <rsalveti> kgunn: I updated the qa tracker with the results
[21:44] <kgunn> rsalveti: thank you
[21:49] <rsalveti> no worries
[22:11] <kgunn> robotfuel: qa-testing any moment now
[22:12] <robert_ancell> LP, faster with the publishing already :)
[22:12] <robotfuel> heh
[22:12] <robert_ancell> Note, there's a u-s-c upload after Mir is done, but that doesn't take too long
[22:14] <kgunn> robert_ancell: right!
[22:32] <robotfuel> robert_ancell: is it ready?
[22:32] <robert_ancell> robotfuel, almost...
[22:39] <robert_ancell> kgunn, robotfuel, published! Note, I haven't run these packages yet, this is just lp:mir+lp:~vanvugt/mir/bypass and lp:unity-system-compositor
[22:41] <robotfuel> ok I'll run the tests
[22:41] <robert_ancell> Hmm, 1:20 to update - I'll revise my estimate for next time
[22:41] <robotfuel> robert_ancell: kgunn do you care which test runs first?
[22:45] <robert_ancell> I don't
[22:53] <kgunn> robert_ancell: i'm going to step out...but the main thing is to see radeon X vs Xmir vs Xmir+bypass....if xmir/xmir-bypass is better than X...why?
[22:53] <kgunn> please email share with tvoss any findings
[22:54] <robert_ancell> kgunn, what is this for?
[22:54] <robert_ancell> robotfuel, do we have the radeon X / XMir numbers at the moment?
[22:55] <robotfuel> robert_ancell: http://reports.qa.ubuntu.com/graphics/openarena/
[22:56] <robert_ancell> robotfuel, ta
[22:57] <robotfuel> robert_ancell: you can doubleclick on a bar to go to the jenkins build results for that benchmark.
[22:57] <robert_ancell> clever!
[22:57] <robotfuel> robert_ancell: the screen looks messed up on the radeon machine
[22:57] <robotfuel> kgunn: ^
[22:58] <robert_ancell> :(
[22:58] <robert_ancell> yeah, I can see it on the video
[22:59] <robert_ancell> robotfuel, can you confirm the versions of packages on that machine?
[22:59] <robotfuel> robert_ancell: I'll pastebin, one second
[22:59] <robert_ancell> ta
[23:03] <robotfuel> http://paste.ubuntu.com/6034625/ <- robert_ancell
[23:03] <robert_ancell> robotfuel, they look correct
[23:04] <robert_ancell> robotfuel, was the video corrupt at all times or just during parts of the test?
[23:04] <robotfuel> robert_ancell: after rebooting in to xmir
[23:04] <robotfuel> robert_ancell: I'll reboot again to double check
[23:04] <robert_ancell> robotfuel, right
[23:06] <robotfuel> robert_ancell: it's bad after reboot
[23:07] <robert_ancell> robotfuel, the previous XMir run is using reasonably old Mir packages - we should run that again and confirm if it's the main archive that's broken and not bypass that's making the difference
[23:07] <robotfuel> robert_ancell: xmir tests ran okay earlier today.
[23:07] <robert_ancell> the last run was mir 0.0.9+13.10.20130821.1-0ubuntu1, archive is 0.0.9+13.10.20130822-0ubuntu1 and  0.0.10+13.10.20130827.1-0ubuntu1 is in proposed
[23:08] <robotfuel> *xmir from archive
[23:08] <robert_ancell> actually, everything seems held up in proposed - anyone know why that is?
[23:08] <robert_ancell> olli, ^?
[23:09] <robotfuel> robert_ancell: I think it was because of xmir crashing on didrocks ati machine
[23:10] <robert_ancell> robotfuel, I thought we'd resolved that / weren't going to block on it
[23:11] <robotfuel> robert_ancell: I need to commute home, I have to restart the camera in a screen session, you'll have to refresh
[23:11] <robert_ancell> robotfuel, this is just qa-ppa right?
[23:12] <robotfuel> robert_ancell: yes
[23:12] <robert_ancell> robotfuel, and just cancel jobs by right clicking on the X beside them? i.e. the machine will restart automatically?
[23:12] <robotfuel> robert_ancell: yes
[23:13] <robert_ancell> ok, thanks!
[23:13] <robotfuel> robert_ancell: the machine will restart automatically on the next test run
[23:13] <robert_ancell> robotfuel, what are all the new jobs? Still doing a run all?
[23:14] <robert_ancell> and which machine is the camera pointed at?
[23:14] <robotfuel> robert_ancell: I didn't add all the new jobs to run all.
[23:14] <robert_ancell> ok
[23:14] <robotfuel> robert_ancell: the machine is pointed at ps-radeon-5750-le
[23:14] <robotfuel> *ps-radeon-hd5750-le
[23:15] <RAOF> Ok, so XMir really does not like the bypass branch.
[23:17] <robert_ancell> RAOF, you're seeing it too?
[23:18] <RAOF> robert_ancell: Oh, what in particular? Crazy horizontal missing rendering?
[23:19] <robert_ancell> RAOF, yep horizontal corrupt lines
[23:20] <RAOF> I wonder if that's not missing flushing.
[23:21] <RAOF> But it doesn't look like any corruption that I'm familiar with.
[23:21] <robert_ancell> RAOF, you have some ati hardware right?
[23:21] <RAOF> robert_ancell: I do, yes.
[23:21] <robert_ancell> RAOF, can you confirm the mir from -proposed works?
[23:22] <robert_ancell> we're somewhat behind because I think there's a block on mir
[23:22] <RAOF> Sure.
[23:23] <robert_ancell> robotfuel, still there?
[23:23] <robotfuel> robert_ancell: the run all test for qa-ppa will now run all openarena, guitoolkits and nexuiz tests for the qa-testing ppa
[23:24] <robert_ancell> robotfuel, the camera link doesn't seem to be working
[23:24] <robotfuel> robert_ancell: I just restarted it in screen
[23:24] <robert_ancell> ah, ok now
[23:24] <robert_ancell> hi!
[23:25] <robert_ancell> interestingly the video only seems to work in chromium, not firefox
[23:25] <robotfuel> I am using simplecv to stream video
[23:26] <robert_ancell> RAOF, is that the type of corruption you were thinking of?
[23:27]  * robotfuel commutes home
[23:27] <robert_ancell> robotfuel, bye, thanks for your help!
[23:28] <RAOF> robert_ancell: No; the corruption I was thinking of is more transient.
[23:28] <RAOF> And is on intel.
[23:28] <robert_ancell> ah
[23:35] <robert_ancell> thomi, would it be possible to make jenkins have a job that uses -proposed?
[23:36] <robert_ancell> I'd like to test the Mir -proposed packages
[23:36] <thomi> robert_ancell: sure, robotfuel has a fancy script.
[23:36] <RAOF> robert_ancell: Just to check, you want me to test just stuff in saucy-proposed on ati?
[23:36] <thomi> what kind of timeline would you like that by? is it OK if I ask Chris to do it tomorrow, or do you need it today?
[23:38] <robert_ancell> thomi, ideally now...
[23:38] <robert_ancell> RAOF, yes
[23:39] <robert_ancell> I'm a bit worried that RAOF wont reproduce the problem and we'll be unsure if it's a bypass issue on that QA machine or a Mir issue
[23:41] <ricmm> hey guys, where do we stand with stuff not going from proposed to main?
[23:41] <robert_ancell> ricmm, I don't know what it's blocked on now, I'm trying to find out
[23:42] <RAOF> robert_ancell: usc in -proposed seems to be built against the wrong version?
[23:42] <robert_ancell> RAOF, is it built against the main version of mir?
[23:43] <robert_ancell> ricmm, is there a particular feature you need to depend on?
[23:45] <RAOF> robert_ancell: Oh. There *is* no usc in proposed!
[23:45] <robert_ancell> RAOF, ah, that's going to mess shit up
[23:45] <RAOF> Yes indeed :)
[23:45] <robert_ancell> thomi, ok, -proposed wont work on Jenkins anyway, so no need to do that
[23:46] <ricmm> robert_ancell: yea, the lifecycle stuff that landed a couple of days ago
[23:46] <robert_ancell> RAOF, who do we ask / what channel to find out why a package has a block on it?
[23:47] <RAOF> #ubuntu-devel or #-release would work.
[23:48] <robert_ancell> RAOF, ah, -release was the name I couldn't remember
[23:48] <robert_ancell> thanks!


[00:44] <C1sM0> Hello, Does anyone know if I can do the "Test-case Live Session Persistence" while booting from a USB device?
[00:54] <smartboyhw> C1sM0: Of course!
[00:57] <C1sM0> smartboyhw but I don't see the "The Startup Disk Creator" application. Furthermore, I believe the USB device that I am using is only 2GB
[01:02] <smartboyhw> eh?
[01:02] <smartboyhw> C1sM0 you have a vanilla Ubuntu systen right?
[01:03] <C1sM0> yes
[01:03] <C1sM0> Xbuntu
[01:04] <smartboyhw> C1sM0: That's a NO:P
[01:04] <C1sM0> =(
[01:05] <C1sM0> what do you mean by vanilla?
[01:07] <smartboyhw> C1sM0: Normal desktop Ubuntu. Not a flavor like Xubuntu. Anyways just install usb-creator-gtk from terminal should get you that.
[01:10] <C1sM0> Ok this is my confusion. I have Xubuntu 12.04 installed on my computer.
[01:10] <C1sM0> I already have "Startup Disk Creator" and "TestDrive"
[01:11] <smartboyhw> C1sM0 uh huh
[01:12] <C1sM0> so I grab an image of Xubuntu 13.04 and installed on the usb
[01:12] <C1sM0> I rebooted with the usb in place and follow the testcase
[01:14] <C1sM0> on the third section of the testccase "Live Session Persistence" asks to create a partition and use the "Startup Disk Creator"
[01:15] <C1sM0> am I missing something? or I am doing it wrong?
[01:27] <smartboyhw> no.
[01:29] <C1sM0> so the last part is actually what you do before testing the image, right?
[01:31] <smartboyhw> yep.
[01:31] <C1sM0> now if in any moment one of the steps does not give the right results the test-case fail, right?
[01:32] <smartboyhw> C1sM0 yes sure.
[01:33] <C1sM0> Ok. Thank you smartboyhw
[04:09] <wxl> shadeslayer: thx, but imagine no internet connection.
[05:08] <smartboyhw> Hey Noskcaj!
[05:09] <Noskcaj> hello smartboyhw
[05:09] <smartboyhw> Noskcaj: What do you think of the "release party" proposed?
[05:10] <Noskcaj> smartboyhw, sounds like a greate idea, if i can make it.
[05:10] <smartboyhw> Noskcaj: :)
[05:10] <Noskcaj> only problem is ANZAC day is on the 25th
[05:11] <Noskcaj> thanks for helping me set up for membership BTW
[05:11] <smartboyhw> Noskcaj: :)
[05:11] <smartboyhw> Noskcaj: The party is on the 26th…
[05:12] <smartboyhw> Noskcaj, you saw my latest post on my blog?
[05:12] <Noskcaj> smartboyhw, i should eb able to make it then, as long as school isn't back. and no
[05:14] <smartboyhw> Noskcaj: Grrr go to smartboyhw.tk/wordpress_smartboyhw
[05:14] <smartboyhw> And have a look at the latest post:P
[05:14] <Noskcaj> i will, i didn;t know you had a blog
[05:15] <smartboyhw> Noskcaj: I set it up to post to Planet Ubuntu & Planet KDE
[05:15] <Noskcaj> ok
[05:15] <smartboyhw> I did quite a few (10 I think) of posts
[05:17] <smartboyhw> Noskcaj: I mentioned you in the blog post:P (Indeed you are the reason behind this post)
[05:21] <Noskcaj> yay, i haven't had time to read it. i will soon
[05:24] <Noskcaj> smartboyhw, so you know, my name is jackson. i just reversed it for the launchpad login
[09:22] <smartboyhw> Uh oh, iso.qa.ubuntu.com is down:(
[12:15] <melodie> hi
[12:16] <Dark_light> Hi everyone I'm having some issues with the 13.04 installer
[12:16] <Dark_light> here's the debug log file http://paste.ubuntu.com/5707491/
[12:18] <melodie> Dark_light that would be /var/log/installer ?
[12:18] <Dark_light> melodie: yep /var/log/installer/debug
[12:18] <melodie> what about - referring to https://wiki.ubuntu.com/DebuggingUbiquity#Getting_log_files_manually the files /var/log/partman and /var/log/syslog  ?
[12:19] <Dark_light> there's no /var/log/partman and /var/log/syslog
[12:19] <Dark_light> oh wait
[12:19] <Dark_light> they are files
[12:19] <Dark_light> not folders
[12:19] <Dark_light> lol
[12:20] <Dark_light> I'll pastebin them right now
[12:20] <Dark_light> partman: http://paste.ubuntu.com/5707537/
[12:20] <Dark_light> syslog: http://paste.ubuntu.com/5707538/
[12:23] <melodie> Dark_light now you just have to wait until someone saavy grabs your logs and use them to improve Ubuntu 13.04
[12:23] <melodie> reminder : this is the version of last night, the Ubuntu Unity one, right ? 32 or 64bits ?
[12:23] <Dark_light> 64bits
[12:24] <melodie> Ubuntu Unity of last night ?
[12:24] <Dark_light> yes
[12:24] <melodie> good
[12:24] <Dark_light> I guess last night I mean it depends from the timezone :P not the latest but latest-1 just to be clear
[12:24] <melodie> try to let the chan opened
[12:25] <melodie> I think there is a new one each 24 hours
[12:25] <melodie> I have to go, continue well
[12:28] <Dark_light> thanks bb
[12:37] <smartboyhw> Dark_light, report a bug:)
[14:04] <Dark_light> humm why is noone working on this https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1081245 ?
[14:04] <smartboyhw> Dark_light, hmm
[14:04] <smartboyhw> Dark_light, ask in #ubuntu-installer.
[14:04] <Dark_light> oh apparently someone is in #1081245
[14:04] <Dark_light> I didn't notice it was a duplicate
[14:04] <smartboyhw> Dark_light, LOL :P
[21:28] <Noskcaj> i've marked bug bug 1088054 as fixed and made a "won't fix" bug for what happens when you maximize that
[21:29] <Noskcaj> xnox, can you mark bug 1168970 as won't fix?
[22:07] <Noskcaj> phillw, i'm running lubuntu alternate, i've found no bugs in the installer so far, but plenty in the website
[22:10] <phillw> Noskcaj: I'm having an issue with http://linuxpoison.blogspot.co.uk/2011/06/how-to-upgrade-ubuntu-using-alternate.html I have asked about this before, but as we do not have a an entry for http://iso.qa.ubuntu.com/qatracker/milestones/243/builds/41977/downloads I will ask for further detaiils
[22:15] <Noskcaj> phillw, interesting. i don't have an install to test that on though. the problem i've found is that the first half of the alternate testcase is copy/pasted from an normal testcase, also, it still doesn't use the "FAMILY" link, it just says "Ubuntu" or in the one i just changed "Lubuntu"
[22:15] <Noskcaj> also "utc" needs to be capitalised
[22:22] <Noskcaj> there, it's swapped to "FAMILY", no someone needs to get the top half done properly
[22:36] <SergioMeneses> phillw, I'm working on bug 1161953 but I dont see any problem


[22:46] <[Ubik]> cyberanger: just don't hook them up to 48V passive PoE...  SOMEONE here in the office did that... and said we had a bad AP because it wouldn't power up...
[22:46] <[Ubik]> I did minor surgery (forcible removal of a particular diode) and it works again
[22:47] <[Ubik]> so now it ended up in a maintenance closet here as a repeater for our wifi...  we have coverage from our office pretty much to the front of the building now... important when we use the conference room for meetings or I go up there to get coffee while on a wifi call (previously it would drop, even with that el crappy linksys extender... this is now an AP in wireless uplink mode and is seemless)


[13:26] <gary_poster> bac benji danilos, I'll look at kanban in a sec, & call in 4
[13:28] <gary_poster> who's doing "identical displays of subscriptions" in FW 1: active?
[13:29]  * gary_poster guesses danilos
[13:29] <danilos> gary_poster, that's right, sorry
[13:29] <gary_poster> np :-)
[13:31] <gary_poster> bac and benji are you rejecting my Skype calls? :-)
[13:37] <benji> gary_poster: should I put this branch on ~yellow to make it easier for us to collaborate?
[13:37] <gary_poster> benji, do you think your branch is in a state that it could be merged, and then we could land separate things on top of it?
[13:38] <gary_poster> (In general, I'd prefer to do that, and feature flags let us)
[13:38] <benji> at the moment it puts placeholder text in the spots, but I think if I changed that it would be sane; or we could accept it as-is if we're cool with it because it's behind a feature-flag
[13:39] <gary_poster> Yeah, I think the only constraint should be that what you have that is supposed to be working is tested before it is merged
[13:39] <benji> yep, it's fully tested
[13:39] <gary_poster> (I don't thin we need tests for the placeholder text, for instance :-) )
[13:40] <gary_poster> awesome
[13:40] <gary_poster> I'm in favor of landing as is
[13:40] <benji> heh, no the tests don't depend on the text
[13:40] <benji> k, I'll do that
[13:40] <benji> and then the plan is that you guys will work from devel?
[13:41] <gary_poster> cool :-) (and even moving a separate card along the kanban board for "direct action pattern" (or "infrastrcture" or something like that)
[13:41] <benji> sounds good
[13:41] <gary_poster> since landing will take a while I'd work from your branch
[13:41] <gary_poster> But then I'd get it reviewed with your branch as a dependency if it is not in devel yet
[13:41] <benji> actually, I should probably mutate my current card to that one and then add a new one for the mute action that I'm adding
[13:42] <benji> k
[13:42] <gary_poster> Yes, that does make sense
[13:53] <bac> gary_poster: did you try to install natty?
[14:10] <gary_poster> bac, no.  problems?
[14:10] <bac> gary_poster: it installed fine under vmware but no unity
[14:10] <bac> as vmware doesn't have the required 3d drivers yet
[14:11] <gary_poster> yeah, that's what I expected, bac
[14:11] <bac> so it is a bit of a wash
[14:11] <gary_poster> might work in parallels
[14:11] <bac> yeah
[14:11] <gary_poster> I'm still using server version
[14:11] <bac> i've read it may work in virtualbox...but i'm dubious
[14:11] <gary_poster> I readthat too
[14:11] <gary_poster> deryck said he might go back to dual boot
[14:11] <bac> i meant to try on metal but the weekend slipped by and i didn't want to risk it
[14:12] <gary_poster> yeah
[14:13] <gary_poster> benji, lp:~benji/launchpad/direct-personal-subscription-actions-scaffolding right?
[14:13]  * danilos -> lunch
[14:13] <benji> gary_poster: yep
[14:13] <gary_poster> cool
[14:19] <benji> gary_poster: should there be a new feature flag for the scaffolding?
[14:19] <gary_poster> benji, no, we feature flag the link to this page
[14:19] <gary_poster> I think that's good enough
[14:19] <gary_poster>  the page was already "broken"
[14:19] <gary_poster> in the sense that it didn't make sense
[14:19] <benji> yep, I agree; I just wanted to make sure it wasn't turned on in production; thanks
[14:20] <gary_poster> cool, np
[14:25] <gary_poster> benji, do you have a plan for what to do after a change has been made that requires another functionality to be available?
[14:25] <gary_poster> i.e.
[14:25] <gary_poster> I go to the page and mute
[14:25] <gary_poster> this is done via ajax
[14:25] <gary_poster> now I need to be able to unmute
[14:25] <gary_poster> "no" is fine, but we should talk through it if so
[14:26] <benji> I've given it a little thought, since the current functionality works off of the cached values and those should be updated by AJAX calls, we can just re-run the code to generate the description and the IDs of the subscription controls that should be visible
[14:27] <gary_poster> so, like, collapse, redraw, expand?
[14:28] <gary_poster> I guess the nice thing is that we only have to do that for the direct/personal stuff
[14:28] <gary_poster> we can leave the "other" bits to handle themselves
[14:28] <benji> right
[14:29] <gary_poster> ok that sounds doable.  Thanks
[14:31] <gary_poster> benji, sorry another question.  You had worked on code that tried to hook up the current subscribe-with-notification-level stuff before I asked you to move to the scaffolding.  What's the status of that work?  What's your opinion on reuse?  Does this warrant a call?
[14:33] <benji> gary_poster: status: not in good shape, prognosis: decent, reccomendation: it shouldn't be too hard to refactor the current code until what we want is easy
[14:35] <gary_poster> ok thanks benji.  not really looking forward to that :-P but that should be done.  I guess I'll try that (so, "subscribe_action" and "change_subscription_action" and, unfortunately, "unmute_action" are all tied into this).  Any pointers on where to get started?  I have not looked at this code at all.
[14:36] <benji> gary_poster: after I prepare to review the branch I'll look at it and see what memories it jogs
[14:36] <gary_poster> ok thanks
[14:44] <benji> gary_poster: I think the state of my hacking branch tells the story of what I know at this point: http://pastebin.ubuntu.com/595519/
[14:44] <benji> if not, feel free to ask me to make up for its story telling deficiencies
[14:45] <gary_poster> benji, .log('cool, thanks, that looks helpful')
[14:45] <benji> :)
[14:46] <benji> gary_poster: that code currently dies wanting to find a spinner, but I think it's close to working
[14:46] <gary_poster> cool
[16:03] <bac> gary_poster: you know what this warning means?  http://paste.ubuntu.com/595547/
[16:05] <gary_poster> bac, I understand some of the elements (for instance, I'd have an idea on what to do to find the unhelpfully described "milestone-edit.pt.validate_widgets") but not the main point, no. :-/
[16:05] <bac> gary_poster: ok.  i didn't introduce it but i was curious
[16:05] <gary_poster> cool
[16:05] <bac> gary_poster: putting my milestone branch up for review now
[16:06] <gary_poster> great!
[16:06]  * gary_poster is staring at largely untested JS with concern and potential dithering
[16:09] <gary_poster> The bug unmute story really is unpleasantly confusing
[16:23] <gary_poster> benji, this code we are trying to reuse makes me sad :-(
[16:23]  * gary_poster goes to go have lunch
[16:23] <gary_poster> :-D
[16:23] <benji> heh
[17:42] <danilos> gary_poster, the big branch is landing, I've still got https://code.launchpad.net/~danilo/launchpad/duplicate-pillars-subscriptions/+merge/58135 up for review
[17:42] <gary_poster> danilos, great.  You need me to shepherd that one through, so you can head out?
[17:44] <danilos> gary_poster, yeah, please :)
[17:44] <gary_poster> danilos, I think I'll claim it so I can be sure to actually feel productive about something today :-P
[17:44] <gary_poster> good luck on the test
[17:44] <gary_poster> talk to you Thursday
[17:49] <gary_poster> danilos, approved with no changes; going to try and land
[17:51] <danilos> gary_poster, cheers
[17:51] <danilos> gary_poster, there was a conflict, merged, and lint is happy now :)
[17:51] <gary_poster> heh, ok thanks
[18:39] <bac> gary_poster: i'm free to help now.  where should i start?
[18:39] <gary_poster> bac, /me looks, one sec
[18:42] <gary_poster> bac, unless benji has another suggestion, I suggest you branch lp:~benji/launchpad/direct-personal-subscription-actions-scaffolding (which he will land separately, so this will be a dependency of your branch), merge in devel, and then look in lib/lp/bugs/javascript/subscripton.js.
[18:42] <gary_poster> I suggest you work on real implementations for unsubscribe_action and unsubscribe_with_warning_action .
[18:42] <gary_poster> benji, agree/disagree/suggest?
[18:42]  * bac branches
[18:42]  * benji has abort/retry/fail flashbacks.
[18:42] <benji> agree
[18:42] <gary_poster> bac, tests are in lib/lp/bugs/javascript/tests/test_subscription.js
[18:42] <bac> great
[18:43] <gary_poster> :-) thanks benji
[18:43] <bac> benji: will you be able to look at my branch soonish?  it's ever so tiny
[18:44] <benji> bac: sure, if it's small I'll do it now
[18:44] <bac> 64 lines of diff, i think
[18:45] <gary_poster> benji, if we are reusing the existing stuff, and I'm trying hard to continue to make myself do so, then mute is tied in with unmute, which is tied in with subscribe.  But nevermind...I'll try to ignore. :-)
[18:46] <gary_poster> Or divide them up in that portlet code
[18:47] <benji> gary_poster: yeah, it's a bit of a tangle, I was going to apply the old saw of refactoring until what you want to do is easy
[18:48] <benji> bac: done
[18:48] <bac> gracias
[18:51] <benji> el gusto es mío
[18:51] <gary_poster> heh
[18:52] <gary_poster> my lack of spanish but knowledge of cognates translated that as "the taste is mine"
[18:52] <gary_poster> But I suspected that "pleasure" was a better translation than "taste"
[18:54] <benji> right; I like "it's my plesure" better than "it's nothing" but that's probably my english-centric brain misapplying idioms
[18:55] <benji> I would really like to learn more Spanish; taking German in HS/college was such a bad choice.
[18:55] <gary_poster> :-)
[19:26] <benji> and I'm back (total machine freeze)
[19:26] <gary_poster> meh
[19:26] <gary_poster> benji, fwiw, I've looked at what the current susbscription stuff does, and what we need, and I've decided to not reuse.  They are too dissimilar IMO.  I've made a list of what we want for the three scenarios that I have claimed
[19:27] <gary_poster> I'm not sure how it will work with what we have exactly, but I'm just going to run with it so I can make some progress.  I have a goal, at leats
[19:27] <gary_poster> least
[19:28] <benji> cool, at least we tried
[19:28] <gary_poster> yeah
[19:28] <gary_poster> you did fix a bug in your branch though
[19:28] <gary_poster> I don't want to lose that
[19:52] <gary_poster> bac are you at UDS Mon and Tues?
[19:52] <bac> yes
[19:53] <bac> gary_poster: you have a mission for me?
[19:53] <gary_poster> bac, Brian Murray wants us to present our work there.  He actually wants to help present.  Would you be willing to work with him on that?
[19:54] <bac> gary_poster: sure!
[19:54] <gary_poster> awesome
[19:54] <gary_poster> thank you
[19:54] <bac> np
[19:54] <gary_poster> I'll email folks
[19:54] <bac> i find it easier to have a structured thing to do than just mill about trying to engage people in discussions about launchpad registry
[19:55] <gary_poster> heh, I can understand that
[19:55] <bac> so, jorge, any thoughts on the team participation table?
[19:55] <gary_poster> :-)
[19:56] <gary_poster> bac, do you know bdmurray already?
[19:56] <bac> yep
[19:56] <gary_poster> cool
[20:13] <bac> gary_poster: in your email you mention me being head down for this week and the next two.  as a reminder, i leave for budapest on tuesday may 3rd
[20:13] <gary_poster> bac, lol
[20:14] <bac> ?
[20:14] <gary_poster> bac, laughing at myself, sorry.  feel free to correct.  If you are not head down for the third week, but just for this and next, I think that will work out fine for us.  Is that OK, do you think?
[20:15] <bac> yes, i just didn't want you to be surprised
[20:15] <gary_poster> cool, thank you
[20:17] <gary_poster> benji, I'm changing some of the framework.  basics are still there but
[20:17] <gary_poster> (1) I'm adding a separate box for actions that increase email quantity, and dividing up the actions into the two kinds (and only showing each box when appropriate);
[20:17] <gary_poster> (2) I'm adding some actions to separate out some of the actions I claimed into individual nodes (some of which will go into the two boxes);
[20:17] <gary_poster> and (3) I'm changing the action functions to use the action_ids mapping (and making those values not have the # prefix).
[20:17] <gary_poster> I'll make that as a separate branch
[20:17] <gary_poster> or at least that's my intent now
[20:17] <gary_poster> does that sound ok?
[20:18] <gary_poster> note that we can tweak this; it's just a step in the right direction, or at least a direction that I can see now
[20:21] <benji> gary_poster: that sounds fine; I'm especially curious to see the results of dropping the #s
[20:22] <gary_poster> benji, cool thanks.  dropping the #s just means I can use the "constant" strings when I construct the nodes; I'll have to add the # back when I use the string as a selector of course
[20:23] <benji> I suspect I'll dislike that, but I dislike lots of things and still manage to forge ahead :P
[20:23] <gary_poster> heh
[20:23] <gary_poster> I'm just reusing your action_ids
[20:23] <gary_poster> but ok
[20:23]  * benji tries not to turn into Fred Drake.
[20:23] <gary_poster> :-)
[20:23] <gary_poster> what is his stance on this?
[20:24] <benji> grumpy
[20:24] <gary_poster> lol
[20:24] <gary_poster>  I see
[20:27] <gary_poster> benji, I think we should assemble some JS differences of opinion and present them to bac for discussion, perhaps at Thunderdome or wherever he thinks is appropriate.  I think string constant identifiers are very good for certain cases, and this fits into those certain cases though I have not taken the time to identify why yet.
[20:27] <gary_poster> Similarly, I disagree with danilos about not reusing var, and about his stance on not reusing values returned from appendChild.  Settling down on some standards probably would save time and annoyance in the long run.
[20:27] <gary_poster> anyway...
[20:29] <bac> gary_poster: are you suggesting that b/c i led such scintillating and productive sessions in dallas?
[20:29] <bac> :), btw
[20:29] <gary_poster> bac, heh, yes...and you are the head of the reviewers, yes? :-)
[20:30] <bac> of course those two hours of pain in dallas have spared us the weekly meeting, so i guess it was a good trade off
[20:30] <gary_poster> yeah, I think so
[20:30] <benji> it's worth a shot; we have a lot to reconcile I think between: our stated desire not to nitpick in reviews, our still quite large python style guide, and our lack of a JS style guide
[20:31] <gary_poster> yeah :-/
[20:31] <gary_poster> If we don't have an LP agreement, I think we need a squad one
[20:31] <bac> benji: and our lack of common expertise in JS
[20:31] <gary_poster> yeah
[20:32] <benji> bac: yep; you know I wonder if there isn't something like "The Seven Stages of Code Review"
[20:32] <gary_poster> ...we need a squad one just so that we can know when to squelch the desire to refactor, or indulge in it
[20:32] <gary_poster> heh
[20:32] <gary_poster> refactor/reformat/...
[20:33] <bac> gary_poster: was danilos against chaining in general or just with appendChild, or did i misread?
[20:34] <gary_poster> bac, I don't know if he took his opinion beyond appendChild.  Even just within the world of appendChild, chaining is pretty idiomatic afaict
[20:34] <benji> unfortunately we'd still have to decide on what format to adopt; do whatever you feel like doesn't seem like an equilibrium
[20:34] <bac> the way we're doing it is pretty jarring to see the first time (multi-line chaining) but is quite readable
[20:34] <gary_poster> agreed
[20:34] <gary_poster> heh, to both
[20:35] <gary_poster> that is, agreed to both
[20:36] <benji> yeah, I'm pretty sure the multi-line chaining is a win; personally I've been experimenting with puttint nothing more than '<tag/>' in the Y.Node.create() call and doing everything with methods from there.  It seems easier to read and reason about thus far.
[20:36] <gary_poster> I noticed that and liked it
[20:36] <gary_poster> I wondered if all browsers support it
[20:36] <gary_poster> IE 7/8 for instance...to the degree that we care
[20:37] <gary_poster> Obviously I didn't, much :-P
[20:37] <benji> I'm pretty sure that pattern is supported on all of YUI's "grade A" browsers.
[20:37] <gary_poster> Francis says we support Firefox, because that's what we have automated tests for
[20:37] <gary_poster> period
[20:37] <gary_poster> everything else is convenience
[20:37] <gary_poster> all Grade A: great
[20:45] <gary_poster> benji, another one. :-)  Why do you prfer
[20:45] <gary_poster>         var i;
[20:45] <gary_poster>         for (i=0; i<direct_info.increases.length; i++) {
[20:45] <gary_poster>             direct_node.one(direct_info.increases[i]).removeClass('hidden');
[20:45] <gary_poster>         }
[20:46] <gary_poster> over
[20:46] <gary_poster>         for (var i=0; i<direct_info.increases.length; i++) {
[20:46] <gary_poster>             direct_node.one(direct_info.increases[i]).removeClass('hidden');
[20:46] <gary_poster>         }
[20:46] <gary_poster> (that is, why do you not like the var in the for statement?
[20:46] <gary_poster> )
[20:46] <benji> primarily because jslint complains about the first, secondly because it has a point
[20:46] <gary_poster> you mean complains about the second?
[20:47] <benji> the point is that in JS the "var" acts in the local scope, not where the var is placed, it's like "global" in python; you should therefore put them in the place that makes their effect as obvious as possible when reading the text
[20:47] <benji> right
[20:47] <gary_poster> ah
[20:48] <gary_poster> so the second has the effect of the first
[20:48] <benji> right
[20:48] <gary_poster> so therefore write the first?
[20:48] <gary_poster> gotcha
[20:48] <gary_poster> I can buy that
[20:48] <gary_poster> thank you
[20:49] <benji> granted, it's a subtle point and if jslint didn't complain, I might come down on the other side, but since it does it's worth going with the flow
[20:49] <gary_poster> yeah, I'm very happy with "follow what the lint says to do" as a general rule, myself
[20:50] <gary_poster> Though I must admit I didn't care for the optional lint bits he introduces as "the good parts"
[20:50] <benji> my rule is "follow what the lint says to do but figure out why it says what it says so you don't feel like a robot"
[20:51] <gary_poster> don't remember details
[20:51] <gary_poster> yeah sounds good
[20:51] <benji> I haven't payed mutch attention to the good parts; we might have to read his book to figure out why he feels the way he does.
[20:51] <gary_poster> yeah
[20:51] <gary_poster> I've read some about the on the net
[20:51] <gary_poster> them
[21:39] <gary_poster> benji, is it possible that the entire JS test suite wasn't passing in your branch?  I think I might be fixing things in the underlying branch now.  Small stuff, but things that we might all hit.  I could be wrong though.  If you are not sure I'll give it a whirl after I'm done
[21:39] <gary_poster> I mean, is it possible that some of thes tests were failing
[21:39] <gary_poster> even though your new suite was passing
[21:39] <gary_poster> argh, new case I mean
[21:40] <benji> it's possible; I don't recall running the whole thing, so I wouldn't be suprised (and I'm a bad person)
[21:40] <gary_poster> heh, I should have run it before I started
[21:40] <benji> I did run all of the ones in the file I added a case too though (because I don't know how to run just one)
[21:40] <gary_poster> that's what I meant
[21:40] <gary_poster> it seemed like some of them might be failing before I came along
[21:40] <gary_poster> but anyway
[21:41] <benji> I'd be really surprised if that were the case.
[21:41] <gary_poster> if that's the case, we can just land my branch of yours
[21:41] <gary_poster> ok
[21:41] <gary_poster> is your branch already reviewed and such
[21:43] <gary_poster> Maybe I removed the one line
[21:43] <gary_poster> no worries
[22:12] <gary_poster> benji, do you mind if I target my MP specifically to you?
[22:12] <gary_poster> since it is tweaking your initial infrastructure
[22:17] <gary_poster> ooh, you freshened...
[22:20] <gary_poster> benji, it lookslike your merge might have done something bad in structural-subscriptions.js
[22:21] <gary_poster> In some places, it uses namespace._add_subscription_overlay (as is current in trunk I think) and in someplaces it uses add_subscription_overlay
[22:22] <gary_poster> and clean_up is in the wrong place
[22:26] <gary_poster> benji, https://code.launchpad.net/~gary/launchpad/direct-personal-subscription-actions/+merge/58197 fwiw
[22:26] <gary_poster> night all


[11:18] <kklimonda> any chance to get a irc cloak: https://edge.launchpad.net/~kklimonda ? :)
[11:21] <erUSUL> !nicksetup
[11:22] <erUSUL> and wait for someone with the power to do it ...
[11:35] <elky> pretty sure jussi if floating around
[11:39] <jussi> niko: VorTechS marienz staff please cloak kklimonda with an @ubuntu/member cloak. thanks!
[12:21] <nhandler> CkkYou are now cloaked
[12:21] <nhandler> err... kklimonda You are now cloaked
[12:21] <kklimonda> thanks
[15:15] <erUSUL> !intelhda
[15:20] <vish> erUSUL: why do you do that^ often?  [just curious :)  ]
[15:20] <Pici> I have a dedicated window for talking with ubottu myself.
[15:20] <erUSUL> vish: lazyness ;) sorry. (avoid a /msg to ubottu )
[15:21]  * erUSUL apologies
[15:29] <vish> erUSUL: i thought it was bot maintenance ;)
[15:29] <erUSUL> nope; not my job :) i only contributed a few factoids
[15:30] <erUSUL> but can not control the bot
[15:30] <jussi> erUSUL: please use /msg in future
[22:49] <Tm_T> jpds: that doesn't help dealing with his attitude
[22:49] <jpds> Tm_T: Yeah, well...
[22:49] <Tm_T> unfortunately


[07:52] <RichEd> ogra: checking now
[07:55] <RichEd> ogra: looks like it is at 9:00
[07:56] <RichEd> no bridge details yet though
[07:59] <ogra> Where: +44 1793 402663, +1<PHONE_NUMBER>, Bridge: 3, Passcode: 3657331
[08:00] <ogra> err
[09:19] <ogra> RichEd, there ia a mobile meeting today at 16:00 UTC
[09:19] <ogra> we should probably show up there and gather more info
[09:21] <RichEd> i'll try to join ... where is it ? irc ?
[09:21] <ogra> on #ubuntu-mobile
[09:21] <ogra> should i add "netbook image cmpc relation" to the agenda ?
[09:21] <RichEd> yes please
[09:23] <ogra> done https://wiki.ubuntu.com/MobileAndEmbedded/Meeting/20080605
[13:56] <puesto0> hi there
[15:07] <nathan406> I have a compaq presario 2700 and i can hear sound from the speakers but i do from the headset ports
[15:07] <nathan406> i am running the generic
[15:28] <RichEd> nathan406: have you tried a google search against site:ubuntu.com for that ?
[15:29] <RichEd> let me try quick
[15:30] <RichEd> nathan406: did you test with system sound setup or from an app ?


[07:32] <chen_> ...
[09:24] <d_1_stortion> lol
[12:25] <oterrivel> hello
[12:25] <oterrivel> why there is not /etc/init/ttyN.conf ?
[12:26] <oterrivel> would like to disable some virtual terminals
[12:42] <alkisg> oterrivel: distros now use systemd, see e.g. https://unix.stackexchange.com/questions/56531/how-to-get-fewer-ttys-with-systemd
[13:46] <mate|21763> Hello.. Indian languages are not in Ubuntu mate 17.10 (keyboard layout)
[13:48] <mate|21763> help me please
[13:52] <alkisg> sudo dpkg-reconfigure keyboard-configuration
[13:53] <mate|21763> which keyboard should I select?
[13:55] <mate|21763> but still Hindi is not in the list
[13:55] <mate|21763> it is available in ubuntu mate 17.04
[13:58] <mate|21763> Hello.. Indian languages are not in Ubuntu mate 17.10 (keyboard layout) , it was available in ubuntu mate 17.04
[14:05] <mate|21763> Hello.. Indian languages are not in Ubuntu mate 17.10 (keyboard layout) , it was available in ubuntu mate 17.04
[14:34] <oterrivel> thanks alkisg
[14:34] <alkisg> np
[14:52] <devbie> Hi everyone. I'd like to set the system-wide default layout for Ubuntu Mate 16.04. I've already modified the layout for the current (admin) user. I'd like to make it the default layout for all new user accounts. Can anyone help pls? Thx
[15:20] <drwho> Anglais YVERA
[15:25] <drwho> You school stuff
[15:53] <ouroumov> devbie, I don't think there's currently a way to do that that doesn't involve some hacking
[15:53] <ouroumov> devbie, maybe you should consider filing a feature request against MATE Tweak.
[15:54] <ouroumov> devbie, actually it would be nice if everything could be configured globally in MATE Tweak.
[16:02] <alkisg> default layout of what? panel? you can just set a gschema override...
[16:04] <devbie> Hi ouromov, I was just creating a new post in the user forums ('Mate Tweak: setting the default system-wide layout')
[16:05] <devbie> i just want to add the 'log out' applet on the top panel. being able to set this as the system-wide default layout would me that the applet would automatically show in new user accounts
[16:07] <ouroumov> devbie, I think this can be done in MATE Tweak, the forum is OK but you might want to ask about a feature here: https://github.com/ubuntu-mate/mate-tweak/issues
[16:10] <devbie> ouroumov, I'll head there then. Thx
[21:25] <Guest74687> TE AMO LINUX!!!!!!!!!!!!!
[21:26] <Guest74687> Hola como estan?