/srv/irclogs.ubuntu.com/2010/01/09/#ubuntu-x.txt

Sarvattsorry, didnt read the full bug and thought you were the person still having a problem with it :D00:02
Sarvattwell 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 time00:03
Sarvattusually just silently drops me to login most boots00:03
Sarvattno logs of course00:03
bryycehrm00:10
bryyceused to be it'd at least left an error msg in the gdm log file00:11
bryycedoes it not do this anymore?00:11
tjaaltonmine didn't get that far00:13
bryycexterm merged00:13
Sarvattit touches the /var/log/gdm/:0.log but doesnt update it at all00:16
Sarvattthe timestamp is right but the contents are from last boot00:16
Sarvatt*when it happens00:16
slangasekSarvatt: g-p-m is configured to 'blank screen' (i.e., 'lock screen'000:20
bryyceheh go figure, I have three test machines, and at the moment none of the 3 are booting00:20
bryyce* and I don't remember why00:20
bryyce* and vt switching is not working on any of them00:21
Sarvattthere 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 then00:22
tjaaltonbryyce: if they use kms it's because of failsafe the vt change doesn't work00:22
bryycewell I likely was testing kms on them00:23
Sarvatti still have wacky vt switching, alt+fkey works but control+alt+fkey doesnt work to go back to X from a vt00:23
bryycebut that was back before holidays00:23
bryyceso they've not been updated in a while, maybe I ought to do fresh reinstalls00:23
bryycehm one boots it just shows nothing on the screen00:23
slangasek"back before holidays" - so gdm was even more likely to fail on boot-up then :)00:24
bryyceindeed00:24
bryycein fact, debugging that problem was the last time I remember having all three systems in use00:25
Sarvattyeah 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 think00:26
tjaaltonSarvatt: the patch for the server?00:27
bryyceaha sure enough00:31
Sarvattyeah, -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 :D00:33
tjaaltonSarvatt: that one is from upstream .1600:33
Sarvattyeah00:33
tjaaltonand only the xserver patch was enough to make it work00:33
tjaaltonbut no reason to drop the -nv one since it's upstream anyway00:33
Sarvattthe xserver patch doesnt work with nv .16, that commit  breaks it00:34
tjaaltonso mandriva ships a forked -sis with a 1,4MB patch on top of it, and calls the result sisimedia00:34
Sarvattyeah I have sis in one of my servers I messed around with that on00:35
tjaaltontoo bad that it's the only driver supporting 671/771 chips00:35
Sarvattsome sis employee leaked an internal blob00:35
bryyceheh00:35
tjaaltonit's not a blob, but a diff00:35
Sarvatti couldnt even get it working with xserver 1.6 though :(00:35
Sarvattthey leaked it as a blob i mean, was blob only for years00:36
tjaaltonok00:36
Sarvattintrepid was the last release i could use it under00:37
Sarvatthttp://ncc-1701a.homelinux.net/~linux-sis/index.php?page=FrontPage00:37
Sarvattbackstory on it there00:37
tjaaltonwoohoo, we are again under 2800 bugs00:37
bryyceseriously?00:38
tjaaltonyes, filed some dupes00:39
bryyceoh, I read the 8 as a 000:39
tjaaltonSarvatt: uh, what a mess00:39
tjaaltonbryyce: hah, in your dreams :)00:39
bryyceyeah saw you've been busy in the tracker timo :-)00:39
tjaaltona drop in the ocean though00:39
bryycetjaalton, yeah I gotta bump up the y-axis on my graphs again :-(00:39
bryycetjaalton, I just closed half the xterm bug reports :-)00:39
tjaaltonhehe, I noticed that the total count went down ~25 bugs00:40
bryycewell I can claim responsibility only for maybe 7 ;-)00:41
tjaaltonthere were several dupes about that sis chip00:41
tjaalton25 bugs is almost 1%00:42
bryycetjaalton, 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.html00:42
bryyceit shows bugs reported by people with over 10k karma00:42
Sarvattoh its the 3D driver that was the blob00:42
tjaaltonooh, so few00:42
JontheEchidnahi, any clue what would cause the following? http://launchpadlibrarian.net/37629930/buildlog_ubuntu-lucid-i386.kdebase-workspace_4:4.3.90-0ubuntu1_FAILEDTOBUILD.txt.gz00:44
JontheEchidna(it built fine in pbuilder yesterday)00:44
bryyceJontheEchidna, wrong channel, this is just for X.org packaging discussion00:44
tjaaltonmake[3]: *** No rule to make target `/usr/lib/libGL.so', needed by `lib/libkwineffects.so.1.0.0'.  Stop.00:44
JontheEchidnawell, it seems to be an X related failure :)00:44
tjaaltonlikely due to the mesa change00:44
bryycetjaalton, 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 goals00:45
JontheEchidnalooks like there's a new mesa waiting to be built00:49
tjaaltonJontheEchidna: that doesn't change anything00:49
JontheEchidnaah, right: https://edge.launchpad.net/ubuntu/+source/mesa/7.6.1~rc3-1ubuntu200:49
tjaaltonmaybe gl.pc needs to be changed00:49
tjaaltonlibdir=/usr/lib00:49
tjaaltonwhile it's /usr/lib/mesa now..00:49
tjaaltonoh well, anything build-depending on libgl1-mesa-dev fails to build now01:01
tjaaltonincluding the xserver01:01
tjaaltonbecause /usr/lib/libGL.so points nowhere01:01
bryycebugger01:01
Sarvattwell good news and bad news and more bad news01:02
Sarvattexecbuff while wedged after about an hour uptime with a newer intel :(01:02
Sarvattgl is all kinds of messed up right now until mesa gets published01:03
Sarvattbut I think I found why intel isnt booting into gdm01:03
Sarvatti 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 row01:04
Sarvattdesktop*01:04
bryycewhat's in that file?01:05
SarvattDRIVER=="i915, "ACTION=="change", ENV{ERROR}==1, PROGRAM="/usr/share/apport/apport-gpu-error-intel.py"01:05
bryyceaha yes01:05
bryyceooh maybe this will explain why that's not been working01:05
Sarvatti dont even have that file01:06
bryyceI thought that file sounded familiar :-)01:06
bryycehmm, neither do I01:06
bryycehowever my intel box is booting ok01:06
bryycethat file should be provided by xserver-xorg-video-intel01:07
tjaaltonI do01:08
bryycedebian/rules has the command to install it01:08
bryycerules:install -m 755 debian/apport-gpu-error-intel.py $(CURDIR)/debian/tmp/usr/share/apport01:08
tjaaltonoh the apport file01:09
tjaaltondon't have that one01:09
bryycehow about /usr/bin/intel_reg_dumper ?01:09
bryyceI'm missing that as well01:10
tjaaltonintel-dbg installs that one01:10
bryyceperhaps the apport script just needs added to xserver-xorg-video-intel.install?01:11
bryyceI suppose if we do this then intel_reg_dumper ought to move into that as well01:12
tjaaltonyeah01:12
Sarvattthat python script should be installed with intel-gpu-tools shouldnt it? it calls intel_gpu_dump from that package01:12
bryyceyeah they definitely go together01:12
bryycewhat do you guys think, should they be in the -dbg or the normal package?01:13
tjaalton-dbg is not on a stock install01:15
tjaaltonwhile -intel and i-g-t are01:15
Sarvattwish intel_gpu_dump was always installed for intel since its doesnt gain anything from being in the dbg package01:15
bryyceI tend to agree01:16
tjaaltonit's in i-g-t, not -dbg01:16
bryyceok, I'll add to my todo list to fix this up and move the dump tool into the regular package01:16
tjaaltonit's installed already, by intel-gpu-tools01:17
bryycewhat's i-g-t?01:17
tjaalton-dbg has intel_reg_dumper01:17
bryyceoh right, this got split out01:17
Sarvatti mean intel_gpu_dump doesnt need anything from -dbg, and moving the apport script to dbg wouldnt get much use01:17
Sarvattin intel 2.10 reg_dumper is in i-g-t now too yeah01:17
tjaaltonhmm? they are separate sources01:18
bryyceyeah01:18
tjaaltonor do you mean 2.10 dropped reg_dumper?01:18
Sarvattwonder 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 tjaalton01:18
bryyceso make the driver depend on i-g-t now, and then put the apport script into the base .install?01:19
Sarvattyeah 2.10 dropped intel_reg_dumper from the intel source01:19
tjaaltonbryyce: it already Recommends it01:19
bryycetjaalton, ok great01:19
tjaaltonSarvatt: so gpu_dump replaces it?01:19
tjaaltonno wait01:20
tjaaltonit's in i-g-t now01:20
Sarvattyep01:20
tjaaltonbut master, not 1.0.201:21
Sarvattwe'll need to change i-g-t to install it whenever we update intel01:21
Sarvatthmm thought it moved to i-g-t in the one we have and just wasnt getting installed last i checked01:21
Sarvattnope!01:22
Sarvattnot in tools/01:22
tjaaltonthe commit was right after the tag01:22
tjaaltonhmm, mesa glx libdir is /usr/lib/glx, but nothing gets installed there01:24
tjaaltonchanging it to /usr/lib/mesa seems to have helped somewhat01:26
tjaaltonbut gl.pc didn't change01:26
tjaaltonoh well, too late anyway01:26
Sarvattwonder 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 :D01:32
Sarvattcompiz starts up and takes control as window manager but doesn't work right now01:33
Sarvatthad to vt switch and DISPLAY=:0 metacity --replace01:33
bryyceusually takes a couple hours plus or minus a bit01:33
Sarvattmaybe libgl1-mesa-swx11 should be updated for /usr/lib/mesa as well?01:44
Sarvattlooks like mandriva has hit some bugs with the setup we're moving to where some binaries had RPATH hardcoded01:52
Sarvatthttp://lists.freedesktop.org/archives/compiz/2008-March/003067.html01:54
bryycex11-xserver-utils merged02:39
ScottKIs anyone looking into the current mesa breakage?02:55
superm1w/ tseliot's new stuff?02:55
Sarvattit's just broken until its published03:12
ScottKSo 7.7-0ubuntu1 is the fix?03:13
Sarvattyeah03:13
ScottKOK.  That's not so bad.03:13
Sarvattstill 30 minutes till amd64 even starts to build :(03:30
ScottKProbably worth trying to poke a buildd admin to rescore it.03:31
Sarvatthmm didnt we used to not build libgl1-mesa-swx11-i686 with mesa?03:42
bryycelibgl1-mesa-glx-i686 was commented out, is that what you were thinking of?03:52
bryyceor libgl1-mesa-dri-i686, that's commented out too03:53
Sarvattyeah must be thinking of those, packages.ubuntu.com says I'm really wrong :)04:04
Sarvattjust 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 one04:21
Sarvattoops, didn't think about how I cant use origin/ubuntu for karmic anymore and almost uploaded a new mesa :D04:30
JontheEchidnabuilds still fail with latest mesa: http://launchpadlibrarian.net/37635550/buildlog_ubuntu-lucid-i386.kdebase-runtime_4:4.3.90-0ubuntu2_FAILEDTOBUILD.txt.04:36
SarvattScottK: 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)04:46
ScottKSarvatt: OK, so waht's the solution?05:51
tjaaltonSarvatt: 7.7 is _not_ the solution07:36
tjaaltontseliot: hey, the mesa change breaks any build that needs /usr/lib/libGL.so (or gl.pc)08:04
tseliottjaalton: ???08:08
tseliotldconfig should know where libGL.so* is08:08
tjaaltonbut libGL.so points nowhere08:09
tseliotlet me check08:10
tjaalton06:36 < JontheEchidna> builds still fail with latest mesa:08:10
tjaaltonhttp://launchpadlibrarian.net/37635550/buildlog_ubuntu-lucid-i386.kdebase-runtime_4:4.3.90-0ubuntu2_FAILEDTOBUILD.txt.08:10
tseliotthe link appears to be brokeni08:12
tseliotbroken08:12
tjaaltonyes, because libdir wasn't changed08:12
tjaaltonbut that's not enough08:12
tseliotno, I mean the URL08:13
tjaaltonand I said the reason for that08:13
* tseliot slept less than 5 hours08:15
tseliottjaalton: there's no trace of libGL.so here, only libGL.so.108:16
tjaaltonlibgl1-mesa-glx-dev08:17
alkisgHi, 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
tjaaltonanything that build-depends on that will fail08:17
tjaaltonor mesa-common-dev, which has the gl.pc08:17
tjaaltontesting the mesa build again..08:17
tseliottjaalton: so it's just a matter of adding a link, right?08:18
tseliotin /usr/lib/mesa08:18
tseliotlibGL.so -> libGL.so.108:18
tjaaltonno links, fixing the config options08:19
tjaalton+but rather08:20
* alkisg tries to install the 185 drivers...08:26
tseliotalkisg: no, 185 won't work08:27
tseliotnvidia-current should08:27
tseliotand please don't use jockey. It doesn't support the new drivers yet08:27
alkisgtseliot, I don't see nvidia-current in synaptic... /me googles...08:30
tjaaltonyour mirror doesn't have it yet08:31
tseliotalkisg: then I guess you'll have to wait until your mirror gets it08:31
alkisgtseliot: ah, thank you, that's it (I'm in Greece)08:31
alkisg(and tjaalton :))08:31
tseliottjaalton: $(LIB_DIR) is what we need to set, right?08:31
tjaaltontseliot: well, --libdir08:33
tjaaltonbut setting that would install gl{,u}.pc in /usr/lib/mesa/pkgconfig, which is wrong08:35
tjaaltonthat can be fixed in *.install08:42
tjaaltonbut practically, everything libGL* needs to be moved to /usr/lib/mesa08:44
tseliottjaalton: libgl1-mesa-dev.install08:44
tjaaltonso the changes are not that small in the end08:44
tjaaltonwonder how many places hardcode /usr/lib/libGL*08:45
tjaaltonin proprietary apps etc08:45
tseliotthey can call dlopen() but the Mandriva developer told me that it works08:45
tjaaltontseliot: libgl*.install08:45
tjaaltonbut they don't install these in a subdir, right?08:45
tjaaltonso we are deviating from them08:46
tseliottjaalton: they will install libGL* in a subdir. It's only by chance that things work there08:48
tseliotas they didn't enable tls08:48
tjaaltonhttp://pastebin.ubuntu.com/35384108:50
* tseliot reads the diff08:51
tseliottjaalton: it looks good08:53
=== \vish is now known as vish
tjaaltontseliot: what package installs the ld.so.conf.d/gl.conf or what's that called?09:12
tseliottjaalton: the xserver installs the /usr/lib/standard-x11/ld.so.conf09:14
tjaaltonno I mean the one with the libGL path09:14
tseliotand /etc/ld.so.conf.d/GL.conf points to it09:14
tseliottjaalton: ldconfig reads /etc/ld.so.conf.d/GL.conf and knows where to find libGL.so09:15
tjaaltonok09:16
tseliotwhen you switch to nvidia, GL.conf points to a different conf file which tells ldconfig where it can find the nvidia libGL stuff09:16
tjaaltonxserver build still failed09:26
tjaaltondpkg-shlibdeps: error: couldn't find library libGL.so.1 needed by debian/xserver-xephyr/usr/bin/Xephyr (ELF format: 'elf32-i386'; RPATH: '').09:26
tseliottjaalton: did you do an ldconfig?09:29
tseliotor is it still a matter of .pc files?09:29
tseliotas I assume that you're testing locally09:31
tjaaltonI would've thought installing the packages ran ldconfig09:31
tseliottjaalton: yes, but what packages are we talking about?09:32
tjaaltonthe mesa ones09:32
tseliotX and nvidia do it09:32
tjaaltonbuilt locally, installed them and built xserver09:32
tseliotmaybe should call ldconfig in mesa too09:32
tseliotwe should09:32
tjaaltonthough I didn't have the newer xserver09:32
tseliottjaalton: what does ldconfig --print | grep GL say?09:33
tjaaltoninstalling the xserver didn't run ldconfig09:34
tjaaltonI have libGL now that I ran ldconfig manually09:34
tseliotaah09:34
tjaaltonso the xserver build should pass now09:36
tseliothopefully ;)09:36
tseliotBTW thanks for working on this09:36
tjaaltonnp09:36
Duke`I wonder why on my lucid box, when I boot Xorg fails, but when I just restart gdm service, it works well.09:46
knittlgood morning09:47
tseliotmy X seems to make the system freeze...09:47
tseliotDuke`: that might be a racing problem between KMS and gdm09:48
tjaaltonI can't get dri working09:55
tjaaltonanymore09:55
tseliottjaalton: was it really necessary to change --libdir for confflags-dri ?09:56
knittlso, i want to give nvidia drivers another try09:56
knittli purged nvidia* yesterday09:56
tjaaltontseliot: yes, that's where libGL is built09:56
knittlwhat do i need to install for jockey to work?09:57
tseliotknittl: you can't right now. I haven't uploaded the new jockey yet09:57
knittltseliot: ok, so i'll wait09:57
knittlbut i could install the necessary packages anyway09:58
knittlnvidia-common i think it was09:58
tseliottjaalton: can you show me the X log and the output of update-alternatives --display gl_conf please?09:58
tseliotknittl: I haven't uploaded the new nvidia-common either09:59
knittlok, then i wait :D09:59
tseliotknittl: if you need to install the latest driver, this should work:09:59
tseliotinstall nvidia-current and then type sudo nvidia-xconfig09:59
knittli thought this will not work because of update-alternatives-something jockey does behind the scenes10:00
knittlat least i remember bugabandoo saying something about it10:00
tseliotknittl: yes as alternatives work in automatic mode without it. And in automatic mode the latest nvidia driver always wins10:01
tseliotif you want to install -173 or -96 some manual configuration is required10:01
knittli have a quadro fx 360m here, it uses the latest driver10:01
tseliotok then10:02
tjaaltontseliot: that looks normal10:05
tjaaltonand the x log shows that dri is fine10:06
tseliottjaalton: what does the other command say?10:07
tseliotdid you upload something that could break evdev recently?10:09
tseliotit seems to segfault here10:09
tjaaltonno10:11
tjaaltonwhat hw?10:11
tseliotradeon10:11
tjaaltonI mean input hw10:11
tseliota usb keyboard10:11
tseliotand a usb mouse10:11
tjaaltonput the logfile somewhere10:11
tseliotI wish I could enter Recovery mode again10:12
tseliotor even ssh into my testing box10:12
tseliot:-/10:12
tjaaltonhow do you know it's evdev then?10:12
tseliotI managed to boot in Recovery mode before10:12
tjaaltonkms ftw10:13
tjaalton+vesa10:13
tseliotnow grub starts and ignores my keyboard (i.e. doesn't offer me a menu)10:13
tseliotshall I use fbdev if/when I can?10:14
tjaaltonthere's a bug open about that10:14
tjaaltonfbdev failsafe with kms10:14
tjaaltonso no dri with the mesa changes10:15
tjaaltonand I don't really have time for this :)10:15
tseliottjaalton: you didn't give me the output of that command though10:15
geserHi, 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 link10:15
tjaaltonalternatives? I said it looked ok10:15
tseliottjaalton: and what do you mean by no dri, exactly?10:16
tjaaltonnot completely true though, glxgears seems to be accelerated10:16
tseliotgeser: tjaalton wrote a fix for that. But yes, the change is intended10:17
geserso only the -dev package is currently broken?10:18
tseliottjaalton: are you referring to glxinfo |grep direct?10:18
tjaaltontseliot: yes10:18
tjaaltonand the logfile says DRI is on10:18
tseliottjaalton: anything interesting in dmesg?10:19
tjaaltonno10:19
tseliottjaalton: did dri work before your last change?10:23
tjaaltonit works with stock packages10:23
superm1tjaalton, how founded is your worry about apps hardcoding to /usr/lib/libGL.so.1 (do you have examples?)?10:24
tjaaltonsuperm1: none10:25
tseliottjaalton: stock being 7.7-1ubuntu1 ?10:27
tjaaltonthe one from the archive10:27
tseliotok10:27
tjaaltontried a dist-upgrade and stuff works then10:27
superm1tseliot, 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/+queue10:28
tjaaltontseliot: I don't know, feel free to mess with the links, I've spent too much time on this already10:32
tseliottjaalton: ok10:32
tseliotsuperm1: slangasek told me that he approved them10:34
superm1tseliot, oh he only approved the source packages then, still has to approve binaries10:34
tseliotd'oh10:34
tseliottjaalton: my filesystem was broken. X starts now10:39
knittlok, x won't start—i guess this is still related to -nv drivers? am i correct?10:41
tseliottjaalton: radeon still seems to fail though (with stock X and mesa). fbdev works10:42
tjaaltontseliot: it's a pretty old snapshot10:44
knittlhow can i use vesa or nouveau?10:45
tseliottjaalton: which used to work with the old mesa and drm. Downgrading mesa didn't help. I'll try downgrading libdrm10:53
tjaaltontseliot: the api changed10:54
tjaaltonso we really need a new snapshot10:54
tjaaltontseliot: but, compiz works here again with the new stuff10:54
tjaaltondouble-checked that the -dev packages were correct10:55
tjaaltonand rebuilt xserver, and works now10:55
tseliottjaalton: what driver are you using? Intel?10:56
tseliottjaalton: also, did you upload your fix?10:56
tjaaltonintel yes, and didn't upload anything yet10:56
knittlThe following packages have unmet dependencies: xserver-xorg-video-nouveau: Depends: xserver-xorg-core (>= 2:1.6.2) but it is10:57
knittlnot going to be installed10:57
tjaaltonknittl: would need a new snapshot10:57
knittltjaalton: ok, so the only way is to use vesa for now?10:57
tjaaltonor -nv?10:57
tseliottjaalton: please upload the fixes if they work correctly10:57
tseliotor push them to git and I'll upload them if you prefer10:58
knittltjaalton: gdm/X won't start, tells me to run in low graphics mode10:58
tseliotknittl: try fbdev10:58
tjaaltontseliot: I'm just trying to figure out if the xserver needs to be rebuilt or not10:58
knittli nuked my xorg.conf10:58
tjaaltonknittl: so you're using vesa then10:58
knittltjaalton: but vesa should work?10:58
tseliotif that's what you're using10:58
knittlhow can i find out?10:58
knittlor, what is the default without an xorg.conf?10:59
tjaaltonyou are running failsafe == vesa10:59
knittli'm not running anything atm10:59
tseliottjaalton: if Xephyr depended on mesa, then I guess we need to rebuild X against the new mesa10:59
knittli exited to console10:59
tjaaltontseliot: uh wait, I didn't have the new glx installed, so no, it doesn't work11:01
tseliottjaalton: do we have a new snapshot of radeon in xorg-edgers with the new api?11:03
tjaaltontseliot: I don't know, probably11:03
tseliotshipping the alpha in this state wouldn't be ideal11:04
tjaaltonreally? :)11:05
tseliotI'll try intel here11:05
tjaaltononly the radeon api changed11:05
tjaaltonin libdrm/mesa/ddx11:05
* tseliot hates grub 211:07
tjaaltonok, signing off.. need to start reading asap ->11:15
sebnertseliot: Building gnome-shell gives me: checking for glXCreateContext in -lGL... no   ---> internet tells me (old gnome-games bug): The libglx.so from nvidia binary11:29
sebnerdriver was replaced by xserver upgrade. That was causing this problem.11:29
tseliotsebner: we need the fix that tjaalton wrote for that11:32
tseliotI'll test things here now11:32
sebnertseliot: cool, /me is afraid of rebooting right now so sebner keeps his 3d for now :P11:33
gesersebner: libgl1-mesa-dev is currently broken in lucid, so everything which tries to link with -lGL will currently fail11:47
tseliotright11:47
sebnergeser: oh ho! good to know, thx11:49
tseliotthe fix that I mentioned is supposed to solve that11:50
sebner:)11:52
tseliottjaalton: if I try to build with your patch I get this: dh_install: libgl1-mesa-swx11 missing files (usr/lib/mesa/libGL.so.*), aborting11:59
* tseliot -> lunch11:59
tseliotnever mind12:51
wind-ridertjaalton: ping14:42
wind-ridertjaalton: after updating libdrm, X segfaults when using the radeon driver (https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/505112)14:53
ubottuLaunchpad bug 505112 in xserver-xorg-video-ati "Segfault at X startup with radeon driver (dup-of: 505095)" [Undecided,Confirmed]14:53
ubottuLaunchpad bug 505095 in xserver-xorg-video-ati "X don't start in Lucid" [Undecided,New]14:53
tseliotwind-rider: the API changed. I'm working on it14:53
wind-ridertseliot: ok, great, thx :) i saw tjaalton updated the package at https://lists.ubuntu.com/archives/lucid-changes/2010-January/003025.html14:54
tseliotyou might want /me nods14:54
wind-ridertseliot: so i thought he might know more14:54
tseliotstupid keyboard..14:54
tseliotwind-rider: thanks for filing the bug report14:54
tseliotoh, it's a duplicate14:55
wind-ridertseliot: oh, that's fine :) i just confirmed it14:55
tseliotok14:55
wind-ridertseliot: and marked a duplicate14:55
wind-ridertseliot: it is assigned now at the xserver-xorg-video-ati package, should it be changed?14:56
* tseliot nods14:56
tseliotno14:56
tseliotI'll take care of the bug report14:56
tseliotthanks14:56
wind-ridergreat :) thx to you!14:56
sebnertseliot: my Xserver segfault after reboot ^^14:58
tseliotaah, so it was that14:58
sebnertseliot: that means?15:03
tseliotsebner: never mind I confused you with someone else15:03
sebnerah15:03
sebnertseliot: me blames the xorg update :P want to see nvida bugreport?15:04
tseliotsebner: the above mentioned crash is about radeon15:04
sebnertseliot: nvidia blob ~o~15:05
Duke`wtf, left computer for 2 hours and found it in kernel panic mode when back15:33
ScottKtseliot: What's the plan on mesa?  In Kubuntu we are broken and will stay broken (as in no Alpha 2) until it's fixed.15:58
tseliotScottK: I'm working on it15:59
sebnertseliot: nvida blob working again. it's like using windows. doing reboots fixes stuff ^^16:00
ScottKtseliot: OK.  Are we talking minutes, hours, or days until it's fixed?16:00
Sarvattahhah its a race between gdm starting up which needs dbus ready and dbus starting at the same time so its not always ready -- https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/50283816:01
ubottuLaunchpad bug 502838 in gdm "gdm starts too early, X.org/VTs fail" [High,Incomplete]16:01
tseliotScottK: I've been working on it today. The fact that the other upload of mesa (7.7) broke radeon slowed me down a bit16:02
tseliotASAP is my answer16:02
tseliothopefully today16:02
ScottKtseliot: I understand.  Thanks.16:03
ScottKtseliot: Based on that, I just sent a status to kubuntu-devel letting people know it may be a while.  I'll quit bugging you and let you focus on getting it fixed ....16:14
tseliotScottK: ah, thanks for sending that email. It was a good idea16:15
ScottKThat's why I was asking for an estimate.16:15
tjaaltontseliot: having problems with -ati?16:44
tseliottjaalton: it looks like the new driver works only with nomodeset16:44
tjaaltontseliot: oh16:44
tseliotalso the patch that you gave me for mesa seems to be wrongly formatted (I guess it's pastebin/browser's fault)16:44
tjaaltoncould be16:45
tseliotI changed things manually and I'm building now16:45
Sarvattyeah ati needs updating due to the libdrm-radeon1 api change http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=4b05c47ac657f9a93d76221269761ed64c81f71616:50
tjaaltontseliot: try pulling just that commit on top of the current driver16:51
tseliottjaalton: I had taken what's in master but sure I can try that16:52
tjaaltonmaybe the displayport stuff broke something16:53
tjaaltonbtw, add DEB_BUILD_OPTIONS="parallel=2" or such to your session, speeds up the builds a lot16:57
tjaaltonif you have a multicore cpu16:57
tjaaltonmesa builds in 15min on my laptop16:57
Sarvattyay this fixes the gdm startup problem here -- http://bazaar.launchpad.net/~ubuntu-desktop/gdm/ubuntu/revision/18616:59
tjaaltonwow16:59
Sarvattjust a little one liner in /etc/init/gdm.conf17:00
tjaaltonwith the config_init fix from debian there should be even less problems booting up :)17:02
jcristauthere's still some weird stuff going on, but yes.17:03
wind-rideri had some problems before the radeon driver was broken17:03
wind-riderkdm or the X server did not start automatically17:04
wind-rideri had to log in on a console and run startx17:04
wind-rideris that a known problem?17:04
knittlwind-rider: yes, it's known17:05
tjaaltonhard to say without the error msg17:05
wind-ridertjaalton: there was no error message17:05
tjaaltondoes kdm use upstart?17:06
jcristauin other news, http://ftp-master.debian.org/new/xf86-input-wacom_0.10.3+20100109-1.html17:06
tjaaltonjcristau: wow!17:06
wind-rideri have no idea if kdm uses upstart17:06
tjaaltonis there a job script in /etc/init ?17:07
Sarvatteww, grabbing the source for kdm pulls in a 70mb package :D17:07
tseliottjaalton: oh, thanks, I have an icore717:07
ScottKtjaalton: kdm does use upstart in Karmic and later.17:07
tseliottjaalton: with your patch: cp: cannot stat `debian/tmp/usr/lib/glx/pkgconfig/dri.pc': No such file or directory17:08
tseliotdh_install: cp -a debian/tmp/usr/lib/glx/pkgconfig/dri.pc debian/mesa-common-dev/usr/lib/pkgconfig// returned exit code 117:08
* Sarvatt cheers at wacom17:08
tjaaltonScottK: so maybe it needs a similar fix as gdm added in the latest upload?17:08
ScottKSigh.  Of course the package that it's part of is currently unbuildable due to mesa ...17:08
ScottKtjaalton: Where's the patch?17:08
Sarvatt http://bazaar.launchpad.net/~ubuntu-desktop/gdm/ubuntu/revision/18617:09
ScottKThanks.17:09
ScottKSarvatt and tjaalton: Looks like it does.  Thanks.17:11
tjaaltonScottK: ncie17:11
tjaalton*nice17:11
tjaaltontseliot: ok, that was an old one then, let me give you the full diff..17:11
tjaaltontseliot: http://users.tkk.fi/~tjaalton/foo/mesa.diff17:12
Sarvattwhere can I get the source for that wacom upload? don't see it on ftp.debian.org17:14
tjaaltontseliot: that variable works with most, if not all xorg modules17:14
Sarvattah got it ftp-master.debian.org, slow today :D17:15
tjaaltontseliot: http://users.tkk.fi/~tjaalton/foo/mesa.diff17:17
tjaaltonbut.. installing the resulting libgl1-mesa-glx breaks things17:17
tjaaltonglxinfo says DRI is used etc, ldconfig finds the libs but apps still fall back to software rendering17:17
tjaaltonwe could sort this out later, and just link whatever is necessary to get the builds rolling again17:18
tjaaltonugly, yes..17:18
tseliotyes, I know17:18
tseliotis that a different patch?17:19
tseliotin the same place?17:19
tjaaltonthat's the current git diff17:19
tjaaltonwhich builds fine17:19
tseliotaah17:19
ScottKSarvatt and tjaalton: It's actually not an immediat problem for kdm, because we still use hal, but I added it anyway as it doesn't hurt to be explicit.17:19
tseliotok17:19
tjaaltonScottK: ok17:19
tseliottjaalton: I would like to see what it builds exactly17:19
* tseliot is building mesa again17:20
tjaaltonhmm17:20
tjaaltonoh crap17:20
tjaaltonI know what's wrong17:20
wind-riderScottK: so it does not solve the problem having to run startx manually?17:20
ScottKwind-rider: I don't know for sure.17:20
ScottKI doubt it.17:20
wind-riderok17:21
wind-riderjust to have it clear17:21
tjaaltonlibgl1-mesa-glx has the swx11 version of libGL17:21
wind-riderknittl: is it already at launchpad?17:21
tjaaltonbecause they are installed in the same prefix17:21
tjaaltonnormally the dri version would be in lib/glx17:21
tjaaltontseliot: so, only changing the libdir for swx11 should be enough17:22
tjaaltonI'll wrap up a new diff17:24
knittlwind-rider: yes, but i can't find it right now17:24
knittlhttps://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/50283817:25
ubottuLaunchpad bug 502838 in gdm "gdm starts too early, X.org/VTs fail" [High,Fix released]17:25
knittlfound it :D17:25
wind-riderknittl: ok, i saw that one earlier today :) but it is for gdm17:25
knittloh, are you using kde?17:26
knittlbut it's probably the same cause17:26
tseliottjaalton: that would make sense ;)17:26
tseliotI'm building ati with only the API patch17:26
tjaaltonso I found out the reason for the different libdir for the dri target :)17:27
wind-riderknittl: ScottK changed it in kdm but he thought it would not solve the problem as he says kdm still uses hal there17:27
knittlok, i don't know about kdm. thought it might be helpful anyway17:27
wind-riderknittl: ok17:27
tseliottjaalton: -ati is not maintained in git, is it?17:30
tseliotas getting only that patch makes it work again with KMS17:31
* tseliot wonders if the master branch requires a kernel update17:31
tseliotor if they just broke the code17:32
tjaaltontseliot: no it's not17:32
tjaaltongreat that it works17:33
tjaaltoncherry-picked the config_init fix17:33
tseliottjaalton: this one? http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=36bd69affc996c92c40b7360a7fbaa1a3a46abfd17:35
tseliotor are you referring to mesa now?17:35
tjaaltonno, xserver :)17:35
Sarvattits the libdrm interface to -ati that changed and broke it, no worries about the kernel17:35
tjaaltonmaybe ati master needs libdrm master17:36
tseliottjaalton: ok, I just wanted to make sure that my upload of -ati could begin without problems17:36
tjaaltonit should17:36
tseliotok17:36
tjaaltonlibdrm doesn't seem to have much ati related post .1717:37
tseliotSarvatt: I know. I was wondering if drm in the kernel had something that we're missing17:38
Sarvattoh shoot, apw was asking if it was ok to turn on radeon KMS by default for a2 and it probably would have been good to mention that ati kms was broken on r600+ with 2.6.32.2 and fixed in 2.6.32.317:40
jcristauSarvatt: i think they have the fix in the lucid kernel?17:40
* tseliot has an r600 card and KMS works17:40
jcristauSarvatt: https://lists.ubuntu.com/archives/lucid-changes/2010-January/002876.html seems to have it (the airlied patch)17:40
tjaaltonyep17:41
Sarvattno linux-meta for that kernel yet but good to see its in there now17:41
tjaaltonprobably not even published yet17:42
tjaaltonthose need to be pushed through the new queue every time17:42
tjaaltonah, -10 is published17:42
tseliotok, -ati uploaded17:46
tseliottjaalton: did you upload mesa?17:46
tjaaltontseliot: no, still need to test17:49
tseliotok17:49
* tjaalton does the dri-dance17:52
tjaaltonworks17:52
tseliot\o/17:53
tjaalton*phew*...17:54
tseliothey we're risking to have an actually functioning alpha 217:54
tseliot:-P17:54
tjaaltonI need to break it when I get back from the party ;)17:54
tjaalton(not)17:54
tjaaltonkeyboards should have breathalysers17:55
tjaalton"did I write _that_?"17:55
tseliothey if you don't have time to break it, I definitely can do it for you ;)17:55
tseliot:-D17:55
tjaaltonfacebook/putty on a Series60 phone is a killer, literally17:56
jcristauhmm i guess i'd need 10 days to break it.  need to have stuff transition to squeeze before it gets autosynced :/17:56
tseliottjaalton: on the e71 ?17:57
tjaaltontseliot: yes17:57
tseliotoh17:57
* tseliot wants it on his e71 too17:57
tjaaltonit's not a good idea to check facebook on the taxi when getting back home :P17:57
tseliotheh17:57
tjaaltonjust google, it works very well17:57
tjaaltonputty that is17:57
tseliotwill do17:58
tjaaltonjcristau: I doubt there'll be much stuff to autosync that might risk breaking anything :)17:59
tjaaltonmesa uploading17:59
tseliot:-)18:00
wind-ridertjaalton: if mesa and -ati are uploaded, will my X server work again?18:01
jcristautjaalton: i don't think x11-xkb-utils is forked?  so i could break xkbcomp, but people won't let it move to testing if i do that :/18:01
tseliotwind-rider: -ati alone should do it. The problem with mesa was visible only if you tried to build something18:02
wind-ridertseliot: ok, great :) i18:02
wind-rider'll try it18:02
wind-ridertjaalton, tseliot: thx for your work18:03
tseliotjcristau: break xkbcomp? Why? Did they change anything interesting?18:03
tseliothey, we break it, we fix it ;)18:03
tseliot(and break it again)18:03
jcristautseliot: no.  it was just me trying to see how i could break alpha218:03
tseliotjcristau: too bad. That could have broken the xkbcomp patch that we use to reduce boot time18:04
wind-riderbye18:04
tseliotoh, well, we'll think of something else18:04
tjaaltonjcristau: right, x11-xkb-utils is the same in both18:05
Sarvatthmm not having any luck searching launchpad for pixman bugs with asserts that would be fixed by upgrading to pixman 0.16.14. only getting the one result with pixman assert in the title19:26
wind-riderScottK: do you know if one can see a package's build status?20:49
wind-riderScottK: is it somewhere on launchpad?20:50
ScottKwind-rider: Yes.  What are you looking for?20:52
ScottKtjaalton: mesa FTBFS: https://launchpad.net/ubuntu/+source/mesa/7.7-0ubuntu2/+build/143809820:53
dhillon-v10ScottK, hi, now that I am working on X what would be the first place to get started, triaging some bugs, I read the wiki page so20:55
ScottKdhillon-v10: I know very little about X.  I'm the wrong one to ask.20:56
wind-riderScottK: at https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/505095 is stated that the fix has been committed, but that the package will be only in the repo when it is built20:56
ubottuLaunchpad bug 505095 in xserver-xorg-video-ati "X don't start in Lucid" [High,Fix released]20:56
wind-riderScottK: i found https://launchpad.net/ubuntu/+source/xserver-xorg-video-ati/1:6.12.99+git20091125.0061c4db-0ubuntu220:57
ScottKThat shows you the build status20:57
wind-riderScottK: and there is stated that the i386 build succeeded, but when trying to upgrade apt-get did not find the new package20:57
ScottKAccepted means it's built, but not in the archive.20:58
ScottKThe archive publisher run starts at :03 each hour and finishes ~:45.20:58
wind-riderok, that clarifies it :) thx20:59
ScottKSo it should be available in about 45 minutes.20:59
ScottKThat assumes you pull from archive.ubuntu.com directly.20:59
ScottKIf you pull from a mirror, then there's additional delay.20:59
sistpotytjaalton, tseliot: aware of the build failure for mesa?21:08
sistpotyif so, and you need some help, feel free to ping me21:08
jcristauyay hacks for closed drivers.21:08
sistpotyjcristau: then make my ati card work with gl :P21:09
sistpoty(just kidding, have seen the diff between ubuntu taking the snapshot from svn and debian... didn't find a trivial patch for the texture problem)21:20
tjaaltonsistpoty, ScottK: sorry, I'm on my phone now, so can't help until tomorrow. if you can come up with a fix, feel free to upload.. :/21:21
sistpotytjaalton: ok, will try21:21
sistpotytjaalton: I'm not too sure if my mesa patch will fix the build failure, but if it does, pretty please clean it up, it's the ugliest patch I ever did for ubuntu, and I'm extremely ashamed of it (just overriding LD_LIBRARY_PATH in debian/rules in a completely nonsense manner)22:06
sistpotyoh, no it bails out somewhere else, yuck22:08
* albert23 just finished a mesa build successfully22:10
albert23dh_shlibdeps -s -l/usr/lib/mesa did the trick22:10
jcristaualbert23: yep, that sounds like it should work22:12
sistpotyalbert23: I got errors for the r200 driver somewhere (but thanks for the trick, much better than the evil hack I've got)22:14
sistpotyradeon_common_context.h:405: error: array type has incomplete element type22:14
sistpotyalbert23: I'm actuallly inclined to just upload your fix. test-building seems underrated for mesa, I guess22:18
albert23That radeon error was fatal for you?22:18
sistpotyyes22:18
albert23I didn't get that22:18
sistpoty(amd64)22:19
jcristauold libdrm?22:19
albert23so am I22:19
sistpotyhm, german mirror problem? (which is not a mirror problem, but a lack of constraints on b-d's)22:19
jcristaunew mesa should probably build-dep on libdrm-dev >= 2.4.1722:20
albert23I have 2.4.17 in the pbuilder22:20
sistpoty2.4.17-0ubuntu1 for libdrm222:22
sistpotysame for libdrm-dev22:22
sistpotyinteresting, I believe it builds further now... mesa is getting more and more obscure to me :)22:24
albert23I have r200 and r300_dri.so in -dri, so the build went ok here22:24
sistpotyI'll just wait and see what happnes ;)22:25
sistpotyno, still the same error :(22:29
* sistpoty updates pbuilder (again)22:30
albert23given the buildd reached the install target in the previous build, we can assume that error will not happen on the buildd?22:32
sistpotyalbert23: are you suggesting to just upload the fix from you? (though it still doesn't build for me)?22:46
albert23sistpoty: that's up to you. But I think it means the radeon failure is something local for you22:47
sistpotyalbert23: I doubt it's local but a bug somewhere (however not trivial to investigate)... 22:47
sistpotyslangasek: ok with replacing a broken version with a probably broken version?22:48
sistpotyalbert23: I think I'll just upload it as is, hoping that tjaalton will fix it up tomorrow if it breaks.22:51
sistpotyalbert23: as the change is really from you, currently I've put "* debian/rules: Fix dh_shlibdeps as proposed by albert32 to fix FTBFS." into changelog22:52
sistpotyalbert23: anything you'd like to see changed there?22:52
albert23sistpoty: my name is Albert Damen, maybe better then an irc nick22:53
sistpotyalbert23: ok, thanks, couldn't figure this on first glance22:53
sistpotyalbert23: just uploaded, thanks againg... let's just cross fingers!22:57
* sistpoty feels dirty though22:57
albert23We will know in an hour22:58
albert23Armel failed in the same way, so I have some hopes22:58
sistpotyhm... mesa should be accepted at least now, very strange23:32
sistpotyalbert23: case solved, I fetched an outdated source23:37

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!