[03:43] <bjsnider> Sarvatt, do you happen to understand the rationale behind the choices of alternatives in fglrx?
[03:44] <Sarvatt> bjsnider: no i dont, thats why i dont touch it lately
[03:44] <bjsnider> i guess i shouldn't try, but i'd like to get it into x-updates
[03:45] <bjsnider> i just don't understand why some of the libs were chosen for alternatives while others weren't
[03:45] <RAOF> What libs are these?
[03:45] <Sarvatt> bjsnider: you know you can build source debs from the installer right?
[03:45] <bjsnider> well
[03:45] <Sarvatt> its really easy to install your own fglrx from their website, thats the other reason i dont
[03:46] <RAOF> Huh.  This laptop has a single combined headphone/mic port.  How annoyingly useless!
[03:46] <Sarvatt> third reason is its a pain in the butt to verify the kernel module builds, thats where things always go wrong
[03:47] <bjsnider> RAOF, usr/lib/libaticalxx is strange
[03:47] <bjsnider> where xx is rt and cl, alternatives are in play, but dd and libatiuki are not covered
[03:47] <bjsnider> and this is where two new opencl libs have appeared
[03:48] <Sarvatt> oh thats opencl stuff, i bet they put that in there themselves without alberto's help
[03:48] <bjsnider> so i don't know if they should be included, but it seems like they should because amd has a now-obsolete opencl package that would have those files and also nvidia provides a libopencl.so.1
[03:49] <bjsnider> but nvidia's libopencl is not covered by alternatives...
[03:49] <Sarvatt> bjsnider: tseliot is going to upload 11.11 probably tomorrow, hopefully they dont have much package churn after that so it should be easy for a few months :)
[03:49] <bjsnider> Sarvatt, phoronix says the december release is a big change too
[03:50] <bjsnider> the source package is now too big to fit on a cd
[03:50] <bjsnider> j/k
[03:50] <Sarvatt> bjsnider: yep you're right, ugh
[03:50] <bjsnider> Sarvatt, for oneiric?
[03:50] <Sarvatt> just looked at the betas
[03:50] <Sarvatt> bjsnider: nah precise but nothings changed really
[03:50] <Sarvatt> easy to nab it :)
[03:51] <Sarvatt> 4 new libs in the december ones
[03:51] <bjsnider> i thought alternatives existed to stop to packages from installing the same file, thus overwriting each other
[03:51] <bjsnider> but all of these laternatives are ati-specific stuff, so why do they need alternatives?
[03:51] <RAOF> They don't.
[03:52] <bjsnider> that's not too confusing or anything
[03:52] <bjsnider> why are laternavites used in fglrx then?
[03:53] <bjsnider> nvidia ships libgl, so it makes a lot of sense there
[03:53] <bjsnider> all of this stuff is libati* or amd*
[03:54] <RAOF> It probably shouldn't be alternatived.
[03:54] <bjsnider> so these packaging scripts are overcomplicated for no apparent reason?
[03:55] <RAOF> That would seem to be the case?
[03:56] <bjsnider> Sarvatt, are the 4 new libs going to add 200mb more size this time?
[03:57] <bjsnider> the graphics driver is bigger than the friggin' kernel
[03:57] <bjsnider> and it's not even shipping its own gl
[03:59] <bjsnider> thier code must be shared cross-platform like nvidia
[10:19] <tjaalton> wacom 0.12.0 uploaded
[10:53] <tjaalton> bryceh: might be the time to change versions-current to show precise?
[11:18] <ricotz> tseliot, hello
[11:19] <tseliot> ricotz: hi
[11:19] <ricotz> tseliot, how is it going with fglrx?
[11:19] <tseliot> I haven't updated the driver yet. I need to upload a fixed nvidia-common and jockey first then I'll think of fglrx (my scripts should be mostly ready)
[11:20] <ricotz> ok, i will be patient then :)
[11:20] <tjaalton> ricotz: wacom is uploaded though
[11:21] <ricotz> tjaalton, good
[11:22] <tjaalton> support for intuos4 oleds should now be in precise.. will test once it's built
[11:25] <ricotz> tseliot, do you thought about getting cuda in repos yet?
[11:25] <tseliot> ricotz: cuda for what?
[11:26] <ricotz> tjaalton, unfortunatelly i dont have a wacom device for testing
[11:26] <ricotz> tseliot, libraries like nvidia-texture-tools can use it for example which isnt packaged yet
[11:27] <tseliot> ricotz: is it in debian already?
[11:27] <ricotz> tseliot, since it is already available in debain syncing it would be nice, but it isnt compatible with the nvidia-driver packaging of ubuntu
[11:28] <tseliot> ricotz: oh, I'll have a look at the debian package then, and see what needs to be done
[11:28] <ricotz> tseliot, do you think it is possible to adapt the nvidia packaging
[11:29] <ricotz> they splitted up all libraries in their own debs though
[11:29] <tseliot> ricotz: it depends. I'll know only when I see it
[11:29] <ricotz> tseliot, ok, thanks
[11:30] <tjaalton> ricotz: no worries, i have one, and an Aiptek (waltop)
[11:31] <tjaalton> i packaged cuda locally for the university where i used to work
[11:31] <tjaalton> there were people doing some research with it
[11:35] <tseliot> ah
[11:41] <tjaalton> there's this sdk that you had to initialize so that it'd be linked to from your home directory
[11:41] <tjaalton> can't remember, strange stuff :)
[12:04] <Milos_SD> can someone help me to get FGLRX drivers installed and working on HP ProBook 4530s with Intel Sandy Bridge + AMD HD6490 graphics?
[12:04] <Milos_SD> When starting Xserver with FGLRX installed, XServer get segmentation fault
[12:06] <Milos_SD> here is the log: http://pastebin.com/hsnCw47g
[15:02] <bjsnider> tseliot, i was looking at the fglrx scripts last night and i don't understand the choices of which files to use with alternatives
[15:03] <bjsnider> they all look like amd-centric stuff, so why are they in danger of overwriting anything?
[15:04] <tseliot> bjsnider: I'm not sure I understand what you mean
[15:05] <bjsnider> well i thought the reason for using alternatives was to make sure file a doesn't overwrite file b of the same name also provided by another package?
[15:05] <bjsnider> but all of this stuff is called libati* or amd*
[15:06] <tseliot> bjsnider: right, and we have 2 flavours of the same driver
[15:07] <tseliot> it's just a case that they cannot be installed at the same time
[15:07] <tseliot> (because of hybrid graphics)
[15:07] <bjsnider> you have 2 versions of fglrx?
[15:08] <tseliot> fglrx and fglrx-updates
[15:09] <bjsnider> why not just make the packages conflict with each other?
[15:10] <Milos_SD> does anyone know how can I fix a problem that I described ? 
[15:11] <jcristau> don't use fglrx
[15:12] <tjaalton> hybrid graphics fail
[15:13] <tseliot> bjsnider: I did that, when I realised that they couldn't be installed at the same time
[15:13] <tseliot> jcristau: that's definitely a solution ;)
[15:14] <bjsnider> but if they conflict then why are alternatives needed?
[15:14]  * tseliot uses only open driver on his main pc
[15:14] <jcristau> that and don't buy silly hybrid graphics.
[15:14] <tseliot> *drivers
[15:14] <tseliot> bjsnider: libGL, and other stugg
[15:14] <tseliot> *stuff
[15:15] <bjsnider> nvidia provides its own libgl
[15:15] <tseliot> and so do mesa and fglrx
[15:16] <tseliot> this way you can install both nvidia and fglrx at the same time
[15:16] <tseliot> (using only one though)
[15:16] <Milos_SD> well, it worked on SLED 11 :S
[15:17] <tseliot> Milos_SD: I don't know what problem you're facing but did you file a bug report about it?
[15:17] <bjsnider> tseliot, http://pastebin.com/hsnCw47g
[15:17] <bjsnider> that's Milos_SD's pastebin
[15:18] <tjaalton> right, it's trying to load both intel and fglrx -> fail
[15:19] <bjsnider> Milos_SD, have you got a switch to turn off one chip or the other?
[15:19] <tseliot> in theory that should work
[15:19] <Milos_SD> bjsnider, there is only switch to turn ATI off
[15:19] <bjsnider> good
[15:19] <tjaalton> and that intel kms is probably being used
[15:20] <Milos_SD> can fglrx that charge if I disable modseting for intel?
[15:20] <Milos_SD> that is the only think I didn't try
[15:20] <bjsnider> a lot of people don't even have a switch
[15:20] <Milos_SD> thing*
[15:20] <tseliot> Milos_SD: there's a script you can try to switch
[15:21] <Milos_SD> it is not actualy a switch... it is option to disable switchable graphics (it disables ATI totaly)
[15:21] <Milos_SD> switchable graphics : ON or OFF... nothing else
[15:21] <Milos_SD> :)
[15:21] <tseliot> Milos_SD: so, if you want to use both cards
[15:22] <tseliot> (in the BIOS)
[15:22] <tseliot> and experiment with the fglrx driver
[15:22] <tseliot> you can do this to use the AMD card:
[15:22] <tseliot> sudo /usr/lib/fglrx/switchlibGL amd
[15:22] <tseliot> sudo /usr/lib/fglrx/switchlibglx amd
[15:22] <tseliot> and restart
[15:22] <tseliot> or
[15:23] <tseliot> sudo /usr/lib/fglrx/switchlibGL intel
[15:23] <tseliot>  sudo /usr/lib/fglrx/switchlibGL intel
[15:23] <tseliot> to use only the intel card (without having to remove fglrx)
[15:26] <tseliot> Milos_SD: if this ^ doesn't help, feel free to file a bug report
[15:29] <Milos_SD> problem is that, I think there are few bug reports about this :)
[15:31] <tseliot> Milos_SD: I don't think this is officially supported by AMD but I do what I can to help
[15:37] <Milos_SD> tseliot, it doesn't work... it is the same as doing: sudo aticonfig --px ddx or --px idx
[15:38] <Milos_SD> and switchlib doesn't even switch libs :)
[15:38] <tseliot> Milos_SD: how so?
[15:38] <tseliot> I mean, how are you so sure that it doesn't switch libraries?
[15:38] <Milos_SD> in xorg log it says something about not right libs are loaded
[15:39] <tseliot> are you using oneiric?
[15:39] <tseliot> 11.10
[15:39] <tseliot> ?
[15:39] <Milos_SD> yes
[15:40] <tseliot> ok, so, do an update-alternatives --display x86_64-linux-gnu_gl_conf (if you're using Ubuntu 64 bit) before and after those two commands
[15:41] <tseliot> things should change. The fact that the driver segfaults is a different issue
[15:41] <tseliot> oh and sudo aticonfig --px ddx or --px idx call those two scripts
[15:42] <tseliot> (which I wrote)
[15:42] <Milos_SD> yes I know that... and after I use aticonfig --px idx I can't use aticonfig at all anymore
[15:42] <Milos_SD> libGL is missing
[15:43] <tseliot> Milos_SD: oh, I think I know what's going on...
[15:44] <tseliot> no wonder it's missing
[15:44] <tseliot> I should've updated the powerXpress alternative with multiarch paths for mesa... my bad
[15:45] <tseliot> I'm going to upload a new upstream release with a fix anyway
[15:45] <tseliot> :~$ cat /usr/lib/pxpress/ld.so.conf
[15:45] <tseliot> /usr/lib/mesa
[15:45] <tseliot> /usr/lib/pxpress/lib
[15:45] <tseliot> /usr/lib32/mesa
[15:45] <tseliot> /usr/lib32/pxpress/lib
[15:45] <tseliot> wrong ^
[15:46] <tseliot> ;)
[15:46] <Milos_SD> btw, I need to create /usr/lib64 directory and then copy fglrx folder from /usr/lib/ in it to make aticonfig --initial -f work at all
[15:47] <tseliot> Milos_SD: it's best if you don't copy things manually, otherwise things will break on next update
[15:48] <Milos_SD> well I do that when I install 11.10 version of fglrx from amd site... but it has to be done for fglrx-updates from repos too
[15:48] <Milos_SD> and I think for fglrx package too
[15:48] <tseliot> Milos_SD: that's because I maintain the scripts for all of them ;)
[15:49] <tseliot> therefore if something is not fixed in my packages in ubuntu it's likely that it's not fixed in the amd installer
[15:50] <Milos_SD> for fglrx package (not the -updates one) have that bug fixed in changelog, but it isn't realy fixed :)
[15:50] <tseliot> I'll check that and make sure that it's really fixed
[15:50] <tseliot> thanks for reporting the issue
[15:51] <Milos_SD> so, that is the main problem that Xserver is segfaulting here?
[15:54] <Milos_SD> main reason*
[15:54] <tseliot> Milos_SD: it could be
[15:54]  * tseliot -> phone call
[17:11] <bryceh> tjaalton, right; will try to get that updated today
[17:12] <tjaalton> bryceh: cool, thanks
[17:39] <Sarvatt> multiarch with PPAs is really proving to be unfun because i386 is always backed up more than amd64 and you get http://paste.ubuntu.com/741401/ for a few hours every day
[17:39] <Sarvatt> accept that and wine silently stops working
[18:14] <ricotz> Sarvatt, thanks for updating right drivers ;)
[18:15] <Sarvatt> the right drivers?
[18:15] <ricotz> the ones which failed so far with xserver git master
[18:16] <ricotz> didnt follow their changes but maybe they got fixed
[18:17] <Sarvatt> oh my script updates every driver whenever there are new updates in upstream git, they must be fixing it :)
[18:17] <Sarvatt> yeah ajax fixed a bunch up it looks like
[18:17] <Sarvatt> its screwed up on mga though, i have to do that one manually
[18:17] <Sarvatt> is that broken?
[18:18] <Sarvatt> ricotz: does geode build on master?
[18:18] <Sarvatt> or openchrome
[18:18] <ricotz> mga built
[18:19] <ricotz> geode i havent in the ppa though
[18:19] <ricotz> https://launchpad.net/~ricotz/+archive/unstable/+packages
[18:22] <Sarvatt> so just vmmouse still
[18:23] <Sarvatt> might be able to fix that up, lets see
[18:24] <ricotz> i am copying the missing one, i just grabbed the driver from the precise pocket
[18:53] <Sarvatt> oh hell
[18:53] <Sarvatt> spent the past half hour fixing up vmmouse then it hit me
[18:53] <Sarvatt> ajax was fixing the upstream drivers up, check fedora
[18:53] <Sarvatt> http://pkgs.fedoraproject.org/gitweb/?p=xorg-x11-drv-vmmouse.git;a=blob;f=0001-Deal-with-opaque-InputOption-types-in-ABI-14.patch;h=ef4a765a4839bb5cd3e8ac8e7fc927c1c8fd952d;hb=9b1097ff9fc1a828eb8e899c5ed4c8f006b88574
[18:54] <Sarvatt> ricotz: new vmmouse incoming :)
[18:54] <ricotz> Sarvatt, nice ;)
[18:55] <ricotz> unfortunatelly wacom failed against all odds
[18:57] <Sarvatt> ricotz: did you check fedora?
[19:00] <ricotz> yeah, it might work with git master
[19:00] <ricotz> wacom said so too ;)
[19:01] <Sarvatt> ricotz: you could always override_dh_auto_test:
[19:01] <Sarvatt> 	dh_auto_test || echo "Test suite failure, but keeping on anyway"
[19:01] <Sarvatt>  :P
[19:02] <ricotz> i see, havent looked at it closely while i dont really need it