| 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:02 |
| 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:03 |
| zmiq_ | many thanks; I'll try asap!! | 00:32 |
| 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:36 |
| 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] | 00:40 |
| zmiq_ | maxb: i've completed all steps; will dpkg-buildpackage -b also install the new module? in which direcotry? | 01:43 |
| 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:51 |
| * stgraber goes looking for a bug on LP | 02:52 | |
| 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:04 |
| bryce | stgraber: no I hadn't heard | 03:40 |
| 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:42 |
| 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:43 |
| 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:44 |
| bryce | stgraber: also check the geode mailing list | 03:45 |
| bryce | morning everyone | 17:18 |
| 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:02 |
| jcristau | bryce: sounds like a good idea | 18:03 |
| crevette | good evening gentlemen | 18:35 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:44 |
| 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:45 |
| crevette | too bad I don't have a VM of jaunty | 18:46 |
| * crevette opens another bug in the meanwhile | 18:47 | |
| kees | crevette: okay, i386 debs are up. | 18:53 |
| crevette | wonderfull | 18:54 |
| crevette | first reboot | 18:57 |
| 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:01 | |
| crevette | 242.1.4 is affected | 19:08 |
| kees | okay. /me suspects 242.1.3 | 19:09 |
| kees | though why it would cause this, I have no idea. | 19:09 |
| 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:10 |
| crevette | 242.1.2 works | 19:14 |
| 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:16 |
| crevette | no problemo, always happy to help | 19:17 |
| crevette | 242.1.3 works too | 19:19 |
| 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:20 | |
| 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:21 |
| 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:22 |
| 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:30 |
| 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:31 |
| crevette | okay | 19:32 |
| * kees hugs crevette | 19:33 | |
| bryce | thanks crevette :-) | 19:33 |
| * crevette hugs kees & bryce | 19:34 | |
| crevette | :) | 19:34 |
| crevette | See you soon | 19:35 |
| crevette | so it seems to work | 19:39 |
| crevette | I admit I didn't tested twice :) | 19:39 |
| kees | heh. | 19:39 |
| 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:40 |
| bryce | installed; rebooting | 19:41 |
| kees | cool, thanks | 19:41 |
| bryce | ok, came right up | 19:43 |
| kees | whee | 19:43 |
| bryce | so, I can confirm the fix | 19:43 |
| kees | okay, I'll push this version, though it's not clear to me _why_ it broke. :P | 19:44 |
| * crevette goes to eat its soup bowl | 19:46 | |
| 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:51 |
| crevette | kewl, thanks a lot | 19:52 |
| kees | np | 20:00 |
| tjaalton | bryce: btw, the compiz-freeze with intel still happens for me, but it's harder to trigger with the latest patch :/ | 20:32 |
| bryce | tjaalton, ok | 20:33 |
| tjaalton | so it's only partially fixed | 20:35 |
| mnemo | tjaalton: same here but here it seems to repro more and more often the longer you run X though | 20:38 |
| tjaalton | mnemo: there's another patch to try | 21:02 |
| 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:35 |
| jcristau | yes, the postinst should take care of that | 21:36 |
| 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:45 |
| jcristau | bryce: don't do that. swap the default in the code | 21:46 |
| 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:47 |
| jcristau | tormod: http://wiki.debian.org/DpkgConffileHandling | 21:48 |
| 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:49 |
| 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:51 |
| 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:52 |
| tormod | well that's almost useful - maybe reason enough | 21:53 |
| tjaalton | tormod: what shipped it? | 21:53 |
| tjaalton | bryce: by patching the server, yes | 21:54 |
| tormod | tjaalton: libgl1-mesa-dri | 21:54 |
| tjaalton | tormod: ok.. nothing in the changelog | 21:55 |
| tormod | I hope jcristau looks another way :) I don't think Ubuntu supports broken release upgrades anyway. | 21:57 |
| jcristau | heh | 21:58 |
| tjaalton | tormod: oh, I dropped it | 22:04 |
| tjaalton | meh | 22:05 |
| 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:06 |
| 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:07 |
| jcristau | (so you'd end up with two copies until you purged xfree86-common. which means two ssh-agents starting. which means fail.) | 22:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:14 |
| maxb | though still not ideal | 22:15 |
| tormod | for instance there is gdm.conf, with gdm.conf-custom for making changes | 22:15 |
| tormod | oh, gdm.conf has such a warning :) | 22:16 |
| maxb | though is still a conffile | 22:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!