[00:00] i *just* got libxfont [00:00] shoot cant use apt-get either [00:01] grumble grumble [00:01] well, at least I did verify this time that 190 applies [00:01] somethings majorly screwed up, i better reboot and hope for the best [00:10] hmm... nouveau + all the other bits from xorg-edgers fails for me, "error opening the drm" [00:11] http://pastebin.com/f2c14c96b [00:11] Sarvatt, luck? [00:11] yeah just something screwy. latest intel git doesnt boot x though which was fun to find out :D [00:12] Version: 7.0.16~git20091111.3ec82cd7-0ubuntu0sarvatt Version: 7.0.15-1 for x11proto-core-dev, looks like the protos arent even built yet [00:14] oh hey [00:14] 190 actually applies to master now with your change [00:14] good [00:14] Argh! Why do I _still_ need to look up 'git help checkout' to switch to an upstream branch? [00:20] shoot, auto-xorg-git changes coming back to bite me now that it was updated, i used ~ instead of + in alot of the protos and libs so >=1.2.0 build deps fail for 1.2.0~whatever [00:25] Should I upload a new nouveau-kernel-source package to Lucid, or wait for whatever falls out of the kernel team discussions? [00:26] Interesting context: nouveau is currently untestable on Lucid, because the current nouveau-kernel-source fails to build against 2.6.32 kernels. [00:27] RAOF, I'd doublecheck with the kernel team first [00:38] oops, looks like 177_animated_cursor_change_master.patch needs to go too [00:39] ../../render/animcur.c: In function ‘AnimCurDisplayCursor’: [00:39] ../../render/animcur.c:222: error: ‘struct _DeviceIntRec’ has no member named ‘isMaster’ [00:57] thats on master but will be the same on 1.7 branch -- http://cgit.freedesktop.org/xorg/xserver/commit/?id=b12d302df8283186ce87882c29b2b0294adb2770 [00:59] darn http://paste.ubuntu.com/334210/ [01:06] yep 177 fails on 1.7.2 too [01:08] checking if 190_cache-xkbcomp_output_for_fast_start_up.patch makes 1.7.2 fail to build now too like it does master [01:09] pushing this little atom cpu hard tonight :) [01:09] hehe [01:11] hrm, wonder if there exists an updated version of 190 [01:11] bugger my pbuilder environment still isn't updated [01:12] well, we can leave 190 disabled for alpha-1, that won't be the end of the world [01:13] ditto 177 [01:14] yeah i'm using edgers just to see if things work, had to change x11proto-xf86bigfont-dev (>= 1.2.0), to x11proto-xf86bigfont-dev (>= 1.1.99), to make it build because of 1.2.0~ behind lower than 1.2.0 [01:15] hmm [01:15] checking for DMXMODULES... yes [01:15] ../configure: line 20715: XDMXCONFIG_DEP_CFLAGS: command not found [01:15] ../configure: line 20716: C: command not found [01:15] ../configure: line 20717: XDMXCONFIG_DEP_LIBS: command not found [01:15] ../configure: line 20718: linker: command not found [01:15] (sorry for so many lines at once) [01:17] 1.7.2 failed the same as master with 190 applied :( [01:17] Sarvatt: that's fixed in 1.7.3 [01:18] that doesn't fail the build here tho [01:18] yeah doesnt fail, just saw the error while that one was building [01:19] same failure on 1.7.2 with 190 though http://paste.ubuntu.com/334216/ [01:25] * bryce comments out in git [01:25] it's my fault, I said "190 was easy" earlier and jinxed us [01:39] now its failing in hw/xfree86/common/xf86Events.c :( [01:40] patch 135 [01:41] trying 1.7.2 to see if it fails there too [01:41] gotta love ccache [01:42] http://paste.ubuntu.com/334223/ [01:44] Ok. So, nouveau would also like libdrm 2.4.16 for Lucid. [01:45] intel requires 2.4.16 to build now too [01:45] And it looks like it's practically finished in pkg-xorg git. [01:48] darn, ccache doesnt work when you build 2 seperate versions of the same package :D [01:56] and i'm an idiot.. disabled 135 when i built 1.7.2 to see if 135 made it fail that time :D [02:05] yeah 135 fails on 1.7.2 in origin/ubuntu too :( http://paste.ubuntu.com/334228/ [02:05] builds fine without it [02:08] oh yeah, can we drop the XAA hack now? I don't think any driver that supports compiz uses XAA by default anymore [02:08] I can't drop the compiz half of it until the Xorg half is gone [02:10] which XAA hack is this? [02:10] * Amaranth looks for it [02:10] the radeon XAA hack for low mem cards? [02:10] it was a way to dynamically enable XaaNoOffscreenPixmaps [02:11] from way back in feisty or something [02:11] looks like maybe it's gone already [02:11] I know it wasn't some time during karmic development though [02:12] if you spot it, let me know [02:12] we mostly don't care about XAA anymore [02:12] well nothing in debian/patches mentions _COMPIZ_GL_INCLUDE_INFERIORS anymore so I guess it is gone [02:13] Amaranth, there actually is a situation where XAA is used on -ati [02:13] upstream found that on some antique cards they can't do EXA very well so they do XAA by default on them [02:14] they'd have to be crazy to be using compiz in that situation where they have 32mb or under video ram though lol [02:14] those are the same ones that report invalid GL_MAX_TEXTURE_SIZE, aren't they? [02:14] however from what I've seen and heard this causes as much trouble as it solves, and I'm tempted to just force it all EXA anyway, and deal with the EXA bugs [02:15] Sarvatt, what our users crazy? [02:15] that need KMS to do it properly because they create a buffer large enough to fit the screen when rotated so they run out of memory [02:17] doesn't fglrx use XAA still? I dont use it but thought it did for some reason [02:18] Pretty sure they have almost useful XRender acceleration so I don't think so [02:19] thats the most positive comment about fglrx 2d acceleration i've ever heard [02:21] wow 1.7.2 has a _huge_ load of dmx compile warnings, no wonder they rushed out 1.7.3 [02:22] Well, fglrx is almost faster than software :) [02:30] how many times is this darn xserver compile going to run the tests [02:32] ...answer is 2 [02:37] * Amaranth stabs xmodmap [02:38] yep fully compiles fine without 135_rethrow_signals.patch. not the full build log because my scrollback didnt go back far enough: http://sarvatt.com/downloads/xserver_1.7.2_buildlog.txt [02:38] not the same build environment that is going to be in lucid as soon as the stuff builds though of course [02:58] bryce: Should I turn on the compiz reflection plugin to test your GPU wedge hook? :) [03:01] patches.ubuntu.com doesnt have the extracted patch folders anymore? :( === ripps|sleep is now known as ripps [03:06] hmm, guess it isnt that big a deal not having the apport hooks in the edgers packages but i need to add a hook for the intel-gpu-tools recommends update [03:07] intel hasnt been stable upstream in almost a month now, i'm still having to use ones checked out on 11-11 [03:10] oh wait its 11/06, forgot i reverted back and dated it higher so it'd override the broken ones even then [03:13] 2.9.99.901 release is ok except I cant use it on a 2.6.31 kernel without it killing x randomly, and cant suspend without the flickering problems under 2.6.32 on any 2.9.x release [03:46] hmmm so what all do I need for this new udev driven xserver? i see synaptics in experimental has a udev rule installed with it, need to do anything special with evdev? [03:48] oh theres a ubuntu branch for evdev now? sweet [03:49] ubuntu did it different than debian before where hal installed the evdev fdi so i wasnt sure if udev installed an evdev rule or something like that [04:13] lets see how this udev xserver works now. when I dont come back things blew up horribly :) [04:15] i'm always disappointed when things just work :D [04:17] was I supposed to purge hal first? [06:02] bryce: yeah I don't think the protos/libs are all built and published yet [06:03] Sarvatt: good catch on that merge goof, I forgot to add the VCS bits back [06:07] the publisher is screwed up or something, even ppa builds arent getting published even though they say they have been and the protos built 6 hours ago https://edge.launchpad.net/ubuntu/lucid/i386/+builds?build_text=&build_state=all [06:07] yes, well LP has been down for hours [06:07] and been up maybe an hour or so [06:08] ah, those have been built fine, so it's the publisher alright [06:09] x11proto-xf86bigfont built about 45 minutes ago on edgers and it still isnt getting used building server [06:10] watched it turn into a gear then finish getting published but still not up for download either [06:17] hmm looks like xfonts-utils is missing in the server build deps [06:18] failed on the PPA configure.ac:41: error: must install fontutil 1.1 or later before running autoconf/autogen but its got font-util 1.1.1 in the PPA [06:21] might be a xserver master only problem though [06:54] 1.7 doesn't check fontutil at all [07:03] well its starting to update, x11proto-xinerama is breaking gtk app builds ;D [07:14] hmm libx11 didnt get synced [07:16] someone just hit rebuild on all the dep wait libs at the same time, of course it's going to fail :D [07:44] well, there are errors too [07:44] since the headers were moved... [07:44] although it shouldn't have mattered [07:45] if the deps were right, the packages would have been waiting in the depwait queue [07:48] stupid g-t can't open urls with epochs :) [07:49] Sarvatt: ok, maybe the build-deps should have been versioned, seems like four packages failed to build because the old version was available [07:50] Sarvatt: and libx11 can't be synced [07:50] if we are going to keep the la_AU stuff [07:56] so there are a couple of libs that need to bump the build-dep on libxext-dev [07:57] we are fine though, since the builds can be retried later [08:28] Sarvatt: it seems that X segfaults when changing resolution on i965.. [08:28] using xorg-edger [08:29] 3: /usr/lib/xorg/modules/drivers//intel_drv.so(i830_set_pixmap_bo+0x4b) [0x7fda715b2d6b] [08:29] 4: /usr/lib/xorg/modules/drivers//intel_drv.so [0x7fda715c0f7d] [08:30] weird that it's calling an i830 function [08:30] hmm there's a new x-x-v-intel around so i'll just upgrade and see [08:33] bryce: so, some libs failed to build because our libxext was newer than what the xextproto was set to Breaks. Once the synced libxext is everywhere, I'll order a round of rebuilds for the missing libs (four of them) [09:02] ...this has to be the first time i've ever seen X screw up so bad i can't even use a terminal [13:24] is this the right place to report problems with packages from xorg-edgers ppa? [13:25] if the guilty are here [13:35] tjaalton: fair enough [13:36] tormod and Sarvatt are the ones you want [13:36] tormod is missing atm [13:37] Sarvatt should be the guilty one in my case... Or, probably intel upstream [13:38] I tried the latest intel packages (2.9.99.901+git20091202.a938673e-0ubuntu0sarvatt~karmic), too much glitches to even run a terminal windows [13:39] characters only show up as black boxes, until I switch desktop back and forth [13:40] gnome-terminal in a pretty much default karmic gnome installation [13:46] the previous version 2:2.9.1~git-0ubuntu0tormod caused some corrupted fonts after suspend (not the same corruption), but was otherwise ok. [13:47] also thanks a lot for the ppa-purge script, very useful :) [15:35] hi dudes, how to use thinkpad's trackpoint on karmic? [15:36] I already configure it with gpointing-device-settings [15:37] X.0.log and lsinput output are here [15:37] http://paste.ubuntu.com/334564 [15:37] http://paste.ubuntu.com/334565 [15:38] tseliot: any clues? [15:41] freeflyi1g: it should work just like a mouse, in relative mode, I guess [15:42] tseliot: I didn't get that lucky :) [15:43] freeflyi1g: what's the problem? [15:44] tseliot: like scrolling can't be used [15:45] tjaalton: ^^ [15:45] * tseliot doesn't own a trackpoint [16:28] tseliot: can't check the urls now. xinput should work though [16:29] does scrolling work with trackpoints? [16:29] is it supposed to? [16:36] it's disabled by default [16:37] you need to hold a button down and then scroll [16:38] middlemouse by default [16:42] tjaalton: is there anything need to be done in kernel? [16:42] freeflyi1g: no [16:43] tjaalton: then trackpoint can't be detected here, I'm using lucid [16:44] xinput list, xinput list-props $id, xinput set-int-prop... [16:44] it doesn't work at all? [16:45] tjaalton: just the scrolling [16:45] so use xinput [16:45] to enble the property [16:45] +a [16:50] darn libxinerama needs to publish already, cant build anything right now [16:51] tjaalton, aha. did xextproto get fixed up? anything I can do to help with this? [16:51] bryce: everything should be ready, but apparently libxinerama needs a retry? [16:53] xinerama built fine [16:53] https://edge.launchpad.net/ubuntu/+source/libxinerama/2:1.1-1/+build/1378080 [16:54] installing x11proto-xinerama-dev wanted to remove all of gnome dev packages too [16:55] proto breaks the old libxinerama-dev version is all [16:55] I don't follow.. [16:55] hyperair: you and me both! intel git is so messed up right now [16:59] libgtk2.0-dev tries to pull in libxinerama-dev [16:59] ok, so it's just a matter of time then [17:00] Sarvatt, I got libxinerama-dev 1.1 a few hours ago [17:01] bryce: the drivers might make it in debian this weekend (depends if there are people to upload them), which would allow us to sync them on monday [17:01] ok both of the mirrors i use are screwy then, one didnt have the protos at all [17:01] gotta go again -> [17:01] tjaalton, ok [17:02] regarding xorg-edgers breakages... especially this cycle we probably should encourage people to look to upstream when they run into issues [17:02] Sarvatt: ..again, huh. [17:02] bryce, that's usually what we do when they use xorg-edgers [17:03] tormod, ok [17:03] Sarvatt: well hopefully it'll get stable before the next release [17:03] hyperair: yeah its like a year ago only worse this past month in intel git :D i'm still using a checkout from 11/06 since it was the last time things just worked [17:04] Sarvatt: heh, i've gone back to using the one in karmic =D [17:04] oh not using lucid then? [17:04] bryce, it's also the main reason for xorg-edgers :) when upstream says "so you have a bug - try latest git" [17:06] what's cool now is that with lucid A1 + xorg-edgers, you have pretty much everything latest git, kernel, mesa, xserver, drivers [17:06] phew! the libxinerama problem was just a mirror problem, both of the ones I tried weren't updated [17:06] Sarvatt: no, not using lucid. i think i'll wait until somewhere around alpha 2 or so before upgrading [17:09] Sarvatt, you might noticed libxinerama worked fine in xorg-edgers also :) [17:09] tormod, right, I was just concerned with the number of people coming here for help with xorg-edgers issues [17:10] concerned in the sense that I don't want Sarvatt wearing himself out! :-) [17:11] bryce, well that's fine, so we know what's up and can tell them/upstream. as long as it does not get too busy in this channel :) [17:12] yes we don't want that! [17:12] * Sarvatt disappears for months again [17:24] woohoo, took 6 reboots but I made it into X with the latest intel :D [17:24] Sarvatt, your 12-Add-libudev... does not apply against master? [17:25] i have a hook to wget a refreshed one that does [17:26] yes, the wget'ed one does not apply, unless I am doing something stupid [17:27] yes I did ^ [17:27] phew [17:28] was going to say, it was working 30 minutes ago when i uploaded a new xserver [17:28] I had the old version laying around, did you just change it? [17:28] change what? the patch? nope havent touched it since last night [17:29] ahh i've gotta run, 2 hours late to a job :D [19:25] jcristau: the flashing on 2.6.32 is fixed in drm-intel-next for me. of course what fixed it i have no clue [19:28] down to 7.4w idle power usage now from around 8.1 too. i just tried this out since drm-intel-next doesnt merge into 2.6.32 cleanly right now http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/ [19:30] Sarvatt: ah. would be nice to figure out what fixed it to get it into 2.6.32.x.. :) [19:31] 31 possibilities there [19:32] maybe i can try tomorrow. need to work though, and right now i should get home.. [19:47] drm-next in kernel-ppa, that's awesome! how come I missed that [20:06] tormod: are you a DD now?-) [20:07] tjaalton, no why? [20:07] tormod: ah ok, saw the intel-gpu-tools upload, but that was sponsored? [20:07] at my current rate of Debian development I can be a DD in like ten years I guess :) [20:08] yes, I am a co-maintainer ("uploader" which is kind of wrong name) of some packages [20:09] I am discussing with the radeontool maintainer also [20:10] heh ok. I guess we need a DD to upload the current stack to unstable, and the drivers once they are ready in git [20:10] starts with j and ends with cristau :) [20:11] too busy I hear :) [20:11] any DD, willing to do the job this weekend after everything is go, would do [20:13] did you ask bgoglin? [20:16] jcristau did, no reply so far. let's see how it goes :) [20:16] i'm asking -release if that'd be ok with them, too.. [20:16] great === _stink__ is now known as _stink_ [21:02] tjaalton, anything I can help with on xserver 1.7 right now? [21:03] ideally it would be nice to get xserver 1.7 uploaded today, but if that's not looking possible I have some bug tool work for the desktop team I should get to [21:11] bryce: it wouldn't help much anyway, since all the drivers need a rebuild, and it's wise to do that as syncs from unstable [21:12] or less work anyway [21:13] I believe the uploads to unstable will happen this weekend [21:13] so we could sync on monday [21:13] mm [21:13] some drivers will remain broken though, like wacom an evtouch (which doesn't build against 1.7) [21:13] but that shouldn't matter much for a1 [21:14] fair enough, although I'm off all next week (and wife has stated she's banishing me from the computer) so won't be able to assist [21:14] oh :) [21:14] as long as you mention it in the release notes [21:14] bryce: well, there shouldn't be much drama [21:14] (wacom, not vacation) [21:15] tjaalton, tseliot might be able to help on the wacom and evtouch issues, could you touch base with him about it? At least, like pwnguin says, it should be mentioned in release notes [21:15] I thought evtouch is dead, evdev supports runtime calibration now.. [21:15] wacom needs xf86-input-wacom, but ron hasn't packaged it yet [21:22] maybe it is; from the touchpad session at UDS I got the impression it still had its uses [21:22] however evdev was clearly the way forward, it just needs more hardware support [21:28] runtime calibration support was added recently, so maybe it was just features missing from evdev that kept evtouch around [21:29] mm [21:32] I remember recently some evdev bugs, and some people using evtouch instead, was it the eeetop maybe? [21:36] no that was 441408 which was fixed in evdev. I guess only older howto [21:37] howto's talk about evtouch [21:39] ron packaged wacom after all http://people.debian.org/~ron/wacom/ [21:40] fast! [21:40] xf86-input-evtouch (0.8.8-0ubuntu7) came recently, with fixes for eeetop [21:40] well, I mailed him about the progress yesterday or so [21:42] tormod: that's just calibration quirks [21:42] same thing can be done for evdev, it's just a matter of deciding where [21:42] aiui quirks belong to the kernel [21:43] the fix yes, but why are these people using evtouch? [21:43] I believe ogra babbled about calibration once [21:43] don't know where we stand now [21:47] we talked about it at length in a session on UDS [21:47] ogra seemed extraordinarily depressed about the whole situation, but gave a ton of good info [21:48] we scoped out a plan for an updated calibration tool, although the blocker is finding someone to do the work (what's new) [22:21] bryce: yeah maybe it was about the fact that evtouch had a tool for that. it should be a lot easier to make one for evdev now [22:24] yeah that rings a bell [22:24] (in my swiss cheese memory) [22:25] hehe [22:27] RAOF, is it linux-nouveau-modules instead of nouveau-kernel-source now?