[00:02] sorry, didnt read the full bug and thought you were the person still having a problem with it :D [00:03] well thats new, gdm didnt start and dropped me to a login prompt at boot but i got a message that it terminated with exit status 1 this time [00:03] usually just silently drops me to login most boots [00:03] no logs of course [00:10] hrm [00:11] used to be it'd at least left an error msg in the gdm log file [00:11] does it not do this anymore? [00:13] mine didn't get that far [00:13] xterm merged [00:16] it touches the /var/log/gdm/:0.log but doesnt update it at all [00:16] the timestamp is right but the contents are from last boot [00:16] *when it happens [00:20] Sarvatt: g-p-m is configured to 'blank screen' (i.e., 'lock screen'0 [00:20] heh go figure, I have three test machines, and at the moment none of the 3 are booting [00:20] * and I don't remember why [00:21] * and vt switching is not working on any of them [00:22] there was a nasty bug for awhile where dpms off would crash intel with multiple screens and dpms off was getting called in some tricky places, changing those options fixed it for some people back then [00:22] bryyce: if they use kms it's because of failsafe the vt change doesn't work [00:23] well I likely was testing kms on them [00:23] i still have wacky vt switching, alt+fkey works but control+alt+fkey doesnt work to go back to X from a vt [00:23] but that was back before holidays [00:23] so they've not been updated in a while, maybe I ought to do fresh reinstalls [00:23] hm one boots it just shows nothing on the screen [00:24] "back before holidays" - so gdm was even more likely to fail on boot-up then :) [00:24] indeed [00:25] in fact, debugging that problem was the last time I remember having all three systems in use [00:26] yeah no fedora patch to -nv to work on G80+ of course because they use nouveau for that, and thats the only place mvo's patches are fixing I think [00:27] Sarvatt: the patch for the server? [00:31] aha sure enough [00:33] yeah, -nv just had a fix that stopped the crash on boot but still had the color problems and isnt supposed to work on 1.7 yet, went looking at fedora cvs to see if they were patching it but then i saw it was only a problem on G80 and newer and of course they didnt patch it because they use nouveau :D [00:33] Sarvatt: that one is from upstream .16 [00:33] yeah [00:33] and only the xserver patch was enough to make it work [00:33] but no reason to drop the -nv one since it's upstream anyway [00:34] the xserver patch doesnt work with nv .16, that commit breaks it [00:34] so mandriva ships a forked -sis with a 1,4MB patch on top of it, and calls the result sisimedia [00:35] yeah I have sis in one of my servers I messed around with that on [00:35] too bad that it's the only driver supporting 671/771 chips [00:35] some sis employee leaked an internal blob [00:35] heh [00:35] it's not a blob, but a diff [00:35] i couldnt even get it working with xserver 1.6 though :( [00:36] they leaked it as a blob i mean, was blob only for years [00:36] ok [00:37] intrepid was the last release i could use it under [00:37] http://ncc-1701a.homelinux.net/~linux-sis/index.php?page=FrontPage [00:37] backstory on it there [00:37] woohoo, we are again under 2800 bugs [00:38] seriously? [00:39] yes, filed some dupes [00:39] oh, I read the 8 as a 0 [00:39] Sarvatt: uh, what a mess [00:39] bryyce: hah, in your dreams :) [00:39] yeah saw you've been busy in the tracker timo :-) [00:39] a drop in the ocean though [00:39] tjaalton, yeah I gotta bump up the y-axis on my graphs again :-( [00:39] tjaalton, I just closed half the xterm bug reports :-) [00:40] hehe, I noticed that the total count went down ~25 bugs [00:41] well I can claim responsibility only for maybe 7 ;-) [00:41] there were several dupes about that sis chip [00:42] 25 bugs is almost 1% [00:42] tjaalton, btw, I dunno if I mentioned this but I set up a new report at http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/high-karma-bugs.html [00:42] it shows bugs reported by people with over 10k karma [00:42] oh its the 3D driver that was the blob [00:42] ooh, so few [00:44] hi, any clue what would cause the following? http://launchpadlibrarian.net/37629930/buildlog_ubuntu-lucid-i386.kdebase-workspace_4:4.3.90-0ubuntu1_FAILEDTOBUILD.txt.gz [00:44] (it built fine in pbuilder yesterday) [00:44] JontheEchidna, wrong channel, this is just for X.org packaging discussion [00:44] make[3]: *** No rule to make target `/usr/lib/libGL.so', needed by `lib/libkwineffects.so.1.0.0'. Stop. [00:44] well, it seems to be an X related failure :) [00:44] likely due to the mesa change [00:45] tjaalton, yeah I have been thinking that looking at *all* bugs is too overwhelming, so looking to slice out saner subsets to focus on more realistic goals [00:49] looks like there's a new mesa waiting to be built [00:49] JontheEchidna: that doesn't change anything [00:49] ah, right: https://edge.launchpad.net/ubuntu/+source/mesa/7.6.1~rc3-1ubuntu2 [00:49] maybe gl.pc needs to be changed [00:49] libdir=/usr/lib [00:49] while it's /usr/lib/mesa now.. [01:01] oh well, anything build-depending on libgl1-mesa-dev fails to build now [01:01] including the xserver [01:01] because /usr/lib/libGL.so points nowhere [01:01] bugger [01:02] well good news and bad news and more bad news [01:02] execbuff while wedged after about an hour uptime with a newer intel :( [01:03] gl is all kinds of messed up right now until mesa gets published [01:03] but I think I found why intel isnt booting into gdm [01:04] i moved /lib/udev/rules.d/40-xserver-xorg-video-intel.rules out of the way and it booted into my desk 6 times in a row [01:04] desktop* [01:05] what's in that file? [01:05] DRIVER=="i915, "ACTION=="change", ENV{ERROR}==1, PROGRAM="/usr/share/apport/apport-gpu-error-intel.py" [01:05] aha yes [01:05] ooh maybe this will explain why that's not been working [01:06] i dont even have that file [01:06] I thought that file sounded familiar :-) [01:06] hmm, neither do I [01:06] however my intel box is booting ok [01:07] that file should be provided by xserver-xorg-video-intel [01:08] I do [01:08] debian/rules has the command to install it [01:08] rules: install -m 755 debian/apport-gpu-error-intel.py $(CURDIR)/debian/tmp/usr/share/apport [01:09] oh the apport file [01:09] don't have that one [01:09] how about /usr/bin/intel_reg_dumper ? [01:10] I'm missing that as well [01:10] intel-dbg installs that one [01:11] perhaps the apport script just needs added to xserver-xorg-video-intel.install? [01:12] I suppose if we do this then intel_reg_dumper ought to move into that as well [01:12] yeah [01:12] that python script should be installed with intel-gpu-tools shouldnt it? it calls intel_gpu_dump from that package [01:12] yeah they definitely go together [01:13] what do you guys think, should they be in the -dbg or the normal package? [01:15] -dbg is not on a stock install [01:15] while -intel and i-g-t are [01:15] wish intel_gpu_dump was always installed for intel since its doesnt gain anything from being in the dbg package [01:16] I tend to agree [01:16] it's in i-g-t, not -dbg [01:16] ok, I'll add to my todo list to fix this up and move the dump tool into the regular package [01:17] it's installed already, by intel-gpu-tools [01:17] what's i-g-t? [01:17] -dbg has intel_reg_dumper [01:17] oh right, this got split out [01:17] i mean intel_gpu_dump doesnt need anything from -dbg, and moving the apport script to dbg wouldnt get much use [01:17] in intel 2.10 reg_dumper is in i-g-t now too yeah [01:18] hmm? they are separate sources [01:18] yeah [01:18] or do you mean 2.10 dropped reg_dumper? [01:18] wonder why that udev rule is dropping me to a login prompt on boot most times though if thats what it is, would be interested if it fixes it for you tjaalton [01:19] so make the driver depend on i-g-t now, and then put the apport script into the base .install? [01:19] yeah 2.10 dropped intel_reg_dumper from the intel source [01:19] bryyce: it already Recommends it [01:19] tjaalton, ok great [01:19] Sarvatt: so gpu_dump replaces it? [01:20] no wait [01:20] it's in i-g-t now [01:20] yep [01:21] but master, not 1.0.2 [01:21] we'll need to change i-g-t to install it whenever we update intel [01:21] hmm thought it moved to i-g-t in the one we have and just wasnt getting installed last i checked [01:22] nope! [01:22] not in tools/ [01:22] the commit was right after the tag [01:24] hmm, mesa glx libdir is /usr/lib/glx, but nothing gets installed there [01:26] changing it to /usr/lib/mesa seems to have helped somewhat [01:26] but gl.pc didn't change [01:26] oh well, too late anyway [01:32] wonder how much longer mesa is going to take to go out, takes about 45 minutes to build on this thing but I'd like GL back :D [01:33] compiz starts up and takes control as window manager but doesn't work right now [01:33] had to vt switch and DISPLAY=:0 metacity --replace [01:33] usually takes a couple hours plus or minus a bit [01:44] maybe libgl1-mesa-swx11 should be updated for /usr/lib/mesa as well? [01:52] looks like mandriva has hit some bugs with the setup we're moving to where some binaries had RPATH hardcoded [01:54] http://lists.freedesktop.org/archives/compiz/2008-March/003067.html [02:39] x11-xserver-utils merged [02:55] Is anyone looking into the current mesa breakage? [02:55] w/ tseliot's new stuff? [03:12] it's just broken until its published [03:13] So 7.7-0ubuntu1 is the fix? [03:13] yeah [03:13] OK. That's not so bad. [03:30] still 30 minutes till amd64 even starts to build :( [03:31] Probably worth trying to poke a buildd admin to rescore it. [03:42] hmm didnt we used to not build libgl1-mesa-swx11-i686 with mesa? [03:52] libgl1-mesa-glx-i686 was commented out, is that what you were thinking of? [03:53] or libgl1-mesa-dri-i686, that's commented out too [04:04] yeah must be thinking of those, packages.ubuntu.com says I'm really wrong :) [04:21] just noticed the intel packaging i do on edgers doesn't have that udev rule in it, but i still had the udev rule hanging around from the ubuntu one [04:30] oops, didn't think about how I cant use origin/ubuntu for karmic anymore and almost uploaded a new mesa :D [04:36] builds still fail with latest mesa: http://launchpadlibrarian.net/37635550/buildlog_ubuntu-lucid-i386.kdebase-runtime_4:4.3.90-0ubuntu2_FAILEDTOBUILD.txt. [04:46] ScottK: I'm sorry, by "breakage" I didn't know you meant this build breakage, gl was broken everywhere for a few hours there if someone updated in the middle (like I did) [05:51] Sarvatt: OK, so waht's the solution? [07:36] Sarvatt: 7.7 is _not_ the solution [08:04] tseliot: hey, the mesa change breaks any build that needs /usr/lib/libGL.so (or gl.pc) [08:08] tjaalton: ??? [08:08] ldconfig should know where libGL.so* is [08:09] but libGL.so points nowhere [08:10] let me check [08:10] 06:36 < JontheEchidna> builds still fail with latest mesa: [08:10] http://launchpadlibrarian.net/37635550/buildlog_ubuntu-lucid-i386.kdebase-runtime_4:4.3.90-0ubuntu2_FAILEDTOBUILD.txt. [08:12] the link appears to be brokeni [08:12] broken [08:12] yes, because libdir wasn't changed [08:12] but that's not enough [08:13] no, I mean the URL [08:13] and I said the reason for that [08:15] * tseliot slept less than 5 hours [08:16] tjaalton: there's no trace of libGL.so here, only libGL.so.1 [08:17] libgl1-mesa-glx-dev [08:17] Hi, are the proprietary nvidia drivers currently working for Lucid? I see 185 in jockey, should I go ahead and install it? I have 8600M GT. [08:17] anything that build-depends on that will fail [08:17] or mesa-common-dev, which has the gl.pc [08:17] testing the mesa build again.. [08:18] tjaalton: so it's just a matter of adding a link, right? [08:18] in /usr/lib/mesa [08:18] libGL.so -> libGL.so.1 [08:19] no links, fixing the config options [08:20] +but rather [08:26] * alkisg tries to install the 185 drivers... [08:27] alkisg: no, 185 won't work [08:27] nvidia-current should [08:27] and please don't use jockey. It doesn't support the new drivers yet [08:30] tseliot, I don't see nvidia-current in synaptic... /me googles... [08:31] your mirror doesn't have it yet [08:31] alkisg: then I guess you'll have to wait until your mirror gets it [08:31] tseliot: ah, thank you, that's it (I'm in Greece) [08:31] (and tjaalton :)) [08:31] tjaalton: $(LIB_DIR) is what we need to set, right? [08:33] tseliot: well, --libdir [08:35] but setting that would install gl{,u}.pc in /usr/lib/mesa/pkgconfig, which is wrong [08:42] that can be fixed in *.install [08:44] but practically, everything libGL* needs to be moved to /usr/lib/mesa [08:44] tjaalton: libgl1-mesa-dev.install [08:44] so the changes are not that small in the end [08:45] wonder how many places hardcode /usr/lib/libGL* [08:45] in proprietary apps etc [08:45] they can call dlopen() but the Mandriva developer told me that it works [08:45] tseliot: libgl*.install [08:45] but they don't install these in a subdir, right? [08:46] so we are deviating from them [08:48] tjaalton: they will install libGL* in a subdir. It's only by chance that things work there [08:48] as they didn't enable tls [08:50] http://pastebin.ubuntu.com/353841 [08:51] * tseliot reads the diff [08:53] tjaalton: it looks good === \vish is now known as vish [09:12] tseliot: what package installs the ld.so.conf.d/gl.conf or what's that called? [09:14] tjaalton: the xserver installs the /usr/lib/standard-x11/ld.so.conf [09:14] no I mean the one with the libGL path [09:14] and /etc/ld.so.conf.d/GL.conf points to it [09:15] tjaalton: ldconfig reads /etc/ld.so.conf.d/GL.conf and knows where to find libGL.so [09:16] ok [09:16] when you switch to nvidia, GL.conf points to a different conf file which tells ldconfig where it can find the nvidia libGL stuff [09:26] xserver build still failed [09:26] dpkg-shlibdeps: error: couldn't find library libGL.so.1 needed by debian/xserver-xephyr/usr/bin/Xephyr (ELF format: 'elf32-i386'; RPATH: ''). [09:29] tjaalton: did you do an ldconfig? [09:29] or is it still a matter of .pc files? [09:31] as I assume that you're testing locally [09:31] I would've thought installing the packages ran ldconfig [09:32] tjaalton: yes, but what packages are we talking about? [09:32] the mesa ones [09:32] X and nvidia do it [09:32] built locally, installed them and built xserver [09:32] maybe should call ldconfig in mesa too [09:32] we should [09:32] though I didn't have the newer xserver [09:33] tjaalton: what does ldconfig --print | grep GL say? [09:34] installing the xserver didn't run ldconfig [09:34] I have libGL now that I ran ldconfig manually [09:34] aah [09:36] so the xserver build should pass now [09:36] hopefully ;) [09:36] BTW thanks for working on this [09:36] np [09:46] I wonder why on my lucid box, when I boot Xorg fails, but when I just restart gdm service, it works well. [09:47] good morning [09:47] my X seems to make the system freeze... [09:48] Duke`: that might be a racing problem between KMS and gdm [09:55] I can't get dri working [09:55] anymore [09:56] tjaalton: was it really necessary to change --libdir for confflags-dri ? [09:56] so, i want to give nvidia drivers another try [09:56] i purged nvidia* yesterday [09:56] tseliot: yes, that's where libGL is built [09:57] what do i need to install for jockey to work? [09:57] knittl: you can't right now. I haven't uploaded the new jockey yet [09:57] tseliot: ok, so i'll wait [09:58] but i could install the necessary packages anyway [09:58] nvidia-common i think it was [09:58] tjaalton: can you show me the X log and the output of update-alternatives --display gl_conf please? [09:59] knittl: I haven't uploaded the new nvidia-common either [09:59] ok, then i wait :D [09:59] knittl: if you need to install the latest driver, this should work: [09:59] install nvidia-current and then type sudo nvidia-xconfig [10:00] i thought this will not work because of update-alternatives-something jockey does behind the scenes [10:00] at least i remember bugabandoo saying something about it [10:01] knittl: yes as alternatives work in automatic mode without it. And in automatic mode the latest nvidia driver always wins [10:01] if you want to install -173 or -96 some manual configuration is required [10:01] i have a quadro fx 360m here, it uses the latest driver [10:02] ok then [10:05] tseliot: that looks normal [10:06] and the x log shows that dri is fine [10:07] tjaalton: what does the other command say? [10:09] did you upload something that could break evdev recently? [10:09] it seems to segfault here [10:11] no [10:11] what hw? [10:11] radeon [10:11] I mean input hw [10:11] a usb keyboard [10:11] and a usb mouse [10:11] put the logfile somewhere [10:12] I wish I could enter Recovery mode again [10:12] or even ssh into my testing box [10:12] :-/ [10:12] how do you know it's evdev then? [10:12] I managed to boot in Recovery mode before [10:13] kms ftw [10:13] +vesa [10:13] now grub starts and ignores my keyboard (i.e. doesn't offer me a menu) [10:14] shall I use fbdev if/when I can? [10:14] there's a bug open about that [10:14] fbdev failsafe with kms [10:15] so no dri with the mesa changes [10:15] and I don't really have time for this :) [10:15] tjaalton: you didn't give me the output of that command though [10:15] Hi, is it expected that libgl1-mesa-glx in lucid puts their libs in /usr/lib/mesa? as this leaves libgl1-mesa-dev with a broken /usr/lib/libGL.so link [10:15] alternatives? I said it looked ok [10:16] tjaalton: and what do you mean by no dri, exactly? [10:16] not completely true though, glxgears seems to be accelerated [10:17] geser: tjaalton wrote a fix for that. But yes, the change is intended [10:18] so only the -dev package is currently broken? [10:18] tjaalton: are you referring to glxinfo |grep direct? [10:18] tseliot: yes [10:18] and the logfile says DRI is on [10:19] tjaalton: anything interesting in dmesg? [10:19] no [10:23] tjaalton: did dri work before your last change? [10:23] it works with stock packages [10:24] tjaalton, how founded is your worry about apps hardcoding to /usr/lib/libGL.so.1 (do you have examples?)? [10:25] superm1: none [10:27] tjaalton: stock being 7.7-1ubuntu1 ? [10:27] the one from the archive [10:27] ok [10:27] tried a dist-upgrade and stuff works then [10:28] tseliot, i dont think you can recommend people install from the archive still even before jockey stuff is in place, nvidia-current is still in NEW: https://edge.launchpad.net/ubuntu/lucid/+queue [10:32] tseliot: I don't know, feel free to mess with the links, I've spent too much time on this already [10:32] tjaalton: ok [10:34] superm1: slangasek told me that he approved them [10:34] tseliot, oh he only approved the source packages then, still has to approve binaries [10:34] d'oh [10:39] tjaalton: my filesystem was broken. X starts now [10:41] ok, x won't start—i guess this is still related to -nv drivers? am i correct? [10:42] tjaalton: radeon still seems to fail though (with stock X and mesa). fbdev works [10:44] tseliot: it's a pretty old snapshot [10:45] how can i use vesa or nouveau? [10:53] tjaalton: which used to work with the old mesa and drm. Downgrading mesa didn't help. I'll try downgrading libdrm [10:54] tseliot: the api changed [10:54] so we really need a new snapshot [10:54] tseliot: but, compiz works here again with the new stuff [10:55] double-checked that the -dev packages were correct [10:55] and rebuilt xserver, and works now [10:56] tjaalton: what driver are you using? Intel? [10:56] tjaalton: also, did you upload your fix? [10:56] intel yes, and didn't upload anything yet [10:57] The following packages have unmet dependencies: xserver-xorg-video-nouveau: Depends: xserver-xorg-core (>= 2:1.6.2) but it is [10:57] not going to be installed [10:57] knittl: would need a new snapshot [10:57] tjaalton: ok, so the only way is to use vesa for now? [10:57] or -nv? [10:57] tjaalton: please upload the fixes if they work correctly [10:58] or push them to git and I'll upload them if you prefer [10:58] tjaalton: gdm/X won't start, tells me to run in low graphics mode [10:58] knittl: try fbdev [10:58] tseliot: I'm just trying to figure out if the xserver needs to be rebuilt or not [10:58] i nuked my xorg.conf [10:58] knittl: so you're using vesa then [10:58] tjaalton: but vesa should work? [10:58] if that's what you're using [10:58] how can i find out? [10:59] or, what is the default without an xorg.conf? [10:59] you are running failsafe == vesa [10:59] i'm not running anything atm [10:59] tjaalton: if Xephyr depended on mesa, then I guess we need to rebuild X against the new mesa [10:59] i exited to console [11:01] tseliot: uh wait, I didn't have the new glx installed, so no, it doesn't work [11:03] tjaalton: do we have a new snapshot of radeon in xorg-edgers with the new api? [11:03] tseliot: I don't know, probably [11:04] shipping the alpha in this state wouldn't be ideal [11:05] really? :) [11:05] I'll try intel here [11:05] only the radeon api changed [11:05] in libdrm/mesa/ddx [11:07] * tseliot hates grub 2 [11:15] ok, signing off.. need to start reading asap -> [11:29] tseliot: Building gnome-shell gives me: checking for glXCreateContext in -lGL... no ---> internet tells me (old gnome-games bug): The libglx.so from nvidia binary [11:29] driver was replaced by xserver upgrade. That was causing this problem. [11:32] sebner: we need the fix that tjaalton wrote for that [11:32] I'll test things here now [11:33] tseliot: cool, /me is afraid of rebooting right now so sebner keeps his 3d for now :P [11:47] sebner: libgl1-mesa-dev is currently broken in lucid, so everything which tries to link with -lGL will currently fail [11:47] right [11:49] geser: oh ho! good to know, thx [11:50] the fix that I mentioned is supposed to solve that [11:52] :) [11:59] tjaalton: if I try to build with your patch I get this: dh_install: libgl1-mesa-swx11 missing files (usr/lib/mesa/libGL.so.*), aborting [11:59] * tseliot -> lunch [12:51] never mind [14:42] tjaalton: ping [14:53] tjaalton: after updating libdrm, X segfaults when using the radeon driver (https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/505112) [14:53] Launchpad bug 505112 in xserver-xorg-video-ati "Segfault at X startup with radeon driver (dup-of: 505095)" [Undecided,Confirmed] [14:53] Launchpad bug 505095 in xserver-xorg-video-ati "X don't start in Lucid" [Undecided,New] [14:53] wind-rider: the API changed. I'm working on it [14:54] tseliot: ok, great, thx :) i saw tjaalton updated the package at https://lists.ubuntu.com/archives/lucid-changes/2010-January/003025.html [14:54] you might want /me nods [14:54] tseliot: so i thought he might know more [14:54] stupid keyboard.. [14:54] wind-rider: thanks for filing the bug report [14:55] oh, it's a duplicate [14:55] tseliot: oh, that's fine :) i just confirmed it [14:55] ok [14:55] tseliot: and marked a duplicate [14:56] tseliot: it is assigned now at the xserver-xorg-video-ati package, should it be changed? [14:56] * tseliot nods [14:56] no [14:56] I'll take care of the bug report [14:56] thanks [14:56] great :) thx to you! [14:58] tseliot: my Xserver segfault after reboot ^^ [14:58]