[00:02] <maxb> apt-get source xserver-xorg-video-intel
[00:02] <maxb> apt-get build-dep xserver-xorg-video-intel
[00:02] <maxb> cd xserver-xorg-video-intel-VERSION
[00:02] <maxb> apply patch
[00:03] <maxb> dch -l zmiq "My local package to do foo"
[00:03] <maxb> (^That adds an entry to the debian/changelog, thus giving the package a distinct version number)
[00:03] <maxb> dpkg-buildpackage -b
[00:32] <zmiq_> many thanks; I'll try asap!!
[00:36] <zmiq_> the truth is I have been waiting for two months for a patch, which is now developed and tested as working, and don't want to wait anymore; it's regarding Option "SDVOBOutput"
[00:36] <zmiq_> developed by Wang Zhenyu
[00:40] <zmiq_> more at: http://bugs.freedesktop.org/show_bug.cgi?id=17823
[00:40] <ubottu> Freedesktop bug 17823 in Driver/intel "[945GM] Unable to switch to VGA with 2.4.2, VGA-1 replaced by TV-1" [Critical,New]
[01:43] <zmiq_> maxb: i've completed all steps; will dpkg-buildpackage -b also install the new module? in which direcotry?
[02:51] <stgraber> bryce: are your aware that geode GX2 are broken in Jaunty (more than they were in Intrepid) ?
[02:51] <stgraber> back in Intrepid, I just had to mention the Driver to use (geode) and force XAA to have them working, now I get a X seg fault in all cases
[02:52]  * stgraber goes looking for a bug on LP
[03:04] <stgraber> bryce: bug 327484
[03:04] <ubottu> Launchpad bug 327484 in xserver-xorg-video-geode "X crashing with Geode GX2 on Jaunty" [Undecided,New] https://launchpad.net/bugs/327484
[03:40] <bryce> stgraber: no I hadn't heard
[03:42] <stgraber> these things are usually extremely buggy and hard to get to work but there always were workarounds :) For jaunty the only one I found so far is using vesa which kind of sucks ...
[03:43] <bryce> stgraber: unfortunately I think AMD laid off their geode support people
[03:43] <bryce> and I gather they will no longer be producing geode
[03:44] <stgraber> indeed, unfortuanately we have a few hundreds of these things out there :)
[03:44] <bryce> stgraber: if you can locate a patch, or a new release which fixes the issue, we can upload it
[03:44] <bryce> else, at least get a full backtrace, in case it's just something simple like a null pointer
[03:44] <bryce> however my guess is that it is missing some support
[03:45] <bryce> stgraber: also check the geode mailing list
[17:18] <bryce> morning everyone
[18:02] <bryce> tjaalton, jcristau: does Option "ModeDebug" impact performance?  if not, would there be any reason not to switch it on while we're in development?  (up to beta perhaps?)
[18:03] <jcristau> bryce: sounds like a good idea
[18:35] <crevette> good evening gentlemen
[18:37] <bryce> heya crevette
[18:37] <crevette> I have a bug recently with jaunty where I can see what it is displayed after usplash, removing usplash to the "kernel " line in grub fixes the issue
[18:37] <crevette> s/can/can't/
[18:37] <crevette> are you aware of such issue ? I remember having the same bug in intrepid :)
[18:37] <bryce> crevette: yes
[18:38] <crevette> okay so I don't need to spam you more
[18:38] <bryce> crevette: bug in usplash; you can sub to it
[18:38] <bryce> 327230
[18:39] <bryce> crevette: kees is looking at it currently - you could help him with some testing if you'd like
[18:39] <crevette> wonderful
[18:39] <crevette> kees: don't hesitate if I can help you
[18:39] <kees> crevette: okay, I've got 8 builds of usplash I need tested.  :)
[18:40] <crevette> hehe
[18:40] <kees> crevette: basically, to isolate the change that broke for some people
[18:40] <crevette> kees: do you need I enumerate my hardware ? 
[18:40] <kees> crevette: nope
[18:44] <kees> crevette: okay, ready?
[18:44] <kees> crevette: here's the list: http://people.ubuntu.com/~kees/usplash-testing/
[18:44] <crevette> I've few minutes free
[18:44] <kees> in order, test 242 242.1.1 242.1.2 242.1.3 242.1.4 243 and 244
[18:45] <crevette> do you have i386 deb ? 
[18:45] <kees> each directory has 2 deb, both are needed.  at some point, after a reboot, it'll fail.  242 should work, for example.
[18:45] <kees> crevette: give me a moment, I can build those...
[18:45] <crevette> okay thanks
[18:46] <crevette> too bad I don't have a VM of jaunty
[18:47]  * crevette opens another bug in the meanwhile
[18:53] <kees> crevette: okay, i386 debs are up.
[18:54] <crevette> wonderfull
[18:57] <crevette> first reboot
[19:01] <crevette> 242 works
[19:01] <kees> okay, good.  that's expected (242 is basically 0.5.27).
[19:01]  * crevette will try the dichotomy way
[19:01] <crevette> let pick on in the middle :)
[19:01]  * kees nods
[19:08] <crevette> 242.1.4 is affected
[19:09] <kees> okay.  /me suspects 242.1.3
[19:09] <kees> though why it would cause this, I have no idea.
[19:10] <kees> if 242.1.2 works and 242.1.3 is busted, then I'll revert the signal handler changes.
[19:10] <crevette> which one do you want me to test ?
[19:10] <kees> try 242.1.2 next.
[19:14] <crevette> 242.1.2 works
[19:16] <crevette> let's got for 242.1.3
[19:16] <kees> okay, ... 242.1.3 next, I guess.  :)  Thanks so much for doing this testing
[19:17] <crevette> no problemo, always happy to help
[19:19] <crevette> 242.1.3 works too
[19:20] <crevette> so 242.1.4 is guilty 
[19:20] <crevette> :)
[19:20]  * kees ponders
[19:20] <kees> uhm
[19:20]  * kees scatches his head
[19:21] <kees> seems the diff between 242.1.3 and 242.1.4 is only in the changelog...
[19:21] <crevette> should I try again to reboot to see if it works again
[19:21] <tjaalton> bryce: i thought upstream turned it on already, but maybe only for master
[19:22] <kees> yeah, can you?  maybe this problem isn't always present on every boot?  geh, I wish I could reproduce this locally
[19:22] <crevette> let do it again
[19:30] <crevette> 242.1.3 didn't work the 2nd time
[19:30] <kees> okay, that does imply a race with the alarm handler... copying up another test version...
[19:31] <kees> crevette: http://people.ubuntu.com/~kees/usplash-testing/ 0.5.29~kees1
[19:31] <kees> that's 244 with the changes between 242.1.2 and 242.1.3 removed
[19:32] <crevette> okay
[19:33]  * kees hugs crevette
[19:33] <bryce> thanks crevette :-)
[19:34]  * crevette hugs kees & bryce
[19:34] <crevette> :)
[19:35] <crevette> See you soon
[19:39] <crevette> so it seems to work
[19:39] <crevette> I admit I didn't tested twice :)
[19:39] <kees> heh.
[19:40] <kees> okay, well, maybe I can get bryce to test the ~kees1 build too?
[19:40] <kees> bryce: do you need i386 or amd64 debs?
[19:40] <bryce> sure thing
[19:40] <bryce> i386
[19:40] <kees> cool, they're up there for ya
[19:40] <kees> http://people.ubuntu.com/~kees/usplash-testing/
[19:40] <kees> the ~kees1 build reverts a signal handler clean up.
[19:41] <bryce> installed; rebooting
[19:41] <kees> cool, thanks
[19:43] <bryce> ok, came right up
[19:43] <kees> whee
[19:43] <bryce> so, I can confirm the fix
[19:44] <kees> okay, I'll push this version, though it's not clear to me _why_ it broke.  :P
[19:46]  * crevette goes to eat its soup bowl
[19:51] <kees> crevette: thanks again.  I've uploaded an official 0.5.29 which reverts the signal handler changes, so hopefully this bug should stay dead.  :)
[19:52] <crevette> kewl, thanks a lot
[20:00] <kees> np
[20:32] <tjaalton> bryce: btw, the compiz-freeze with intel still happens for me, but it's harder to trigger with the latest patch :/
[20:33] <bryce> tjaalton, ok
[20:35] <tjaalton> so it's only partially fixed
[20:38] <mnemo> tjaalton: same here but here it seems to repro more and more often the longer you run X though
[21:02] <tjaalton> mnemo: there's another patch to try
[21:35] <tormod> tjaalton: I still have /etc/X11/Xsession.d/65mesa-check-x86-64 here, is this a conf file that needs to be deleted even if it's not shipped any longer, or is it just me?
[21:36] <jcristau> yes, the postinst should take care of that
[21:45] <tormod> jcristau: thanks. just rm it no question asked?
[21:45] <jcristau> tormod: it's a bit more complicated than that
[21:45] <tormod> I was afraid so :)
[21:45] <bryce> tjaalton: so do you think slipping ModeDebug into dexconf would be ok for pre-beta?  or is there a better way we could do it?
[21:46] <jcristau> bryce: don't do that. swap the default in the code
[21:47] <jcristau> tormod: xsfbs.sh has remove_conffile_lookup, remove_conffile_commit, remove_conffile_rollback. there's another example on the debian wiki somewhere iirc
[21:47] <bryce> jcristau: why not?  would be easier to swap than patching the xserver
[21:48] <jcristau> tormod: http://wiki.debian.org/DpkgConffileHandling
[21:49] <tormod> bryce: it's easier to revert it in the server than to try to rewrite xorg.conf's later
[21:49] <jcristau> bryce: because dexconf only runs on initial install, and is the wrong place to set defaults anyway
[21:49] <jcristau> also, what tormod says
[21:51] <tormod> jcristau: but but this is not really a configuration file... nobody should have changed if not only to disable it
[21:51] <jcristau> it's a conffile...
[21:52] <jcristau> though i can understand if you don't care enough and want to just remove it :)
[21:52] <jcristau> tormod: the xsfbs.sh stuff also makes sure the conffile is restored if for some reason the upgrade gets aborted (the rollback function)
[21:53] <tormod> well that's almost useful - maybe reason enough
[21:53] <tjaalton> tormod: what shipped it?
[21:54] <tjaalton> bryce: by patching the server, yes
[21:54] <tormod> tjaalton: libgl1-mesa-dri
[21:55] <tjaalton> tormod: ok.. nothing in the changelog
[21:57] <tormod> I hope jcristau looks another way :) I don't think Ubuntu supports broken release upgrades anyway.
[21:58] <jcristau> heh
[22:04] <tjaalton> tormod: oh, I dropped it
[22:05] <tjaalton> meh
[22:06] <tjaalton> there should be a /usr/share/X11/Xsession.d
[22:06] <tjaalton> or similar
[22:06] <tjaalton> and /etc/X11/Xsession.d left for the local admin
[22:07] <jcristau> (we had the same problem with xfree86-common -> x11-common, i think the files in /etc/X11/Xsession.d/ were left around on sarge->etch upgrades :/)
[22:08] <jcristau> (so you'd end up with two copies until you purged xfree86-common. which means two ssh-agents starting. which means fail.)
[22:09] <maxb> It's a shame dpkg doesn't make the corner-cases of conffile handling easier
[22:09] <tormod> I thought you had to declare what's a conffile? Or is everything under /etc conffiles?
[22:10] <maxb> debhelper declares everything under /etc for you
[22:10] <maxb> Though I believe it would be frowned upon to put something in /etc/ that wasn't a conffile
[22:11] <tormod> there is certainly a good bunch of stuff under /etc that is not meant to be edited, no more than you would recompile something under /usr/bin
[22:14] <maxb> I guess it would be ok if you had a comment informing the local admin that the file is liable to have local changes destroyed on upgrade
[22:15] <maxb> though still not ideal
[22:15] <tormod> for instance there is gdm.conf, with gdm.conf-custom for making changes
[22:16] <tormod> oh, gdm.conf has such a warning :)
[22:17] <maxb> though is still a conffile