=== wylde_ is now known as wylde === AfC is now known as AfC|gym [00:53] TheMuso, I mentioned to bryceh in a dm...sure, go ahead and get the case. I don't know where to get it, but get it somewhere and make sure the ARM desktop is working ;) [00:56] Yup, just trying to nut out some way that I can test audio functionality on the board without having to disconnect and reconnect stuff to my speakers all the time. :) [01:03] HDMI audio! [01:03] Yeah, thats one of the dilemmas. My monitor has speakers, buyt only stereo. I'd like to make sure 5.1 works at least. [01:04] Ah. [01:55] Oh wow unity/compiz from the unity team staging PPA starts up sooooo much faster now. [01:55] But I have no window decoration and no keyboard shortcut to get to a window menu to maximise etc. [02:22] RAOF, any idea on why my wayland listeners don't seem to be working? I'm connecting up the key bindings and I can see the events being generate in the weston log but my listeners for them don't work either [02:22] In lp:~robert-ancell/.../weston-compositor? [02:23] y [02:24] RAOF, oh duh. It was my fault [02:27] Heh [02:30] RAOF, so, how do I control which VT weston runs on? [02:31] Hm. I think the current answer is ‘you don't’. [02:32] RAOF, is it weston or wayland (or drm) that is picking the VT? [02:33] Weston [02:35] Specifically, it'll call VT_OPENQRY on /dev/tty0, which I think will return the first available VT? [02:36] RAOF, ok, so we just need to be able to override that like X does [02:36] yes it does [02:36] Oh, there we go. [02:38] You could, if you so chose, open a tty connection yourself, allocate the VT, and then pass the fd of that tty via the WESTON_TTY_FD environment. [02:39] RAOF, uh, can I just pass a --tty to weston? It seems that's what weston-launch does [02:39] That'll change which /dev/tty? it's opening, which is not necessarily the same as the VT, right? [02:40] If my understanding of VT/tty mapping is incorrect, you could certainly just pass --tty to weston. [03:14] RAOF, hmm, I wonder if ConsoleKit is going to freak out having multiple sessions on the same VT [03:14] Probably. [03:14] Let's see if it notices! [03:14] I thought we were moving away from consolekit. [03:14] TheMuso, if we can [03:15] Right. [03:15] I need to check what logind does. When I raised it with Lennart a while ago he didn't seem convinced but the recent stuff on the list suggest he might be more convinced now [03:20] robert_ancell: You might also be interested in the systemd-devel/wayland-dev crossover discussion about VTs and systemd and system-compositors. [03:20] RAOF, yeah, that's what I was referring to [03:20] is it on wayland-dev as well? [03:21] Yeah. [03:23] Well, most of it (grr) [03:38] RAOF, so you were right about the messed up video being a CK issue. I have it working now, BUT I need to know what VT weston is runing on, idealy by me setting it [03:43] Actually, do you really want to be the one setting the VT? What if it's already in use? [03:43] RAOF, I've already picked on [03:43] one [03:44] How do you do that? [03:44] RAOF, and I need to tell it to run on the same VT as Plymouth [03:44] Ah, fair point. [03:45] RAOF, but yes, it is an ugly mess and basically relies on the DM being in control of the VTs [03:47] Perhaps you *do* want --tty 7 [03:47] RAOF, that only appears to be on weston-launch, which we don't use right? [03:47] No; that's a compositor-drm option. [03:47] * RAOF again sees the need for --help to work :) [03:50] RAOF, yay! works great - on the correct VT now and CK all happy [03:50] Woot! [03:50] Now with sound and GL? [03:50] for me, but not for the second user it seems [03:51] The second user runs on the same VT, I take it? [03:51] RAOF, yes, by definition [03:51] ck-list-sessions shows both entries but the first user is active and the second one is not [03:51] And thus the confusion of ConsoleKit begins :) [03:52] I think it needs the VT switch event for it to realise the user has changed [03:52] Good morning [03:52] cyphermox: still here? [03:53] cyphermox: for a start you can run "sudo adt-run --built-tree=. --no-built-binaries --- adt-virt-null" [03:53] cyphermox: unless your test actually has the "build-needed" restriction, then --built-tree -> --unbuilt-tree [03:53] cyphermox: I have a rather small ubuntu server VM where I test what jenkins does [03:54] cyphermox: sudo adt-run --no-built-binaries foo.dsc --- adt-virt-null" [03:54] robert_ancell: I suspect that lightdm is going to end up subsuming consolekit. [03:55] RAOF, that was an idea I had a long time ago, It pretty much has all the information require [03:55] d [03:56] It's what spawns the user sessions, it's what the DE talks to to switch user, it's what the DE talks to to log out... [03:56] RAOF, the issue is it only handles graphical sessions, but it could of course handle text ones with a few small changes [03:57] or perhaps the text consoles will dissapear altogether [03:57] Or be full-screen weston terminals. [03:57] then you have ssh logins [03:57] Which don't actually *need* access to /dev/dri, or /dev/sound, etc? [03:57] practically, no [03:58] Likewise, kernel VTs. [03:58] definitely not [03:58] So I'm not sure if we'd actually lose anything by not tracking non-graphical sessions. [03:59] in the future the kernel could drop support for VTs entirely, which could simplify things quite nicely [03:59] You could just not hook up Ctrl-Alt-F* to switch_vt; it'd have much the same effect :) [04:00] RAOF, yeah, but I imagine VTs add some complexity into the kernel for video drivers etc [04:01] Probably a bit, yeah. I'm not very familiar with that. [04:02] RAOF, my composited desktop is sooo blueee. Need some color management working! [04:02] You should be able to calibrate it :) [04:03] RAOF, I'm guessing xwayland doesn't support it? [04:03] ... [04:03] I'm actually not sure. [04:03] I think it should. [04:04] textmode should always remain [04:04] But it won't recognise your *existing* profile, because weston doesn't pass that info down properly. [04:04] RAOF, oh, I will have to try recalibrating then [04:04] So I think you should be able to load a profile, but it'll be against the "xwayland-1" display. [04:04] is there a decent website on wayland [04:05] i heard it was going to combine compositor and windowmanager, which sounds like a shame because i like the variety of windowmanagers in linux [04:05] ceti331, It depends on how you put it together. wayland is quite generic [04:05] is it a library rather than an executable perhaps [04:05] ceti331, yes [04:06] i mean as you can see from mac OSX (mission control).. and windows 8 - desktop/window managers are hardly a "solved problem" [04:06] (and see the reaction to unity & gnome3) [04:06] there are so many ways to do it... and the great thing about linux is you ahve the option to change it [04:07] ceti331, in a wayland system a display manager is a type of compositor. So you will be able to switch compositors. For applications to work with multiple compositors there will need to be a common protocol [04:07] this is a similar problem to the current X window manager protocol issues [04:08] not sure i undertsand all the jargon [04:08] weston is the first compositor/wm that has been implemented, but it's still early days yet [04:08] i know theres's X which is the low level windowing 'protocol', then the window manager, then desktop-environment... 3 seperate layers [04:08] oh so "Wayland" is a library used in "weston" ? [04:09] ceti331, right, in weston it's a tree of compositors that take the images from their children and paint that upwards. The topmost compositor draws to the screen [04:09] i have to ask, is anyone working on a windowmanager for wayland called "Yutani" ? [04:09] ceti331, no idea [04:09] Not that I'm aware, no. [04:09] so thats a tree of texture generators ? .. all textures being painted by opengl? [04:10] its an obvious name :) [04:10] It is indeed. [04:10] ceti331, so in the obvious weston system there is a toplevel compositor that switches between user sessions, each session has a compositor that draws windows, and each application is a compositor [04:10] "each application is a compositor" ... does this run existing applications [04:10] Well, each application would only want to be a compositor if it needs to embed other windows. Unless you count cairo as a compositor :) [04:11] or is it a very different model [04:11] It's a different model. [04:11] so will it need new GUI toolkits [04:11] RAOF, I have a package for lightdm that has the compositor. I'd like to put it in your PPA. Should we make a LP group and start a new PPA? [04:11] or will GUI toolkits just have a "Wayland" back end [04:11] The latter. [04:11] robert_ancell: Sure! [04:11] e.g. GTK -> (x11, windows, osx, Wayland..) [04:12] ceti331, that already exists [04:12] aah o [04:12] ok [04:12] Both GTK and Qt have a wayland backend (they might be a bit out of date); EFL *also* has such a backend. [04:12] Does that require app-recompile [04:12] RAOF, btw I think the weston screensaver turned on and I can't seem to turn it off... [04:12] robert_ancell: Yeah, I should fix that :) [04:12] does wayland have a low level drawing api... framebuffer access for cpu even [04:12] NO. [04:12] Sorry, no. [04:12] Wayland has no drawing API. [04:12] framebuffer or backbuffer [04:13] whats the interaction between opengl and wayland [04:13] RAOF, can't you just get a memory buffer and fill it in? [04:13] i've liked using the GLUT library for quick graphical programs [04:13] You allocate buffers and hand them to the compositor. [04:13] robert_ancell: Yeah, you can certainly do that. [04:13] I think that's what ceti331 was asking [04:13] robert_ancell: But that's not actually a drawing API :) [04:13] yes [04:14] 'allocate buffers', that answers my question [04:14] presumably you can 'allocatebuffers' that the CPU can modify or poopulate [04:14] still curious to know how openGL will interact with wayland [04:15] The GL implementation will allocate buffers, and hand them to the compositor. [04:15] Pretty much the same way it works now, really. [04:15] so its GL implementations that need to be re-coded in a wayland friendly manner [04:15] whereas at presetnt they are X11 friendly [04:15] Well, you do need a wayland GL implementation, yes. [04:15] that level of change does sound a big scary [04:15] You can't use GLX, obviously, because it's an X11 protocol. [04:16] Eh, EGL already works. [04:16] bit scary, e.g. updating driver support etc [04:16] All the free drivers work now. [04:16] ok [04:16] And it's not particularly difficult to add that support. [04:16] so is wayland something that will streamline some layers [04:17] Yes. [04:17] ceti331, remember wayland wasn't redesigned from scratch - it's built from the components that X was already using [04:17] and perhaps make future maintainance easier [04:17] Also yes. [04:17] understatement of the year [04:17] It'll make developing window managers and compositors *substantially* easier. [04:17] ok, cool. [04:17] second understatement of the year [04:18] i recall apple saying X11 was retarted which is why they did quartz compositor [04:18] It's got some terrible parts, yes. [04:18] so actually having the drawing API built into X is a pain ? [04:18] too much legacy [04:18] obselete primatives [04:20] i was interested in modifying compiz plugins - but haven't as yet managed to run what i've compiled .. just compiling compiz from launchpad, something is broke [04:20] the desktop experience i'm after is: Mountain Lion (apples' expose back to normal, but with horiz row of desktop thumbnails) [04:21] RAOF, hmm, so it seems we don't have administration rights for a PPA in ~ubuntu-desktop [04:21] X11 goes back to mid 1980s ? [04:22] Earlier than that, I think. [04:22] robert_ancell: Yeah, that seems to be my experience too. [04:23] RAOF, that does seem like the right place for it though.. [04:23] Eh, we can just make a new team. [04:23] Although it would be nice to do it under ~ubuntu-desktop. [04:23] wayland uses GLES2.0 ? lovely! [04:23] RAOF, we could put it in lightdm-team. Or an X team? [04:23] pitti: Yo! Would you be so kind as to create a system-compositor PPA under ~ubuntu-desktop? [04:24] RAOF, can we upload to it? [04:24] I don't see why we wouldn't be able to; we're members of ~ubuntu-desktop. We just can't create one, because we're not admins (unlike seb & pitti) [04:25] go pitti! [04:25] looking === robert_ancell_ is now known as robert_ancell [04:25] what can you run with wayland at the moment [04:26] heading out, be back in 45mins or so [04:27] Let there be https://launchpad.net/~ubuntu-desktop/+archive/system-compositor ! [04:27] RAOF, robert_ancell ^ [04:27] pitti: Ta muchly! [04:32] anyone got any ideas what can break a compiz install [04:32] i set out to build a compiz plugin ... originally tried from compiz.org but, being on ubuntu, i figured I should be building compiz from launchpad instead [04:33] since doing that compiz has ceased working... I can't fix it by apt-get re-install. [04:33] I thought i had files left over /usr/local/bin vs /usr/bin - but deleted these and it still doesn't work [04:33] ceti331: do you have a ~/.compiz-1 directory [04:33] ah let me check [04:33] where did you build it to? [04:34] ls ~/.compiz-l ... no [04:34] one not L [04:34] yes that is there [04:34] damn my xchat font [04:35] so if there is something in there, it will be attempted to be loaded by compiz at startup [04:35] if it has a different ABI [04:35] it may crash compiz [04:35] thanks [04:35] anything in the ~/.compiz-1/plugins directory [04:36] oh its only got "sesson" [04:36] but i presume taht is settings taht could break it [04:36] ok, won't be that then [04:36] maybe [04:36] try moving it out of the way [04:36] i'm pretty sure i compiled into "/usr/local/bin [04:36] but compiz installs by default in /usr/bin ? [04:37] my /usr/local/bin is now empty [04:37] i'lll try what you advised.. [04:45] ok removal of ~/.compiz-1 didn't help [04:45] i give in , I will re-install [04:45] re-install distro [04:48] wayland will allow switching between different user sessions more easily? [04:48] I gather Android differs from desktop linux in that every app is a user [04:49] i read that weyland would allow effects/compositing when switching user sessions [05:09] The system-compositor will, yes. [05:16] android makes a user per app for sandboxing i guess [05:30] RAOF, is there a wiki page anywhere with system compositor stuff? If not, I plan on doing something like https://wiki.ubuntu.com/Wayland/SystemCompositor [05:31] robert_ancell: There is not, no. Not as far as I'm aware. [05:44] Gah. Evolution, stop losing my mail server settings! [05:55] RAOF, I've updated https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-system-compositor. There's some spaces where we should file bugs (e.g. the washed out login screen) [05:55] Did I not already file that bug and associate it with the blueprint? Bah. [06:09] good morning [06:19] bonjour didrocks [06:19] hey pitti [06:24] urgh, I have to turn the light on in my working room -- outside it looks like the world is officially going to end now [06:24] haven't needed light for months === tkamppeter_ is now known as tkamppeter [06:36] RAOF: "The Unity panel can't be accessed with the mouse when set to autohide" [06:36] RAOF: is that really a compositor problem? [06:36] starting from today, I cannot access the launcher/dash at all [06:37] they are painted behind all other windows [06:37] pitti: quantal? [06:37] RAOF: and do you really mean "panel" here or "launcher"? [06:37] didrocks: yes, du jour [06:37] pitti: yeah, there is a stacking issue that can happen sometimes, it's not from latest release [06:37] pitti: Yup, it's a compositor problem; specifically, it's because X is receiving it's input from weston, which is clipping it to the visible display, but Unity requires that X get out-of-range inputs. [06:37] pitti, can you upload CUPS to Debian and Ubuntu? Thanks. [06:38] tkamppeter: can do [06:38] RAOF: ah, so it's an underlying change? For me, it started some days ago, with the previous release [06:38] didrocks: No, unless you're running from ppa:~ubuntu-desktop/system-compositor this is nothing to do with whatever crack Unity bug you're running into :P [06:38] RAOF: how bad is the incorrect screen resolution? I'm pondering trying this, but not if I end up with an 1024x768 screen [06:40] pitti: It depends on your display and drm driver, I think. On *my* 1366x768 display weston incorrectly reports 1360x768, so X has left 6 pixels down the right side. [06:42] ah, I can spare 6 pixels :) [06:42] That PPA also won't work until I upload a mesa that'll build to it. [06:44] tkamppeter: reverting the tiff build dep, FYI [06:44] tkamppeter: it's not yet our preferred libtiff, and not appropriate yet for Debian either [06:44] pitti, OK, so the change of -3ubuntu1 is undone? [06:45] argh [06:45] tkamppeter: yes, it will be [06:45] the correct way to switch ubuntu to libtiff5 is to move the "Provides: libtiff-dev" from libtiff4 to libtiff5 [06:46] instead of changing a gazillion source packages [06:46] tkamppeter: also, please don't commit the XSBC-Original-maintainer: bits to Debian [06:46] tkamppeter: I'm looking at the two RC bugs in Debian and the hurd patch, and will upload then [06:49] pitti, the XSBC-Original-maintainer seems to have got in by someone else, I did not do that intendedly. Probably it came in from merging in the changes of -3ubuntu1 from the diff linked in the changelog in Launchpad. [06:49] tkamppeter: right, it did come from the merge; it's correct for Ubuntu uploads, but not for Debian === ubuntu is now known as Nathan_S [07:06] tkamppeter: uploaded [07:09] RAOF: taking the plunge then; I'll blame you if my workstation gets broken :) [07:10] ♪ There's room for your dog ♫ [07:11] RAOF: OOI, why do I need to start lightdm once wtih type=weston and then remove it again? [07:11] RAOF: or is that just the step to disable the compositor again? [07:12] (but still running with the new libraries) [07:12] pitti, thanks. [07:12] Robert wrote those instructions; I believe the answer is so that you get standard X next time. [07:12] ah, ok [07:12] so, reboot, brb (hopefully) [07:12] It'll not work yet [07:13] Still no functioning mesa! [07:13] pitti: Ah, I see what's confusing. “When done” means “Once you're done testing” [07:13] I see that we've not got appropriate version dependencies on the packages ;) [07:26] hey desktoppers [07:26] RAOF: hm, no joy here [07:27] RAOF: after stopping/starting lightdm, my external TFT went black with "frequency not supported", and the internal one showed the "x failed to start" dialog [07:27] RAOF: after reboot, everything went completely black [07:27] You clearly missed the bit where I said “this is not actually going to work yet, until I fix mesa” [07:27] I disabled the "weston" seat type again [07:27] Sorry about that. [07:27] RAOF: oh :) [07:28] RAOF: robert sent out a call for testing a little too early then [07:28] Oh. He sent a call for testing out to the mailing list? [07:28] Ooops. [07:29] RAOF: https://lists.ubuntu.com/archives/ubuntu-desktop/2012-July/003890.html [07:29] RAOF: well, he did say to contact you first [07:30] Time to reply to that and say "not just yet, mesa's not built!" [07:40] RAOF: but did you build libdrm yet? [07:40] mlankhorst: No, but I've got a snapshot in the PPA too. [07:41] oh I already did for precise [07:45] been using it for testing mesa, that's why i wanted it to be uploaded to quantal [08:05] hey [08:05] Hey, yo! [08:06] hey seb128 [08:06] hey RAOF, mvo [08:07] mvo, weirdly you start saying hello again today ... less scarred to be pinged back with nagging? ;-) [08:07] mvo, thanks for getting that SRU tested! [08:07] seb128: exactly ;) [08:07] seb128: not feeling like I need to hide in shame today [08:08] seb128: thanks for the constant reminder, it wsa important [08:09] * seb128 hugs mvo [08:09] * mvo hugs seb128 [08:09] bonjour seb128 [08:09] hallo mvo, wie gehts? [08:09] pitti, hey, wie gehts? [08:09] hey pitti, good, thanks! how are you? [08:09] seb128: je vais bien, merci! [08:10] trying to get my kernel and udev patches upstream, and writing autopkgtests like mad :) [08:11] pitti, what do you need to patch the kernel for? [08:11] just curious ;-) [08:11] seb128: for making scsi_debug fake removable devices [08:11] pitti, btw please keep posting your progresses on google+, I like to read those ;-) [08:11] it's a silly and simple patch, but would help a bit to test udisks and gvfs [08:11] seb128: ah, I moved some of them to my Canonical me [08:11] as I thought they were too much detail/too uninteresting for the general public [08:11] pitti: autopkgtest is something I need to investigate for s-c too! [08:12] mvo: didn't we already have s-c being tested in jenkins? [08:12] and mterry needs to fix the autopkgtest for update-maanger and release-upgrader [08:12] pitti: yeah, but I'm not sure its using autokgtest for this [08:12] nasty red dots on https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/ [08:13] mvo: I don't think it's still being tested at all [08:13] oh, ok [08:13] mvo: but yes, with dep-8 it's a lot easier; zero changes necessary in jenkins [08:13] it just picks up new packages automatically [08:13] and there's a standard way to test them locally [08:13] its a pre-upload hook, so its tested locally here, but getting it there is much better [08:13] cool [08:13] I guess update-manager mostly needs a python-mock dep in debian/tests/control [08:14] pitti: it has a python3-mock one there [08:15] https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/job/quantal-adt-update-manager/ARCH=i386,label=albali/9/console [08:15] nose.plugins.cover: ERROR: Coverage not available: unable to import coverage module [08:15] ah, so it was that one, not mock [08:16] aha, cool [08:17] probably best to test that in a server VM/pbuilder etc. first, it's rather common for them to break on missing deps [08:33] Good Morning. [08:40] seb128: do you have anything for gtk+? if not, I'd do an upload now to get the new autopkgtest into jenkins [08:41] pitti, hum, maybe, wait a minute please ;-) [08:44] seb128: sure, no prob; stashed in bzr, and I tested locally; it's not actually that urgent [08:46] pitti, I'm pondering turning on the wayland backend, we had a request for that before precise, I think now would be a good time for it [08:47] pitti, hum, that's going to take me a while to test though, I'm still on precise on my main box ... so please just go ahead with the upload, I can do another one tomorrow if needed, there is no hurry there [08:47] seb128: as you wish; likewise it's not urgent to upload the autopkgtest either [08:48] is there any way to start wayland on a headless VM? [08:48] pitti, no please upload, looking on my todo it's likely the wayland stuff will slip back for a day or two [08:48] would be interesting to add an autopkgtest for that then, similar to the two I added with xvfb-run [08:48] seb128: ack [08:48] pitti, I don't know, a question for RAOF I guess [09:00] does ubuntu installer support partitions on encrypted LVM nowadays? or should I still use the text-based installer? [09:04] hey seb128, how are you? [09:08] chrisccoulson, hey, I'm good, how are you? [09:08] tired :) [09:09] xclaesse, you should probably ask on #ubuntu-devel but I guess it's going to be the second one, there is work to bring the missing features to the desktop installer but I don't think it has been finished yet, maybe this cycle === ubuntu is now known as Nathan_S [09:14] hey chrisccoulson ;) [09:14] chrisccoulson, how is Maisie doing? [09:14] chrisccoulson, waking you up every hour at night? ;-) [09:15] seb128, ok thanks :) [09:15] chrisccoulson, lol, just reading your new tweet, Ruby learnt to like thunderstorm from you? ;-) [09:15] hey didrocks :) [09:16] seb128, yeah, we didn't get much sleep last night. maisie is nocturnal ;) [10:16] hey chrisccoulson how are things? [10:27] hi jasoncwarner_. things are good thanks! how are you? [10:34] pitti: Yes, you could do a headless wayland; if nothing else, you should be able to run weston with the x11 compositor under xvfb. [10:35] RAOF: that might be a workable thing to do for a smoketest of the gtk wayland backend in autopkgtest then? [10:35] Yeah, I think so. [10:35] You'd start xvfb, start weston under xvfb, and then profit.\ [10:35] nice [10:36] * pitti off for ~ 3 hours, bbl [10:43] Laney, hey, there? [10:43] seb128: yeah, a bit. [10:44] thanks for looking at gsd! [10:44] Laney, yw [10:44] Laney, I'm starting pondering if we should stay on g-s-d g-c-c 3.4 this cycle [10:44] It might be easier, yeah. [10:45] as long as other components aren't going to rely on the new versions? [10:45] no, g-s-d g-c-c are pretty separate from everything else [10:45] and what's the plan with that ubuntu-control-center fork? [10:45] (out of maybe gnome-shell) [10:45] Laney, #ps is just overworked I doubt they will get to it this cycle [10:45] ok [10:45] and our design delta is starting to be lower [10:46] so we'll still need to work out a plan for dealing with the patches there [10:46] GNOME took some of our changes and is going to take our sound panel redesign [10:46] and our designer are working upstream [10:46] and we will be able to drop the gsettings revert patches soon [10:46] so we should be back to a reasonable delta [10:46] like the big one we're having trouble with now [10:46] i guess it will basically be a rewrite [10:47] which one? [10:47] the indicator one [10:47] right [10:47] well we need a proper keyboard-indicator [10:47] ya [10:47] i.e a standalone source like the indicator-{session,messages,sound,...} [10:48] it still needs to be done though [10:48] will ps work on that? [10:48] Laney, how likely is the "replace language-selector by region panel" likely to happen this cycle in your opinion? [10:49] Laney, I'm think we should maybe stay on 3.4 and postpone that one to next cycle and focus on other stuff [10:49] I think that it doesn't make sense to do that if we're staying on 3.4 indeed [10:49] well, #ps said they were looking at hiring somebody to do the keyboard stuff properly but they have difficulties to file the position, no good candidate so far it seems [10:49] I wouldn't count on it for this cycle [10:50] it's probably a good candidate to defer [10:50]