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