[00:00] <Prf_Jakob> So the basic noob question is how do I edit the package? Or can I magically make the dkms tool add it for me?
[00:01] <RAOF> Why don't you add the udev rule in the package which installs the dkms source?
[00:02] <Prf_Jakob> Yeah that was my plan, but I do know how to edit the .deb file?
[00:02] <Prf_Jakob> do not know*
[00:02] <RAOF> Why would you want to edit the .deb file?  Which .deb file?
[00:03] <Prf_Jakob> Right noob
[00:03] <Sarvatt> the packaging is all contained in the debian/ directory and you want to edit stuff there to alter how the package is built, debian/rules is what builds the package from source and if you want to add a udev rule that you have already you should be able to just add it as debian/vmwgfx.udev (replacing vmwgfx with whatever your source package name is)
[00:03] <Prf_Jakob> okay
[00:04] <Prf_Jakob> right the problem is that I used dkms to generate the package for me, it did all the debian magic.
[00:04] <Sarvatt> nice, i've never even heard of dkms mkdeb before
[00:04] <Sarvatt> it generated a source package for you?
[00:04] <Prf_Jakob> yeah
[00:04] <Sarvatt> you should be able to dpkg-source -x foo.dsc to extract it
[00:07] <Prf_Jakob> I don't have a *.dsc file, only a .deb
[00:08] <Sarvatt> ah looks like you need mkdsc instead of mkdeb to make a source package that you can go in and edit after
[00:10] <Prf_Jakob> Ah..
[00:14] <Prf_Jakob> Sarvatt: okay edited
[00:15] <Sarvatt> you'll probably need to name it foo-dkms.udev since it looks like it defaults to that package name
[00:16] <Sarvatt> debian/foo-dkms.udev rather
[00:20] <Sarvatt> after you edit the packaging you want to debuild -S -sa to make a new source package to do something with, or debuild -uc -us -b to make a .deb again (not sure what you're doing with it)
[00:25] <Prf_Jakob> oh yay a mail server!
[00:26] <Sarvatt> sudo apt-get purge postfix bsd-mailx :P
[00:26] <Sarvatt> hate that devscripts pulls that crap in
[00:28] <Sarvatt> or sudo apt-get --no-install-recommends install devscripts
[00:29] <Prf_Jakob> hmm okay..
[00:29] <Prf_Jakob> so I made a package, but I can't install it because it says I already have the package installed.
[00:29] <Prf_Jakob> But I purged it before
[00:29] <Prf_Jakob> After it fails I can purge it again.
[00:34] <Prf_Jakob> Ah there we go
[00:34] <Sarvatt> sudo apt-get purge foo fails to remove it? sudo dpkg -i foo.deb fails to install it? can you share the source package? I'd be more than happy to take a look at it and see whats going on and help clean it up some
[00:35] <Prf_Jakob> It didn't remove the /var/lib/dkms/vmwgfx/1.4.1 directory because it forgot about the dsc directory in there
[00:37] <Prf_Jakob> ah I probably need to add a dh_installudev to debian/rules as well?
[00:38] <RAOF> Depending on what sort of rules file dkms generates, yes.
[00:38] <Prf_Jakob> not one containing dh_installudev :)
[00:39] <RAOF> If it uses the “dh” tool then you wouldn't need it, but it's probably not that new :)
[00:49] <Sarvatt> RAOF: where would the dh_installudev go in /etc/dkms/template-dkms-mkdsc/debian/rules? just before dh_link in binari-indep?
[00:50] <RAOF> I'd put it next to the dh_install call, which I presume is in there somewhere.
[00:54] <Prf_Jakob> I only see dh_installdeb and dh_installdirs
[01:00] <Prf_Jakob> /lib/udev/rules.d/40-vmwgfx-dkms.rules
[01:01] <Prf_Jakob> \o/
[01:01] <RAOF> Woot!
[01:01] <Prf_Jakob> I added dh_installudev under the install target in rules
[01:02] <RAOF> Yeah, that'd fly :)
[01:04] <Prf_Jakob> do how do you guys manage packages like this?
[01:05] <Prf_Jakob> do you do a git-init in the package dir and just "git add debian && git commit" and thats it?
[01:05] <RAOF> http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html
[01:05] <RAOF> Generally something like that.
[01:08] <Prf_Jakob> errr
[01:09] <RAOF> That's the full toolchain thingy.  git add debian && git commit is what often happens on a day to day level :)
[01:19] <Prf_Jakob> ok
[01:25] <Sarvatt> if you git init in debian/ you need to pass -i -I to debuild when you build packages so the .git crap doesn't end up in the package
[01:25] <Sarvatt> or just add DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I" to ~/.devscripts
[01:26] <Sarvatt> (sorry popped out there, glad it worked!)
[01:27] <Sarvatt> there's no right way to do it, just whatever you prefer
[01:27] <Sarvatt> causes lots of headaches adopting other peoples workflows to update packages, thats for sure :)
[01:29] <Prf_Jakob> I'm just glad I have a package that I can use
[01:31] <Prf_Jakob> So where do specify the package version?
[01:31] <Prf_Jakob> debian/rules?
[01:32] <RAOF> debian/changelog
[01:32] <RAOF> The version of the most recent changelog entry is the version of the package.
[01:33] <Prf_Jakob> ah
[01:33] <RAOF> (dch is a useful tool for manipulating the changelog; I use emacs' debian-changelog mode for my stuff, though)
[01:34] <Prf_Jakob> hmm okay
[01:34] <Prf_Jakob> dch uses envar EDITOR?
[01:34] <RAOF> Yes.
[01:34] <Prf_Jakob> Yes it does
[01:34] <Sarvatt> yeah dch -i to make a new changelog entry and automatically bump the package version (although it almost always does it wrong)
[01:45] <Prf_Jakob> hehe so I noticed
[01:53] <Sarvatt> Prf_Jakob: there's probably a 50 page document somewhere on the debian policy regarding the version string, but basically x.y.z is the upstream version, the part after - is the debian revision of the package, and if that debian version is modified in ubuntu it gets a ubuntuX version added
[01:53] <Prf_Jakob> And if its vmw?
[01:53] <Prf_Jakob> VMware*
[01:53] <Prf_Jakob> do I add vmwX?
[01:53] <Prf_Jakob> I just went with rX
[01:53] <Prf_Jakob> for some reason
[01:54] <RAOF> Sarvatt: It's actually not very complicated :P http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
[01:55] <Sarvatt> RAOF: that totally omits things like x.y.z-2 being higher than x.y.z-2~vmw1 though, hmm
[01:55] <Sarvatt> oh no it doesnt
[01:55] <RAOF> Prf_Jakob: If you're not expecting to distribute it, or if it's not going to conflict with a package name in the Ubuntu archives then the only real constraint on versioning is that you want it to be strictly monotone increasing, and the tools will raise warnings if you have a native package (one without a -$SOMETHING component).
[01:56] <Prf_Jakob> RAOF: down the line I would like to make a ppa for it, now its just a internall thing.
[01:56] <RAOF> Sarvatt: It doesn't say it in so many words, but it *does* say that “~” sorts before everything, including the empty string.
[01:57] <RAOF> Prf_Jakob: Then you can go nuts with whatever versioning scheme you want :)
[06:02] <tjaalton> Sarvatt: and having 'DEBCHANGE_RELEASE_HEURISTIC="changelog"' in .devscripts makes dch a bit better when handling dvcs repos
[06:03] <tjaalton> no need to use -i
[08:03] <tjaalton> RAOF: do you know if *DM has been updated to the new '-background none' so patch 209 could be dropped from the server?
[08:04] <RAOF> tjaalton: No, they haven't.
[08:04] <tjaalton> is there a bug about it?
[08:05] <RAOF> I'm not sure.
[08:05] <tjaalton> ok
[08:05] <RAOF> Looking.
[08:06] <tjaalton> i'm bisecting our patches to see which one causes wacom button clicks to move the cursor around
[08:06] <tjaalton> not happening on upstream code
[08:06] <tjaalton> so I came across that one
[08:07] <tjaalton> sure it doesn't cause it :)
[08:08] <tjaalton> at least gdm hasn't changed
[08:08] <RAOF> :)
[08:08] <tjaalton> ubuntu_plymouth.patch still uses -nr
[08:17] <RAOF> tjaalton: Now filed as bug #806857
[08:17] <ubot4> Launchpad bug 806857 in lightdm (Ubuntu) (and 1 other project) "Plymouth integration should use upstream “-background none” option (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/806857
[08:19] <tjaalton> RAOF: thanks
[08:19] <tjaalton> I think kdm is not using -nr anymore
[08:19] <tjaalton> ScottK: can you verify ^
[08:21] <tjaalton> the changelog of kdebase-workspace is confusing, it's talking about 07_kdmrc_defaults_kubuntu.diff, but there is no such patch but kdmrc_defaults.diff which is commented out :)
[08:23] <tjaalton> and I guess lightdm hasn't used -nr
[09:42] <tjaalton> ok, disabling patches 200-> fixed the cursor jumping, but only a fraction of the tablet surface was usable. bisecting some more
[09:54] <tjaalton> yep, it's the multitouch patches that cause the cursor jumping
[10:22] <RAOF> Hurray! :/
[10:23] <RAOF> mikey_: So, what's broken? :)
[10:25] <mikey_> Well, I was hoping to sort out a strategy to do a second session in X that plays nice with ubuntu, at the moment it's a bit of a hack based on my outsider readings on X.
[10:26] <RAOF> mikey_: As in: run a second X server?
[10:27] <RAOF> And then the game in that second server?
[10:27] <mikey_> So basically all I do is utilise xinit to start a second X session along side the first and open openbox (I just chose this as something lightweight that didn't use Compiz) 
[10:28] <mikey_> And then it waits and opens a game on that
[10:28] <mikey_> It's pretty simple but avoids a lot of the problems you get with compiz
[10:29] <mikey_> There (just acording to poles of people using this strategy) is a slight performance boost over running it in one session
[10:30] <mikey_> Also the game is slightly sandboxed so any major crashes don't effect the first x session
[10:30] <RAOF> Right.
[10:30] <mikey_> The problem is that it has become increasingly opaque in ubuntu how to deal with the security and x session management features.
[10:31] <mikey_> So at the moment a commmand I use looks something like this:
[10:32] <mikey_> xinit '/tmp/tmp-xinitrc'  -- :1
[10:33] <mikey_> Where the tmp-xinitrc  has a session command like:
[10:33] <mikey_> exec ck-launch-session openbox-session
[10:34] <RAOF> Ah, right, yes.  ConsoleKit.
[10:35] <mikey_> I had to introduce that to deal with sound problems. 
[10:35] <mikey_> Now there's issues about whether a user level application can start a session at all 
[10:35] <jcristau> i wouldn't expect xinit from an existing X session to work, as a regular user?
[10:36] <mikey_> I can get arround it by getting people to turn on user level x session management but I don't know if that is a security risk
[10:36] <RAOF> I presumed there's an implicit sudo in there :)
[10:36] <mikey_> No
[10:36] <mikey_> Sorry I was typing as you were. Hope that explains where I am
[10:37] <RAOF> I think ck-launch-session is going to stop working properly, isn't it?  consolekit is starting to require the sessions be set up with all the trimmings - vt, display number, etc.
[10:37] <mikey_> Also there's a problem that when I exit openbox now something takes down the first x session as well
[10:38] <RAOF> What is “user level x session management” in this context?
[10:39] <mikey_> Sorry, you can tell X that users can start and stop sessions without sudo
[10:43] <mikey_> I'm just looking for the change now, as I can rememebr exactly which file you cange
[10:44] <RAOF> Right.  /usr/bin/X is setuid, and from memory the wrapper has some authorisation hooks.
[10:48] <mikey_> sudo dpkg-reconfigure x11-common
[10:48] <mikey_> and choose "anyone" to enable X privileges
[10:48] <RAOF> mikey_: I'm not entirely sure what you're looking to achieve.  We're not deliberately breaking this sort of thing, but its also not something that we (or many upstreams) particularly think of either.
[10:50] <mikey_> I was hoping to knock out a strategy that was more in keeping with the way that these things were intended to work. Since there is an issue with gaming on ubuntu. 
[10:50] <RAOF> The way that this *should* be fixed is by fixing whatever's wrong with compiz, basically.
[10:51] <mikey_> I've asked the compiz people a couple of years ago if they intended to make some workaround for games but nothing has been forthcoming.
[10:52] <RAOF> What is the actual problem?
[10:52] <mikey_> They said they were.
[10:53] <mikey_> Many games, particularly using Wine. Crash when run under Compiz or don't work at all
[10:55] <RAOF> Can you give some examples?  I've not run into any of these problems, but I haven't got a particularly extensive gaming library.
[10:56] <mikey_> Well, I've not tried many games under compiz for a while as I've been using my approach
[10:57] <mikey_> But I just started up the first game that came to mind Oblivion using wine
[10:57] <mikey_> and while it ran the fullscreen did not cover the unity pannel
[10:59] <RAOF> Ah, fullscreen.
[10:59] <RAOF> The state that X forgot.
[11:01] <RAOF> So, *that* is just a window management bug in compiz.
[11:02] <RAOF> And sometimes the way to have things fixed is to fix them.  There's not a huge difference in difficulty between fiddling around with running extra X sessions and fixing bugs in compiz.
[11:02] <mikey_> Same issue on other wine games (just checked) so a wine compiz issue. 
[11:03] <mikey_> In the past there've been issues where wine games were in fact transparent.
[11:04] <RAOF> And that was almost certainly a wine bug :)
[11:04] <mikey_> No compiz
[11:04] <mikey_> Well... compiz and maybe wine was misslabeling 
[11:05] <RAOF> Probably would have happened with another compositor too; wine was probably filling its windows with a transparent colour and not noticing because that only takes effect under a compositor.
[11:06] <mikey_> I think actually it was thinking the window was a menu
[11:06] <mikey_> as I had transparent menus at the time
[11:06] <RAOF> Possible, if you set up compiz to make menus transparent.
[11:08] <mikey_> But like I say, things may have change a lot over the last couple of years since I used wine games under compiz but increased crashes also were an issue. 
[11:09] <mikey_> The second session made that kind of problem no problem at all.
[11:10] <RAOF> Yeah, but it's not a particularly wonderful solution.  Specifically, it's not something that we'll do by default.
[11:10] <mikey_> OK.
[11:12] <mikey_> Can you give me any pointers to coping with session management if I continue to try to run an app that does this?
[11:13] <mikey_> So would you recommend not enabling user level session management on security grounds? 
[11:13] <RAOF> No, not particularly.
[11:14] <mikey_> Do you know what it is that is killing the first x session when I exit the second?
[11:14] <mikey_> I guess GDM
[11:14] <RAOF> I wouldn't think so, but it's possible I guess.
[11:14] <RAOF> You're not starting an X server that gdm knows about.
[11:15] <RAOF> It *might* be consolekit playing around on you.
[11:16] <mikey_> How is a session started properly under Ubuntu at the moment? (Or where can I read about it?)
[11:16] <RAOF> As I said, I think you're going to need to use something more clever than ck-launch-session soon
[11:17] <RAOF> mikey_: X servers are started by the display manager, as are login sessions; check the lightdm source for details, pretty much.
[11:18] <mikey_> Can I interact with the display manager to request a new session or do I need to reimplement what it's doing?
[11:19] <RAOF> You possibly could?  It'd be moderately involved, I think.
[11:22] <mikey_> OK. Thank you for your help
[12:34] <Sarvatt> RAOF: doh, thats a nasty mesa bug to have on the alpha 2 image
[13:00] <ScottK> tjaalton: I can't find any evidence of a plymouth related -nr and I do see a background being set in kubuntu_63_ksplash_fix.diff, but I'm not sure if that's the same background setting or not.
[13:00] <ScottK> So I think it's OK, but not sure.
[13:01] <tjaalton> ScottK: yeah, good
[17:47] <hyperair> Sarvatt: does sna in xorg-edgers somehow cause dri2 to stop working?
[19:06] <ricotz> Sarvatt, hello
[19:07] <ricotz> is it normal that the nvidia blob get broken a lot these days? or is my system messed up? rebuild the blob package solved the problem lately
[19:10] <Sarvatt> hyperair: nope shouldn't be related, if anything I might have messed up one of the packages for natty? can ya pastebin your Xorg.0.log?
[19:11] <hyperair> Sarvatt: Xorg.0.log shows dri2 present.
[19:11] <Sarvatt> ricotz: oneiric nvidia in the archive? I have no clue, still have yet to try it after the multiarch stuff but i've got an alpha 2 image downloading now
[19:11] <hyperair> Sarvatt: glxgears on the other hand... seems to not get redirected.
[19:11] <hyperair> Sarvatt: so when i move the glxgears window around, it gets left behind just like pre-dri2 times
[19:11] <hyperair> and when i activate some compiz animation it gets left behind as well
[19:12] <Sarvatt> hyperair: LIBGL_DEBUG=verbose glxinfo output please
[19:12] <Sarvatt> hyperair: hrm that got fixed recently
[19:12] <hyperair> eh?
[19:12] <hyperair> http://paste.debian.net/122245/
[19:12] <hyperair> also, wine seems to have artifacts with snb things.
[19:12] <Sarvatt> the glxgears sticking around until you stop moving the window got fixed recently
[19:12] <hyperair> i see
[19:12] <Sarvatt> hyperair: amd64 right
[19:12] <hyperair> yeah
[19:13] <Sarvatt> hyperair: you need to install the 32 bit mesa libs for it to work
[19:13] <hyperair> hmm
[19:13] <hyperair> does mesa support multiarch yet?
[19:13] <hyperair> in xorg-edgers?
[19:13] <Sarvatt> edgers and oneiric yeah
[19:13] <hyperair> oo nice.
[19:13] <Sarvatt> natty and oneiric in edgers
[19:13] <ricotz> ricotz, yes, the oneiric package, the glx module cant be loaded
[19:13] <ricotz> Sarvatt, °
[19:13] <ricotz> ^
[19:13] <ricotz> oops
[19:13] <hyperair> Sarvatt: do i need to get rid of ia32-libs?
[19:13] <Sarvatt> hyperair: nope it shouldn't even look for things where that gets installed anymore
[19:14] <hyperair> okay.
[19:14] <Sarvatt> hyperair: add uhh
[19:14] <Sarvatt> foreign-architecture i386 to /etc/dpkg/dpkg.conf
[19:14] <hyperair> something foreign..
[19:14] <hyperair> aha
[19:14] <hyperair> okay
[19:14] <hyperair> and apt?
[19:14] <Sarvatt> then sudo apt-get update and sudo apt-get install libgl1-mesa-dri:i386
[19:15] <Sarvatt> hopefully it'll pull everything it needs in
[19:15] <hyperair> okay
[19:15] <hyperair> let's see..
[19:15] <hyperair> aptitude update doesn't seem to be pulling in i386 things
[19:15] <hyperair> i think some apt option is also needed.
[19:16] <jcristau> Sarvatt: err, why is that needed for glxgears/compiz?
[19:16] <Sarvatt> ricotz: to be honest i haven't even looked at multiarch on the blobs yet and am not sure whats going on, got an image downloading to install on my nvidia box right now
[19:16] <Sarvatt> it isn't, was for wine
[19:16] <jcristau> ah.
[19:16] <hyperair> Sarvatt: Apt::Architectures
[19:16] <jcristau> i knew i was missing something :)
[19:17] <Sarvatt> he's using software rendering and getting artifacts, but i'm sure he wants to be using hardware acceleration so needs the 32 bit stuff :P
[19:17] <jcristau> ack
[19:17] <ricotz> Sarvatt, ok :)
[19:17] <Sarvatt> glxinfo looks fine there hyperair, the glxgears problem you mentioned was fixed last week sometime though, have you not restarted X in a week?
[19:18] <hyperair> Sarvatt: nah, my laptop just locked up and i've restarted
[19:18] <hyperair> stupid mode switching
[19:18] <Sarvatt> hyperair: ugh you said natty right?
[19:18] <hyperair> yea natty
[19:18] <Sarvatt> hyperair: hopefully it wasn't a compiz update in oneiric that fixed it then..
[19:18] <hyperair> ._.
[19:18] <hyperair> hmmmmmmmmmmmmmmmm
[19:19] <hyperair> lemme poke smspillaz.
[19:19] <hyperair> oh wait he's in the same timezone as me. probably asleepn ow
[19:20] <Sarvatt> i dont know what fixed it, mentioned it to ickle and went off to dublin and it was fixed sometime last week in the updates
[19:22] <hyperair> hmm
[19:22] <hyperair> i see.
[19:23] <Sarvatt> err maybe it was http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=b460b9645451af84136c5daebbc00c7545de67f4
[19:23] <Sarvatt> whats your x-x-v-intel version
[19:25] <Sarvatt> 2:2.15.0+git20110706.0be47f45-0ubuntu0sarvatt here
[19:31] <Sarvatt> i'd put money on it being an old xserver-xorg-video-intel, that problem started with http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=c3b1a0d7046a83b6daec03e5a562116e3adf3c71
[19:43] <hyperair> *** 2:2.15.0+git20110706.0be47f45-0ubuntu0sarvatt~natty 0
[19:43] <hyperair> Sarvatt: ^^
[19:54] <hyperair> Sarvatt: urgh, multiarch on natty seems pretty broken.
[20:00] <Sarvatt> hyperair: I feared as much :( you're the first person i've spoken to that's tried it, guess i'll  be dropping multiarch and forking the packaging for crap to keep natty up to date in the end..
[20:01] <hyperair> heh
[20:15] <Sarvatt> ricotz: so what are you doing when it dies? you said it happened when you upgraded stuff?
[20:15] <Sarvatt> looks like its working ok here
[20:22] <Sarvatt> ricotz: nevermind reproduced it, filing a bug
[20:25] <ricotz> Sarvatt, what is the problem?
[20:34] <bjsnider> ricotz, howcome not many gnome3 updates for natty recently?
[20:36] <Sarvatt> ricotz: not sure yet, this is a mess
[20:36] <Sarvatt> http://bugs.launchpad.net/bugs/807209
[20:36] <ubot4> Launchpad bug 807209 in nvidia-graphics-drivers (Ubuntu) "Lost glx after first upgrade from oneirc alpha 2 install (affects: 1) (heat: 6)" [Undecided,New]
[20:39] <ricotz> Sarvatt, alright, i will follow it, i suspected binutils (pulled from thin air ;))
[20:40] <ricotz> bjsnider, hmm, it isnt planned to update it to 3.1.x -- it would need a whole lot of unstable updates
[20:40] <Sarvatt> Setting up libgl1-mesa-glx (7.11~1-0ubuntu3) ...
[20:40] <Sarvatt> update-alternatives: renaming x86_64-linux-gnu_xorg_extra_modules slave link from /usr/lib/xorg/extra-modules to /usr/lib/x86_64-linux-gnu/xorg/extra-modules.
[20:40] <Sarvatt> hrm
[20:40] <Sarvatt> xserver is still trying to load from /usr/lib/xorg/extra-modules first
[20:41] <ricotz> bjsnider, and might break a lot other things after G_CONST_RETURN and new gtk+3 deprecations
[20:42] <ricotz> Sarvatt, hmm, it could have happen on mesa updates
[20:42] <ricotz> brb
[20:42] <Sarvatt> yeah that makes sense
[20:42] <Sarvatt> [     8.172] (==) ModulePath set to "/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules"
[20:45] <Sarvatt> whats up with apport being useless btw
[20:45] <Sarvatt> bryceh: ?
[20:45] <bryceh> Sarvatt, ?
[20:46] <Sarvatt> didn't attach anything to that bug i just filed
[20:46] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/807209
[20:46] <ubot4> Launchpad bug 807209 in nvidia-graphics-drivers (Ubuntu) "Lost glx after first upgrade from oneirc alpha 2 install (affects: 1) (heat: 6)" [High,New]
[20:46] <bryceh> ah, nvidia
[20:46] <bjsnider> Sarvatt, so then if you reinstall nvidia-current the problem should be fixed, if it's only broken alternatives
[20:47] <bryceh> Sarvatt, were there any error messages printed to console?
[20:47] <Sarvatt> darn i've already rebooted since then but i dont believe so
[20:47] <bryceh> Sarvatt, do you have xdiagnose installed?
[20:48] <Sarvatt> it was a clean install, not sure, let me hook it back up
[20:48] <bryceh> Sarvatt, try filing a bug against xorg or xserver-xorg-video-intel and see if that works properly
[20:48] <bryceh> Sarvatt, aside from the move from xorg to xdiagnose I haven't uploaded any changes to the apport hooks
[20:49] <bryceh> they've been working ok in my tests but some of the changes could easily break things in specific cases (i.d. proprietary drivers)
[20:51] <Sarvatt> bryceh: yep no xdiagnose on an alpha 2 install
[20:52] <bryceh> ok, so that's probably what the problem is
[20:52] <bryceh> maybe xorg needs to depend on xdiagnose more forcefully?
[20:53] <bryceh> tjaalton, ^^?
[20:54] <Sarvatt> xserver-xorg should depend on it no?
[20:54] <Sarvatt> oh xorg instead
[20:55] <Sarvatt> thats what ubuntu-desktop depends on, and that pulls in x11-common, which has a recommends for xdiagnose that isn't getting pulled in
[20:55] <bryceh> yeah
[20:56] <bryceh> why would it not pull in an x11-common recommend?
[20:56] <Sarvatt> only pulls in recommends of things it depends on directly maybe?
[20:57] <bryceh> maybe slangasek would know
[21:01] <bryceh> Sarvatt, anyway, meanwhile, can you manually install xdiagnose and confirm then that bugs are reported correctly?
[21:01] <Sarvatt> bryceh: xorg depends on xfonts-scalable and that isn't pulled in either so i guess it should just be moved to depends
[21:01] <Sarvatt> sure one sec i'll file a new one
[21:01] <bryceh> I'm going to upload a new xdiagnose 0.7 probably early next week, with some semi-substantial changes
[21:04] <Sarvatt> bryceh: yep it works, updated that bug
[21:04] <Sarvatt> btw its in universe still
[21:04] <bryceh> ??
[21:05] <Sarvatt> it downloaded xdiagnose from universe
[21:05] <bryceh> maybe that's why it didn't get pulled in?
[21:05] <Sarvatt> .proc.driver.nvidia.gpus.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/0'
[21:05] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/807209 apport info on that
[21:05] <ubot4> Launchpad bug 807209 in nvidia-graphics-drivers (Ubuntu) "Lost glx after first upgrade from oneirc alpha 2 install (affects: 1) (heat: 8)" [High,New]
[21:06] <Sarvatt> cursor theme in use? that might be a bit too much info :)
[21:07] <bryceh> Jun 18 00:04:26 <bryce> tjaalton, btw on upgrading to latest I notice xorg didn't pull in xdiagnose; does it need stro\
[21:07] <bryceh> nger than Recommends?
[21:07] <bryceh> Jun 18 00:05:36 <tjaalton>      bryce: it is, and it got installed here though
[21:07] <bryceh> Jun 18 00:05:44 <bryce> hmm
[21:07] <bryceh> Jun 18 00:05:53 <tjaalton>      recommends should be enough
[21:07] <bryceh> Jun 18 00:06:35 <tjaalton>      if your apt is configured to install recommended packages (which is on by default sinc\
[21:07] <bryceh> e a couple of years)
[21:07] <Sarvatt> maybe the installer uses different defaults
[21:08] <bryceh> Jun 18 00:07:09 <bryce> total defaults on this system, fresh install as of 2 days ago
[21:08] <bryceh> Jun 18 00:07:15 <tjaalton>      ok
[21:08] <bryceh> Jun 18 00:07:29 <tjaalton>      I'll check my logs
[21:08] <bryceh> Jun 18 00:08:15 <tjaalton>      ah I had it installed already
[21:09] <bryceh> but we didn't look into it  beyond that :-/
[21:19] <Sarvatt> bryceh: cool beans, just sucks we're going to get a bunch of alpha 2 bugs with no apport info :P
[21:19] <bryceh> maybe
[21:21] <bryceh> this might explain why we've got relatively few gpu hang bugs on -intel
[21:22] <Sarvatt> for sure
[21:23] <bryceh> not a big deal; we'll get plenty more soon
[21:24] <cnd> bryceh, RAOF: every time I try lightdm it fails to work for me
[21:24] <cnd> mouse and kb don't work
[21:25] <cnd> I found out today that the X server doesn't have any input devices
[21:25] <cnd> it does under gdm though
[21:25] <Sarvatt> cnd: i had to pin udev to the natty version on one of my machines to get around that.. :(
[21:25] <bryceh> cnd, hmm worked for me when I poked at it last week
[21:25] <cnd> Sarvatt, interesting...
[21:25] <cnd> Sarvatt, I'll try that out
[21:26] <Sarvatt> cnd: got an ssd in that machine?
[21:26] <cnd> Sarvatt, no
[21:26] <bryceh> there have been some bug reports about with lightdm, it'll make X SIGQUIT when you first hit a '2' or enter
[21:26] <Sarvatt> ok that was my running guess, booting too fast since it doesn't happen on a second identical e6420 minus the SSD
[21:28] <Sarvatt> i should have swapped the drives before giving it to RAOF to see if it had the same problem
[21:30] <cnd> Sarvatt, natty udev doesn't help...
[21:31] <cnd> $ sudo udevadm trigger
[21:31] <cnd> that makes it work
[21:31] <cnd> well, it made mouse work
[21:31] <Sarvatt> err yeah, no keyboard or anything before lightdm starts and can't interact with the system at all, thats different from when lightdm didn't give me devices
[21:31] <cnd> kb doesn't...
[21:32] <Sarvatt> sorry, got the symptoms confused, i had the lightdm problem a long time ago and it fixed itself about 3 weeks ago
[21:32] <cnd> my kb doesn't come up, perhaps because there's no udev event for it?
[21:37] <cnd> so now gdm won't come up
[21:37] <cnd> and lightdm is still broken...
[21:37] <bryceh> anything in /var/log/gdm /var/log/lightdm of relevance?
[21:38] <cnd> which log file should I look in in /var/log/gdm?
[21:38] <bryceh> like :0.log
[21:38] <Sarvatt> dont suppose there's anything useful in /var/log/lightdm/lightdm.log?
[21:38] <Sarvatt> err guess i should read scrollback before asking lol
[21:38] <bryceh> also, sorry if you already mentioned it but does keyboard work on vt console?
[21:39] <Sarvatt> he probably cant even switch to a vt to check
[21:39] <bryceh> oh true
[21:39] <Sarvatt> i couldn't when i had that problem
[21:39] <cnd> I'm ssh'd in, so I can chvt
[21:39] <bryceh> cnd, umm...  ok so presumably you can get into grub on boot?  can you boot into a recovery session and just verify kernel input is working outside X?
[21:40] <cnd> I can type into a vt
[21:40] <bryceh> ok
[21:40] <cnd> I know kernel input works
[21:40] <cnd> or at least it did until I dist-upgraded today
[21:40] <cnd> and I've had the lightdm issue for quite some time
[21:40] <bryceh> ah ok, guess I missed that
[21:41] <bryceh> maybe I should back up and ask, what have you narrowed the problem down to?
[21:41] <Sarvatt> cnd: does it work if like, you boot with text instead of splash into recovery and continue past that to skip all the plymouth stuff?
[21:41] <cnd> hmmm, RAOF did stuff to this machine at the sprint
[21:41] <cnd> said he took off fglrx
[21:41] <cnd> but something seems odd
[21:42] <cnd> well, I thought maybe he didn't remove the fglrx lines from Xorg.conf, but I think I'm just seeing a standard error about not finding fglrx
[21:42] <bryceh> "did stuff" - do you mean, with the objective of fixing input?  or that the input breakage started after that?
[21:42] <bryceh> yeah that's innocuous
[21:42] <cnd> no, with the objective of fixing 3d so unity would run :)
[21:42] <bryceh> if fglrx is removed you shouldn't need xorg.conf
[21:43] <cnd> hmm, from dmesg:
[21:43] <cnd> [  395.259525] gdm-simple-slav[1310]: segfault at 0 ip 00007f89d2fc9f15 sp 00007fff4ec516f0 error 4 in libnss_compat-2.13.so[7f89d2fc6000+8000]
[21:43] <bryceh> I wouldn't think that would affect input
[21:44] <cnd> yeah, I think that's the cause of gdm not working
[21:44] <cnd> well, I have two issues now
[21:44] <cnd> input doesn't work in lightdm
[21:44] <cnd> and gdm doesn't work at all
[21:44] <cnd> so this segfault is likely the issue for gdm
[21:44] <cnd> but I still don't know what's up with lightdm
[21:45] <bryceh> ok, the gdm issue sounds unrelated to X, but I'm curious about the lightdm issue
[21:45] <bryceh> did you spot anything pertinent in the lightdm logs?
[21:45] <cnd> nothing I can tell
[21:46] <cnd> but the log is so short
[21:46] <bryceh> also, did the input breakage start after RAOF's changes or before?
[21:46] <cnd> :0.log that is
[21:46] <Sarvatt> cnd: encrypted home directory?
[21:46] <cnd> I dunno if they're filtering out warning messages?
[21:46] <cnd> Sarvatt, no encryption
[21:46] <cnd> bryceh, the input breakage has existed ever since I upgraded to natty
[21:46] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/805154
[21:46] <cnd> about a month ago
[21:46] <ubot4> Launchpad bug 805154 in gdm (Ubuntu) "gdm-simple-slave crashed with SIGSEGV in _nss_compat_getpwnam_r() (affects: 13) (dups: 6) (heat: 88)" [Medium,Triaged]
[21:46] <cnd> Sarvatt, thanks!
[21:47] <Sarvatt> oddly i had the lightdm no input thing and used gdm for a week and it was fixed by the first lightdm upgrade in june where i switched back
[21:48] <cnd> so I can fix the lightdm issue for mice by calling udevadm trigger
[21:48] <cnd> but kb still doesn't work
[21:50] <Sarvatt> after you run udevadm trigger does the keyboard work if you stop and start lightdm again?
[21:50]  * Sarvatt is out of ideas :P
[21:51] <cnd> nope
[21:51] <cnd> where's the udev code in xorg-server?
[21:52] <cnd> I can't remember
[21:52] <bryceh> pastebin your Xorg.0.log and xinput stuff
[21:52] <Sarvatt> config/udev.c
[21:54] <cnd> bryceh, log: http://paste.ubuntu.com/639763/
[21:54] <cnd> oops, wrong log
[21:55] <cnd> wait, that's the right one
[21:55] <cnd> I have a phantom X server running
[21:56] <cnd> bryceh, xinput list: http://paste.ubuntu.com/639764/
[21:56] <cnd> now it shows the AT translated keyboard
[21:56] <cnd> but it doesn't work...
[21:56] <cnd> using xinput test-xi2 I get raw key press and releases
[21:57] <cnd> bryceh, so apparently I get KeyRelease, but not KeyPress events
[21:58] <cnd> there's somethign in the server that is witholding keypress
[21:58] <cnd> now that I think of it, I had the same problem way back in natty
[21:58] <cnd> when I was running xorg-edgers
[21:58] <cnd> there was a change to something related to keyboard support
[21:58] <cnd> like xkb stuff
[21:58] <cnd> and it caused this
[21:58] <bryceh> hmm
[21:58] <cnd> so perhaps now oneiric is updated to whatever was broken when I was running xorg-edgers before
[21:59]  * cnd was hoping it was a fluke...
[22:00] <cnd> back then I tried to step through the server to figure it out
[22:00] <cnd> and I got lost
[22:00] <cnd> that's not a good sign...
[22:00]  * bryceh browses through xserver patches
[22:00] <cnd> I got into the xkb stuff and I had no clue what was going on
[22:00] <bryceh> 208_switch_on_release.diff ?
[22:01] <bryceh> that fiddles with keypress behavior... roughly around the timeframe you mention... maybe try disabling that
[22:01] <cnd> bryceh, ok, I'll try it
[22:02] <bryceh> although, you mentioned you have a phantom X session?  Could it be stealing keyboard input?
[22:02] <cnd> I killed it
[22:02] <cnd> but this occurs when it's a clean boot
[22:02] <cnd> so I don't think that's it
[22:03] <bryceh> ok
[22:04] <cnd> ok, time to take the dog out while it compiles :)
[22:04] <bryceh> yeah that's the only xserver patch that looks close to relevant
[22:04] <bryceh> cnd, oh btw would appreciate your look at 504_exevent_proximity_null_ptr_check.patch some time
[22:21] <cnd> bryceh, where's that patch?
[22:22] <bryceh> xorg-server-git-ubuntu/debian/patches/208_switch_on_release.diff
[22:22] <cnd> bryceh, no, the one you want me to look at?
[22:24] <bryceh> cnd, https://bugs.launchpad.net/ubuntu/+bug/764700
[22:24] <ubot4> Launchpad bug 764700 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in utouch_frame_sync() (affects: 1) (heat: 14)" [High,Triaged]
[22:26] <cnd> bryceh, that's not related to any multitouch or gesture stuff right?
[22:27] <cnd> the patch seems fine, but I don't understand why there would be proximity events for a device without a proximity class
[22:29] <bryceh> cnd, yeah the backtrace the guy posted doesn't match to what he mentioned earlier that involved utouch
[22:29] <bryceh> but it's not obvious why it would fail on the proximity stuff
[22:29] <cnd> bryceh, the only note I'd make is that the 5xx serios of patches are intended to be gesture/multitouch
[22:30] <cnd> and this isn't
[22:30] <bryceh> anyway, guess we can see what the user finds testing it
[22:30] <cnd> so should it be a 2xx patch?
[22:31] <bryceh> yeah, but that'd require redoing the MT patches
[22:31] <bryceh> (I think)
[22:31] <bryceh> if the patch pans out, we could do that; not worth the bother until we know if it works
[22:32] <cnd> yeah
[22:32] <cnd> I didn't think that patch touched the MT stuff
[22:32] <bryceh> cnd, btw looking at your Xorg.0.log it appears you have two keyboards?
[22:32] <cnd> no, only one
[22:32] <cnd> what is the second kb you see?
[22:33] <bryceh> one appears to be attached to event4, the other is on event3
[22:33] <bryceh> [   925.109] (II) HID 413c:8161: Configuring as keyboard
[22:33] <bryceh> [   925.109] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.0/input/input4/event4"
[22:33] <bryceh> [   925.109] (II) XINPUT: Adding extended input device "HID 413c:8161" (type: KEYBOARD)
[22:33] <bryceh> and
[22:33] <bryceh> [   925.280] (II) config/udev: Adding input device AT Translated Set 2 keyboard (/dev/input/event3)
[22:33] <bryceh> [   925.280] (**) AT Translated Set 2 keyboard: Applying InputClass "evdev keyboard catchall"
[22:33] <bryceh> [   925.280] (II) Using input driver 'evdev' for 'AT Translated Set 2 keyboard'
[22:33] <cnd> not sure what that is
[22:33] <cnd> the first one
[22:34] <bryceh> bet it's some other device being mis-detected as a keyboard
[22:34] <cnd> yeah
[22:34] <bryceh> the touchscreen maybe?
[22:35] <cnd> bryceh, http://www.linux-usb.org/usb.ids says it's a Dell Integrated Keyboard
[22:35] <bryceh> [   925.108] (**) HID 413c:8161: Applying InputClass "evdev keyboard catchall"
[22:35] <cnd> it could be the extra function keys at the top
[22:35] <cnd> media buttons
[22:35] <bryceh> mm, yeah that seems more likely
[22:36]  * bryceh thinks
[22:37] <bryceh> well, I'm sketchy on if it's even a problem, but maybe try putting in a udev rule to disable or switch drivers on that, and see if things work any better?
[22:38] <bryceh> cnd, do the media keys do anything?  :-)
[22:39] <bryceh> I wonder if xinput --remove-master would do anything useful
[22:40] <bryceh> cnd, anyway, that's my guess as to the problem.  probably Xi or evdev messing up
[22:42] <cnd> bryceh, removing that patch didn't help :(
[22:42] <cnd> bryceh, I think it's inside the server since I'm getting keyrelease but not keypress
[22:42] <cnd> I do see rawkeypress though
[22:42] <cnd> so the keypress events are being sent to the server
[22:42] <cnd> they're just being dropped somewhere
[22:43] <bryceh> hmm
[22:46] <tjaalton> Sarvatt, bryceh: if xdiagnose is in universe there's no way it's going to be installed by default. My desktop got installed as natty, enabled universe and this week upgraded to oneiric; xdiagnose got pulled in like it should
[22:46] <bryceh> tjaalton, it wasn't seeded.  cjwatson fixed it for  us about an hour ago
[22:46] <tjaalton> bryceh: ah good, well it had to move to main first?
[22:48] <tjaalton> so it seems
[22:48] <bryceh> tjaalton, yeah apparently there's multiple levers to be pulled, and I closed the MIR before the last one had been pulled
[22:48] <tjaalton> right
[22:48] <tjaalton> cnd: testing your xserver now :)
[22:49] <bryceh> tjaalton, any ideas on where to go with debugging cnd's missing keypresses?  Sarvatt and I are out of clues
[22:49] <bryceh> xtrace wouldn't be useful in this case, would it?
[22:50] <tjaalton> well, if cnd can't figure it out how could I :)
[22:50] <bryceh> tjaalton, so you think he should speak with our resident X input expert, eh?
[22:51] <tjaalton> skimmed through the backlog pretty quickly, I'll have another look after this wacom test
[22:51] <tjaalton> bryceh: well.. :)
[22:52] <bryceh> that's the problem with learning too much about X.org
[22:52] <RAOF> If the keypresses are being eaten in the server...
[22:52] <bryceh> you learn too much and then when you run into X problems you get referred back to yourself
[22:52] <tjaalton> but, I've never heard of that happening.. sounds really weird
[22:54] <cnd> yeah, I'm perplexed
[22:55] <bryceh> cnd,  xinput list --long | pastebinit
[22:55] <cnd> probably the worst place to have a bug in the xserver is in keyboard handling :)
[22:55] <cnd> based on what I've heard of xkb
[22:55] <RAOF> There does seem to be some oddness there; your various jack devices seem to keep confusing evdev and causing it to unload.
[22:56] <bryceh> otoh with keyboard bugs there's a fair chance of a pre-existing patch out there
[22:56] <cnd> bryceh, http://paste.ubuntu.com/639789/
[22:56] <RAOF> I'd just like to assert that everything was working fine when I handed it back to cnd at the sprint :P
[22:56] <tjaalton> cnd: wacom fixed!
[22:56] <cnd> RAOF, I had it using gdm :)
[22:56] <cnd> tjaalton, \o/
[22:57] <cnd> this is a lightdm issue
[22:57] <bryceh> interesting - http://people.freedesktop.org/~whot/evtest/
[22:57] <tjaalton> cnd: whot gave me some ideas earlier today, so I tried to backport some stuff from master, but it turned out to bee a bit too complex trying to match it with this version
[22:57] <tjaalton> bryceh: apt-get install evtest
[22:58] <cnd> tjaalton, for handling the wacom issue?
[22:58] <tjaalton> cnd: yeah
[22:58] <tjaalton> I think this case is handled in master
[22:58] <cnd> yeah, anything dealing with cursor or mouse input doing weird stuff likely can't be helped by whot until we get XI 2.1 merged upstream :(
[22:58] <tjaalton> but the functions have changed too much, and soon it became minigolf time so I gave up
[22:58] <cnd> heh
[23:11] <cnd> tjaalton, bryceh, RAOF: I can't seem to push a commit to git.debian.org
[23:11] <cnd> did the alioth switchover affect ssh access?
[23:12] <tjaalton> cnd: check your .git/config, change the host to git.d.o
[23:12] <tjaalton> then it should work
[23:13] <cnd> tjaalton, everything looks good there...
[23:13] <tjaalton> hmm, .ssh/known_hosts then?
[23:13] <cnd> and I can't ssh to git.debian.org like I used to be able to
[23:13] <tjaalton> what does it complain?
[23:13] <cnd> Permission denied (publickey).
[23:13] <cnd> fatal: The remote end hung up unexpectedly
[23:13] <bryceh> generic error
[23:14] <bryceh> cnd, tried checking out a fresh new branch and pushing from that?
[23:14] <tjaalton> that error is from ssh though
[23:14] <cnd> bryceh, my remote url is set up correctly
[23:15] <cnd> and the error does seem to come from ssh
[23:15] <tjaalton> could you paste that nevertheless :)
[23:15] <cnd> oh wait...
[23:15] <cnd> I'm cndougla-guest on alioth
[23:15] <cnd> cause of their weird username rules
[23:15] <tjaalton> right
[23:16] <tjaalton> but surely you've pushed there before?
[23:16] <tjaalton> not from the same machine?
[23:16] <cnd> aha, it worked!
[23:17] <cnd> ok, I managed to get *something* done today :)
[23:18] <cnd> I hate being blocked by silly things like keyboard not working
[23:18] <tjaalton> hehe :)
[23:19] <cnd> bryceh, I just committed a patch as 504
[23:19] <cnd> just fyi
[23:21] <tjaalton> so the kbd works in a vt?
[23:22] <cnd> yeah
[23:25] <tjaalton> hum, you tested with gdm already, noticed that you said it happens only with lightdm?
[23:25] <tjaalton> uh, nonsentence
[23:26] <tjaalton> getting late!
[23:26] <cnd> tjaalton, it used to work in gdm, when gdm actually worked
[23:26] <cnd> gdm doesn't work anymore
[23:26] <tjaalton> oh, works here though
[23:26] <cnd> that's great :)
[23:26] <tjaalton> just start plain x with xterm
[23:26] <tjaalton> isn't it :)
[23:27] <cnd> anyone know how to manually start my normal user session?
[23:27] <cnd> something like startx
[23:28] <RAOF> xinit gnome-session ?
[23:28] <tjaalton> yeah that might work
[23:28] <cnd> I'm not authorized
[23:29] <cnd> but sudo xinit unity is coming up
[23:29] <cnd> I'm sure it's running as the root user though...
[23:30] <cnd> oh what failure...
[23:30] <tjaalton> xinit -- gnome-session :1
[23:30] <tjaalton> as the user
[23:30] <tjaalton> without 'gnome-session' it just runs an xterm
[23:31] <tjaalton> didn't try with g-s
[23:31] <cnd> as root?
[23:31] <tjaalton> no wait
[23:31] <tjaalton> xinit gnome-session -- :1
[23:31] <tjaalton> use your username
[23:31] <tjaalton> uh
[23:31] <tjaalton> non-root
[23:31] <tjaalton> :)
[23:32] <cnd> hmm?
[23:32] <tjaalton> does 'xinit -- :1' work?
[23:32] <cnd> not as myself
[23:32] <cnd> only as root
[23:32] <tjaalton> oh
[23:33] <tjaalton> is lightdm running
[23:33] <tjaalton> ?
[23:33] <cnd> I'm trying to get around lightdm
[23:33] <cnd> or are you saying I can run lightdm first
[23:33] <tjaalton> yes, separate xservers
[23:33] <cnd> and then run something else to kick it through to my desktop?
[23:34] <tjaalton> maybe xinit works since I have my real desktop running too
[23:34] <tjaalton> dunno..
[23:35] <cnd> is there another lightweight DM I can run?
[23:35] <tjaalton> xdm
[23:35] <cnd> of course :)
[23:35] <tjaalton> lightestdm
[23:35] <tjaalton> +''
[23:36] <cnd> gah!
[23:36] <cnd> no kb there either
[23:36] <tjaalton> ouch
[23:36] <cnd> somewhere the dev gods are pointing and laughing...
[23:37] <tjaalton> check /etc/default/keyboard, does it have the XKB*-values on it?
[23:37] <cnd> yeah
[23:38] <tjaalton> I can run xinit just fine even without any X running, as a user
[23:38] <tjaalton> anyway..
[23:38] <cnd> hmm
[23:38] <cnd> tjaalton, what groups are you a part of?
[23:39] <tjaalton> adm dialout cdrom plugdev lpadmin admin sambashare
[23:39] <tjaalton> some of which I've added myself
[23:39] <cnd> nothing there stands out
[23:39] <tjaalton> plugdev is maybe the most useful of them
[23:41] <RAOF> tjaalton: Have you configured x11-common to allow unfettered access to the X server?  It's got 3 settings - root, at console, and everyone.
[23:41] <tjaalton> RAOF: good point, console. I think it's the default?
[23:43] <tjaalton> cnd: run 'xinit xev', see if X thinks it gets any events from the keyboard
[23:43] <cnd> RAOF, just found that through a google search
[23:43] <cnd> I was able to get to an xterm
[23:43] <cnd> xev gives keypress and keyrelease
[23:43] <cnd> what's the unity 2d session called?
[23:44] <tjaalton> unity-2d
[23:44] <tjaalton> ah
[23:44] <tjaalton> gnome-session --session=ubuntu-2d
[23:44] <cnd> hmm, "xinit unity-2d" didn't work
[23:45] <tjaalton> so plain xterm works?
[23:45] <cnd> tjaalton, yes
[23:45] <cnd> now I need to figure out how to set the session using xinit
[23:45] <cnd> xinit gnome-session --session=ubuntu-2d doesn't work
[23:46] <cnd> bad command line option
[23:46] <tjaalton> yeah, put -- in between
[23:46] <cnd> then it thinks it's a server option
[23:46] <cnd> well, put '--' in between where?
[23:46] <tjaalton> xinit gnome-session -- --session=ubuntu-2d
[23:46] <cnd> yeah, then it thinks it's a server option
[23:47] <tjaalton> according to the manpage that should be ok
[23:47] <tjaalton> oh
[23:47] <tjaalton> argh, right
[23:48] <bryceh> xinit gnome-session -- /usr/bin/X --session=ubuntu-2d  ?
[23:48] <cnd> I think I got it
[23:48] <cnd> I made a shell script
[23:48] <tjaalton> cnd: just put 'gnome-session --session=ubuntu-2d' in your .xinitrc
[23:48] <tjaalton> right
[23:48] <cnd> and put "gnome-session --session=ubuntu-2d"
[23:49] <cnd> and did xinit <script>
[23:49] <tjaalton> yep
[23:49] <cnd> ok, I finally have a desktop again
[23:49] <cnd> now I can get back to work
[23:49] <tjaalton> and if you put that as ~/.xinitrc you'd start it with just 'xinit'
[23:50] <cnd> why does ubuntu one *always* crash
[23:50] <cnd> all the time, incessantly
[23:50] <tjaalton> so keyboard in gnome works too, meaning it's just lightdm that refuses to work?
[23:50] <cnd> and the "ignore future crashes" thing doesn't work
[23:50] <cnd> I think it's just lightdm and xdm
[23:50] <tjaalton> ok
[23:51] <tjaalton> still, weird
[23:51] <RAOF> I wonder if lightdm starts the server in a particularly weird way?