[00:18] <bryce> http://bryceharrington.org/drupal/zap
[06:00] <tjaalton> bryce: hope it does it's job to silence the minority
[06:55] <bryce> thanks for mentioning the alt-sysrq-k on the merge thread; I'm not sure how to add replies to that other than replying to emails
[07:11] <tjaalton> yep, me neither
[07:49] <bryce> heya mvo
[07:49] <mvo> hey bryce
[07:50]  * mvo yawns
[07:53] <mvo> is there a consensus now on the discussion about the dontzap option? 
[07:54]  * mvo reads the mails about it
[07:56] <bryce> mvo: see my blog as well
[07:56] <pwnguin> i cant believe it went this long without noticing
[07:56] <bryce> mvo: I don't know that we necessarily have consensus, but we do have definitive sabdfl direction on it
[07:58] <bryce> I don't think we really need the checkbox anyway; we still have alt-sysrq-k which seems to work just as well for me
[07:59] <mvo> ok, I will revert the merge again
[08:00] <bryce> thanks mvo
[08:05] <tjaalton> i was surprised to see the merge request, since there had not been any discussion about adding it to the capplet
[08:07] <bryce> tseliot had emailed me and rick privately with the idea.
[08:07] <bryce> in hindsight probably should have been discussed more widely first
[08:07] <mvo> I had the impression this was part of the uds discussion already
[08:08] <mvo> a bit unfortunate that alberto did the work on it and now its not being used :/
[08:10] <bryce> yeah, for kubuntu we decided at the uds session to have a checkbox for it.  For ubuntu we actually decided to make it available in the xorg.conf options editor
[08:10] <bryce> however tseliot is thinking he may not get that sufficiently done in time, so suggested doing a checkbox for gnome as well, for the time being
[08:12]  * mvo nods
[08:12] <mvo> about the transition for fglrx->ati, I think that is straightforward, I will answer in detail today
[08:15] <bryce> thanks.  Yeah it will be good to have that in our back pocket
[08:16] <bryce> after my last confcall with them I think we may need that in the future
[08:35] <bryce> new troubleshooting guide --  https://wiki.ubuntu.com/X/Troubleshooting/HugeFonts
[09:59] <marijus1> what are the prerequisites to get kms working on jaunty with intel?
[10:00] <jcristau> marijus1: a new kernel, and possibly rebuilding the driver against that
[10:01] <jcristau> not sure about the latter
[10:01] <marijus1> i got .29-rc3
[10:01] <RAOF> Depends on how much you want X to work, I think.
[10:01] <marijus1> :D
[10:02] <marijus1> well... i tried... and gdm was kind of not messed up
[10:02] <jcristau> if you want things to work somewhat better, you probably want master of the driver and libdrm, instead of the releases
[10:02] <RAOF> And probably building the kernel modules from master wouldn't hurt.
[10:03] <jcristau> RAOF: .29-rc3 is fine
[10:03] <jcristau> results will depends on the chipset, too. and you need to use uxa iirc
[10:03] <marijus1> so jaunty libdrm is not suited for that?
[10:03] <RAOF> Cool.  Ish.  More cool would be if nouveau did it :)
[10:06] <marijus1> i got an 855GM :)
[10:06] <jcristau> ah. that's probably not going to work
[10:06] <marijus1> not yet... or never ever?
[10:07] <jcristau> not yet
[10:07] <marijus1> well i guess ill try anyway...
[10:10] <marijus1> does it also have anything to do with mesa?
[10:11] <bryce> marijus1: 855 is just such an old chip...
[10:11] <marijus1> i know :)
[11:20] <dholbach> hello my friends - how are you doing?
[11:21] <dholbach> I was wondering if somebody knew the magic silver bullet to make my compose key and the "usual accents" and stuff work on my intrepid and jaunty again
[11:21] <dholbach> ~n  'e  `e  ^e  ,c  "i  is the stuff that I get right now
[11:21] <dholbach> with German Eliminate Dead keys
[11:21] <dholbach> and a compose key set
[11:23] <dholbach> the might seb128 says it might be xkeyboardconfig
[11:27] <dholbach> œ ñ é è ê ç ï - seems like I have to use the right strg key
[11:27] <dholbach> everything else either blocks other key combinations or does not work
[11:28] <dholbach> the behaviour definitely changed
[11:28] <dholbach> s/strg/ctrl
[11:34] <Ng> mmm, compose. I probably can't help, I just told gnome to use Alt-Gr as compose and it kinda just worked with the UK layour ;)
[11:46] <dholbach> thanks Ng - I fixed it now
[11:46] <dholbach> using "Germany" instead of "Germany Eliminate Dead Keys"
[11:46] <Ng> huh
[11:47] <dholbach> and the right win key or is it a menu key(?) does not work for me
[11:47] <dholbach> Germany with Ctrl as compose works
[11:47] <dholbach> very weird
[11:47] <dholbach> I hope I get it working on jaunty on the other machine now too
[11:47] <dholbach> I felt stupid and illiterate for not writing names properly :)
[11:51] <dholbach> works in jaunty now too
[11:51]  * dholbach is happy
[11:51] <dholbach> thanks again my X friends
[13:08] <ogra> hmm, did Xorg drop support for ~/.xsession ? 
[13:08] <jcristau> no
[13:08] <ogra> creating a .xsession in my homedir that just contains xterm makes startx fail 
[13:09] <ogra> removing that file gets me to a desktop proper
[13:09] <jcristau> define fail
[13:12] <ogra> its in qemu ... so it uses fb0 ... i see (==) using config file: "/etc/X11/xorg.conf" which is a completely empty file apparently 
[13:12] <ogra> next line says "Primary device is not PCI" (how did it know that ! :) )
[13:13] <ogra> then an xkbcomp warning 
[13:13] <ogra> and then: waiting for X server to shut down ddxSigGiveUP: closing log
[13:13] <ogra> thats all
[13:14] <ogra> removing .xsession just works
[13:15] <ogra> its an armel install done with d-i with yesterdays iso 
[13:16] <ogra> gdm works as well btw ... but both, gnome and gdm are just to heavy since the arm qemu has a restriction to 256M
[13:16] <ogra> so i wanted to use an xterm to be at least able to test single apps
[13:17] <ogra> nothing in the log either, no errors or anything
[13:19] <ogra> looks like X itself comes up fine but doesnt go to the .xsession file 
[13:21] <ogra> same if i put gnome-terminal instead f xterm in there
[13:22] <ogra> hmm, works with metacity (which indeed doesnt get me anywhere)
[13:22] <ogra> argh and no zapping ... 
[13:22]  * ogra reboots the VM and grumbles
[13:25] <ogra> hmm
[13:25] <ogra> metacity &
[13:25] <ogra> xterm
[13:25] <ogra> doesnt work either 
[13:26] <ogra> the other way round metacity starts but i dont get an xterm ... 
[13:27]  * ogra doesnt get it
[13:28] <ogra> aha !
[13:29] <ogra> .xsession-errors: xterm Xt error: Unresolved inheritance operation
[13:29] <ogra> whatever that means ... it prevents treminals from starting apparently
[14:20] <tjaalton> bryce: heh, not a single comment on your blog, or maybe they are on the moderation queue?
[17:59] <bryce> tjaalton, oh yeah probably in the moderation queue
[19:00] <Rocket2DMn> hey bryce , got a few minutes?
[19:02] <bryce> Rocket2DMn: sure
[19:02] <Rocket2DMn> cool, ive been working on bug 322610 triage for a friend
[19:03] <Rocket2DMn> ive been having trouble deciding on the package to file under, im thinking it might be the intel driver though, which is why im asking you
[19:03] <Rocket2DMn> since in Xorg.0.log intel is talking about the backlight
[19:03] <bryce> mmm
[19:04] <bryce> gnome-power-manager would be my first guess
[19:04] <bryce> often problems with backlights are ACPI issues rather than X.
[19:04] <Rocket2DMn> yeah the bug was originally filed under gpm
[19:05] <bryce> that said, there have been some cases where it is the video driver that's at fault.
[19:05] <Rocket2DMn> but the problem kicked in only after a kernel upgrade, so i filed it under linux as a hardware regression
[19:05] <Rocket2DMn> the kernel upgrade came in the other day, the intel driver update a few days before
[19:05] <bryce> yep that's also possible
[19:05] <kees> Rocket2DMn: you can booting an earlier kernel, or downgrading the intel driver?
[19:06] <Rocket2DMn> kees, i had him reboot into an older kernel and the problem goes away
[19:06] <Rocket2DMn> there are attachments on the bug from both kernels, but the logs basically line up
[19:06] <Rocket2DMn> there was a quirk in hal, the older kernel picked up 2 compter_backlight entries, whereas the new kernel only saw one
[19:08] <Rocket2DMn> thinkpad_acpi has some stuff in kern.log but its the same in both, it looks like its surrendering control
[19:08] <Rocket2DMn> which seems normal in this case
[19:09] <bryce> yeah, sounding a lot like an acpi kernel issue
[19:09] <bryce> Rocket2DMn: speak with ogasawara who is the kernel bug triage person, to help get attention on your bug
[19:10] <Rocket2DMn> alright, its not my bug, its a friend's
[19:10] <Rocket2DMn> ill ping her about that
[19:10] <Rocket2DMn> do you think its ok under linux or should it be under acpi-support?
[19:10] <pwnguin> its kind of unfortunate that one person determines what kernel devs do and don't see
[19:11] <pwnguin> if you follow all the triage rules, it still won't make it onto her "suggested bugs of the week" list
[19:11] <Rocket2DMn> i think sometimes she is a little slow to look at some bugs, but im sure the kernel team is very busy
[19:12] <pwnguin> rocket2dmn: well, its also easy to fall off her radar
[19:12] <Rocket2DMn> yeah, i dont doubt that
[19:12] <bryce> at least there is a process; it was worse before
[19:13] <Rocket2DMn> hehe, yeah, i guess they decided at the last UDS to not have triagers assign bugs to the kernel team either
[19:14] <Rocket2DMn> i think that's unfortunate, but i hope it helps their process
[19:16] <bryce> tjaalton, ok comments are up at http://www2.bryceharrington.org:8080/drupal/zap
[19:19] <tjaalton> bryce: cool :)
[19:20] <bryce> heh, most common message is that yet again macbook is missing keys
[19:21] <bryce> it baffles me why people buy macbooks when they are missing so much functionality
[19:21] <jcristau> tell them to get a real computer :)
[19:21] <bryce> anyway, presumably they still have a power button at least
[19:22] <tjaalton> hehe
[19:45] <tjaalton> bryce: hmm, still can't see the comments there
[19:57] <bryce> really? hm
[19:58] <bryce> tjaalton, try reloading?  they should all be there
[20:00] <tjaalton> still nothing.. bad firefox
[20:00] <tjaalton> oh well, maybe I don't want to read them anyway
[20:01] <tjaalton> s/want to/*shouldn't*/
[20:01] <tjaalton> uh, s/don't//
[20:02] <tseliot> tjaalton: firefox knows what's better for you :-P
[20:02] <tjaalton> tseliot: seems to be the trend ;)
[20:02] <tseliot> hehe
[20:02]  * tseliot -> away
[20:03] <bryce> I really need to upgrade drupal...
[20:05] <bryce> tjaalton, could you try again?  I tried a different method for publishing the comments this time
[20:06] <tjaalton> bryce: shiny.. works this time
[20:07] <bryce> awesome
[20:29] <tjaalton> nothing too alarming there. on my thinkpad I don't need to use Fn, but altgr instead of alt
[20:30] <tjaalton> so maybe documenting "the new behaviour" isn't that straightforward as would be ideal
[20:32] <bryce> yeah
[20:33] <bryce> tjaalton oh btw, what do you think of that patch for kees' bug to change the max client limit?
[20:48] <jcristau> hrm. the vmmouse_detect(1) manpage upstream says 'report bugs to launchpad'.
[20:48] <jcristau> should that be changed to fd.o bugzilla?
[20:50] <bryce> jcristau: interesting; yes that should be changed
[20:51] <jcristau> the manpage has your copyright so it's not too surprising, just noticed it while looking at getting the latest version in experimental
[21:08] <jcristau> http://people.debian.org/~jcristau/0001-Point-to-freedesktop.org-bugzilla-instead-of-launchp.patch
[21:36] <bryce> jcristau: wow nice.  I didn't know about @PACKAGE_BUGREPORT@ before
[21:37] <jcristau> yeah it's the third argument to AC_INIT
[22:14] <tjaalton> bryce: yeah, I do agree
[22:14] <bryce> working on the 'High CPU' bugs this afternoon
[22:15] <tjaalton> the gnome-madness bug you say?
[22:15] <bryce> it feels very nice to be able to drop bugs as "looks like a client-side application problem to me"
[22:15] <bryce> oh all over the place.  one was an xfce-theme problem (just two themes triggered it)
[22:15] <tjaalton> hehe
[22:16] <bryce> "I notice these two themes do some really intense gradient animation... no idea if that's related..."
[22:16] <bryce> also appears kde was doing monitor polling with xrandr calls every 10 sec at some point too
[22:17] <bryce> http://jakob.petsovits.at/projector-fun
[22:18] <bryce> it drives me crazy that even after people realize the problem was caused by something other than X, they still blame X for their problems ;-)
[22:18] <bryce> silly people
[22:21] <tjaalton> yeah, more work for the cluebat
[22:29] <bryce> tjaalton, btw I pushed out the xorg changes that were sitting in git.  Figured we should get them out for alpha-4 next week
[22:33] <bryce> making bug 294972 master for cpu load issues
[23:01] <tjaalton> bryce: ok, did you push the release commit?-)
[23:01] <bryce> oh yeah
[23:02] <tjaalton> k, our spamfilter must've eaten it
[23:02] <bryce> no I mean, "Oh yeah, <mumble> git <mumble> needs to be committed still..."
[23:02] <tjaalton> hehe
[23:02] <bryce> pushed
[23:03] <tjaalton> thanks
[23:04] <bryce> oh btw, seb128 is thinking about dropping the forced 96 dpi in gnome next week at the sprint
[23:04] <bryce> so we might get more of those "HUGE font" bugs
[23:05] <tjaalton> figures
[23:05] <tjaalton> did I already ask about 'gdm on vt1'?-)
[23:06] <tjaalton> I guess we need a flamewar for jaunty+1 too
[23:06] <bryce> hehe
[23:07] <bryce> we need a section in the release notes titled, "How X will piss you off to no end in this release of Ubuntu"
[23:08] <tjaalton> I've been running X on vt1 since UDS. very few changes needed, gdm and system-services (drop /etc/event.d/tty1)
[23:08] <bryce> we can end it with a link to the Wayland home page
[23:08] <tjaalton> bwaha
[23:09] <tjaalton> "a teaser of what we'll see... in 2017!"
[23:32] <bryce> ok, high cpu bugs done.  I was able to drop x from almost all of them, except a couple that actually were xserver lockups
[23:32] <bryce> ok, lunchtime
[23:35] <tjaalton> whoa, first real nouveau bug
[23:35] <tjaalton> bug 323377
[23:38] <bryce> sweet
[23:46] <bryce> I'll close it
[23:47] <tjaalton> well, even though it's not really supported, it might be nice to see how the driver progresses
[23:48] <bryce> hank you for testing the new -nouveau driver and reporting your finding of a problem.
[23:48] <bryce> However, while we are providing -nouveau for testers to experiment with, we are not yet supporting -nouveau in Ubuntu and will not be following up on this bug at this time.
[23:48] <bryce> It sounds like you have a good lead on finding a solution to this problem associated with lvds detection though, and I would strongly encourage you to contact the upstream developers directly and work with them on finding a solution.
[23:48] <bryce> +T
[23:59] <tjaalton> getting late.. night!