=== michael_ is now known as michaellarabel [04:23] anyone know what causes xorg.conf to sometimes get truncated to 0? === Amaranth__ is now known as Amaranth [06:23] bryce__: broken jaunty postinst [06:25] happens at least on a preseeded install [07:05] tjaalton, mvo fixed the upgrader to handle this case, but anything else we could/should do about it so it's not a problem for folks? [07:58] bryce__: for karmic, nothing [07:58] since karmic doesn't install one [07:59] bryce__: btw, did you pull the changes from xorg git before releasing? [07:59] tjaalton, I believe so [07:59] tjaalton, did I miss anything? [07:59] pushing, at least :) [08:00] aha there we go [08:00] there was only one commit after the -vmmouse one, removing it from other archs than x86-based ones [08:00] ok, different question [08:00] am I on crack, or did we use to have -fglrx (and -nvidia) on the CD up through Hardy, but starting with Intrepid it is no longer there on the cd? [08:01] it never was AIUI [08:01] are you sure? wasn't it in l-r-m, and that was on the CD? [08:01] only the kernel module was in lrm [08:02] but the driver had to be downloaded [08:02] I'm pretty sure, will check now [08:02] what was the non-kernel driver package called? [08:02] man, it's times like these I wish my memory didn't suck so bad [08:04] nvidia-glx-new et al [08:05] and yes. hardy livecd only had the lrm bits and drdsl from restricted, nothing else [08:05] well, at least 7.10 had [08:05] couldn't find the hardy cs [08:05] *cd [08:06] ok [08:08] btw, I'm thinking about answering to the "xorg release process" thread about how they are going to schedule the server release(s) [08:08] good [08:09] I hadn't been tracking the list this week [08:09] since it seems that x.x.0 is going to be released on late March/September from now on, it seems it's a bit late for us [08:09] _unless_ we get an exception like the gnome guys [08:10] that was discussed after XDC [08:11] oh hell, yeah that's about a month late for us [08:11] was afraid they were going to pick those two months, those are like the worst possible for us :-/ [08:11] although they are going to release a beta ~three months earlier, and the first RC a month after that [08:13] and it seems like the last three months are going to be only for bugfixing.. we'll see how that works out [08:15] so let me see if I understand the l-r-m thingee right... so when it was built, it created debs for the kernel portion (which was included on the LiveCD) and some non-kernel portions (which were only installable from the network). Correct? [08:16] correct [08:16] ok, wow [08:17] l-r-m (the binary package) included all the modules [08:17] but not all of them were usable, like the nvidia/fglrx ones [08:17] without the other part [09:42] Hm, Ill ask here, perhaps there is help. [09:42] Im having a problem with karmics x [09:42] It starts in failsafe foe no apparent reason on most coldboots [09:45] Im at a loss as to where I should even start debugging this === crevette is now known as baptistemm [10:25] |Alexia_Death|: the log would be nice [10:25] <|Alexia_Death|> tjaalton: there was no other log than the failsafe I think === |Alexia_Death| is now known as Alexia_Death [10:27] check the gdm logfile then [10:28] I use kdm, but same thing. cheking [10:33] tjaalton: http://pastebin.com/d4a32ad11 [10:33] there is something there [10:33] xinit: unexpected signal 15. [10:34] what does that mean? [10:35] don't know [10:35] it doesn't start without a conffile? [10:35] I'm interested in that logfile [10:35] my KDM log? [10:36] no, xorg [10:36] for the failes session? [10:36] what failsafe do you mean btw? [10:36] failsafe KDE or xorg? [10:36] xorg [10:37] so get the logfile _before_ failsafe [10:37] you know, the low rez screen [10:37] that's not necessarily failsafe [10:37] if it's not forced to use vesa [10:37] it says so on the top of the box [10:38] well, try to salvage the logfile which has the original failure [10:38] and looks like warped garbage on my laptop pane [10:38] OK [10:38] I need to do it crom the command line sesson [10:38] The X log retantsion really should be longer than just the last session for a vt [10:40] maybe, but failsafe should save the old one with a different name [10:40] it should [10:40] ? [10:40] Let me see [10:42] What sort of different name? because theres certanly nothing in the Xorg.* variety that could be such a log. [10:46] there don't seem to be hooks for kdm [10:46] so just remove the conffile and start over [10:47] what conffile? [10:47] sigh [10:48] xorg.conf [10:48] created by failsafe? [10:48] OK [10:48] that would then be [10:49] sudo rm /etc/X11/xorg.conf.failsafe* [10:49] no [10:49] O_o [10:49] the server is using xorg.conf [10:50] yes. I need it. [10:50] those are backups created by failsafe [10:50] why? [10:50] nividia driver [10:50] heh [10:50] so most likely it's not installed properly [10:50] missing the kernel module etc [10:50] uh? [10:50] no. i works [10:51] and you claim it's using failsafe with vesa? [10:51] it's failing most likely because of nvidia [10:51] if it starts ok without xorg.conf, I'm right [10:51] It starts ok with it too [10:51] in 4 cases out of 10 [10:52] so why are we discussing then? [10:52] 4 cases that it does not [10:52] well, nvidia so.. meh [10:53] tjaalton: there is no alternative that actually works. [10:53] so if you restart kdm ten times in a row, it fails four times? [10:53] and I doubt nvidia is the problem. It oly happens on colld boots [10:53] no [10:54] blame kdm them [10:54] then [10:54] hmmm [10:54] interesiting option [10:54] but just cold boots? [10:55] no idea [10:55] on cold boots, ive had about 5 since the upgrade, 4 have failed 1 worked [10:55] kdm restart always works [10:55] my 8600gt works fine [10:55] never failed [10:56] but I use gnome [10:57] i had the same wit GDM I think [10:57] the first sessions I used gnome after upgrade [10:58] In jaunty I used GDM but now KDE user switching does not work with GDM any more [11:19] Alexia_Death: actually, it could be that the xserver tries to start too early, before the nvidia kernel module is usable [11:19] tjaalton: it does have the feeling of a timing issue [11:20] and with an heavily optimised boot thats entierly possible [11:21] if kdm uses upstart, it could be caused by the upstart job