[01:47] <Sarvatt> how do I get git diff between two branches to show newly added files?
[01:49] <Sarvatt> trying to backport some nouveau changes in mesa that way and its just creating an empty file
[01:54] <RAOF> That diff should show newly added files?
[01:55] <RAOF> Unless they've been added locally but not committed?
[02:04] <Sarvatt> in the middle of updating this vm to maverick to try building mesa, i was doing git diff HEAD..upstream path/to/directory/ and new files were just empty in the diff, i was on debian-experimental branch
[02:04] <Sarvatt> will check once its done updating I mean, cant open the diff at the moment
[02:05] <RAOF> You probably had the missing -- in there locally, I guess.
[02:07] <Sarvatt> guess i'll have to backport dpkg in edgers to lucid for whats in debian-experimental :D
[02:08] <RAOF> Or just drop the regexs from the symbols files.
[02:09] <Sarvatt> it looks like dist-upgrades to maverick work again at least
[02:15] <bryceh> btw, good work on the merges guys.  I think the versions-current page is closer to 0 than I think I've ever seen it
[02:21] <Sarvatt> oh yeah speaking of which, need to look at xdm and xterm. will do that while mesa builds :)
[02:21] <RAOF> Gratias.
[02:24] <Sarvatt> is there some voodoo to import from a dsc?
[02:24] <Sarvatt> or should i just make a new branch and import all the ubuntu stuff by hand?
[02:25] <Sarvatt> looking at http://git.debian.org/?p=pkg-xorg/app/xterm.git;a=summary
[02:25] <jcristau> there's a git-import-dsc
[02:26] <Sarvatt> nice, yeah I just found that
[02:34] <Sarvatt> hmm, looks like i need to create a new ubuntu branch from the 256 tag before importing it
[02:47] <Sarvatt> git branch ubuntu xterm-256-1 && git-import-dsc --no-merge --debian-branch=ubuntu --upstream-branch=upstream-unstable  ../xterm_256-1ubuntu1.dsc seems to work
[02:47] <jcristau> cool
[02:47] <Sarvatt> ah need to make it not tag
[02:49] <Sarvatt> which doesn't seem possible :)
[02:50] <jcristau> worst case you can git tag -d $foo afterwards
[02:50] <Sarvatt> guess it doesn't matter as long as i dont push the tags
[02:50] <Sarvatt> oh yeah that too
[02:57] <Sarvatt> hmm dont want to screw this up, looks like our tarballs differ? Switched to a new branch 'upstream-unstable'
[02:57] <Sarvatt> rm 'vttests/query-fonts.pl'
[02:58] <Sarvatt> ah because that files new in 259
[03:15] <Sarvatt> no big deal, just deleted the tags it added and reverted upstream-unstable, this is pretty sweet
[03:26] <Sarvatt> so all I need to do to push this is git push origin ubuntu and it'll create the branch right?
[03:26] <RAOF> Yup.
[03:32] <Sarvatt> i dont like how you cant see the upstream git history this way though
[03:33] <Sarvatt> ah its svn
[03:35] <bjsnider> adobe appears to have dropped the 64-bit flash plugin for linux
[03:36] <RAOF> By “dropped” do you mean “released”, or “not bothered to release”?
[03:38] <bjsnider> the download link has been removed. it is not mentioned on the site anymore
[03:38] <bjsnider> as if it never existed
[03:40] <bjsnider> ok, the download link for the last known version still works. but it is not mentioned anymore
[03:40] <bjsnider> at least they haven't taken it off the web server (yet)
[03:42] <bjsnider> namely: http://download.macromedia.com/pub/labs/flashplayer10/libflashplayer-10.0.45.2.linux-x86_64.so.tar.gz
[03:43] <Sarvatt> ok pushed xterm
[03:43] <Sarvatt> yeah it sucks, i was complaining about that in #ubuntu+1 earlier
[03:43] <Sarvatt> its cus 10 had a security problem and they released 10.1 and there was no 10.1 64 bit i'm sure
[03:44] <Sarvatt> so i'm stuck using the one with the security problem, yay :)
[03:44] <Sarvatt> 32 bit isnt an option at this point
[03:51] <Sarvatt> ok the xterm merge *seems* to be fine
[03:51] <Sarvatt> http://git.debian.org/?p=pkg-xorg/app/xterm.git;a=shortlog;h=refs/heads/ubuntu
[04:10] <Sarvatt> oh RAOF, xdm is in universe so you can upload~ \o/
[04:10] <RAOF> :)
[04:15] <Sarvatt> not sure whats going on with mesa, i think they're waiting for the glsl2 stuff to do a 7.9 RC snapshot because it looks like -intel and libdrm are almost set for the next quartery release
[04:18] <Sarvatt> and intel seems to be driving all the major release schedules
[04:28] <Sarvatt> AH I figured out why git diff was screwing up!
[04:28] <Sarvatt> lrwxrwxrwx  1 sarvatt sarvatt    51 2010-06-10 20:28 nouveau_class.h -> ../../../../gallium/drivers/nouveau/nouveau_class.h
[04:29] <Sarvatt> its a symlink to a file outside of the diff path
[04:34] <RAOF> Funky.
[04:34] <Sarvatt> looks like we can just add nouveau_class.h to the two directories and it'll work
[04:36] <Sarvatt> trying with git checkout upstream src/gallium/drivers/nouveau/nouveau_class.h && git checkout upstream src/mesa/drivers/dri/nouveau/nouveau_class.h
[04:37] <Sarvatt> with upstream being a local branch tracking master
[04:46] <Sarvatt> i dont think its recommended to use nouveau_vieux from 7.8.x
[04:46] <Sarvatt> fedora backports it from master to 7.8
[04:47] <Sarvatt> i have a patch to do that too btw.. http://sarvatt.com/downloads/patches/nouveau-update.patch
[04:47] <Sarvatt> making that patch was why ii was trying to figure out why nouveau_class.h was empty
[04:48] <Sarvatt> ping pong back and forth between irc channels, sorry :)
[04:52] <Sarvatt> i'd like to get our libGL back into /usr/lib
[04:53] <Sarvatt> it works fine now there, i hacked up nvidia-current to install the alternatives there and it takes priority correctly now that we removed the abi tag from tls from the lib
[04:54] <Sarvatt> once we get all this stuff fixed up i'll do that
[05:00] <Sarvatt> http://cgit.freedesktop.org/mesa/mesa/log/src/mesa/drivers/dri/nouveau -- ah everything after march 4th isn't in 7.8 branch
[05:58] <Sarvatt> RAOF: is this normal?
[05:58] <Sarvatt> - (regex|optional=mesa internal ASM optimized functions)"^_mesa_.*@Base$" 7.8.1
[05:58] <Sarvatt> +#MISSING: 7.8.1-3# (regex|optional=mesa internal ASM optimized functions)"^_mesa_.*@Base$" 7.8.1
[05:59] <RAOF> Sarvatt: Yes; I can tell you're building on i386, which doesn't have those x86-64 optimisations :)
[05:59] <RAOF> This is why those are marked optional; they're processor-specific.
[06:00] <RAOF> If I were more awesome I'd have provided a patch to ensure they don't get exported.
[06:04] <Sarvatt> http://pastebin.com/JjHks0eS ?
[06:05] <Sarvatt> i have no idea, just ripped off jcristau's libdrm changes :)
[06:06] <Sarvatt> why have .symbols? libGL doesn't
[06:07] <RAOF> Because .symbols make it easier to detect accidental ABI breakage.
[06:08] <Sarvatt> woohoo, she works with my backported cherry-pick commit!
[06:08] <Sarvatt> needed that nv50_screen.c change on top of the header
[06:08] <Sarvatt> just tested it on a nouveau machine and its working fine
[06:09] <Sarvatt> btw I'm going to commit this soon if i dont see any problems with it.. http://sarvatt.com/downloads/patches/mesa-ccache.patch
[06:10] <Sarvatt> pain in the butt setting up my ccache symlinks on all these other machines i'm test building on :D
[06:12] <Sarvatt> guess we should wait for libdrm 2.4.21 to clear debian NEW to upload to ubuntu? :)
[06:15] <Sarvatt> i want to try building master with your spiffy debian/, to see what files actually get built
[06:16] <RAOF> Yeah.
[06:33] <lifeless> RAOF: what would you say, if I said closing a full screen wine app hard-locks my machine ?
[06:34] <RAOF> I'd say that you were lying.  Everyone knows X is perfect.
[06:35] <RAOF> I might also consider the X crash that we used to have when closing GLX 1.3 apps, but that's *definitely* been fixed by not allowing GLX 1.3 apps.  Unless you're running Maverick.
[06:36] <lifeless> I'm on lucid, nvidia blob
[06:36] <RAOF> HAH!
[06:36] <lifeless> its 'plants vs zombies', if that helps.
[06:36] <RAOF> That game sounds fun :)
[06:37] <RAOF> Debugging the binary drivers is unlikely to be very fruitful.
[06:37] <Sarvatt> lifeless: tried the wine PPA version?
[06:38] <lifeless> Sarvatt: In case its glue? Not since I upgraded to lucid; can/will do
[06:38] <Sarvatt> https://edge.launchpad.net/~ubuntu-wine/+archive/ppa
[06:38] <RAOF> One of our X PPAs has shiny new binary drivers you could try, too.
[06:38] <Sarvatt> what game/app?
[06:39] <Sarvatt> more "fullscreen game X crashes the system!" bugs fixed in each of the 1.2-rc changelogs than I can count lol
[06:42] <Sarvatt> merging debian-experimental into ubuntu locally then gonna try that with mesa master
[06:52] <lifeless> Sarvatt: 'plants vs zombies'
[07:02] <Sarvatt> is the machine *completely* dead? can you ssh in at all?
[07:03] <Sarvatt> anything in /var/log/Xorg.0.log.old when you reboot about it?
[07:03] <Sarvatt> looks like lots of complaints about resolution problems with that game on winehq unless you disable 3D acceleration inside the game
[07:05] <Sarvatt> RAOF: building 7.9 with a merged debian/, will send ya the build log and full file list once its done
[07:05] <m3ga> i have a bootable usb-key with lucid and I'm trying to boot a tablet device. problem is that the kernel (or possibly X) seems to try to switch the vga mode and screws up the graphics.
[07:06] <m3ga> is there any way to work around this? i just want a console.
[07:12] <lifeless> RAOF: ^ how do you avoid X coming up ?
[07:37] <Sarvatt> boot with text or single added to the command line and drop splash, hold shift while booting the livecd and press tab at the boot a live session option to edit the command line
[07:38] <Sarvatt> most likely you want to add nomodeset also but i have no idea what GPU you have without any more info
[07:38] <Sarvatt> RAOF: so you're replacing i915_dri.so with the gallium one here?
[07:55] <lifeless> Sarvatt: thanks :)
[07:55] <lifeless> Sarvatt: I'll pass that on
[08:00] <Sarvatt> RAOF: hmm first change is that debian/tmp/usr/glx/ doesn't exist in 7.9 and thats where some things are installing from like openvg
[08:57] <alf__> Hi all, I just updated maverick and got new X packages that somehow broke fglrx. Is that expected?
[08:57] <bryceh> yes
[08:58] <alf__> Any way I can fix it now?
[08:59] <alf__> The strange thing is that it complains: [atiddxSetup] X version mismatch - detected X.org 7.1.1.901, required 7.5.1.0
[08:59] <alf__> why is X.org detected as 7.1.1.901?
[09:02] <bryceh> no there is nothing you can do to fix it
[09:03] <alf__> great, I 'll just use vesa then :)
[09:03] <bryceh> if you must have fglrx, either use lucid or wait until maverick beta 1
[09:27] <Sarvatt> darn net died, anyway looks like some of the problems might just be because i'm not passing --enable-gles-overlay, the es state tracker doesn't exist anymore
[09:29] <Sarvatt> i dont know why usr/glx/whatever.so is being used instead of usr/lib/glx/whatever.so in the current packaging
[09:32] <Sarvatt> debian/tmp/usr/lib is OSMesa and debian/tmp/usr/lib/glx is everything from the confflags-dri target
[09:39] <jcristau> Sarvatt: to avoid conflicts between the dri libGL and the swx11 libGL
[09:39] <jcristau> at dh_install time
[09:40] <Sarvatt> does it matter that the .pc's are screwed up?
[09:42] <Sarvatt> some have libdir pointing at /usr/lib/glx in them I mean, and we're installing gl.pc from osmesa instead of the confflags-dri target one in libgl1-mesa-dev
[09:44] <Sarvatt> http://paste.ubuntu.com/448160/
[09:44] <jcristau> the .pc with screwed up libdir is dri.pc where it doesn't matter
[09:54] <Sarvatt> all of these new .pc's have the messed up libdir's in mesa 7.9 since they're in usr/lib/glx :(
[09:56] <Sarvatt> http://paste.ubuntu.com/448165/ :(
[10:02] <Sarvatt> any way to install osmesa/swx11+glu stuff, clean then install dri to reuse usr/lib?
[10:07] <jcristau> not easily
[10:07] <Sarvatt> yeah this looks to be a pain in the butt
[10:10] <Sarvatt> are the .pc files generated at make install time?
[10:13] <jcristau> no, at compile time
[10:13] <Sarvatt> cus if not we could just not use --libdir=/usr/lib/glx in confflags-dri, seperate out the dri install and make it install that one to debian/tmp/usr/lib/glx and tell it to install those things into usr/lib in the .installs?
[10:14] <jcristau> yeah
[10:14] <jcristau> except that would require dealing with mesa's build system ;)
[10:15] <jcristau> but if you want to do that, it sounds like a fine plan to me
[10:15] <Sarvatt> i'll give it a shot
[10:16] <jcristau> might be easier to set DESTDIR to debian/tmp/dri than install to debian/tmp/usr/lib/glx
[10:16] <jcristau> but.  whatever works.
[10:53] <Sarvatt>         set -e; for config in $((filterout dri,$(CONFIGS))); do \
[10:53] <Sarvatt>                 $(MAKE) -C $(DEB_BUILD_DIR)/$$config DESTDIR=$(CURDIR)/debian/tmp install; \
[10:53] <Sarvatt>         done
[10:53] <Sarvatt>         $(MAKE) -C $(DEB_BUILD_DIR)/dri DESTDIR=$(CURDIR)/debian/tmp/dri install;
[10:53] <Sarvatt> something like that?
[10:54] <jcristau> looks plausible
[10:54] <Sarvatt> err set -e; for config in $($(filterout dri,$(CONFIGS))); do \ ?
[10:54]  * Sarvatt needs to read a make manual
[10:57] <jcristau> $(filterout dri, $(CONFIGS))
[10:57] <jcristau> no extra $( )
[11:09] <Sarvatt> any idea if i can just prefix the paths in the .install's with debian/tmp/dri or debian/tmp?
[11:10] <Sarvatt> i'll dig through the debhelper docs and figure it out
[11:11] <jcristau> the paths there are relative to debian/tmp
[11:13] <jcristau> so 'dri/usr/lib/foo usr/lib' should work
[11:14] <Sarvatt> oh duh was confusing myself, dri is inside debian/tmp so its no problem, i was thinking i was making DESTDIR outside of debian/tmp
[11:50] <Sarvatt> ok trying out this - http://sarvatt.com/downloads/patches/mesa-testing.patch
[11:53] <Sarvatt> + the nouveau patch so it builds against libdrm 2.4.21 but i left that out
[12:21] <Sarvatt> not a single arm bug on launchpad with any X logs.. sheesh
[12:43] <Sarvatt> darn, this didn't work
[12:50] <Sarvatt> set -e; for config in ; do \
[12:50] <Sarvatt>                 /usr/bin/make -C /home/sarvatt/source/mesa-orig/build/$config DESTDIR=/home/sarvatt/source/mesa-orig/debian/tmp install; \
[12:50] <Sarvatt>         done
[12:50] <Sarvatt> /usr/bin/make -C /home/sarvatt/source/mesa-orig/build/dri DESTDIR=/home/sarvatt/source/mesa-orig/debian/tmp/dri install
[12:50] <Sarvatt> make[1]: Entering directory `/home/sarvatt/source/mesa-orig/build/dri'
[12:50] <Sarvatt> that variable must have been wrong
[12:51] <Sarvatt>         set -e; for config in $(filterout dri, $(CONFIGS)); do \
[12:54] <jcristau> hrm.
[12:54] <Sarvatt> at least i can test this part without rebuilding it all :D
[12:54] <Sarvatt> its only doing the dri stuff
[12:54] <jcristau> it's filter-out
[12:54] <jcristau> http://www.gnu.org/software/automake/manual/make/Text-Functions.html
[12:54]  * Sarvatt slaps his forehead
[12:55] <Sarvatt> yeah i had 3 working directories and pasted it from the first one where i didnt fix that, go me
[12:55] <Sarvatt> set -e; for config in swx11+glu swx11+glu-static swx11+glu-i386-i686 osmesa osmesa-static osmesa16 osmesa16-static osmesa32 osmesa32-static; do \
[12:55] <Sarvatt> 		/usr/bin/make -C /home/sarvatt/source/mesa-orig/build/$config DESTDIR=/home/sarvatt/source/mesa-orig/debian/tmp install; \
[12:55] <Sarvatt> 	done
[12:55] <Sarvatt> \o/
[12:58] <Sarvatt> now the question is, are we supposed to use the dri gl.pc or the swx11 one? :)
[13:04] <jcristau> doesn't matter imo
[13:04] <jcristau> the only thing it does is give you -lGL
[13:09] <Sarvatt> the Requires.private and Libs.private aren't important? 
[13:10] <Sarvatt> Requires.private: libdrm >= 2.4.15 dri2proto >= 2.1 glproto >= 1.4.11 x11 xext xxf86vm xdamage xfixes Libs.private: -lm -lpthread -ldl     vs    Requires.private: x11 xext Libs.private: -lm -lpthread
[13:12] <Sarvatt> could install one each in libgl1-mesa-dev (that pulls in glx) and libgl1-mesa-swx11-dev and have them conflict? talk about asking for trouble :)
[14:54] <kenvandine> has anyone seen the mouse jitter problem in maverick?
[14:55] <kenvandine> trying to search for a bug with that symptom is pretty hard...
[14:55] <kenvandine> started happening yesterday
[14:58] <Sarvatt> what type of mouse?
[14:58] <Sarvatt> you just did a major replacement of every X package yesterday so not surprising it started yesterday :)
[14:59] <Sarvatt> is it a dell mini?
[15:00] <Sarvatt> kenvandine: can ya pastebin your /var/log/Xorg.0.log? its possible i screwed up something in the synaptics merge, or you dont have synaptics installed and are using evdev :)
[15:12] <kenvandine> Sarvatt, actually i did some digging in my dpkg.log and saw that xserver-xorg-input-mouse got removed
[15:12] <kenvandine> should it have been removed?
[15:12] <jcristau> yes
[15:13] <kenvandine> ok... 
[15:13] <kenvandine> i do have a synaptics touchpad
[15:13] <kenvandine> but bratsche saw the same thing using vmware
[15:14] <Sarvatt> no it shouldn't have been removed I dont think, xserver-xorg-input-vmmouse is in xserver-xorg-input-all and depends on xserver-xorg-input-mouse
[15:14] <kenvandine> http://pastebin.ubuntu.com/448265/
[15:15] <kenvandine> i am not sure if that got removed for him
[15:15] <kenvandine> i am not using vmware and seeing the same problem
[15:16] <Sarvatt> kenvandine: do you have xserver-xorg-input-synaptics installed?
[15:16] <kenvandine> nope
[15:16] <Sarvatt> because you're using evdev there
[15:16] <kenvandine> i just installed it again...
[15:16] <Sarvatt> yeah thats why, you accepted a partial upgrade and it broke things
[15:16] <kenvandine> that also got removed yesterday
[15:17] <kenvandine> damn dist-upgrade!
[15:18] <Sarvatt> sudo apt-get install xorg xserver-xorg-input-all xserver-xorg-video-all xserver-xorg just incase :)
[15:20] <Sarvatt> yeah the breaks: on xserver-xorg-core were doing all kinds of nasty things like that for me too, it'd offer upgrading xserver-xorg-dev and xserver-common and stuff while holding back on xserver-xorg-core because of the breaks, but after you did that there was all kinds of breakage
[15:21] <Sarvatt> lucky you dont have nvidia, you still would have things broken :)
[15:22] <kenvandine> hehe
[15:22] <kenvandine> Sarvatt, thx!
[15:23] <Sarvatt> no worries, sorry about the trouble, neither me nor RAOF can upload to main! :D
[15:24] <Sarvatt> it took me about 3 hours to do the whole transition in a PPA but that was nonstop uploading and dropping ubuntu changes :)
[16:12] <jg> Sarvatt, RAOF: https://bugs.freedesktop.org/show_bug.cgi?id=28070 seems to have settled down to a minimal patch. Probably time to try it for real, if you can get me an image.
[16:12] <ubot4> Freedesktop bug 28070 in Driver/intel "[Arrandale] No output (black) on eDP" [Major,New]
[16:16] <tseliot> Sarvatt: BTW I don't know if any other driver apart from nvidia 195 works with kernel 2.6.35
[16:18] <Sarvatt> yeah they dont, but xserver-xorg-core breaks: xserver-xorg-video-6 so peoples package managers are all kinds of screwed up if they have it installed. i dont think nvidia-currrent should be providing an abi even since it works with multiple ones?
[16:19] <Sarvatt> tseliot: btw wait until you see the fun nvidia had packaging up the 256 series! 
[16:19] <Sarvatt> everythings in one directory now
[16:20] <tseliot> Sarvatt: I'm not sure about not providing an ABI with nvidia. It's not guaranteed to work with the new X ABI either
[16:20] <tseliot> Sarvatt: yes, I know about about the new driver but I've been too busy with my OEM work to even think about packaging it
[16:21] <Sarvatt> it works with 4 or 5 abi's and its just the package manager stopping people at the moment is all i was thinking
[16:22] <Sarvatt> tseliot: well its mostly done in x-updates if you ever go to mess with it, could probably use a bit of refinement :)
[16:22]  * ripps is building new version of wacom-dkms, doesn't require any xorg-dev files to work.
[16:23] <ripps> uploading to ppa:ripps818/wacom
[16:23] <Sarvatt> libGL in /usr/bin does work now too, i hacked up a nvidia blob to test it out and am going to try to get the mesa side done
[16:23] <Sarvatt> ripps: yeah dont ship the X driver from linuxwacom, xf86-input-wacom is what you want to use you just need the kernel module
[16:24] <tseliot> Sarvatt: to put back the mesa libraries where they used to be?
[16:24] <tseliot> also it's good to know that there's a package for that driver, I'll have a look at it
[16:24] <tseliot> (when I have the time)
[16:27] <ripps> Sarvatt: actually, it just because configure won't finish without them. So, instead, I have all the xorg-dev stuff as build-depends and I run configure while it's building the package on launchpad. When someone installs the package from the ppa, they will only need dkms and linux-headers-generic to build the module
[16:28] <jcristau> shouldn't the kernel stuff use kconfig instead of configure anyway?
[17:40] <bjsnider> Sarvatt, a shared lib in /usr/bin?
[17:41] <Sarvatt> i meant /usr/lib
[17:49] <bjsnider> ok, that makes more sense
[17:50] <apw> Sarvatt, hey did you manage to sort out my xorg-edgers membership?
[17:54] <Sarvatt> apw: yeah fixed ya up right when ya ask, did I not say anything? sorry man!
[17:55] <apw> Sarvatt, missed it, thanks man
[17:56] <Sarvatt> oh yeah speaking of membership renewal..
[17:57] <Sarvatt> bdmurray: any chance I could get my bugcontrol membership renewed? got a mail saying it was expiring soon
[17:58] <bdmurray> Sarvatt: what is your launchpad id?
[17:59] <Sarvatt> sarvatt
[17:59] <Sarvatt> bdmurray: appreciate it!
[17:59] <Sarvatt> thanks :)
[18:00] <bdmurray> Sarvatt: thank you for helping out!
[18:00] <Sarvatt> there has *got* to be a better way to manage 1 silly libGL.so.1 symlink. I have the GL stuff from nvidia-current, nvidia-173 and mesa all installed in /usr/lib at the same time and thats the only conflict
[18:02] <ripps> I remember somebody here talking about using appmenu in Maverick. Well, according to maverick-changes, someone added just that.
[18:03] <Sarvatt> probably me the other day, i was trying to run with a mix of ppa and archive packages and not having any luck :D
[19:38] <ripps> Okay, can someone help me figure this out. There's something wrong with my wacom-dkms packag in ppa:ripps818/wacom. For some reason, it's not adding the module build directory to the make -C called by dkms. It might be because I'm running the ./configure in launchpad, but I can't figure this out.
[19:45] <ripps> I'm thinking it might be impossible to keep the -dev files out of this. Since it seems that it's required to run configure locally.
[19:46] <ripps> Hmm.... maybe I could just patche the configure so that it doesn't try to look for the xorg wacom driver dependencies
[19:51] <alkisg> I've a laptop with intel 945 which is misteriously broken, with Lucid or Vista it's only showing some broken lines in the first 30-40 pixels of the screen. Completely unusable.
[19:51] <alkisg> It works fine with Intrepid though! And it also works fine with vesa.
[19:51] <alkisg> Is there any way to use the Intrepid intel module on the Lucid kernel? Or to downgrade the kernel? I wouldn't want to always stick to Intrepid...
[19:56] <ripps> Okay, I think I see whats wrong with my wacom-dkms. When I build it in pbuilder, it passes kernel source properly to configure. But, on launchpad, even though it install all the linux-headers packages, configure isn't able to find the linux source directory.
[20:02] <ripps> this dumb, I shouldn't need a bunch of xserver development code just compile a kernel module that doesn't even use it.
[20:17] <alkisg> Ah, it seems that the older versions (8.10 and 9.04) use the "intelfb" module, while 10.04 uses the "i915" module, and fails.
[20:18] <alkisg> Can I force the use of the intelfb module on lucid?
[20:19] <jcristau> you shouldn't ever have used intelfb
[20:20] <alkisg> jcristau: it's some weird hardware/driver problem
[20:20] <alkisg> It's also there on vista. But 8.10 and 9.04 work fine
[20:20] <alkisg> Will passing video=intelfb as a kernel parameter do it?
[20:21] <alkisg> Ah, it seems that I misread "have used" with "have to use"
[20:21] <alkisg> lspci -vv on 9.04 tells me that intelfb is used
[20:32] <Sarvatt> oh yuck, debian/nvidia_supported in that 256.29 doesn't work right and only generates a tiny modalias file
[20:32] <bjsnider> maybe hte file it scans has changed
[20:33] <Sarvatt> nope, just checked, it just makes a tiny one with about 15 cards in it
[20:33] <bjsnider> there's something else that wasn't in the changelog
[20:33] <Sarvatt> file is right, i did it by hand
[20:34] <Sarvatt> # This is a nasty kluge, but it seems to work. Better check the output when
[20:34] <Sarvatt> # upgrading to a new release of the nvidia driver, though.
[20:34] <Sarvatt> :D
[20:35] <bjsnider> what is a kluge?
[20:35] <bjsnider> maybe the file location is different
[20:38] <Sarvatt> it's not, i'm doing it by hand and its the same as its making at build time
[20:49] <Sarvatt> http://heh.fi/tmp/nvidia_supported
[20:49] <Sarvatt> (thats the script)
[20:58] <alkisg> The difference I see is in lspci -vv: Ubuntu 8.10 and 9.04 report "intelfb" there, and work fine. Ubuntu 9.10 and 10.04 report "i915" there, and do not work.
[20:58] <alkisg> Is it possible to use the "intelfb" kernel module in Lucid? If not, I'll just uninstall it and install Jaunty instead...
[21:00] <alkisg> Ugh, google says that "intelfb is blacklisted on lucid"...
[21:01] <alkisg> Hmm I'll try blacklisting i915 and whitelisting intelfb - if that doesn't work, I'll just install jaunty.
[21:08] <alkisg> Urm, I don't even see an intelfb module in Lucid. OK, installing Jaunty instead...
[21:18] <kees> hm, shouldn't Xorg be installable now?
[21:18] <kees> I can't seem to install 1.8
[21:18] <kees> The following packages have unmet dependencies:
[21:18] <kees>   xserver-xorg-core: Breaks: xserver-xorg-video-6
[21:18] <kees> E: Broken packages
[21:20] <jcristau> what driver?
[21:21] <kees> I have intel
[21:21] <jcristau> should be ok then, afaik..
[21:21] <kees> I'm trying to sort out apt's clues on this, but it makes no sense.
[21:22] <kees> dist-upgrade wants to hold everything back.  explicit install of -core fails as above
[21:25] <ripps> okay, I think I *really* have wacom-dkms working. I made a custom makefile using 'uname -r' instead of the one generated by configure.
[21:30] <Sarvatt> kees: what do you have providing xserver-xorg-video-6?
[21:30] <Sarvatt> i'm going to guess virtualbox OSE
[21:31] <Sarvatt> hmm then again that would be providing input-7 too
[21:32] <Sarvatt> kees: do you have an nvidia driver maybe? if you open up synaptic you can search for provides: xserver-xorg-video-6, i never could find a way to search from the command line
[21:33] <kees> Sarvatt: I'll try that.  what's weird is that aptitude can do the dist-upgrade, but doesn't show anything Xish being removed
[21:34] <Sarvatt> i wouldn't do it, it'll upgrade one of the metapackages and put you in a screwed up state where it thinks everythings broken
[21:34] <kees> yeah
[21:35] <Sarvatt> weird though, wonder what you got providing that still
[21:35] <jcristau> i'm trying to get rid of the need for conflicts/breaks on x upgrades...
[21:35] <kees> the only thing that shows up is xserver-xorg-video-apm which I don't have installed
[21:36] <Sarvatt> weird
[21:36] <kees> if I search for -7, I get lots of hits.
[21:36] <jcristau> 7 is the current abi
[21:36] <Sarvatt> how about xserver-xorg-input-7?
[21:37] <kees> nothing there
[21:37] <jcristau> that makes no sense..
[21:38] <jcristau> apt error messages are cryptic sometimes
[21:38] <Sarvatt> sudo apt-get install xorg xserver-xorg xserver-xorg-video-all xserver-xorg-input-all install anything?
[21:38] <kees>   xserver-xorg: Depends: xserver-xorg-core (>= 2:1.8) but 2:1.7.6-2ubuntu7 is to be installed
[21:38] <kees>   xserver-xorg-input-all: Depends: xserver-xorg-input-vmmouse but it is not going to be installed
[21:38] <kees> etc
[21:38] <kees> but apt-cache policy shows 1.8 available
[21:39] <Sarvatt> sudo apt-get install xserver-xorg-input-mouse fix it?
[21:39] <kees>   xserver-xorg-input-mouse: Depends: xorg-input-abi-9.0
[21:39] <kees>                             Depends: xserver-xorg-core (>= 2:1.8) but it is not going to be installed
[21:40] <jcristau> apt-get install xserver-xorg xserver-xorg-video-all xserver-xorg-input-all xserver-xorg-input-vmmouse?
[21:41] <jcristau> ime if you add the packages it complains about one by one you eventually reach a useful error message
[21:41] <kees> same error, but I'll try
[21:41] <jcristau> ah yeah add -core
[21:42] <kees> yeah, back to square one.
[21:42] <kees> after this: sudo apt-get install xserver-xorg xserver-xorg-video-all xserver-xorg-input-all xserver-xorg-input-vmmouse xserver-xorg-input-wacom xserver-xorg-input-mouse xserver-xorg-core xserver-xorg-video-ati xserver-xorg-video-nv xserver-xorg-video-tseng xserver-xorg-video-i128 xserver-xorg-video-intel xserver-xorg-video-s3 xserver-xorg-video-mach64 xserver-xorg-video-cirrus xserver-xorg-video-mga xserver-xorg-video-tdfx xserver-xorg-video-r128 xserv
[21:42] <kees> I get:
[21:43] <kees> The following packages have unmet dependencies:
[21:43] <kees>   xserver-xorg-core: Breaks: xserver-xorg-video-6
[21:43] <kees> E: Broken packages
[21:43] <kees> and aptitude says it'll do that install ... bug in apt?
[21:44] <Sarvatt> sudo apt-get purge xserver-xorg-video-cirrus && sudo apt-get dist-upgrade? :)
[21:45] <Sarvatt> Provides: xserver-xorg-video-6
[21:45] <Sarvatt> Package: xserver-xorg-video-cirrus
[21:45] <Sarvatt> Version: 1:1.3.2-1ubuntu1
[21:45] <kees> that didn't seem to do it, it still wants to hold it back
[21:46] <jcristau> bad apt.
[21:46] <jcristau> i blame mvo :)
[21:49] <Sarvatt> ok last try before i'm stumped
[21:49] <Sarvatt> purge xserver-xorg-video-all xserver-xorg-input-all
[21:50] <kees> hehe
[21:50] <kees> Package xserver-xorg-video-all is not installed, so not removed
[21:50] <kees> Package xserver-xorg-input-all is not installed, so not removed
[21:50] <kees> here are all the things I have installed for video-6 currently:
[21:50] <kees> xserver-xorg-video-v4l xserver-xorg-video-s3virge xserver-xorg-video-openchrome xserver-xorg-video-vmware xserver-xorg-video-radeon xserver-xorg-video-fbdev xserver-xorg-video-tdfx xserver-xorg-video-r128 xserver-xorg-video-mga xserver-xorg-video-i128 xserver-xorg-video-s3 xserver-xorg-video-intel xserver-xorg-video-mach64 xserver-xorg-video-ati xserver-xorg-video-tseng
[21:50] <kees> based on /var/lib/dpkg/status
[21:50] <Sarvatt> can you just install video-all? :)
[21:51] <Sarvatt> openchrome is providing video-6 too, that needs a rebuild :(
[21:51] <Sarvatt> v4l was dropped
[21:52] <kees> can't install video-all, going one-by-one in the -6 list now, trying to purge stuff where there's no new version
[21:53] <Sarvatt> oh man, I was looking at provides: on a lucid machine.... :\
[21:55] <Sarvatt> all of those you listed are abi 7
[21:57] <kees> even fbdev.  wtf
[21:59] <Sarvatt> tried just installing input-all? :)
[21:59] <Sarvatt> i'm sure that gets stuck on vmmouse
[21:59] <kees> will try that in a moment, purging all but -intel now
[21:59] <Sarvatt> did you remove the metapackages on your own before or did you try upgrading when things were broken to get this way?
[21:59] <Sarvatt> upgrading while it was broken removed video/input all for me every time
[22:00] <kees> not sure.  the -alls might have gone away for me during lucid.  :P
[22:01] <kees> ooooh, got to an installable state
[22:01] <kees> sudo apt-get install xserver-xorg-core xserver-xorg-input-all xserver-xorg-video-all xserver-xorg-video-intel xserver-xorg-video-nv
[22:02] <kees> that will let me install.
[22:02] <kees> makes me think this is an apt bug somehow
[22:03] <kees> purging xserver-xorg-video-nv seemed to do the trick.
[22:03] <kees> weird.
[22:04] <kees> thanks for all the help!
[22:05] <Sarvatt> really?!
[22:05] <Sarvatt> thats the exact same one that got me stuck 3 times
[22:06] <Sarvatt> but i thought it was my own packaging fault because I hacked it up locally
[22:14] <Sarvatt> so something that gets installed when xserver-xorg-core is in a broken has problems with something about nv
[22:28] <Sarvatt> i think you lucked out that nvidia-current isn't built against the new video abi yet because when i was in that exact situation it kept installing it when i had one that was :)