| shadeslayer | hi, when trying to run shank using the drivers from xorg-edgers it says it can't find the R600 driver, presumably because I'm on am64 and it uses i386 libs | 06:45 |
|---|---|---|
| shadeslayer | and I can't install the i386 drivers because keyboard-configuration is arch any | 06:45 |
| shadeslayer | any ideas how to fix? | 06:45 |
| RAOF | Why can't you install the i386 drivers? They should be installable. | 06:46 |
| shadeslayer | because xserver-xorg-core:i386 depends on keyboard-configuration:i386, but there is no keyboard-configuration:i386 | 06:47 |
| shadeslayer | http://paste.kde.org/688472/ | 06:48 |
| RAOF | Why are you trying to install xserver-xorg-core:i386? All you need for 3D is the mesa drivers - libgl1-mesa-glx:i386 and what it recommends/depends on. | 06:48 |
| shadeslayer | don't I need xserver-xorg-video-radeon:i386 ? | 06:48 |
| shadeslayer | because I get : libGL error: failed to load driver: r600 | 06:49 |
| RAOF | One reason you'll get that is if you don't have the appropriate libgl1-mesa-dri installed. | 06:53 |
| RAOF | But, as it probably says, ‘LIBGL_DEBUG=verbose glxinfo’ will get more information. | 06:53 |
| RAOF | Or just throwing LIBGL_DEBUG=verbose into your environment. | 06:53 |
| shadeslayer | aye, that's what I'm doing | 06:53 |
| shadeslayer | RAOF: http://paste.kde.org/688484/ | 06:54 |
| shadeslayer | I think you're right | 06:54 |
| RAOF | shadeslayer: So, “libGL error: dlopen /usr/lib/i386-linux-gnu/dri/r600_dri.so failed (/usr/local/games/shank/bin/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /usr/lib/i386-linux-gnu/libLLVM-3.2.so.1))” is the interesting bit. | 06:55 |
| RAOF | As you can see, you've *got* the r600_dri.so driver; however, there's a problem somewhere in its dependencies. | 06:55 |
| shadeslayer | I see | 06:56 |
| RAOF | Oh! | 06:56 |
| RAOF | Of course. | 06:56 |
| RAOF | It's trying to load /usr/local/games/shank/bin/libstdc++.so.6 as your libstdc++, but that's the wrong version. | 06:56 |
| shadeslayer | oh | 06:56 |
| shadeslayer | :< | 06:56 |
| RAOF | So, try moving that out of the way. | 06:57 |
| RAOF | Or just deleting it. | 06:57 |
| RAOF | You've got a perfectly functional libstdc++.so.6 in /usr/lib/i386-linux-gnu, so unless shank has done something *utterly insane* like patching their libstdc++, deleting their copy should work. | 06:57 |
| shadeslayer | yeah | 06:58 |
| shadeslayer | it does work :) | 06:58 |
| shadeslayer | bah | 07:00 |
| shadeslayer | stupid game | 07:00 |
| shadeslayer | it didn't work on the intel card, doesn't work on the ATI card | 07:00 |
| shadeslayer | http://wstaw.org/m/2013/03/06/plasma-desktopnQ5646.png | 07:02 |
| llstarks | shadeslayer, having fun with powerxpress/enduro? | 07:14 |
| RAOF | shadeslayer: I wonder if you need the dxtn library for i386? libtxc-dxxtn-s2tc0:i386? | 07:19 |
| shadeslayer | llstarks: heh :) | 07:24 |
| shadeslayer | I'm not sure if it's a powerexpress, it's whatever Apple used for the 8,2 MBP | 07:25 |
| * mlankhorst yawns | 07:25 | |
| mlankhorst | morning | 07:25 |
| shadeslayer | RAOF: libtxc-dxtn-s2tc0:i386 is already installed | 07:26 |
| hyperair | force s3tc compression on using driconf? | 07:27 |
| shadeslayer | do I need to restart X or just the game after I do that? | 07:28 |
| shadeslayer | hm | 07:33 |
| shadeslayer | hyperair: fwiw I don't have that option on the ATI card | 07:33 |
| hyperair | oh | 07:33 |
| hyperair | just the game. | 07:34 |
| shadeslayer | well, driconf doesn't give me an option to force s3tc compression | 07:34 |
| hyperair | weird | 07:34 |
| hyperair | oh well | 07:34 |
| llstarks | shadeslayer, oh that's gmux | 07:50 |
| tjaalton | hah, got a good backtrace of the crash with the touch fix branch | 08:40 |
| tjaalton | phew.. | 08:40 |
| tjaalton | took a lot longer to crash this time | 08:40 |
| mlankhorst | tjaalton: would it be reproducable with a macbook touchpad? | 08:59 |
| tjaalton | mlankhorst: dunno | 09:02 |
| tjaalton | maybe, if you set it absolute, and so it registers a click on every touch :) | 09:04 |
| tjaalton | maybe needs to mimick a touchscreen otherwise as well | 09:04 |
| tjaalton | hmm so what are the multitouch gestures again? | 09:06 |
| tjaalton | since I'm seeing something strange here... | 09:06 |
| mlankhorst | three fingers was adjusting window iirc, 4 was dash | 09:07 |
| tjaalton | aka. they only work when the single touch is locked.. | 09:07 |
| tjaalton | ah, no.. works | 09:07 |
| tjaalton | ok, now on to the crazy intel backports.. | 09:16 |
| tseliot | ricotz: hi, I think you spoke with bryce saying that the versioned dep on nvidia-current in nvidia-cuda 5 needs to be unversioned to work with virtual-packages. Can you explain exactly what package you were referring to? | 10:34 |
| ricotz | tseliot, i am not remembering the package right now, but afair some lib package has a versioning dep on nvidia > 304.xx | 10:35 |
| ricotz | which breaks the installation with edgers nvidia-313 | 10:36 |
| tseliot | ricotz: can it be libcuda? | 10:36 |
| ricotz | and having all those provides/conflicts is kind of bad | 10:36 |
| ricotz | it should get some thinking to avoid those | 10:36 |
| ricotz | let me see | 10:36 |
| tseliot | ricotz: provides/conflicts in nvidia or in cuda? | 10:37 |
| ricotz | in the nvidia packaging | 10:37 |
| tseliot | right, tumbleweed mentioned that too | 10:37 |
| ricotz | this is pretty bad, imo there should be one "Provide: xorg-driver-binary-blob" or something | 10:38 |
| tseliot | but we need the drivers manager to be able to easily switch between nvidia drivers, without complaining when trying to install a driver other than the one you have already installed | 10:39 |
| ricotz | to unify amd/nvidia in some way | 10:39 |
| ricotz | the manager should be able to pick the package directly nvidia-304, -313 and so on | 10:40 |
| ricotz | sorry, i don't have insight in how they get picked currently | 10:40 |
| tseliot | yes, what I mean is, for example the user has already installed 304, then he decides to install 313 | 10:40 |
| ricotz | ok, so? | 10:41 |
| tseliot | but without the conflicts/replace/provide stuff, apt will give an error since the packages conflict with one another | 10:41 |
| ricotz | both will provide the virtual package | 10:42 |
| tseliot | I'm pretty sure I tried that in the past and it didn't work | 10:42 |
| ricotz | "xorg-driver-binary-blob" | 10:42 |
| ricotz | i see | 10:42 |
| tseliot | I can try again in case memory is failing me but I think I've already tried that path | 10:43 |
| ricotz | ok | 10:44 |
| ricotz | havent tried it myself yet | 10:45 |
| tseliot | ricotz: BTW, I've made some changes to the packaging of 313 so as to make the creation of new flavours easier | 10:49 |
| tseliot | https://github.com/tseliot/nvidia-graphics-drivers/commit/e62fccf6ab50161026e1d2c75199f7ff03e26a4e | 10:51 |
| tseliot | https://github.com/tseliot/nvidia-graphics-drivers/commit/1d503d498b0de824974693b50ca7fe7f68d14291 | 10:51 |
| ricotz | tseliot, thanks, will resync it with 304 and 313 in edgers when i get to it | 10:53 |
| tseliot | ricotz: I'm also uploading the latest 313 as we speak | 10:58 |
| ricotz | 313.26? | 10:58 |
| tseliot | yep | 11:26 |
| tseliot | ricotz: I've tried with dummy packages and the whole conflicts/replace/provides works with a metapackage (at least with apt, not with dpkg). This is great news! | 12:40 |
| mlankhorst | tjaalton: I guess it's about the series of 7 and series of 12 on ml? | 12:53 |
| tjaalton | mlankhorst: yep | 12:53 |
| mlankhorst | so I just grab canonical-x ppa for all drivers and cherry pick those patches into my xserver? | 12:53 |
| ricotz | tseliot, ok :) | 12:56 |
| === ara_ is now known as ara | ||
| mlankhorst | tjaalton: mind if I stuff 1.14 in canonical-x? | 13:26 |
| tjaalton | mlankhorst: huh? it's in there? | 13:27 |
| tjaalton | already | 13:27 |
| mlankhorst | oh 1.14 was released | 13:27 |
| mlankhorst | this morning | 13:28 |
| tjaalton | oh that | 13:29 |
| tjaalton | yeah, go for it | 13:29 |
| mlankhorst | boo, site is down | 13:51 |
| mlankhorst | tjaalton: well since x1.14 won't be in raring, I'm just going to keep changelog updated with the ppa for now. I'm also using some self generated tarball for xorg 1.14, seems the site is down :/ | 14:15 |
| tjaalton | hmm, not 100% sure if you can change the tarball once we push it to the main repo | 14:22 |
| tjaalton | then again, there should be .1 at some point, with these touch fixes | 14:22 |
| mlankhorst | well I expect 1.14.0 not to be the version we'll upload :) | 14:22 |
| tjaalton | or the final set, without crashers :) | 14:22 |
| tjaalton | right | 14:22 |
| tjaalton | git.fd.o doesn't work either | 14:23 |
| mlankhorst | annarchy is down, i cant ssh to it | 14:23 |
| mlankhorst | blergh can't rebase to test on my macbook now, thing broke :( | 15:41 |
| tseliot | ricotz: also, make sure you check the latest commit for 313 in my git repository (I've fixed an issue in my previous changes) | 15:41 |
| tseliot | ricotz: *latest commits | 15:41 |
| ricotz | tseliot, alright | 16:43 |
| mlankhorst | oh finally got x1.14 set up now | 17:25 |
| Duke` | latest xorg-intel-video driver in xorg-edgers (2013-03-01) is totally broken for i945 GM x_x | 17:32 |
| mlankhorst | tjaalton: what is the easiest way to reproduce the hang? | 17:32 |
| Duke` | and the previous one (2013-02-26) was not very good too | 17:33 |
| mlankhorst | erm the touch hanging :) | 17:33 |
| tjaalton | mlankhorst: read the upstream bug :) | 17:38 |
| tjaalton | afk -> | 17:38 |
| mlankhorst | oh fd bugzilla still works | 17:38 |
| mlankhorst | tjaalton: yeah I can reproduce it on my macbook :) | 17:47 |
| mlankhorst | it's a lot easier to crash with valgrind enabled too! :D | 17:53 |
| mlankhorst | ugh hold on i might have removed the flavor | 18:00 |
| * mlankhorst reinstalls xserver-xorg-core to be sure | 18:00 | |
| tjaalton | ah cool | 18:15 |
| tjaalton | with multitouch synaptics? | 18:15 |
| mlankhorst | yeah | 18:28 |
| tjaalton | ok | 18:29 |
| tjaalton | so this is with 1.13 or patched 1.14? | 18:29 |
| mlankhorst | 1.14.0 + the input patches | 18:37 |
| tjaalton | ok, did you try the original bug? | 18:39 |
| tjaalton | maybe the new one isn't touch specific then | 18:40 |
| tjaalton | since I can still use touch gestures | 18:42 |
| mlankhorst | I think it's separat | 18:44 |
| tjaalton | yeah | 18:45 |
| bryce | where we at with mesa 9.1? | 18:47 |
| mlankhorst | Fire when ready? | 18:47 |
| tjaalton | well the slow blur with dash on intel would be nice to get fixed | 18:48 |
| bryce | any reservations to including it in 13.04? | 18:48 |
| tjaalton | but we could FFe it | 18:48 |
| tjaalton | not really | 18:48 |
| tjaalton | maybe even get 9.1.1 in time | 18:48 |
| bryce | mm, that'd be nice | 18:49 |
| mlankhorst | but packaging for 9.1 is done | 18:50 |
| tjaalton | I'd like to review it one more time though, there is the -dev package mess on debian for instance | 18:50 |
| tjaalton | that kano is so vocal about | 18:51 |
| bryce | heh | 18:51 |
| bryce | pushed the "fix" for the drm race condition | 21:19 |
| bryce | (I quote fix because I think it just works around the problem by adding sleep. But this may be the best we can do on the X side.) | 21:20 |
| tjaalton | bryce: it doesn't fix it | 21:27 |
| tjaalton | I tried a similar patch, and even when it doesn't give that error message it can fail | 21:27 |
| tjaalton | too bad though.. | 21:28 |
| ogra_ | https://plus.google.com/hangouts/_/914b5784e52c5967784eae44e4b138a346b1ff90?authuser=0 post UDS drinking hangout ... | 21:28 |
| tjaalton | ogra_: is there a live feed to watch with popcorn? :) | 21:28 |
| tjaalton | no beer at hand :/ | 21:28 |
| ogra_ | i donmt think so, you have to participate with beer :) | 21:29 |
| tjaalton | dammit | 21:29 |
| bryce | tjaalton, on the contrary, the testing has shown when the message shows up, it does result in a working system | 21:29 |
| tjaalton | which message? | 21:29 |
| bryce | setversion 1.4 failed | 21:29 |
| tjaalton | you mean _doesn't_ show up? | 21:30 |
| bryce | no | 21:30 |
| tjaalton | I'm confused then :) | 21:31 |
| tjaalton | that would mean when it fails to open the drm device the system works? | 21:31 |
| bryce | real simple: I uploaded a patch that works around the issue. Testers confirm their systems now boot and work reliably (although sometimes with slight delay due to the sleeping) | 21:31 |
| bryce | yep, that seems to be what's happening. I don't understand why, but there are multiple confirmations it's true. | 21:32 |
| tjaalton | I'm just reading the commit msg | 21:32 |
| bryce | tjaalton, there's ample logs there now if you want to study further | 21:33 |
| tjaalton | I know the logs :) | 21:33 |
| bryce | tjaalton, you're just wanting to diss my fix? ;-) | 21:33 |
| tjaalton | which show that when "setversion 1.4 failed" is on them it will fail | 21:33 |
| tjaalton | nono | 21:33 |
| tjaalton | I believe it'll make it harder to hit | 21:33 |
| tjaalton | so it's definitely good to have _something_ | 21:34 |
| tjaalton | I'll edit my first comment: "it doesn't fix it completely". there :) | 21:35 |
| bryce | well, thus my quotes. "fix" | 21:35 |
| tjaalton | ah, true | 21:35 |
| bryce | the problem seems deeper than X tho | 21:36 |
| bryce | I'm not sure there's more we can do *in X* than this | 21:36 |
| tjaalton | me neither | 21:36 |
| mlankhorst | I could mess up the kernel :P | 21:36 |
| tjaalton | please do | 21:36 |
| tjaalton | :) | 21:36 |
| mlankhorst | but I'd need a good way to reproduce the issue first | 21:36 |
| bryce | at least this gives us clearer error messages (error codes!) and improves the situation for users | 21:36 |
| tjaalton | there was some option to fully disable plymouth (removing splash isn't enough) on the cmdline, also maybe get some proper tracing from the kernel or such | 21:37 |
| bryce | i seem to remember early on several people tried switching off plymouth but it didn't make a difference. Maybe they didn't do it "fully" enough tho. *shrug* | 21:39 |
| RAOF | mlankhorst: You're not in #ubuntu-mir, but moving to Mir dma-buf is one of my upcoming tasks. ☺ | 21:39 |
| tjaalton | "adam" on that bug hit some nouveau issue | 21:40 |
| tjaalton | bryce: removing 'splash' isn't enough, i was told | 21:40 |
| tjaalton | there's also some plymouth.debug option | 21:40 |
| tjaalton | but maybe it is just a race inside drm. one guy said on a bug that removing 'splash' made it fail every time | 21:41 |
| tjaalton | too bad the system that fails for me 7 out of 10 bootups is my main desktop.. | 21:44 |
| tjaalton | which has a surprisingly long uptime of 11 days now :) | 21:44 |
| mlankhorst | can I reproduce it after removing/re-inserting the module somehow/ | 21:47 |
| tjaalton | how do you remove a kms module? | 21:47 |
| tjaalton | is it possible? | 21:48 |
| mlankhorst | oh I have a script for that | 21:48 |
| tjaalton | alright | 21:48 |
| mlankhorst | first you do echo 1 > /sys/class/vtcon/*1/unbind | 21:48 |
| mlankhorst | then rmmod probably works | 21:48 |
| mlankhorst | although maybe just binding/unbinding would be enough | 21:49 |
| tjaalton | hmm some of the crashes might be hybrid races too | 21:50 |
| tjaalton | that airlied has not seen | 21:50 |
| tjaalton | yet | 21:50 |
| mlankhorst | actually binding/unbinding might be easier to test | 21:51 |
| mlankhorst | tjaalton: and I suspect hybrid might mess up if it loads the modules in the wrong order, for example nouveau first instead of i915, but this is just speculation, maybe I was just hitting the same race as before | 21:59 |
| tjaalton | should we create a wikipage or something to track this? it might need a diagram or two about what happens between kernel loading and xserver being up? | 21:59 |
| tjaalton | mlankhorst: could be | 22:00 |
| mlankhorst | i think tomorrow I'll just try to make some test case that doesn't involve booting to trigger | 22:00 |
| tjaalton | that would be great | 22:00 |
| mlankhorst | and then probably fix it | 22:01 |
| tjaalton | maybe udev plays a part in it too | 22:01 |
| mlankhorst | some strategic placed sleeps in the kernel might make it easier to hit :p | 22:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
