[00:19] RAOF, will you be following up on the xkeyboard-config security issue? [00:19] cnd: Yes. [00:19] cool [00:20] We can fix it without an X patch, just a fixed xkeyboard-config. [00:20] (Because the ability to turn on that behaviour is awesome) [00:21] actually, I needed that functionality last week :) [00:22] :) [00:22] when I hit that bug in the server that was using the wrong timestamps to verify AllowEvents requests [00:22] silly me, I obviously just needed to hit ctrl+alt+KP_Multiply [00:24] :) [00:24] I, sadly, don't have a KP_MULTIPLY :( [00:24] I was going to comment the same, until I glanced over and was reminded how beastly behemoth is [00:25] sadly, I *did* have KP_Multiply last week, even on the machine I was testing with [00:30] RAOF, I'd like to upload a version of synaptics with MT [00:30] Make it so. [00:30] my thoughts are to squash all the patches I pushed out to the list today into one big 127_xi22.patch [00:30] sound good? [00:31] Sounds reasonable. Once those patches are accepted we'll nab a newer upstream snapshot? [00:31] yeah [00:31] I don't really know if they'll be accepted in their current form [00:31] see email 0/6 [00:31] but I think it's the best we're going to get before feature freeze [00:34] That's Feb, right? [00:35] yeah [00:36] I'm afraid that either this patch set is acceptable, or major synaptics overhaul will be needed [00:36] Ah, yeah. The rebuilding eventcomm thingy. [00:36] yeah [00:36] I've asked whot about it a few times in passing this week [00:36] he seems too busy to think about it much [00:36] so I just pushed out what I've got [00:37] Yeah, I've seen that. [00:42] RAOF, we really should send a patch upstream to make xtst usage optional at configure time for syndaemon [00:42] it's annoying having to install, remove, install, remove libxtst-dev [00:43] each time I switch between building synaptics and anything else [00:43] That sounds good. You can't chroot it, though? [00:44] I mean, do all your test-builds in the source tree, with libxtst-dev installed, and then build packages in an schroot. [00:44] building in chroots is so much slower :) [00:45] argh, bash keeps segfaulting on me in precise [00:45] make check in utouch-frame and xserver-xorg-input-synaptics results in: [00:45] /bin/sh: line 5: 12477 Segmentation fault (core dumped) ${dir}$tst [00:46] Build on tmpfs, with a local mirror. It's not *that* much slower :) [00:47] Except the first time, when it's populating the cache. [00:47] that's too fancy for me [00:47] the more it takes for me to set things up, the less likely it is I'll remember when my hard drive dies [00:47] * RAOF should really clean up his sbuild config for that and submit it as a patch upstream. [00:49] ok, new xorg-server and xserver-xorg-input-synaptics are uploaded with MT support for trackpads [00:50] Woot! [00:50] RAOF, do you want to organize some last minute smoke testing after they finish building? [00:50] the synaptics stuff is all brand spankin' new [00:50] Yes, please. That would be swanky. [00:51] I'll send an email to ubuntu-devel and ubuntu-x [00:59] Mmmm, segfaults in the testsuite. [01:03] on the buildds too... [01:04] wow, the archive buildds are fast [01:04] xorg-server is already done for amd64 and i386 [01:04] They're like 18 core super awesomes. [01:07] Dear server-side XCB. Why don't you exist? [01:08] sarvatt was saying the reason the buildds were unavailable to ppas was the result of a glitch in a script failing to reassign them back to ppa duty, that has been fixed now [01:15] I'm noting also that it took the buildds 5 minutes, 6.1 seconds to build xorg-server on amd64 [01:15] including the udeb [01:16] that's way faster than I remember them building on any buildd [01:16] * cnd wonders if they turned on DEB_BUILD_OPTIONS="parallel=" [01:17] I'm pretty sure they do. [01:29] downgrading bash to oneiric doesn't fix things... [01:31] I don't think it's bash segfaulting; I think it's your test segfaulting. [01:32] cnd: I'm pretty sure that's an artefact of the way autotools runs the tests; when they segfault, they look like that. [01:32] hmm [01:33] Man, wouldn't it be awesome if we had developer tools that didn't occasionally lock up? :/ [01:33] ahh yes, eventcomm-test is segfaulting [01:34] let's see what's wrong [01:34] I guess I have a bug in my utouch-frame testsuite too :) [01:35] I see the issue [01:47] things should be all better now [01:48] RAOF, when do you think the xkeyboard-config issue will be fixed? [01:48] I'm writing up the email to the lists for smoke testing [01:48] if it'll be fixed in a jiffy, I'll not mention it so as not to cause confusion [01:48] but if not, then I'll leave a note about it [01:49] It should be fixed in a jiffy, I think. [01:49] ok, my definition of jiffy is in the next couple hours [01:49] do we have the same definition :) [01:49] ? [01:49] Yes [01:49] cool [01:50] * cnd would love to hold you to the kernel definition of a jiffy [01:50] oh, too late... [02:01] I decided to be safe and mention the security hole [02:01] ok, I'm out of here [02:01] leaving on a high note :) [02:02] :) [02:02] see you all tomorrow, unless you're one of those weirdos on the other side of the dateline :) [02:03] Ah. 1pm. [02:03] So *that's* why I'm hungry! [04:47] RAOF, I just noticed your wacom upload [04:47] was it straightforward to fix? [04:48] Yeah. [04:48] It was just a matter of convincing wacom that input abi 15 didn't mean the options abi was available. [04:49] You'll see the diff is pretty small. [04:50] Of course, I don't *have* a wacom device, so I'm not sure that it actually works ☺ [04:54] same here :( [04:59] tjaalton: Oh, hey. You might think that pkg-xorg can push to your xf86-input-wacom repository on alioth, but all the subdirectories of object are missing write permissions for the group. [04:59] RAOF: oh boo [05:01] tjaalton, I can never figure you out, is it really early in your day, or really late? [05:01] cnd: really early this time :) [05:01] heh, ok [05:02] RAOF: ok, it's busted then, now I can't change the permissions on objects owned by you :) [05:02] I can change those. [05:02] cnd: don't worry, just got here [05:03] And now we win! [05:04] Well, um, for a while. [05:04] right.. [05:05] if only ron would be willing to move -wacom under collab-maint or sth [05:05] or pkg-xorg [05:06] RAOF: actually, the faulty bit is the default umask, i think. and that's hard to fix properly [05:06] so that it doesn't mess the other repos [05:07] Yup. [05:11] oh and I have wacom [05:16] also, 0.13 is released but I can do that later [05:36] RAOF: is this all going in today or next week? [05:37] I've still the xorg changelog to update and push to staging [05:39] tjaalton: Next week, I think. [05:39] yeah [05:39] tjaalton: We can get a little smoke testing over the weekend, and push on Monday. [05:40] Well, over *my* weekend. Over other people's Friday :) [05:40] hehe [05:40] is the newest stuff on a private ppa? [05:40] or was that only used for builds [05:42] oh, new emails [05:44] cnd: you didn't mention where the stack is, though I'm assuming it's x-staging still :) [05:45] tjaalton: whoops, https://launchpad.net/~canonical-x/+archive/x-staging [05:45] aha, not that private, good [05:58] It needed to be a canonical-only team to get access to the non-virtualised PPA, but it's public. [06:13] gotcha [07:31] upgraded to current staging, all is well [07:35] tjaalton: Are you using an amd64 box? [07:36] tjaalton: I suspect that nvidia-{current,173} amd64 in there are broken, because it seems you can't build the source package properly on i386. [07:37] RAOF: yep, intel though [08:37] RAOF, good afternoon :) [08:38] RAOF, do you mind syncing pixman? https://bugs.launchpad.net/ubuntu/+source/pixman/+bug/918873 [08:38] Launchpad bug 918873 in pixman (Ubuntu) "Sync pixman 0.24.2-1 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Undecided,New] [08:48] i can do that [08:52] done [09:11] tjaalton, thanks! :) === chrisccoulson_ is now known as chrisccoulson === yofel_ is now known as yofel [15:07] doing the xorg changelog update now, then push it to the staging repo [18:55] ricotz: ugh, 2 hour queue for openchrome/qxl/mga [18:55] and geode [19:10] RAOF: I think you might like anno 2070 btw [19:31] Sarvatt, ideas on bug #918769? seen any dell vostro 360's? [19:31] Launchpad bug 918769 in xserver-xorg-video-intel (Ubuntu) "X blink with Vostro 360 and Ubuntu Oneiric and Precise (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/918769 [19:32] bryce: eDP [19:32] aha [19:33] if the system has a video input board, it uses an hdmi display internally, if not it uses eDP, that system was a nightmare [19:33] so disable that in xorg.conf? [19:33] nawh just saying there were problems, it was only fixed in 3.2 [19:33] will take some digging but i might be able to find the backported fix for 3.0, its not going to be possible to SRU though [19:34] aka its a HUGE change [19:34] this guy finds it happens on 3.2.0-9.16-generic-pae 3.2.1 though [19:34] oh, hmm [19:34] Sarvatt, did it show the same symptoms? blinking every 10 seconds (edid polling??) [19:35] no display wouldn't turn on at all, sorry for not reading it fully :) [19:35] that has an upstream bug.. [19:35] hold on, finishing up lunch [19:35] eDP1 is connected [19:39] hows the X server packaging comming along? [19:39] Prf_Jakob, are you on the ubuntu-x@ mailing list? there's been some discussion there as to its status [19:40] bryce: hmm no, maybe I should get on there. [19:41] Prf_Jakob, x-staging is available for smoke testing. I think there's some builds we're still waiting on but I should expect the upload any day now. [19:42] Sarvatt, I think this sounds like a good bug to have the guy test a ppa kernel on [19:42] thanks for the info. [19:58] Prf_Jakob, bryce: https://launchpad.net/~canonical-x/+archive/x-staging/+packages [19:58] all green checks now [19:58] for those we expect to build [19:58] we'll probably push them on monday unless people have blocker issues [19:59] hmm... looks like xf86-video-msm should build for armhf [19:59] it's probably not a blocker though [20:01] Has anyone had success removing the Xorg-Edgers PPA in Oneiric? [20:01] The page just says that there are issues, but not how one might fix them. [20:02] Currently when I try to do so apt wants to remove most installed packages [20:02] cnd: ok nice, onto mesa after that? [20:02] Prf_Jakob, tbh, I don't know anything about the video side of X [20:02] so I don't know much about mesa, or what you're even asking :) [20:03] cnd: ok fair enough. [20:03] bryce, Sarvatt, any ideas for Prf_Jakob? ^^ [20:03] xrdodrx, htorque on #ubuntu-kernel ran into that and manually downgraded stuff to resolve it [20:04] Prf_Jakob, yes on to mesa following that [20:04] Cool, thanks [20:04] bryce, do you think he'd help me if I asked him which packages he downgraded? [20:05] xrdodrx, no idea [20:05] xrdodrx: give it another hour or so and it'll be fixed [20:05] the message is saying dont upgrade [20:05] here's what he said: [20:05] unless you're using proprietary drivers that is [20:05] Sarvatt: thanks, already on it. ppa-purge might not work, but it seems to give me the right order in which i can mark the packages for a downgrade in synaptic. should be done soon. :) [20:06] well, I can surely wait an hour [20:06] thanks :) [20:06] xrdodrx, yep, that's probably easiest [20:06] xrdodrx: mind pasting the output of apt-get dist-upgrade (don't accept the upgrade, just want to know whats held back) [20:07] geode openchrome mga and qxl were just finished building and haven't been published yet, that should be the end of it [20:08] but I might have missed something.. [20:09] Sarvatt, nothing is held back [20:09] 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. [20:09] I re-added the PPA, however [20:09] Sarvatt, feel free to go ahead ;) [20:10] go ahead? [20:11] looks like apm and rendition were missed [20:11] xrdodrx: did you apt-get update after adding it again? [20:11] yes. [20:11] 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. [20:11] Sarvatt, i mean you can upgrade to 1.12 [20:12] ricotz: i'm still on your 1.12 ppa so cant see what people usually see trying to upgrade [20:13] Sarvatt, oh, ok, i thought you arent using it [20:15] ok apm and rendition uploaded, what else did we miss.. [20:15] poulsbo! [20:16] oh cool you got fglrx and nvidia-current [20:17] virtualbox time [20:17] right [20:17] if it compiles... [20:20] building it locally first [20:22] Sarvatt, forgot to mention I'm using Oneiric and accidentally accepted an update a few hours ago to all my packages ;-) [20:22] dist-upgrade still shows nothing hold back :o [20:24] xrdodrx: ohhh i'm sorry, the transition is only for precise, nothings been updated in oneiric in a few days [20:24] except unity thats building right now [20:24] Right, the only thing that broke here is 3D acceleration. [20:24] That's why I'm either trying to downgrade or remove Xorg Edgers. [20:24] sheesh, I'm blind! ok so you want to revert xorg-edgers.. this is going to be rough :) [20:25] I'd prefer to just downgrade it, I installed it as my Mesa was not working in default Ubuntu (certain 3D acceleration tasks crashed X) [20:25] (and resulted in a hung GPU) [20:25] so with edgers sources enabled, run sudo ppa-purge xorg-edgers, dont accept any aptitude solutions (aka press q), you get a list of packages that need to be downgraded [20:25] well first off, are you on amd64 or i386? [20:26] amd64 [20:26] its significantly easier on i386 because ppa-purge works :) [20:26] darn [20:26] ok [20:26] i5-2500, video-intel (sandy bridge graphics) [20:26] you're going to need to downgrade/remove :i386 versions of xorg-edgers stuff [20:28] easiest way is going to be to apt-get purge the :i386 stuff completely, let it break multiarch [20:28] break as in remove other :i386 stuff too [20:28] like it'll remove wine, skype, maybe flash [20:28] Sarvatt, I shouldn't need :i386 anyway, right? [20:28] you can always readd it after you're done but it makes it lots more complicated [20:28] I use the new 64-bit flash [20:29] and neither wine nor skype [20:29] can ya pastebin dpkg -l | grep :i386? [20:30] http://pastebin.com/vpz8uSLT [20:30] i have skype installed but i never use it as even the beta is very old [20:30] ok one sec, let me make up a list for you to start out with [20:31] okay. thank you :) [20:33] sudo apt-get purge libpciaccess0:i386 libdrm-intel1:i386 libdrm-nouveau1a:i386 libdrm-radeon1:i386 libegl1-mesa:i386 libdrm2:i386 libegl1-mesa-drivers:i386 libffi6:i386 libgbm1:i386 libgl1-mesa-dri:i386 libgl1-mesa-glx:i386 libglapi-mesa:i386 libpixman-1-0:i386 [20:33] paste what it wants to remove, will tell ya if its ok [20:34] Sarvatt, There isn't some way I can just downgrade my xorg-edgers packages? [20:35] like i said, official ubuntu packages were crashing X on certain video accel tasks [20:35] here's the paste, in any case: http://pastebin.com/Gt9s1w5w [20:35] downgrade to what? [20:35] older uploads? [20:35] Yes. [20:36] how much older? did it start with something recent? [20:36] I don't really want to get rid of Xorg-edgers, I enabled it for a reason... [20:36] launchpad only stores 2 versions :( [20:36] ouch [20:36] much more than 2 :( [20:36] xrdodrx: you may have packages in /var/cache/apt/archives/ [20:36] currently my X works [20:36] I just don't have video accel. [20:36] hmm [20:37] So xfwm4 runs instead of Compiz. [20:37] And I can't watch video [20:38] do you see anything in /var/log/Xorg.0.log that stands out? glxinfo? [20:38] hmm, one question, do you have oneiric-proposed enabled? [20:38] I don't think so, no. [20:39] ok just making sure, was a unity update that would have killed edgers today [20:39] so glxinfo says it's using software rasterizer? can ya paste your /var/log/Xorg.0.log? [20:39] Sure. [20:40] http://pastebin.com/nZ0FjjzW [20:40] ^ Xorg.0.log [20:41] that looks fine [20:41] Compiz (opengl) - Fatal: Software rendering detected [20:42] what about glxinfo output? [20:42] different than usual, I'll show you [20:42] usually it says "Tungsten Graphics" [20:42] http://pastebin.com/K88vfHCq [20:43] ok LIBGL_DEBUG=verbose glxinfo output now [20:44] http://pastebin.com/RMz4QRts [20:44] err pastebin only got the stdout, can you paste the top few lines at the top before the name of display: :0 part here? [20:45] that's weird, I used a pipe [20:45] will do manually [20:45] fredrick@desktop:~$ glxinfo [20:45] name of display: :0.0 [20:45] There is nothing before name of display... [20:45] LIBGL_DEBUG=verbose glxinfo [20:46] $ LIBGL_DEBUG=verbose glxinfo [20:46] name of display: :0.0 [20:46] yeah. [20:46] (I knew I had already set LIBGL_DEBUG so I just ran glxinfo again the first time, sorry) [20:48] Sarvatt, I just killed X and Compiz works again. It seems to not wait long enough on a first boot, or something. [20:48] Pretty odd... [20:52] I'm going to attempt another reboot to see if it happens again.