[00:00] <Q-FUNK> especially since a lot of people already expect this to work in gutsy
[08:35] <tjaalton> I guess the xresprobe bugs can be marked as wontfix now
[08:36] <bryce> true
[08:36] <bryce> I can take care of that tomorrow if you'd like
[08:37] <Q-FUNK> hm?
[08:37] <Q-FUNK> what about xresprobe?
[08:37] <tjaalton> Q-FUNK: obsolete
[08:37] <bryce> it's deprecated now
[08:37] <Q-FUNK> replaced by?
[08:38] <tjaalton> xserver autoconfiguration
[08:38] <Q-FUNK> ah yes
[08:38] <tjaalton> bryce: there are only 11 of them, no big deal :)
[08:38] <tjaalton> I need more karma :)
[08:38] <bryce> hehe
[08:38] <bryce> ok go for it
[08:38] <Q-FUNK> although this doesn't yet work for all drivers.  they need to be ported to randr 1.2 and upgraded to recent api.
[08:39] <tjaalton> hmm no
[08:39] <tjaalton> it doesn't depend on randr 1.2
[08:39] <tjaalton> although there are some issues with vesa at least
[08:40] <Q-FUNK> and with -amd
[08:40] <Q-FUNK> siliconmotion also
[08:40] <bryce> what issues?
[08:40] <tjaalton> "no modes left" with vesa
[08:41] <bryce> ah
[08:41] <Q-FUNK> for DDC probing, bartman produced patches that should at least fix -amd.
[08:41] <Q-FUNK> that sound familiar from other drivers too.
[08:41] <Q-FUNK> IIRC someone reported that for -amd as well, on some hardware.
[08:41] <tjaalton> trident is buggy too, it hangs in a loop
[08:41] <tjaalton> but it's upstream now with a backtrace
[08:42] <Q-FUNK> ah, btw, amd 2.7.7.5 is in debian now
[08:42] <Q-FUNK> it introduces basic OLPC support
[08:42] <tjaalton> ok, file a sync request again, and tell the bug #
[08:44] <Q-FUNK> grmbl.  doesn't yet show in changelog server.
[08:48] <tjaalton> there, 11 bugs closed
[08:48] <Q-FUNK> #182781
[08:49] <Q-FUNK> hmm
[08:49] <Q-FUNK> this is in main, right?
[08:49] <Q-FUNK> or is it still in universe?
[08:50] <tjaalton> main
[08:50] <ubotu> New bug: #182778 in xserver-xorg-video-openchrome (main) "Wrong resolution on Hardy Alpha 3" [Undecided,New] https://launchpad.net/bugs/182778
[08:51] <tjaalton> heh, add openchrome to the list
[08:51] <tjaalton> there are also a lot of reports about not being able to change the resolution on livecd
[08:51] <tjaalton> which puzzles me
[08:52] <bryce> hrm
[08:52] <tjaalton> but that's an old issue
[08:52] <bryce> "not change" as through xorg.conf, or via displayconfig-gtk
[08:52] <bryce> ?
[08:52] <tjaalton> xrandr or d-g
[08:52] <bryce> odd
[08:53] <tjaalton> yep
[08:53] <tjaalton> maybe #u-installer could help, I'll ask
[08:55] <ubotu> New bug: #182781 in xserver-xorg-video-amd (main) "Please sync xserver-xorg-video-amd 2.7.7.5-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/182781
[09:19] <bryce> tjaalton: heh, we've triaged too many bugs.  bdmurray has skipped us in favor of openoffice for bug hug day this month
[09:19] <tjaalton> :)
[09:20] <bryce> looks like between xorg, xserver, and major drivers, we barely have a total of 100 untriaged bugs left ;-)
[09:20] <bryce> actually probably more like 50
[09:21] <tjaalton> xorg has maybe 6
[09:21] <bryce> -nv has the most ironically
[09:21] <tjaalton> heh, yeah
[09:21] <tjaalton> I should go through them now that I have one..
[09:25] <bryce> so I wonder what we do when we hit 0 New bugs :-)
[09:26] <tjaalton> we try to fix those that are confirmed? :)
[09:26] <bryce> maybe focus on getting everything filed upstream?
[09:26] <bryce> hehe
[09:26] <tjaalton> going through b.df.o is one
[09:27] <bryce> I got one of my upstream reported bugs marked invalid because it was one of those bugs that a bunch of users had "me too"ed their issues onto, so I summarized and sent upstream
[09:27] <bryce> however upstream seems to prefer each person's issue be a separate bug report
[09:27] <tjaalton> as do we
[09:27] <bryce> unfortunately I think launchpad lets us down a bit here, since it's set up to only allow one upstream bug report per bug
[09:28] <bryce> hmm, I've not been so picky that people who have roughly the same issue, report it separately (sometimes)
[09:28] <tjaalton> i've closed bugs where people have reported other issues than the original one, and asked them to file new bugs
[09:28] <bryce> maybe I need to be more strict though.
[09:29] <Ng> I'm going to be bugging you X guys again like I was with gutsy. resuming my laptop is causing graphical issues again ;)
[09:29] <bryce> I suppose that's a good practice
[09:29] <bryce> heya Ng
[09:29] <bryce> heh, the membership of #ubuntu-x sure has grown since I started working here....
[09:29] <tjaalton> bug 180409
[09:29] <ubotu> Launchpad bug 180409 in linux-restricted-modules-2.6.24 "bugs in fglrx - blank screen - artifacts" [Undecided,Invalid] https://launchpad.net/bugs/180409
[09:30] <Ng> hey bryce :)
[09:30] <tjaalton> that's one good example of a messy bug report..
[09:30] <tjaalton> hey Ng!
[09:30] <Ng> tjaalton :)
[09:32] <Ng> erk, this is more broken than I thought. scrolling in firefox => jumbled mess
[09:32] <Ng> bryce: do you know if the fix from 133118 made it upstream?
[09:32] <bryce> I was fairly sure it did
[09:32] <Ng> I don't think it can be the same thing, because Im sans compiz atm and 2d stuff is broken
[09:32] <tjaalton> Ng: switch to XAA, set 'Option "AccelMethod" "XAA"'
[09:33] <Ng> tjaalton: I did that already to get the 2d acceptably fast ;)
[09:33] <bryce> man, that's sad that I recognize bugs off their bug id#
[09:33] <bryce> my memory really isn't this good normally
[09:34] <Ng> hehe, well to be fair i did buy pretty much everyone pretty much all the time about it ;)
[09:34] <bryce> I'm 99.999% certain the fix was taken upstream
[09:34] <bryce> however, what upstream has done with it since then is anyone's guess
[09:35] <bryce> I know they've done additional work on this area since then
[09:35] <bryce> Ng: file another bug with the current state of the issue, ref the prev bug, and I'll follow it up
[09:35] <Ng> ok, ta :)
[09:36] <Ng> fwiw, http://mairukipa.tenshu.net/855gm-resume-broken.png is what I'm seeing
[09:36] <bryce> don't understand...
[09:37] <bryce> I see what looks like some image doubling or something?
[09:37] <Ng> see how the network-manager icon shows all the trails from the spinning, as well as the latest state (LAN connection)
[09:37] <bryce> mm, sort of...
[09:37] <Ng> if I cover that icon it'll force it to redraw, but if I then connect to another network the trails will build up again until I next force it to completely redraw
[09:37] <bryce> hmm
[09:38] <Ng> so scrolling in firefox causes a bit of a mess ;)
[09:38] <bryce> make sure to describe the situation really well (or include screencast)
[09:38] <Ng> oki doki
[09:38] <Ng> I'm going to have a quick trawl of bugs to see if I can find anything similar
[09:38] <bryce> I'm sure we'll here, "Oh yeah, that's 100% fixed.  Just switch to TTM."
[09:39] <Ng> heh
[09:39] <Ng> these interregnum periods are a pita for distros ;)
[09:52] <Ng> filed as bug #182791
[09:52] <ubotu> Launchpad bug 182791 in xserver-xorg-video-intel "855GM resume problems" [Undecided,New] https://launchpad.net/bugs/182791
[09:56] <bryce> thanks
[09:57] <bryce> Ng, I've been lightly hammering on Intel to get the <= 855 issues sorted out for a while
[09:57] <Ng> good :)
[09:57] <Ng> there are a lot of such laptops still in use and when they work they work fantastically ime, but it is a bit of a shame to have to chase down weird bugs each release ;)
[09:58] <bryce> I've got it on record that they want -i810 deprecated, and thus desire all issues that work in -i810 but not -intel to be resolved in -intel so we can deprecate -i810
[09:58] <bryce> sort of circular there, but in a good way
[09:58] <Ng> has i810 changed since gutsy? istr it hadn't changed there since feisty?
[09:59] <bryce> no it hasn't
[09:59] <Ng> mmkay, well I probably won't bother even testing that yet, it was never very good at resume anyway ;)
[09:59] <bryce> upstream in fact has just symlinked -i810 to -intel
[09:59] <Ng> I am going to quickly try EXA just in case, since that is at least the default the driver is choosing
[09:59] <bryce> cool
[10:01] <ubotu> New bug: #182791 in xserver-xorg-video-intel (main) "855GM resume problems" [Undecided,New] https://launchpad.net/bugs/182791
[10:03] <Ng> heh, good work ubotu ;)
[10:10] <Ng> wow, it's even worse with EXA
[10:10] <Ng> it's almost impossible to get anything to render. at best I could see the background of gtk widgets, but absolutely no foregrounds or text
[10:24] <Ng> heh, I found an (I think) unrelated 855gm bug on fd.o's bugzilla and the intel guys seem to be saying that they don't have such hardware to test on
[10:24] <Ng> this is not encouraging ;)
[10:30] <ubotu> New bug: #182802 in xserver-xorg-video-intel (main) "[hardy] Screen freeze on resume" [Undecided,New] https://launchpad.net/bugs/182802
[10:46] <ubotu> New bug: #153122 in xserver-xorg-video-openchrome (main) "Fatal error while loading Xorg" [Undecided,Incomplete] https://launchpad.net/bugs/153122
[10:46] <ubotu> New bug: #164342 in xserver-xorg-video-openchrome "Suspend broken" [Undecided,Incomplete] https://launchpad.net/bugs/164342
[10:53] <ubotu> New bug: #178313 in xserver-xorg-video-via (main) "antspotlight screensaver hangs computer" [Undecided,Incomplete] https://launchpad.net/bugs/178313
[13:27] <mvo> tjaalton: you mentioned in #179515 that the screensaver might kill X during a upgrade, do you know any details?
[13:28] <mvo> tjaalton: I'm wondering what to do about it, sending a inhibit signal via dbus for gnome-screensaver would be a obvious (but not trivial as the release-upgrader does not have access to the session bus) solution, but that leaves xscreensaver and kde out 
[13:30] <tjaalton> mvo: yeah :/
[13:30] <tjaalton> mvo: no perfect solution there, but I don't know what else could have caused it
[13:35] <mvo> tjaalton: ok, its at least a hint. I will try to reproduce it here with screensaver on and see what comes out of it
[13:38] <tjaalton> mvo: it only happens if your driver is buggy with DRI
[13:38] <mvo> tjaalton: so for every driver ;) ?
[13:38] <tjaalton> hehe
[13:38] <tjaalton> there's always the possibility, sure :)
[13:38] <mvo> tjaalton: do you know more details?
[13:38] <mvo> I mean, what exactly is causing it? the fact that libdrm/libGL changes while the screensaver is runing?
[13:39] <mvo> some incompatibility between the drm/dri interfaces?
[13:39] <tjaalton> well, GL screensavers tend to trigger bugs
[13:40] <tjaalton> but if the stuff is already loaded in the memory it doesn't matter if the libs are updated
[13:40] <mvo> meh, if its in dri, then I can not reproduce it in a VM :(
[13:40] <tjaalton> no, it's just a scenario
[13:40] <tjaalton> that X crashes when you upgrading
[13:41] <tjaalton> and to minimize the possibility it would be wise to disable the screensaver
[13:41] <mvo> its probably a good theory, because I have not seen it crash in a VM yet, but it seems to happen sometimes on real HW - I have seen some reports
[13:41] <tjaalton> yeah, I bet there are dupes
[13:43] <tjaalton> you can disable gnome-screensaver with gconf
[13:43] <tjaalton> idle_activation_enabled
[13:45] <mvo> I look into it, I need to come up with something that works for xubuntu and kubuntu as well 
[13:45] <tjaalton> ok, cool
[15:21] <ubotu> New bug: #182865 in xserver-xorg-video-intel (main) "Cannot switch to console after installing "xserver-xorg-video-intel 2:2.1.1-0ubuntu9.1"" [Undecided,New] https://launchpad.net/bugs/182865
[15:46] <ubotu> New bug: #182878 in xorg (main) "[gutsy] gma 950 no TV-OUT in dispalyconfig" [Undecided,New] https://launchpad.net/bugs/182878
[15:46] <ubotu> New bug: #182883 in xserver-xorg-video-intel (main) "dual screen support doesn't work" [Undecided,New] https://launchpad.net/bugs/182883
[16:41] <ubotu> New bug: #182898 in xserver-xorg-video-intel (main) "erratic widescreen intel gma 3000" [Undecided,New] https://launchpad.net/bugs/182898
[17:11] <Ng> not a good day for -intel and bugs ;o
[17:16] <tjaalton> poor intel
[19:48] <mvo_> bryce I may do a mesa upload within this week, is there anything planed? I need to patch it so that compiz can detect glx window
[19:55] <bryce> mvo, it should be safe.  I don't have mesa uploads planned and don't think timo does either
[19:56] <bryce> I'm going to do an xserver upload for Q-FUNK with some new patches, but that'll be for gutsy-proposed, not hardy
[19:56] <bryce> tjaalton might have some other things planned
[19:57] <mvo_> bryce ok, thanks. I'm currently in testing stage, but it looks promising so far and I don't want to interfere with the X team, especially since you use git now (not sure if you also use it for mesa)
[20:07] <bryce> no we don't
[20:09] <mvo_> good, thanks for this info
[20:12] <Q-FUNK> bryce: aye, thanks for that
[20:12] <Q-FUNK> let's see if it improves everyone's results 
[20:12] <tjaalton> mvo_: please go ahead
[20:12] <Q-FUNK> if it does, we can always come back to the Hardy patch before the release takes place
[20:18] <bryce> Q-FUNK: I need to do some UME stuff (trying to get it booted on the test hw they've provided)
[20:19] <Q-FUNK> ah ok
[21:04] <Ng> tjaalton: hmm, don't you have an X40?
[21:05] <tjaalton> Ng: nope, X61
[21:06] <Ng> ah, doh
[21:06]  * Q-FUNK is patiently waiting for his Dell D430 to be delivered.
[21:06] <Ng> I noticed that my particular model doesn't have any pm-utils quirks, so figured that might be causing X to fail to resume, but I've tried what I think should be the matching options from the old acpi-support, which made absolutely no difference ;(
[21:09] <tjaalton> you might want to ask mjg59 for some tips
[21:09] <Ng> yeah
[21:09] <tjaalton> or check thinkwiki
[21:10] <tjaalton> bryce: mjg59 confirmed that SHMConfig is not an option for us (pun intended)
[21:10] <tjaalton> so I closed the bug that asked for including it
[21:11] <tjaalton> ps. comedy inc. rules :)
[21:13] <Ng> tjaalton: it was a sad day when mjg59's x40 got ruined and he switched to an HP ;)
[21:15] <tjaalton> aww
[21:16] <tjaalton> that explains the recent blog post then ;)
[21:18] <bryce> tjaalton: ah ok
[21:35] <Q-FUNK> ah. vorlon pushed the new -amd into hardy
[21:37] <bryce> ok, I'm done (stuck) on the ume stuff for the time being.  -amd time.
[21:39] <jcristau> `
[21:40] <Q-FUNK> heh
[21:40]  * jcristau blames ssh
[21:41] <jcristau> fwiw, #182252 is invalid. X is started with '-nolisten tcp' by default, so obviously inet connections don't work
[21:50] <bryce> Q-FUNK, what are the bug ID('s) that are fixed with these two xserver patches?
[21:50] <tjaalton> jcristau: good point, I'll close that one
[21:54] <Q-FUNK> bryce: I'm not sure that there was a separate bug open for this freeze issue on some BIOS
[21:55] <bryce> can you open one please?  In order to upload SRU candidates they require patches be tied to bug ID's in launchpad
[21:57] <bryce> are these patches fixes for bug 140051?
[21:57] <ubotu> Launchpad bug 140051 in xserver-xorg-video-amd "amd driver fails to autoconfigure" [High,Triaged] https://launchpad.net/bugs/140051
[21:58] <Q-FUNK> yes and no
[21:58] <bryce> hmm, maybe I'm asking the wrong question
[21:58] <Q-FUNK> it prevents X from freezing at configure time, but doesn't directly resolve DDC failing with -amd yet
[21:59] <bryce> hmm, maybe I don't understand this
[22:00] <bryce> it sounds like these don't fix the issue, as there is another known issue that prevents it from working
[22:01] <bryce> however it adds the risk of changing existing -amd user's systems (presuming there are -amd users able to use the current driver)
[22:03] <bryce> wouldn't it be more appropriate to put this into hardy or a ppa if the purpose is simply to check if it breaks other -amd user's systems?
[22:04] <Q-FUNK> it needs to go into hardy regardless, if it works, but testing via gutsy-proposed feels as the most harmless way of having a wide test range
[22:04] <bryce> hmm
[22:04] <Q-FUNK> well, -amd is essentially borken for too many people, thanks to the broken x86emu
[22:05] <Q-FUNK> I'm stuck with Etch and a souped-up Feisty to they my thincans here, because of that
[22:05] <Q-FUNK> they->test
[22:06] <bryce> there could also be some risk for non -amd users, since it affects code that (I gather) is run by all xserver users, so want to be careful we're not pushing it too aggressively
[22:09] <bryce> not that I don't trust that this is a good fix to have, but it feels like we're skipping over some intermediary testing steps
[22:09] <bryce> hmm
[22:09] <bryce> ok I'm building the xserver with the patches.  Let me go grab lunch and think of how we should do this.
[22:11] <ubotu> New bug: #134951 in ubuntu "gutsy too high resolution (dup-of: 182778)" [Undecided,New] https://launchpad.net/bugs/134951
[22:18] <Q-FUNK> bryce: I just made a call to the X list for people to test this as much as possible
[22:24] <bryce> back
[22:27] <bryce> the bus patch failed to apply
[22:28] <bryce> Applying patch 146_x86emu-correct-bus-dev-fn.patch
[22:28] <bryce> patching file hw/xfree86/int10/helper_exec.c
[22:28] <bryce> Hunk #1 succeeded at 469 (offset -80 lines).
[22:28] <bryce> Hunk #2 FAILED at 480.
[22:28] <bryce> Hunk #3 FAILED at 494.
[22:28] <bryce> patch: **** malformed patch at line 61: PCI_OFFSET(PciCfg1Addr) + offset);
[22:28] <bryce> P
[22:30] <bryce> checking other patch...
[22:30] <bryce> Q-FUNK: I did think about this some.  What I'd like to do is before uploading to gutsy-proposed, to put up a deb and get a few people to test it on gutsy systems, to make sure it doesn't cause X to fail to start
[22:31] <bryce> Q-FUNK: if we can get three thumbs up, I say let's stick it in gutsy-proposed 
[22:31] <bryce> oops, the other patch also failed to apply
[22:33] <Q-FUNK> :(
[22:33] <Q-FUNK> let's ask bartman
[22:34] <bryce> hang on, I am looking into it deeper
[22:34] <bryce> I can usually fix up patches to apply, if they're not too intricate
[22:43] <bryce> Q-FUNK: hmm, those patches appear to be against current xserver head.  Let me check them against xserver 1.4
[22:49] <bryce> nope
[22:54] <Q-FUNK> bryce: I just told Bart and Gadi about it
[22:54] <jcristau> i'm not sure what patches these are, but if they're for a post-pciaccess server, then they might need porting
[22:54] <bryce> ok, I'm trying to do the patches manually
[22:55] <bryce> jcristau: ah that might be; yes they appear to deal with pci tags
[22:55] <bryce> hmm, that might be more work than I have time for
[22:56] <Q-FUNK> indeed
[22:56] <Q-FUNK> never mind
[22:56] <Q-FUNK> I'll ask bartman to rebase against 1.3 for the test
[23:07] <ubotu> New bug: #182743 in xorg (main) "hardy xorg not detecting for compaq evo n410c" [Undecided,Confirmed] https://launchpad.net/bugs/182743
[23:09] <bryce> Q-FUNK: ok cool