[02:28] <ubotu> New bug: #200407 in xorg (main) "Notifications" [Undecided,New] https://launchpad.net/bugs/200407
[02:28] <ubotu> New bug: #200411 in xorg (main) "[hardy] Recent update gives 400x300 resolution after login" [Undecided,New] https://launchpad.net/bugs/200411
[06:20] <ubotu> New bug: #185423 in wine (universe) "Wine crashes and close my session went to login screen (dup-of: 178292)" [Undecided,New] https://launchpad.net/bugs/185423
[08:41] <ubotu> New bug: #197639 in linux-restricted-modules-2.6.24 (restricted) "[hardy] fglrx xv output not available for video playback" [High,Confirmed] https://launchpad.net/bugs/197639
[08:46] <tjaalton> bryce: around?
[09:11] <bryce> tjaalton: heya, just on the way to bed.  what's up?
[09:12] <tjaalton> bryce: hi, I won't hold you for long, just wanted to get your ack/nack for bug #87947
[09:12] <bryce> ok
[09:13] <tjaalton> xcb enabled libx11 is breaking apps that use old java's (up to java6)
[09:13] <tjaalton> that's well known, and there's the environment variable to use sloppy locking instead
[09:14] <tjaalton> my plan is to use sloppy locking by default
[09:16] <bryce> that sounds like the most logical solution to me as well
[09:17] <tjaalton> it still prints an ugly trace, but the app runs
[09:17] <bryce> well that's better than a crash
[09:18] <tjaalton> so, I'll upload a new libxcb once I get the logic right ;)
[09:18] <bryce> sounds like it's unlikely to cause further regression, but it'll be smart to keep an eye on it
[09:19] <tjaalton> the other option would be to set the variable in /etc/environment, but upgraders would still be affected
[09:19] <bryce> true
[09:20] <bryce> would it be possible for people to turn it off with an env variable?
[09:20] <tjaalton> that's what I'm trying to accomplish
[09:20] <tjaalton> the first iteration didn't work out :)
[09:35] <ubotu> Launchpad bug 87947 in libxcb "xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed." [High,Fix committed] https://launchpad.net/bugs/87947
[09:35] <bryce> yay
[09:36] <tjaalton> ubotu is snappy today
[09:36] <ubotu> Sorry, I don't know anything about is snappy today - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[09:43] <tjaalton> bryce: also, I'd like to pull some upstream fixes for at least xserver and libx11
[09:49] <bryce> sure
[09:49] <bryce> I was thinking we ought to look for upstream fixes
[09:52] <bryce> I've got some more xrandr gui changes I'm going to work on tomorrow
[09:57] <pwnguin> heh, reflections?
[10:08] <bryce> night
[10:11] <tjaalton> night
[10:19] <tjaalton> ffs, can't get the logic right with sloppy lock.. it's either always on or always off
[10:20] <tjaalton> and the reason must be something stupid
[12:16] <ubotu> New bug: #200086 in xserver-xorg-video-ati (main) "[hardy] visual effects require proprietary drivers don't needed in gutsy" [Undecided,Confirmed] https://launchpad.net/bugs/200086
=== mvo_ is now known as mvo
[14:04] <ubotu> New bug: #200568 in linux-restricted-modules-2.6.24 (restricted) "Ubuntu hardy does not provide suspend or hibernate on Thinkpad laptop T61 with NVidia" [Undecided,New] https://launchpad.net/bugs/200568
[14:58] <ubotu> New bug: #200589 in linux-restricted-modules-2.6.24 (restricted) "fwlanusb crashes the system" [Undecided,New] https://launchpad.net/bugs/200589
[15:21] <tjaalton> hmm, should I just merge libx11-1.1.4..
[15:28] <Ng> we support the x3100, right? :)
[15:35] <tjaalton> it's basically a 965 AFAIK
[15:39] <Ng> ok
[15:39] <Ng> because I seem to own one now :o
[15:40] <tjaalton> heh
[15:40] <Ng> I couldn't resist buying an X300 ;)
[15:41] <tjaalton> damn you :)
[15:43] <Ng> it sucks working within lunchbreak distance of a really good lenovo dealership ;)
[15:48]  * Ng worried by tjaalton's hints of jealousy, I don't want to see any uploads with "break Ng's laptop" in the changelog
[16:02] <tjaalton> hehe
[16:03] <tjaalton> I just got an X61, and soon after comes X300 :P
[16:22] <Ng> tjaalton: just booted alpha6 and it's at least guessed the right resolution I think :)
[16:43] <ubotu> New bug: #200632 in xserver-xorg-video-intel (main) "[gutsy] Opengl applications' windows are not refreshed with compiz when partially hidden on the right (intel drivers)" [Undecided,New] https://launchpad.net/bugs/200632
[16:48] <ubotu> New bug: #200638 in xserver-xorg-video-openchrome (main) "The OpenChrome driver provided in Synaptics is old" [Undecided,New] https://launchpad.net/bugs/200638
[16:53] <Ng> although it did just display a lot of noise when it quit X to shutdown the livecd
[16:53] <Ng> I think I've seen a bug about that before
[17:35] <ubotu> New bug: #200654 in linux-restricted-modules-2.6.24 (restricted) "Screen flickers badly before screensaver with fglrx 8.2" [Undecided,New] https://launchpad.net/bugs/200654
[17:38] <seb128> bryce: around?
[17:38] <bryce> yup
[17:38] <seb128> bryce: in case you didn't notice g-s-d is broken again for radeonhd users apparently
[17:38] <bryce> ok, I'll look.  bug id#?
[17:39] <seb128> bryce: your patch was sort of working because the configure was not setting HAVE_XRANDR in the previous version, so the xrandr code was just disabled for everybody
[17:39] <seb128> the new version does set it correctly
[17:39] <seb128> so the xrandr code is used
[17:39] <seb128> I think you need a runtime check there
[17:39] <seb128> bug #199260
[17:39] <ubotu> Launchpad bug 199260 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV when using radeonhd driver" [Medium,Incomplete] https://launchpad.net/bugs/199260
[17:40] <seb128> bub #197645
[17:40] <seb128> bug #199245
[17:40] <ubotu> Launchpad bug 199245 in gnome-settings-daemon "gnome-settings-daemon crash opening any window: "BadWindow" X error under Xvnc" [Low,Incomplete] https://launchpad.net/bugs/199245
[17:40] <bryce> thanks, looking
[17:41] <seb128> you are welcome
[17:41] <seb128> as said what 92_gsd-xrandr-version-check.patch was basically to disable the xrandr code for everybody
[17:42] <seb128> since the configure was not setting the define
[17:42] <bryce> hmm, 199245, comment 1 suggests it's an issue with the keyboard plugin
[17:43] <bryce> 199260 unfortunately does not have a backtrace
[17:44] <seb128> I was just picking some on the list
[17:44] <bryce> ah
[17:44] <seb128> let me find the mails I read about that yesterday
[17:44] <bryce> ok
[17:44] <seb128> bug #197153
[17:45] <ubotu> Launchpad bug 197153 in gnome-control-center "gnome-settings-daemon crashed with SIGSEGV" [Medium,Confirmed] https://launchpad.net/bugs/197153
[17:45] <seb128> and bug #199960
[17:45] <ubotu> Launchpad bug 199960 in gnome-settings-daemon "error starting GNOME Settings Daemon" [Undecided,Confirmed] https://launchpad.net/bugs/199960
[17:45] <seb128> those should be the correct ones
[17:47] <bryce> yeah, I remember when I put the XRANDR define fix, I was not expecting that alone would solve it, and was very surprised that it did
[17:47] <bryce> the issue seems to be that radeonhd promises xrandr 1.2 but for some reason isn't delivering
[17:48] <bryce> I wonder if there's some other way to detect and disable it
=== asac_ is now known as asac
[19:19] <tjaalton> Ng: actually, X61 has the same chip, so it definately is working ;)
[19:53] <Ng> tjaalton: interesting. I noticed in lspci it looks a lot like a 965 ;)
[19:53] <Ng> I have no sound or suspending or brightness control yet though ;)
[20:19] <ubotu> New bug: #173418 in xorg (main) "[Hardy] NVIDIA cards using vesa driver and low screen resolutions on livecd" [Undecided,Confirmed] https://launchpad.net/bugs/173418
[20:36] <bryce> tjaalton: btw, did you make a decision on my force-all-greedy patch?  (bug 177492, http://people.ubuntu.com/~bryce/Uploads/)
[21:01] <tjaalton> bryce: I just forgot it :/
[21:02] <tjaalton> but I'll upload it tomorrow
[21:02] <tjaalton> btw, the patch for libxcb is making me crazy
[21:03] <tjaalton> I just can't understand why this doesn't work: http://users.tkk.fi/~tjaalton/dpkg/100_sloppy_lock.diff
[21:04] <tjaalton> the if-clause is never true
[21:04] <tjaalton> but I made a test program where it works
[21:06] <ubotu> Launchpad bug 177492 in xserver-xorg-video-intel "EXA is balls-achingly slow" [Critical,Confirmed] https://launchpad.net/bugs/177492
[21:07] <bryce> tjaalton: lemme take a quick look.
[21:08] <tjaalton> dropping 'if' had some other problems
[21:11] <tjaalton> oh right, it would set sloppy_lock = 0; if the variable is not set
[21:12] <bryce> ok, well the if() statement looks redundant
[21:13] <bryce> is what you want to do, to interpret the value set in LIBXCB_ALLOW_SLOPPY_LOCK?
[21:15] <tjaalton> basically yes, but so that if it's not set leave sloppy_lock=1
[21:16] <bryce> http://pastebin.ubuntu.com/5556/
[21:17] <bryce> the != 0 is just checking if the pointer is NULL, so will return true always, whether the string is set to 0, or 1 or "foobar"
[21:17] <bryce> using atoi() to convert the string into an integer is probably what you want
[21:18] <tjaalton> the if() is straight from the old patch for feisty (which was pulled later), so maybe it didn't work there either :/
[21:19] <bryce> it looks like it was just checking if the env var was present; looks like it could have been set to anything (even 0), and that would turn it on
[21:23] <tjaalton> right..
[21:27] <tjaalton> ok, now the question is should I keep the same variable name
[21:28] <tjaalton> or use LIBXCB_NO_SLOPPY_LOCK like before
[21:41] <bryce> hmm
[21:42] <bryce> LIBXCB_DISABLE_SLOPPY_LOCK would probably be more explicit
[21:44] <tjaalton> refreshed the link
[21:45] <bryce> that looks ok
[21:51] <tjaalton> ok, thanks
[21:51] <tjaalton> sigh, trying to debsign the -intel for upload, but it's not my day apparently
[21:59] <tjaalton> hmm, wrong tool
[22:31] <tjaalton> bryce: ok, -intel uploaded..
[22:31] <bryce> awesome, thanks
[22:46] <seb128> bryce: any news on the g-s-d crasher?
[22:47] <bryce> seb128: I've been looking at the bugs and sorting things out, but haven't discovered the underlying cause there
[22:47] <bryce> seb128: we already have a check for xrandr version=1.2 afaik, so it seems there is something more at work
[22:48] <seb128> bryce: ok, I'll have a look tomorrow and drop the patch if I don't find what is causing the issue
[22:48] <seb128> bryce: GNOME 2.22.0 is due this week and we have quite some user running hardy to try it
[22:49] <seb128> it's not good to have GNOME crashing for many of those so we need to fix the situation either way
[22:49] <bryce> seb128: which patch would you be dropping?
[22:49] <seb128> the xrandr gsd changes
[22:49] <seb128> we can reapply those once the issue is fixed
[22:50] <seb128> but as said we need a stable GNOME by wednesday
[22:51] <ubotu> New bug: #199960 in gnome-settings-daemon (main) "error starting GNOME Settings Daemon (dup-of: 198951)" [High,Confirmed] https://launchpad.net/bugs/199960
[22:51] <seb128> bryce: we had the patch not applied for a week and nobody noticed so I don't think it'll be a real issue
[22:52] <ubotu> New bug: #197813 in firefox-3.0 (main) "blogspot webpage messed up in rendering (dup-of: 186186)" [Undecided,Confirmed] https://launchpad.net/bugs/197813
[22:55] <ubotu> New bug: #200785 in xserver-xorg-video-nv (main) "please sync from Debian unstable" [Undecided,New] https://launchpad.net/bugs/200785
[23:00] <ubotu> New bug: #200788 in xserver-xorg-input-aiptek (universe) "please sync from Debian unstable" [Undecided,New] https://launchpad.net/bugs/200788
[23:28] <bryce> seb128: I think this patch may be our culprit:  http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=c6c284e64b1f537a3243856cf78cf3f2324e4c2b;hp=33b94da6327d3423b4ebc1a58d5894c9904e67c9
[23:29] <seb128> bryce: ah?
[23:29] <seb128> bryce: it's not obvious from the changeset ;-)
[23:29] <seb128> bryce: btw thanks for the bug triage and looking to the issue
[23:30] <bryce> well, the bug we were having before was that pointer was NULL; in looking at the traces (wish we had mroe detailed gdb output), it seems the pointer is defined, but to a random value
[23:31] <bryce> Matthias Hopf is one of the radeonhd developers and I saw him discussing the problem in a mail post, and mentioned he had a fix, so I looked around in git and found this
[23:31] <bryce> sort of a convoluted path to find a patch, but we just need to get someone to test it.  I'm packaging the patch for testing presently
[23:32] <bryce> but this would totally explain why we're seeing the same effect on several drivers, but not on the "main" ones
[23:32] <bryce> the main ones probably have workarounds 
[23:32] <seb128> ok, I was going to ask why not the main ones
[23:32] <seb128> that's worth testing ;-)
[23:34] <bryce> btw, I did check thoroughly into the version 1.2 detection, and it's definitely there.  Plus, the drivers being reported as having problems definitely do advertise xrandr 1.2 support (radeonhd even says partial 1.3 support), so version checking wouldn't help in this case anyway
[23:35] <seb128> I've buggy configuration there
[23:35] <seb128> but I can test on a radeonhd box tomorrow
[23:35] <seb128> gra
[23:35] <bryce> excellent, thanks
[23:35] <seb128> I've *no* buggy configuration there
[23:35] <bryce> I'll post dsc and deb
[23:35] <seb128> you should use a ppa ;-)
[23:36] <bryce> honestly I'm not sure what the advantage of ppa is (I did try it out after your last suggestion)
[23:36] <bryce> it gives amd64 builds, but otherwise is extra maintenance overhead, and you can't put debdiffs or README's into it
[23:36] <seb128> build for free on several archs
[23:36] <seb128> and apt sources easy to use
[23:37] <bryce> just x86 and amd64, no?
[23:37] <seb128> extra maintenance overhead? 
[23:37] <seb128> you just have to dput
[23:38] <seb128> x86 lpia amd64
[23:38] <bryce> for like if you need to clean things up later, you must use the web ui, you can't just ssh in.  Also it's harder to organize the files (like if 3 packages need installed together)
[23:38] <seb128> well, depends of your workflow
[23:38] <bryce> probably
[23:38] <seb128> I don't use it a lot neither, but I think it's cool
[23:39] <bryce> I can sure see it useful for several use cases
[23:39] <seb128> I've no amd64 install so getting binaries in a easy way is already something
[23:39] <bryce> I usually compile to deb before uploading anyway, so having to wait the extra time for the ppa to finish building kind of disrupts my workflow
[23:39] <seb128> and an apt source is easier to use than wget random debs and installing those
[23:40] <bryce> that may be, however I haven't had that many complaints
[23:40] <seb128> for testing one deb wget is fine
[23:40] <seb128> for things like daily language pack updates a ppa rocks ;-)
[23:40] <bryce> heh, I bet
[23:41] <bryce> anyway, I'm thinking/planning on making more extensive use of it for x testing and auto-driver builds when I get time to set those up
[23:44] <ubotu> New bug: #200791 in xorg (main) "[hardy] the mouse doesn't respond (move) in X after upgrade of diplay manager (gdm and kdm)" [Undecided,New] https://launchpad.net/bugs/200791
[23:44] <ubotu> New bug: #200797 in linux-restricted-modules-2.6.24 (restricted) "nvidia not loading in 2.6.24-12-generic" [Undecided,New] https://launchpad.net/bugs/200797
[23:44] <bryce> http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=184e571957f697f2a125dc9c9da0c7dfb92c2cd9
[23:44] <bryce> oops mis-paste
[23:49] <bryce> mm, found several other xrandr patches that would be good to have.  I'll make a bundle of them; these could solve a few issues...