[00:16] <jcristau> tjaalton: lintian bug filed.
[02:27] <ubotu> New bug: #126861 in xserver-xorg-video-intel (main) "OpenGL crashes x61s" [Undecided,New] https://launchpad.net/bugs/126861
[08:09] <bryce> beh, backporting mesa from git-head is a PITA
[08:10] <bryce> it's not worth this much effort :-P  I'm calling time
[08:13] <tjaalton> hehe
[08:14] <bryce> btw, we probably should move libpciaccess-dev into main during hardy; if/when people ask for xserver backports we'll want that in
[08:18] <bryce> huh, this is odd - https://bugs.launchpad.net/xorg-server/+bugs
[08:18] <bryce> are those misfiled bugs?
[08:19] <tjaalton> no, it's the "upstream component"
[08:19] <tjaalton> meaning upstream xorg
[08:19] <tjaalton> although it's misnamed
[08:19] <bryce> oh, is this how launchpad tracks bugs linked to it from bugzilla?
[08:20] <tjaalton> it's not automatic, someone has created that one
[08:23] <bryce> huh
[08:25] <tjaalton> when you mark a bug to affect a project, it selects this "X.org X server" automatically for some components, like savage
[08:27] <tjaalton> it would be better to have just X.org I think
[08:27] <bryce> yup
[08:28] <tjaalton> but there's no way to edit the project
[08:28] <tjaalton> oh, there is X.Org already
[08:29] <tjaalton> ah, so xorg-server is a subproject
[09:33] <superm1> twb, what exactly were you trying to accomplish with openchrome?
[09:33] <twb> Because I don't want to rollout hardy, I'm trying to force xserver-xorg to use vesa in xorg.conf
[09:33] <twb> I'm doing fully automated d-i net installs to a bunch of (hopefully) homogeneous laptops.
[09:34] <superm1> twb, would a backport of openchrome help then?
[09:34] <superm1> perhaps
[09:34] <twb> Possibly
[09:34] <twb> I tried seeding these, which apparently had no effect:
[09:34] <twb> xserver-xorg xserver-xorg/config/autodetect_video_card boolean true
[09:34] <twb> xserver-xorg xserver-xorg/config/device/driver select vesa
[09:34] <twb> Oh damn
[09:34] <superm1> if you want to grab the dsc and build it on gutsy you can give it a spin
[09:34] <twb> Now I *read* the first one I see it should be false :-/
[09:35] <superm1> hehe
[09:35] <superm1> :)
[09:35] <twb> I wasted ninety minutes testing that
[09:35] <tjaalton> yes, set that to false and it should work
[09:35] <superm1> you will get a lot better performance out of openchrome than vesa, so if these all support openchrome, it would be worthwhile to switch it over
[09:35] <tjaalton> that's what I use here :)
[09:35] <twb> I'm quite cabable of backporting by hand should the need arise, but for the immediate future I want to make vesa work.
[09:36] <superm1> k
[09:36] <superm1> bryce, speaking of which, should that MIR idea for openchrome be revisited now?
[09:36] <tjaalton> bryce: are you still around?
[09:36] <superm1> considering it uses a different module name 
[09:36] <superm1> and no longer just 'via'
[09:36] <tjaalton> superm1: it probably should
[09:37] <tjaalton> and perhaps replace via as the default (like fedora9 does)
[09:37] <superm1> well but not all the cards support openchrome?
[09:37] <tjaalton> I thought it was just a fork
[09:38] <superm1> it forked from unichrome at some point
[09:38] <tjaalton> hmm
[09:38] <superm1> but there was separate development, and hence different supported hardware
[09:38] <superm1> i swear there is a table somewhere that lists it all
[09:38] <superm1> let me see if i can find it
[09:38] <tjaalton> the driver code :)
[09:39] <twb> Upstream svn openchrome calls itself openchrome_thingy.so
[09:39] <twb> Where thingy ~= dri
[09:40] <superm1> so via forked into unichrome, and unichrome forked into openchrome
[09:40] <superm1> http://wiki.openchrome.org/tikiwiki/tiki-index.php?page=HardwareCaveats
[09:44] <twb> Incidentally if anyone knows how to simply tell the default driver to work on the LCD head, that would be great, too.
[09:44] <tjaalton> hmm, so 2d is supported for all of them?
[09:44] <twb> I tried telling it the panel resolution (1280x800, yecch) and playing with the Fn-<display> chord, but only got garbage on the laptop LCD except when using svn openchrome or vesa.
[09:44] <twb> (Telling it in the device stanza, I mean.)
[09:48] <tjaalton> openchrome seems to support lot more chips than via
[09:48] <twb> Somebody suggested that the via driver is just an old snapshot of unichrome
[09:49] <twb> He might have been on crack at the time, tho...
[12:41] <ubotu> New bug: #177138 in xserver-xorg-video-intel (main) "Display will not start because bad frecuency choosed by Intel i810 driver" [Undecided,New] https://launchpad.net/bugs/177138
=== seb128_ is now known as seb128
[19:25] <ubotu> New bug: #177029 in linux-restricted-modules-2.6.22 (restricted) "Video Play back corrupted after making ANY change to Desktop Effects" [Undecided,New] https://launchpad.net/bugs/177029
[21:02] <pochu> Hey folks. The bug we talked about the other day has been fixed upstream, and commited to HEAD, see freedesktop bug #13108. The launchpad bug is 173265. This affects (afaik) only intel chipsets, and the way to reproduce is to put a video in the background (e.g. hide it with another window), and after some seconds (more than 10 it seems) display it.
[21:02] <ubotu> Freedesktop bug 13108 in Driver/intel "[overlay] XV window hidden for some seconds causes SEGFAULT when taken into foreground again" [Major,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=13108
[21:02] <pochu> bug 173265
[21:02] <ubotu> Launchpad bug 173265 in xorg-server "Xorg crashed with SIGSEGV" [Unknown,Confirmed] https://launchpad.net/bugs/173265
[21:03] <pochu> Is it possible to get this patch in? There seems to be various dups, although I haven't marked them as such as I'm not really sure.
[21:25] <bryce> pochu: heya, I'll take a look today once I've finished merging in -psb
[21:26] <pochu> bryce: thanks. Let me know if you need me to do some tests :-)
[21:27] <bryce> sure
[22:53] <bryce> tjaalton: had a chance to test the patch for bug #174537?
[22:53] <ubotu> Launchpad bug 174537 in xorg "[Hardy] No Xorg in live cd" [Critical,Confirmed] https://launchpad.net/bugs/174537
[22:56] <tjaalton> bryce: I haven't succeeded to build a livecd :/
[22:56] <bryce> hrm; should we just go ahead and push it out, and see how it goes?
[22:56] <tjaalton> because openoffice refuses to install
[22:56] <tjaalton> I guess so
[22:57] <bryce> ok, do you want to upload it, or I could ask slangasek?
[22:57] <tjaalton> (the new openoffice depends on a library that is in universe, and doesn't build)
[22:57] <tjaalton> either works
[22:58] <bryce> ok, go ahead and upload; I'll let slangasek know it's incoming
[23:08] <tjaalton> so now that I push the change, it'll upload a new version automatically?
[23:13] <tjaalton> ah no
[23:21] <bryce> <bryce> slangasek: we're fairly confident that the change fixes the issue, and at least certain it won't make anything worse, so I'm going to have timo go ahead and upload it
[23:21] <bryce> <slangasek> ok
[23:21] <bryce>  the OOo build issue is also on my list to chase up today
[23:29] <bryce> <cjwatson> bryce: patch looks fine to me, if it'll do the job
[23:29] <bryce> <bryce> cjwatson: cool thanks
[23:30] <tjaalton> cool
[23:30] <tjaalton> pushed already
[23:31] <tjaalton> and now uploaded
[23:31] <tjaalton> hopefully that's all it takes :)
[23:33] <bryce> thanks!
[23:43] <tjaalton> yeah, I'll test the daily cd tomorrow
[23:43] <tjaalton> for some reason those have been generated without any OOo issues
[23:44] <tjaalton> but even better if the new version is built by tomorrow
[23:44] <tjaalton> bedtime again, cya ->