[00:09] <Sarvatt> darn, it might have been good to mention somewhere like the changelog about the changes to DontZap handling with the updated xkeyboard-config bryce :D
[00:10] <Sarvatt> should I add it to the wiki maybe for the release notes?
[00:12] <Sarvatt> just having DontZap in xorg.conf isnt good enough to enable it anymore, need to setxkbmap -option terminate:ctrl_alt_bksp (you can map it to other things now as well and enable/disable in userspace)
[00:12] <bryce> Sarvatt: erf forgot about that
[00:12] <bryce> Sarvatt: yeah definitely need to get that documented
[00:13] <bryce> in fact I wonder if we ought to transition people... check if it is set in xorg.conf and then turn the option on for people
[00:13] <bryce> hrm
[00:17] <Sarvatt> thats a really good idea
[00:29] <james_w> we should make the dontzap package do the right thing as well
[01:03] <Sarvatt> its a checkbox option in the keyboard layout options now, would we even need the dontzap package anymore?
[01:04] <Sarvatt> "Key sequence to kill the X server"
[01:14] <Sarvatt> sent tseliot an email with a heads up about it getting updated in karmic today
[02:13] <bryce> Sarvatt: thanks
[02:14] <bryce> yeah the dontzap package becomes redundant
[02:14] <bryce> but it may still be of benefit in some cases
[02:14] <bryce> good to email alberto, he can take a look and decide.
[03:13] <hyperair> Sarvatt: i fell asleep waiting for fsck to finish (god knows why it triggered, i restarted it properly damnit! and i just fscked less than a frigging day ago! stupid ext4 >=( ), but anyway  the stuff you told me to add to modules resulted in the black screen occurring *before* i could even type in my cryptsetup password
[03:13] <hyperair> cryptroot password i mean
[03:13] <hyperair> so i had to type it in blindly
[03:13] <hyperair> heh
[03:13] <Sarvatt> ah, how about booting with video=fbcon?
[03:18] <hyperair> Sarvatt: hmm i'll try that. kernel parameter right
[03:18] <Sarvatt> probably something to do with the whole cryptloop stuff :D
[03:18] <hyperair> Sarvatt: it doesn't blank out if usplash isn't on, by the way.
[03:18] <hyperair> if i boot without the 'splash' parameter, it doesn't blank out
[03:21] <Sarvatt> so I guess KMS has a problem with the cryptloop display stuff...
[03:23] <hyperair> Sarvatt: it does?
[03:23] <Sarvatt> apparently? its blacking out and not working under a real drmfb?
[03:23] <hyperair> Sarvatt: i don't really think so, because if i don't have that, the screen blanks out anyway, but *after* the cryptloop display stuff
[03:24] <Sarvatt> because you arent using the drmfb until later
[03:24] <hyperair> well yes, but how would KMS have issues with cryptloop?
[03:24] <hyperair> it doesn't exactly attempt to display anything, right?
[03:25] <hyperair> the cryptloop prompt is rendered by usplash
[03:25] <Sarvatt> doesnt it hook into usplash for the prompt?
[03:25] <Sarvatt> yeah
[03:25] <hyperair> as in, it talks to usplash
[03:25] <hyperair> hmm
[03:25] <hyperair> so you're saying that the usplash prompt causes problems with it?
[03:25] <hyperair> but why would it cause problems if it happened before i915 kicked in?
[03:26] <Sarvatt> because you dont use the drm fb until alot later normally (18 seconds in in your dmesg)
[03:27] <hyperair> but there aren't any further cryptloop prompts!
[03:27] <Sarvatt> just using intelfb or uvesafb or whatever it uses until then and it blacks out
[03:27] <hyperair> hmmm
[03:27] <hyperair> what does usplash use exactly?
[03:31] <Sarvatt> actually, looking at my bootcharts
[03:31] <Sarvatt> it looks like usplash in KMS just plain shuts off right after it starts and leaves the picture up
[03:32] <hyperair> what?
[03:32] <hyperair> O_O
[03:32] <Sarvatt> when i915 is built in and i have a KMS console up at 3 seconds in
[03:32] <Sarvatt> i should force a fsck and see if it shows the fsck stuff :D
[03:32] <hyperair> how bizarre O_o
[03:32] <hyperair> hmm
[03:32]  * hyperair is beginning to really hate fsck
[03:32] <hyperair> 20 minutes for one round
[03:32] <hyperair> ugh
[03:32] <hyperair> what a pain
[03:33] <Sarvatt> my bootcharts without KMS have usplash going for a long time, with kms it stops 2 seconds after it starts and i dont get progress bars or anything
[03:33] <hyperair> i don't even know why my stupid /home loves to trigger fsck
[03:33] <hyperair> i se
[03:33] <hyperair> no progress bars eh
[03:33] <hyperair> then imo we should get usplash fixed before turning on KMS by default
[03:33] <hyperair> or remove it completely.
[03:34] <hyperair> no actually newbies have a tendency to think that black screen with scrolling text = spoilt computer
[03:34] <Sarvatt> probably the cryptloop :D
[03:34] <hyperair> meh
[03:34] <Sarvatt> (reason for the fscks i mean)
[03:35] <hyperair> no, i don't think so
[03:35] <hyperair> it never had an issue before this
[03:35] <hyperair> come to think of it, it never managed to unmount root because it was busy at the end of the shutdown cycle
[03:37] <hyperair> but cryptloop doesn't cache stuff does it
[03:37] <hyperair> it's pretty much synchronous in that all operations on it are written straight to the disk, unless i'm mistaken
[03:37] <Sarvatt> ext4 is marked needs fsck until its unmounted..
[03:38] <Sarvatt> clears the flag when its unmounted cleanly
[03:39] <hyperair> which means /home is never unmounted cleanly
[03:39]  * hyperair facepalms
[03:39] <hyperair> but hey i restarted it normally, surely the kernel should know to unmount all filesystems before shutting down *properly*?!
[03:40] <Sarvatt> shutdown script trying to unmount / before your cryptloop maybe?
[03:40] <hyperair> er doesn't it have to unmount / before cryptloop?
[03:40] <hyperair> either way if / needs fscking, i don't really care
[03:40] <hyperair> that takes at most 5 minutes
[03:41] <hyperair> i'm annoyed if /home needs fscking
[03:41] <hyperair> that takes at least 20 minutes
[03:41] <hyperair> ugh
[03:41] <Sarvatt> your cryptloop isnt somewhere on /?
[03:41] <hyperair> oh yeah it is
[03:41] <hyperair> it's on /dev/mapper
[03:41] <hyperair> /something
[03:49] <Sarvatt> i mean it might be trying to unmount the actual loop device before the file system inside is unmounted so that needs fsck, i had a similar problem with the shutdown scripts doing the kill wifi script before umountnfs by default..
[03:50] <hyperair> no, you can't do something of that sort. cryptsetup does not allow you to do anything to the underlying block device before unmounting it
[03:50] <hyperair> and the LVM on top of cryptsetup won't allow that eitehr
[03:51] <Sarvatt> can you remove the loop module with it mounted?
[03:51] <hyperair> no i don't think you can
[03:51] <hyperair> it'll complain that it's "in use"
[03:51] <hyperair> also, some rounds of REISUB don't trigger an fsck, but some do
[03:51] <Sarvatt> how about the crypto module?
[03:52] <hyperair> hmm
[03:52] <hyperair> i think it would also complain about still being used
[03:52] <hyperair> lemme try
[03:53] <hyperair> actually come to think of it... what's the name of the module? O_o
[03:53] <hyperair> ah nevermind found it
[03:53] <Sarvatt> maybe add a sync to the shutdown script?
[03:53] <hyperair> module in use
[03:53] <hyperair> where is the shutdown script? O_o
[06:48] <tjaalton> xserver master switched back to zapping by default, so that the shortcut can be configured with xkeyboard-config 1.6
[06:49] <tjaalton> I'm not sure there's much to migrate, other than documenting it
[06:49] <tjaalton> note that there's no shortcut defined by default
[06:49] <tjaalton> so it's effectively still off
[08:35] <tseliot> bryce: are you still there?
[08:43] <tseliot> nm
=== crevette__ is now known as crevette
[15:59] <Ng> bah, rebooted this morning for a new kernel and my laptop wouldn't come out of dpms-off after lunch, had to do sysrq stuff
[16:41] <hyperair> Ng: that sounds fun. did you by any chance get to fsck in the dark later?
[16:41] <Ng> hyperair: heh, no, ext4 seemed to be happy just recovering things
[16:42] <hyperair> Ng: good for you. i had to sit through a 20 minute long fsck, faced with a black screen, because usplash doesn't like KMS.
[16:42] <Ng> ohh, there's an oops in my logs
[16:42] <hyperair> or KMS doesn't like usplash
[16:42] <hyperair> or something
[16:42] <hyperair> yeah there's always an oops when that happens
[16:42] <Ng> it's 915 related
[16:42] <hyperair> i couldn't capture it though, for some reason dmesg > dmesg.txt gave me a bloody blank file
[16:42] <Ng> which I guess isn't surprising
[16:43] <Ng> wow, multiple oopses
[16:43] <hyperair> heh
[16:43] <superm1> hyperair, dmesg | tee dmesg.txt instead maybe then
[16:43] <Ng> I think they're all the same, some hung_task kernel thing
[16:43] <hyperair> superm1: i don't see how that would be any better
[16:43] <superm1> well if plain ol 'dmesg' doesn't work, then i guess it wouldn't be any better
[16:44] <hyperair> heh
[16:44] <Ng> do we want bugs from i915 on the kernel?
[16:44] <Ng> (I would assume so)
[16:46] <hyperair> i would think so too
[16:46] <Ng> huh, the backtrace looks a lot like bug #384865 which is 9.04
[16:46] <ubottu> Launchpad bug 384865 in linux "kernel oops with intel graphics when screensaver turns screen off" [Undecided,New] https://launchpad.net/bugs/384865
[16:46]  * Ng facepalms, it's 9.10
[16:48] <Ng> I guess this should be upstreamed
[16:57] <hyperair> heh
[17:01] <Ng> upstreamed and linked
[17:01] <hyperair> woohoo
[17:01] <Ng> bit weird having it in the kernel package in ubuntu and the intel video driver in bugs.freedesktop.org, but whatever
[18:10] <Duke`> Sarvatt: now intel KMS on jaunty works without xorg.conf file!
[18:17] <hyperair> since when did KMS require a xorg.conf?
[18:18] <hyperair> wasn't it some kernel module option?
[18:19] <crevette> hey a
[18:21] <Duke`> hyperair: previously, xorg server was trying to load i810 module instead of intel driver and failed... so I had to force manually the intel driver in a simple xorg.conf file
[18:21] <hyperair> i see
[18:21] <hyperair> great then =p
[18:23] <jcristau> Duke`: sounds unrelated to kms..
[18:23] <jcristau> also doesn't sound like a problem, but meh
[18:23] <crevette> I've a problem with KMS, I boot with grub i915.modeset=1 ,I can see the splash screen but no gdm
[18:23] <hyperair> that sounds like the opposite of what i get
[18:23] <tjaalton> bryce: has the nouveau testing been with kms? our snapshot of the driver is quite old too
[18:23] <Duke`> jcristau: yeah was strange, but it did only when I enabled KMS
[18:23] <hyperair> i get gdm but i don't get the usplash
[18:24] <jcristau> Duke`: loading i810 was not the problem then.  loading fbdev might have been.
[18:24] <crevette> my hardware is described at https://wiki.ubuntu.com/X/KernelModeSetting/ (bmillemathias)
[18:24] <Duke`> jcristau: ah yes, that was probably that
[18:25] <Duke`> http://pastebin.com/m20b737fc
[18:25] <crevette> my Xorg is https://wiki.ubuntu.com/X/KernelModeSetting/
[18:25] <crevette> my Xorg is http://bmm80.free.fr/misc/X/Xorg.0.log rather
[18:35] <bryce> (sorry, was in #ubuntu-desktop meeting)
[18:36] <bryce> tjaalton: not going so good, so far.  Getting black screens on 2 cards, and failsafe mode on the third.
[18:36] <crevette> hey no problem bryce, I was supposed you were in meeting, irc is low latency by nature
[18:36] <crevette> :)
[18:36] <bryce> Ng: for bug reports against the kernel that involve X issues such as KMS, etc. what we're doing is tagging them 'xorg-needs-kernel-fix'
[18:37] <bryce> Ng: this let's us find the X/kernel bugs more easily in the huge kernel bug pile
[18:37] <Ng> aha
[18:38] <Ng> bryce: thanks, added the tag
[18:42] <crevette> I didn't opened a bug yet, what should I attach as files to the bug (I already have Xorg.0.log)
[18:42] <crevette> and to which component should I the bug against? (xorg, intel driver, kernel?)
[18:52] <Sarvatt> thats an xorg-server problem crevette
[18:52] <Sarvatt> the exact problem just fixed for Duke` :D
[18:53] <Ng> now I just need to find someone to bribe/pester into fixing the problem :D
[18:53] <tjaalton> bryce: but is it with kms? would it be different without?
[18:57] <crevette> Sarvatt, what is the problem I arrived a bit late ... :)
[18:57] <Sarvatt> http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commit;h=daf26a14473563aa7368c93246f483b11e009d23
[18:58] <crevette> ah yeah, it seems to be that
[18:59] <crevette> because I see also the failsafe thingy trying to launch X just after and failing also
[18:59] <crevette> this patch was not sent upstreamN
[18:59] <jcristau> the patch is a hack
[19:01] <bryce> tjaalton: yeah this testing was with apw's kms kernel; I need to re-test with the stock kernel and !kms, and also probably should pull newer -nouveau bits
[19:01] <bryce> tjaalton: but so far the problems are making me lose some confidence on how far we can get with -nouveau this cycle
[19:04] <Sarvatt> well I got it working fully including 3d via gallium, some changes were needed. you need to drop the dependancy on linux-nouveau-source in the nouveau ddx when you use the KMS kernel, and the KMS kernel doesnt work in non KMS mode for me
[19:07] <Sarvatt> bryce: were you booting with nouveau.modeset=1 on the grub command line?
[19:07] <bryce> Sarvatt: no, I assumed the kernel was set up with that by default
[19:08] <Sarvatt> if i didnt use that it would try to boot in non KMS which wasnt working at all, dmesg flooded with errors and a black screen when x starts
[19:09] <bryce> ah, perhaps that's what I'm seeing ... trying
[19:09] <crevette> Sarvatt, so the fix will be available soon
[19:09] <tjaalton> bryce: ok.. I should try with my 8600GT
[19:11] <bryce> [    0.000000] Unknown boot option `nouveau.modeset=1': ignoring
[19:11] <Sarvatt> did you drop the nouveau kernel source from the ddx install bryce?
[19:12] <bryce> this is with 2.6.30-8-generic #10~kms2-Ubuntu
[19:12] <Sarvatt> because if you built the kernel module with dkms just installing it normally you'll get the non KMS compatable one
[19:14] <Sarvatt> do you see symbol version mismatch errors in dmesg? you built an external module thats overriding the KMS compatable one if so
[19:14] <crevette> is the "i915.modeset=1" boot option supported in the karmic kernel, because I have the same error message than bryce
[19:14] <Sarvatt> i915 isnt in the initrd by default so it gives the error trying to pass it early
[19:15] <jcristau> bryce: that message is expected
[19:15] <jcristau> bryce: just means i915 is not built-in
[19:15] <bryce> how about "[   25.697743] nouveau: Unknown parameter `modeset'" which appears later?
[19:15] <tjaalton> or nouveau, in this case
[19:16] <jcristau> tjaalton: yeah, that :)
[19:16] <tjaalton> bryce: maybe it's the dkms version Sarvatt mentioned
[19:16] <bryce> there are no messages in dmesg about mismatched versions
[19:17] <bryce> fwiw, I didn't build this kernel, this is from apw's package.
[19:18] <Sarvatt> did you install xserver-xorg-video-nouveau? because if you did it overrided the nouveau kernel module that has KMS support with the one from nouveau-kernel-source
[19:19] <bryce> ah, that could be; yes I updated -nouveau after installing the kernel.  Will try redoing that
[19:19] <Sarvatt> unless you rebuilt xserver-xorg-video-nouveau without the linux-nouveau-source dependancy dropped
[19:19] <Sarvatt> err with it dropped I mean
[19:20] <Sarvatt> i'll make a ppa with everything right now
[19:20] <tjaalton> just force purge -source, and remove the module it built
[19:23] <bryce> nouveau-kernel-source:
[19:23] <bryce>   Installed: 0.0.11+git20090515-0ubuntu1
[19:23] <tjaalton> yep, that would suggest that it overrides the module from the kernel
[19:23] <bryce> tjaalton: but if I try purging it, it also tries to remove -nouveau itself
[19:23] <bryce> The following packages will be REMOVED:
[19:23] <bryce>   nouveau-kernel-source* xserver-xorg-video-nouveau*
[19:24] <bryce> I'll just try reinstalling the kernel over the top first
[19:24] <tjaalton> that's why I said force purge :)
[19:24] <tjaalton> or use what Sarvatt will provide
[19:24] <tjaalton> or build -nouveau without the dep
[19:25] <Sarvatt> it'll probably take me about 30 minutes to get everything together, will be here though https://edge.launchpad.net/~sarvatt/+archive/nouveau
[19:26] <bryce> tjaalton: that was with apt-get purge -f nouveau-kernel-source
[19:26] <tjaalton> dpkg --purge --force-depends nouveau-kernel-source?
[19:29] <bryce>  * Running DKMS auto installation service for kernel 2.6.30-9-generic                                                  
[19:29] <bryce>  *  nouveau (0.0.11+git20090515)...                                                                                    nouveau (0.0.11+git20090515): Installing module.
[19:29] <bryce> ................
[19:30] <tjaalton> heh
[19:31] <tjaalton> dropping the dependency should work
[19:31] <bryce> although I notice from the changelog, that nouveau.modeset=1 is probably unnecessary - * NOUVEAU: Pull in the Nouveau driver and enable KMS by default.
[19:34] <Sarvatt> ok everything uploaded to the PPA, just gotta wait to be built
[19:34] <bryce> heya gang65
[19:35] <gang65> hello bryce
[19:36] <bryce> tjaalton: http://pastebin.ubuntu.com/197228/
[19:39] <Sarvatt> https://edge.launchpad.net/~sarvatt/+archive/nouveau
[19:39] <tjaalton> bryce: ok, and what happens then on boot?
[19:41] <bryce> tjaalton: [   22.776767] nouveau 0000:01:00.0: display fifo hung :(
[19:41] <bryce> heh, smilies in dmesg
[19:41] <jcristau> progress!
[19:41] <jcristau> :)
[19:41] <tjaalton> hehe
[19:41] <bryce> I had a brownish flash before it went black this time
[19:41] <Sarvatt> yeah thats without nouveau.modeset=1, i actually add options nouveau modeset=1 to /etc/modprobe.d/nouveau.conf as well
[19:42] <bryce> alright, from the changelog it sounds like that's not necessary, but easy enough to test
[19:43] <bryce> SWEET
[19:43] <bryce> console switched to the tiny fonts
[19:43] <bryce> wow, login screen is fucked though
[19:43] <Sarvatt> oh yeah, you also have to add nouveau to xorg.conf
[19:43] <tjaalton> yeah it tries to use nv
[19:44] <bryce> mm, think I did that already, lemme check
[19:44] <bryce>         Driver  "nouveau"
[19:44] <bryce>         Option  "Randr12" "on"
[19:44] <bryce> yep
[19:44] <Sarvatt> its possible whatever driver you're using doesnt work with the kernel nouveau though, they bumped the api around 0605, the one in my PPA should work
[19:45] <tjaalton> releases ftw
[19:45] <bryce> ok, well it's a *very* dark screen, but i could make out gdm's login box, so did my credentials and it started the desktop session, however the screen is fully blank (backlight is on, screen is kind of off-black)
[19:48] <Sarvatt> oops, silly me, uploaded the ddx before the drm was finished building on x64 and lpia
[19:48] <bryce> [   23.372708] nouveau 0000:01:00.0: Unhandled PFIFO_INTR - 0x00000010
[19:50] <Sarvatt> i386 is fine though, dont know if you're on x64 or not
[19:51] <bryce> murphy would have it no other way ;-)
[19:51] <Sarvatt> rebuilding amd64 now
[19:51] <Sarvatt> i should make a livecd for this :D
[19:51] <bryce> well, I need food anyway, so hopefully the amd64 stuff will be there when I get back
[19:57] <Sarvatt> amd64 or i386 for the livecd?
[19:59] <Sarvatt> well getting i386 because i dont think the script can handle building a amd64 one on my i386 machine i'm doing it on right now :D
[20:00] <Sarvatt> so i've gotta add nouveau to xorg.conf, and i'll echo options nouveau modeset=1 to /etc/modprobe.d/nouveau.conf, sure i'm forgetting a step...
[20:02] <Sarvatt> hmm i force it to EXA and use option noaccel false too on my nouveau kms machine
[20:02] <Sarvatt> but i think thats why i have problems with nouveau gallium
[20:36] <Sarvatt> ahh heck, Recommends: still pulls in nouveau-kernel-source, reuploading another with it dropped completely
[20:36] <Sarvatt> glad i tried it out before building the livecd :D
[20:48] <Sarvatt> yeah i have to pass nouveau.modeset=1 to grub every time or it wont boot, even with options nouveau modeset=1 in /etc/modprobe.d/nouveau.conf
[20:48] <Sarvatt> there an easy way to make that the default option on a live cd?
[20:51] <tjaalton> not sure
[20:55] <Sarvatt> ok heres logs of everything working http://sarvatt.com/downloads/nouveau-kms.txt
[20:56] <tjaalton> you've got gallium there too?
[20:59] <Sarvatt> yep
[20:59] <Sarvatt> not packaged, built it locally
[20:59] <tjaalton> ok
[21:00] <Sarvatt> used ./configure --enable-glx-tls --disable-egl --disable-asm --with-dri-drivers= --enable-gallium-nouveau --disable-gallium-intel --disable-gallium-radeon --with-state-trackers=glx,dri --with-demos=xdemos,demos,trivial,tests
[21:01] <Sarvatt> then I use LD_LIBRARY_PATH=~/source/mesa-7.6.0~git20090613.18af7c38/lib LIBGL_DRIVERS_PATH=~/source/mesa-7.6.0~git20090613.18af7c38/lib/gallium <program> to run it
[21:04] <Sarvatt> hate these darn HP bioses, i need to fix the dsdt for every single one i have
[21:06] <Sarvatt> probably should mention i cant run anything more than glxinfo with gallium :D
[21:23] <Sarvatt> ahh ok isolinux/gfxboot.cfg you can append things to the command line
[21:33] <Sarvatt> with no xorg.conf, is there any way to tell xserver to prefer the nouveau driver, or am I going to have to make the xorg.conf only work for nouveau on the livecd?
[21:39] <tjaalton> not without patching the server
[21:41] <Sarvatt> can I add multiple device sections and have it go down the list to find a working one?
[21:42] <tjaalton> hmm yes
[21:42] <tjaalton> that's what the server does, in practise
[21:45] <Sarvatt> http://sarvatt.com/downloads/xorg.conf.txt
[21:45] <Sarvatt> that look ok to you? or do i need screens too
[21:45] <tjaalton> not sure, have you tried it?
[21:49] <jcristau> Sarvatt: yeah iirc you need one Screen for each Device
[21:49] <tjaalton> try running without one, see what the logfile looks like
[21:50] <jcristau> otherwise it'll just use the first Device
[21:52] <Sarvatt> i just stepped out for a few minutes and dont have another machine handy to try it, and i'm almost done building the livecd so it'd be a shame to restart x to test it on this
[21:53] <Sarvatt> would adding screen 0 to each device work possibly?
[21:54] <Sarvatt> ahh i'm just going to add the nouveau device, if anyone wants to use it on something else they can fix it in failsafe :D
[21:57] <Sarvatt> sure is fun building the squashfs on an atom cpu, hope my battery lasts
[22:02] <Sarvatt> building it based on https://edge.launchpad.net/~sarvatt/+archive/xorg-testing so can test xserver 1.6.99.1 too
[22:03] <Sarvatt> need to update the xserver master hooks,because alot more builds now, just kdrive having problems
[22:11] <tjaalton> 1.6.99.1?
[22:11] <tjaalton> I see no such release
[22:16] <Sarvatt> not released yet, xserver master branch
[22:16] <Sarvatt> making the liveusb now to see if it works then i'll upload it
[22:22] <tjaalton> ah, so inventing release numbers then?-)
[22:33] <Sarvatt> no thats the version it reports
[22:34] <Sarvatt> no go on the livecd, xorg.conf gets overwritten with a default one on first boot
[22:35] <Sarvatt> AC_INIT([xorg-server], 1.6.99.1, [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], xorg-server)
[22:37] <tjaalton> Sarvatt: ah, ok
[22:43] <Sarvatt> cant figure out whats making it recreate a default xorg.conf, hmm
[22:46] <tjaalton> xserver-xorg.postinst
[22:46] <tjaalton> casper runs that
[22:47] <tjaalton> forgot that it's still not fixed in karmic
[22:52] <Sarvatt> hmm so if i comment the stuff from remove_conffile_prepare () { down to run ()  { out of xserver-xorg.postinst it should keep it?
[22:55] <tjaalton> maybe
[22:56] <jcristau> Sarvatt: rm xserver-xorg.postinst might be even better, for the live cd?
[22:56] <Sarvatt> even easier, will try that
[22:58] <jcristau> hrm. unless it still does something important. i'd need to check :)
[22:59] <jcristau> ah, right, it does the ln -s /usr/bin/Xorg /etc/X11/X
[22:59] <jcristau> but that probably doesn't need to be re-run on the live system
[23:01] <Sarvatt> yeah theres a link there already, phew
[23:49] <Sarvatt> ok i have a working livecd now, problem is you need to manually remove splash from the startup line. dont know if i should rebuild it with splash disabled by default or just note that :D
[23:51] <Sarvatt> ahh i can rebuild it manually without rebuilding the squashfs