[00:02] I am uploading an xorg-server to build against that mesa build now - reality check [00:10] does X autodetect work with only USB? [00:13] pwnguin: AIUI yes [00:13] tabletPCs commonly connect via tty, I had thought perhaps the X autodetect stuff might do away with the need for tabletPC =( [00:13] err [00:14] do away with xorg.conf for tabletPC [00:14] well, its good to know that at least it works for usb tablets [00:15] X only knows what hal knows [00:16] so if it can be set up so that hal knows about it before the server is started, it should work? [00:16] ok, so x does talk with hal [00:16] it's never worked for me =( [00:17] i'll bring it up with toshiba-tablet [00:18] it talks with hal to see if there are devices that match some keys [00:18] or something like that.. [00:18] so you need to have fdi files to set up the values [00:18] right [00:19] one of the HAL maintainers works with suse [00:19] and tablets [00:20] I need to find some good resources on HAL -- nothing I've found quite hits everything I need to know [00:20] tjaalton: so mesa seemed to build fine once I added --disable-glut to the swx11 confs in debian/rules. [00:21] tormod: but that would mean that glut is not built at all [00:21] was it build before? [00:21] it builds here.. maybe it needs something else. or do you mean amd64 [00:22] what builds? my ppa source which already had --disable-glut? [00:22] no I am not talking about the amd64 failure, I am clueless there [00:22] tormod: no the one from git, builds locally [00:23] what's the error wit glut? [00:24] first it needed libxmu-dev and libxi-dev to satisfy configure [00:26] then http://launchpadlibrarian.net/15797046/buildlog_ubuntu-hardy-i386.mesa_7.1.0~git20080703.b3e1f9bd-0ubuntu0tormod2_FAILEDTOBUILD.txt.gz - seems like missing XInput.h etc [00:26] all this was not needed before the autotools change [00:29] now xorg-server build fails because dri2 needs GL/internal/dri_sarea.h (wonder what "internal" means) [00:29] use --disable-dri2 [00:29] no point in building that [00:29] since libdrm does not support ttm [00:30] 2.3.1 that is [00:30] libdrm git? [00:30] or I need a special branch [00:30] modesetting [00:30] yes [00:30] it built fine before (although it probably was useless) [00:30] don't know if the gem-branch would do [00:31] there should be checks now to disable dri2 if libdrm was too old [00:31] thanks, I'll wait for that to land on trunk [00:31] heh [00:32] yes I saw that xorg-server commit, didn't seem to kick in here [00:32] right, GLUT seems to need xmu and xi [00:35] and it was not built before [00:37] re that libdrm check, maybe my git libdrm declares itself as 2.3.2? [00:37] or 2.4.0 [00:39] looking at the source (configure.ac) it's 2.3.1. strange [00:40] it's 2.3.1 in libdrm.pc [00:41] ok [00:46] I see that 2.3.2 check in both configure{,.ac} but the build log shows it passed [00:56] night [01:14] sigh, too tired to do anything useful.. night [01:15] night [01:18] is wacom-tools installed by default now? [01:19] im not sure how to query apt to figure this out [01:28] I'm not sure either [01:32] i'd rather not set up a chroot just to figure out whether ubuntu-desktop draws it in [05:41] the wacom driver is installed by input-all [09:07] ouch, alpha2 next thursday.. [09:42] mesa uploaded to my ppa to make sure it builds [09:42] locally it does [09:50] tjaalton: why is libgl1-mesa-dev automatically installed in Intrepid? [09:55] tjaalton: I'm asking because nvidia-glx--dev will need to remove "libgl1-mesa-dev", together with "mesa-common-dev" [09:56] tseliot: it shouldn't be automatically installed [09:57] at least the reverse-depends don't show anything suspicious [09:58] tjaalton: sorry, I meant the "Automatically installed: yes" when you do aptitude show package [09:58] tseliot: some package that you installed pulled it in [09:58] Yes, I had figured that out, no problem then [09:59] funny that in hardy nvidia*dev _depend_ on libgl1-mesa-dev [09:59] are the packages going to be named nvidia-glx-VER? [10:00] I'm just confused about where we are at the moment :) [10:00] right, mesa build failed on amd64 [10:06] tjaalton: honestly I don't know why it depends on libgl1-mesa-dev in Hardy [10:06] as regards the names, they will be nvidia-glx-177, nvidia-glx-173, etc. [10:10] ok [10:11] I will show you the source as soon as the packages are finished [10:14] I don't think I have anything to add :) [10:14] since I've been away for a couple of weeks etc [10:14] you are so much ahead on this [10:15] I almost sent an email to the debian folks about how they are planning on resolving the issues, but didn't [10:16] honestly, I don't know if we'll ever manage to have our changes integrated in debian [10:16] right [10:16] so it doesn't matter if we diverge [10:16] even further [10:16] yes [10:17] shall I still keep the unused files and folders? [10:17] the ones from the merge, I mean [10:20] nah, feel free to clean it up as you see fit [10:20] ok :-) [10:21] when do you expect to have them ready for upload? [10:22] for alpha2? [10:23] Driver 177 is ready i.e. it installs, uninstalls, replaces the old packages with no problems. I'll have to install Intrepid (32 and 64bit) on a real machine so as to see if the driver loads. Currently I'm testing the packages in virtualbox [10:23] I have to apply a few changes to driver 173, 96, 71 [10:23] and test them all [10:24] when is alpha 2 due? [10:24] next thursday [10:24] so the packages should be ready by tuesday.. [10:25] even if the packages were ready by tuesday, the rest wouldn't be ready [10:25] i.e. the kernel postinst.d hook, etc. [10:25] I'm working on it ;) [10:26] ok, take your time [10:50] unexporting LDFLAGS seems to do the trick for mesa amd64 build [11:17] ok, will upload mesa no [11:17] *now [11:55] bryce: xorg-server uploaded too. when it's built we can start uploading drivers as -Xbuild1 === james_w_ is now known as james_w