[00:22] anyone know if NVIDIA put out a new -96 yet? [03:13] seems pretty safe to say nvidia-96 is dead, its been a year since the last release [03:19] that's too bad, as it's such a great driver [06:36] morning [07:21] Aw my keyboard died, one of the support legs snapped of. Finally enough motivation to buy a new one since this was a really damn good logitech keyboard. :) [07:42] RAOF: just xf86-modesetting was added right? [07:45] mlankhorst: Between Precise and Quantal? I think so, yes. [07:48] has the renaming postfix been decided? or do we just use what the kernel has? (-lts-q) [07:48] * -lts-quantal [07:48] think we just follow lts-quantal [07:48] yeah, good [07:48] shorter names :) [07:49] it was just s/backport-// anyhow [07:49] yup [07:50] wonder if we can just sync libx11 now [07:51] I'm really hoping.. can we make libdrm-nouveau1 be separately installable so we could upgrade libdrm instead of needing a rename? [07:51] I could make the package for it [07:52] remember that this would need to be done for every backport series [07:52] sru'ing libdrm [07:53] We always need to upgrade/rename libdrm anyway; we only test the *whole* stack in ubuntu+1 [07:54] yeah I know [07:54] If we cherry-pick bits of the stack we lose some of the benefit of that testing. [07:54] Thinking of libdrm, why aren't we on 2.4.35 again? [07:54] nouveau [07:54] Changes ABI. Does it bump SONAME, or do we need to beat someone with a seal? [07:55] A *baby* seal. [07:55] My quick ls suggests that it does the sensible thing and is now libdrm_nouveau.so.2. [07:56] Which is entirely parallel installable with libdrm_nouveau.so.1, right? [07:56] I guess we don't get to rebuild mesa, though. [07:57] and that would really be the problem [07:59] don't get to rebuild libdrm_nouveau1a either [08:00] cnd: I'm syncing both libx11 and libxi, looks like the upstream versions have everything we need [08:04] cnd: yay synaptics 1.6.2 is in -proposed finally [08:06] RAOF: it bumps soname but it doesnt ship the old version anymore which our mesa needs until august [08:07] Sarvatt: Right. The first would be fine; we'd just keep libdrm-nouveau1a around in the archive until everything had settled down. It's the latter bit that's the problem. [08:08] give it a few days, airlied already bugged darktama about that [08:08] they need to update f17 :) [08:08] i think they added a hack there for it though :\ [08:09] There's always the option of embedding libdrm-noueveau1a's source in mesa. :) [08:09] oh speak of the devil [08:09] 1 hour ago http://pkgs.fedoraproject.org/gitweb/?p=libdrm.git;a=shortlog;h=refs/heads/f17 [08:10] oh so it did land [08:11] Sarvatt: Well do you want to update libdrm or shall I? [08:11] nice little patch :) [08:12] mlankhorst: 4am and whisky o'clock here, safe to assume the latter unless tomorrow :) [08:13] heh sure === yofel_ is now known as yofel [10:17] ok uploaded renamed base packages, if they work I'll upload drivers again :) [13:02] RAOF: can you upload 'xorg'? I updated the git tree for x1.12 [13:04] he's probably asleep by now [13:04] ah k, can you? [13:04] yep [14:43] I verified the synaptics sru, uploaded libdrm to a local ppa for testing tomorrow, renamed xorg-server seems to have built succesfully, so I'm uploading all the renamed drivers and call it a day. :-) [17:06] is there any easy way to deal with libdrm-nouveau1a/2 collisions? [17:06] the packages don't play nice if i use oibaf's ppa [17:08] who's oibaf [17:17] erappleman: working on it :\ [17:17] https://launchpad.net/~mlankhorst/+archive/ppa didn't test yet [17:17] tomorrow [17:25] mlankhorst, i dont think that's what he is talking about, this is just a messed up packaging while putting nouveau.2 in nouveau1a package [17:26] https://launchpad.net/~oibaf/+archive/graphics-drivers/+sourcepub/2495386/+listing-archive-extra [17:48] oh [17:49] that should really not be attempted, even [20:13] <`rand`> Bug: I upgraded to 12.04 and was disappointed to learn that the Sticky Keys feature has lost some functionality. Specifically, pressing a modifier key twice no longer "locks" it, in Xkb terms; latching still works, but it's much more tedious. Which package (or packages) would I need to look at to correct this? [20:28] <`rand`> I guess, more generally, which package (or packages) control the core keyboard functionality for X and/or Ubuntu? It's not just Unity, but even Awesome--which could enable sticky keys through the use of the xkbset package in prior versions--no longer works. The regression is frustrating and I would love to help fix it. [20:32] it's in the accessibility features [20:33] system settings, a11y, writing.. [20:34] seems to work just fine [20:34] `rand`: ^ [20:35] pretty sure we would've heard about it by now if it was generally broken [20:38] <`rand`> check bug 998877 on launchpad. [20:38] Launchpad bug 998877 in Ubuntu "Sticky keys disabled when pressed twice" [Undecided,Confirmed] https://launchpad.net/bugs/998877 [20:41] ok [20:47] just shoved in xdiagnose 2.9. This changes the gpu lockup udev rule to hopefully eliminate false lockup reports. but not entirely sure what it'll do, so keep an eye out for oddities with freeze bug reporting and let me know. [20:48] okie [20:50] <`rand`> bryceh: Was that to me? [20:50] no [20:51] <`rand`> ah, thanks. [20:53] <`rand`> tjaalton: which WM are you using? [20:53] I'm not really sure what exactly does the sticky keys thing. xkeyboard-config is the source package for keyboard mapping issues, but haven't run across anything about sticky keys there. I'd suggest asking one of the accessibility folks who deal with that functionality more regularly. === Amaranthus is now known as Amaranth [20:55] <`rand`> Thanks bryceh. It has something to do with modifying XkbStateRec, but I'm not sure where I would need to do that. [20:56] `rand`: i misread your description, sticky keys work but not that particular use case I guess [20:57] <`rand`> I tried apt-get source xkbset, but it only gives me the .h files for the helper functions that modify it. :/ [20:58] <`rand`> tjaalton: it's all good, I just want to fix it. I'm using 10.10 now until I can. [20:59] so it happens with plain Awesome, ie. no gnome bits running? [21:00] <`rand`> It no longer works in Awesome, sadly--no Gnome bits. [21:01] then it's probably something in the xserver that changed [21:02] <`rand`> emacs is my preferred editor, so the regession was obvious immediately. [21:03] amazing, no changes to the package since 2006 [21:03] <`rand`> Is X hosted on git? [21:03] cgit.freedesktop.org [21:03] <`rand`> thanks! [21:03] among many other bits [21:11] <`rand`> I'll clone the xserver repo and look through it. What was the last commit for 11.10? 12.04? That'll help me narrow my search. [21:13] <`rand`> Hah--just saw my "hosted on git?" Meant github. :) [21:13] oh just 1 package failed to build in q-lts-backport [21:14] so works on 11.10, not on 12.04? [21:14] <`rand`> correct. [21:18] https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport/+build/3627065 yuck :S [21:18] hmm, well it too had at least some version of the multitouch work [21:18] mlankhorst: oh, did it build on quantal? [21:19] tjaalton: probably, was using the source package from quantal [21:19] but it might have been copied over.. [21:20] tjaalton: I'm going to investigate tomorrow at least [21:20] right, since the input drivers weren't rebuilt against the new server, since the abi should be the same. could be something else too [21:21] i might just as well update wacom, though there aren't that many changes [21:21] 0.16 should be out soon [21:27] but yeah nice point that it didn't build with quantal too, should have come up with that if i was more awake :) [21:42] 101_fix_build_against_frankenserver.patch just needs to be disabled, same thing that happened in synaptics [21:42] ah === `rand` is now known as `rand`-AFK [21:44] Sarvatt: sure will do that tomorrow, I guess I'm just the first to rebuild it :) [21:49] i'll upload it to quantal now [21:50] there is xf86-input-wacom-0.15.99.1 but i've not time to test it before vacation, so dropping the patch will have to do [21:51] mlankhorst: wait, where did you get -0ubuntu3? [21:52] I only see -0ubuntu2 [21:52] its a rebuild which bumps it [21:52] iirc [21:53] it's not in quantal [21:53] my git has 2 [21:53] tjaalton: I mean I think the rename script bumped it [21:53] ahh ok [21:53] that's wrong :) [21:54] yeah but i dont feel like clicking 50 times to rename it once more, next version [21:55] well it'll be messy if it stays like that [21:56] it won't, just on the list of things to fix with x1.13 [22:12] bryceh: whot said we need to update our keyboard driver to 1.6.1 [22:12] https://bugs.freedesktop.org/show_bug.cgi?id=50683 [22:12] Freedesktop bug 50683 in Server/General "Black screen with "AutoAddDevices" "Off"" [Major,Resolved: notourbug] [22:13] in precise? [22:13] quantal has it [22:14] yeah, I think in precise [22:14] it has 1.6.0 [22:14] the bug report is from a lubuntu 12.04 user [22:16] cnd, is there a ubuntu bug for that? we'd need one for SRU [22:17] cnd, is there a specific patch I could pull, in case a point release update is not in the cards? [22:18] 20beb15d24b5f8ab194b94f7e29f49e91ea38a8b probably [22:18] only five commits there [22:24] whot said something about unresolve symbol xf86IsPC98 [22:24] "Remove calls to xf86IsPc98()" [22:24] same :) [22:25] yeah, that looks right :) [22:25] ok [22:28] whot said we may also need http://cgit.freedesktop.org/xorg/driver/xf86-input-keyboard/commit/?id=38e4defe795776479594825859e101cd7cb5aa17 [22:28] it's the commit right before [22:28] nm, he says not to worry about it [22:29] cnd: hey, there was some talk about a sticky key regression since 11.10.. think it could be due to the input changes? [22:29] dunno [22:32] ok, just a thought [22:43] <`rand`-AFK> tjaalton: still here--I'm checking it now. :) === `rand`-AFK is now known as `rand` [22:57] <`rand`> Be back tomorrow--hopefully with a solution! [23:26] umm [23:26] tjaalton, looking closer now at the upstream bug report, the guy saw his failure after enabling xorg-edgers on precise [23:27] so SRUing this to precise is not the right solution [23:28] this needs to have -keyboard 1.6.1 added to xorg-edgers [23:29] cnd, ^^ [23:30] bryceh: ahh, ok, thanks :) [23:31] bryceh: do we have warnings to tell people to file bugs in LP and not upstream when they use edgers? [23:31] I don't know where we would put a warning like that though... [23:31] maybe in the ppa description [23:31] since that is shown when you want to add the ppa now [23:31] cnd, no in fact we do the opposite [23:31] we ask people to file upstream bugs? [23:32] yup. purpose of edgers is to track upstream and provide packages of the upstream stuff to make testing easier [23:32] we close out bugs about edgers problems if filed in LP. [23:33] well, that commit in xf86-input-keyboard was from last october [23:33] if we're going to tell people to file bugs upstream, we probably need to keep in sync better [23:33] * bryceh nods [23:34] -keyboard in edgers is 1:1.6.1+git20120703.dd6f110c-0ubuntu0sarvatt~precise [23:34] hmm... [23:34] then what's going on... [23:34] updated 47 min ago [23:34] oh, just updated :) [23:34] yay