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