[00:53] hello, all, does somebody know if there is a known issue with single clicks sometimes being registered as double clicks, and at other times double clicks _not_ being recognized as such? [00:53] (mouse butten clicks) [00:53] button [01:17] did you look in launchpad? [01:21] not (really) yet, was just wondering if it's a well-known bug [01:27] at first sight I can't find anything, but not sure what to search for :-/ [01:29] https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-mouse/+bug/365300 sounds similar [01:30] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/365300/+text) [01:31] it's like some events are eaten, and others are duplicated, or whatever [01:32] maybe I should also try with a wired mouse, but this didn't happen before karmic [01:33] and https://bugs.launchpad.net/ubuntu/+bug/339256 & https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/333005 [01:33] Launchpad bug 339256 in ubuntu "Double mouse click every time I single click" [Undecided,Incomplete] [01:35] and https://bugs.launchpad.net/ubuntu/+bug/325127 [01:35] Launchpad bug 325127 in ubuntu "Ubuntu 8.10 Logitech LX7 Cordless Optical USB Mouse issues with single clicks being double clicks, multiple clicks for action etc." [Undecided,New] [01:35] and https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/275590 [01:35] Launchpad bug 275590 in xserver-xorg-input-evdev "Sometimes single clicks register as double-clicks" [Undecided,Confirmed] [01:36] bryce: seems like I'm not the only one with similar problems, although some have it for a much longer time [01:49] of course the main problem with this seems to be that it's not reproducible in any controlled way :-( [08:22] does anybody know what happened to xorg-driver-fglrx? [08:24] oh wait nevermind [14:00] What is the modern equivalent of dpkg-reconfigure xserver-xorg? My laptop X locked up last night and won't start now. [14:03] i believe it's rm /etc/X11/xorg.conf ;-) [14:03] I'll see if I have one of those now. Last I looked I didn't [14:04] i don't think dpkg-reconfigure touches anything else other than xorg.conf [14:04] Yeah, that's the problem. [14:04] unless you're meaning you want a xorg.conf? [14:04] It used to actually work for reconfiguring X. Now it's mostly a no-op [14:05] i remember there was an option to tell X to dump the xorg.conf [14:05] it doesn't call dexconf anymore [14:05] then you can hand edit it? [14:05] I have no xorg.conf (just looked) [14:06] it worked before the lockup? [14:06] Yep [14:06] I had it freeze once before, but that time restarting the system resolved it. [14:06] Now it fails to start entirely [14:06] do you have a logfile? [14:07] I'd like to get this troubleshot enough to where I can report a good bug. [14:07] Yes. Which do you want? [14:07] the one when it froze [14:07] or both, actually [14:07] You mean Xorg.0.log? [14:08] yes [14:08] OK [14:08] I'll pastebin it in a moment (I have network, but no X on the box in question) [14:09] tjaalton: http://pastebin.com/f4bcfe87d/ [14:10] tjaalton: Sorry, withtout the trailing "/" [14:10] ScottK: which one is this? [14:11] The most recent [14:11] so you don't get a login screen? the log looks fine [14:12] I don't. I just get a black screen [14:13] there was a new intel uploaded yesterday, maybe downgrading it would help? [14:13] Here's a point. startx works. kdm doesn't. [14:13] ah [14:14] Just tried that [14:14] after the final line there should be the config/hal stuff [14:20] http://pastebin.com/f3c2575d7 is now that I've logged in. [14:25] And then once I got into KDE via startx, the next regular boot works. [14:25] huh [14:25] Yeah [14:26] So something got screwed and a successful login cleared it. [14:26] In the future, if X just freezes, what's the most important thing to try and capture? [14:26] if you can login via ssh, get a backtrace [14:27] https://wiki.ubuntu.com/X/Backtracing [14:27] This particular system I have very little luck ssh'ing into, but I'll try. thanks. [14:28] if you can't switch the vt, then there's little you can do on just that system [14:28] s/on/with/ [14:28] OK. I did try that and was unable to. [14:30] maybe the gpu was wedged, there's intel-gpu-tools which might help to get a dump [14:30] but that'd need sshd running AIUI [14:30] OK. I'll install that so I'm more ready for next time. [16:24] bryce, are you online yet? [17:15] rickspencer3, yes [17:15] just did AMD call [18:05] bryce, so ... mesa 7.6 [18:05] what are we going to do? [18:14] well, I guess I can put it in a PPA so as people find they need it we have something they can upgrade to [18:15] bryce, I thought the current plan was to roll it out asap [18:15] with a plan to roll back if needed [18:16] and a set of criteria to trigger the roll back deciscin [18:17] hang on, I've not read all the emails in the thread yet [18:20] huh, ok [18:23] rickspencer3, there is a debian package of it, so we just need to merge it with ubuntu changes [18:24] bryce, ok, the roll back plan will be key [18:24] talking to marjo atm [18:52] thread? [18:55] tjaalton, was offlist; wasn't looking likely when I went to bed, but it seems alberto, rick, and asac worked out an acceptable compromise for us [18:55] cool [18:56] I think it's a no-brainer ;) [19:00] bryce, could you please answer pitti's second question for me? [19:00] [19:00] My other concern is that there doesn't seem to be a final 2.6.0 [19:00] package, just a 2.6.1+gitsomething. If we upgrade to that, then we [19:00] have the very same problem again: a git snapshot instead of a stable [19:00] release. But if there's a tested 2.6.0 somewhere, let's get that [19:00] uploaded (it was pre-approved in LP #420803 anyway). [19:00] Launchpad bug 420803 in xserver-xorg-video-ati "FFe for updating -ati/mesa/libdrm git snapshots until their individual releases" [Wishlist,Confirmed] https://launchpad.net/bugs/420803 [19:00] [19:01] or tjaalton, or anybody ;) [19:15] I've got the debian package and am just checking through our recent cherrypicks to see what can be dropped [19:27] rickspencer3: if it's mesa he's referring to, we'd have a snapshot of the stable branch, not master [19:27] thanks tjaalton [19:28] I think bryce is packaging 2.6.0 for upload atm [19:28] 7.6 was branched after it was released [19:29] tjaalton, specifically, I'm merging from Debian's 7.6-1 package [19:29] ok [19:29] there's only one new bug that I saw from the debian bugtracker that we might not yet have. it's freedesktop bug 24131 [19:29] Freedesktop bug 24131 in Drivers/DRI/Radeon "radeon_bo_legacy.c:207: legacy_is_pending: Assertion `bo_legacy->is_pending <= bo->cref' failed" [Major,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=24131 [19:30] heh, i was going to say that [19:30] :) [19:30] also maybe #550011 [19:31] those are the two mesa bugs reported since 7.6 was uploaded to sid, afaik [19:32] bryce: are you doing libdrm as well? [19:32] tjaalton, after mesa [19:32] tjaalton, or feel free to tackle it yourself if you have some time [19:33] * tjaalton shows puppy-eyes to the wife [19:34] no response, so I have some time ;) [19:35] hah, looks like i prepared 2.4.14 a while ago, but never pushed/uploaded [19:36] nice [19:38] ah, now i remember, i stopped because libpthread-stubs in sid is broken [19:38] oh well [19:39] still is? [19:40] yeah. shouldn't affect libdrm other than adding a bogus dependency on it, though, so i'll go ahead [19:41] * rickspencer3 visualized tjaalton pulling a pair of bloody eyeballs out of his pocket and showing them to his wife [19:41] close to Halloween I guess [19:42] [19:42] there, done [19:43] I've got "contacts" made of a split table tennis ball, they look rather nice [19:45] bryce: mesa itself doesn't need the new libdrm, but it's a prereq for intel 2.9 ;) [19:45] or at least recommended [19:45] as part of the Q32k9 release [20:18] hi, to use radeon KMS in karmic i only need to add the radeon.modeset=1 thing? (i have a r400) [20:21] tjaalton, right [20:21] ilPisano, it's kind of buggy but yeah [20:22] and with KMS i will get DRI2? atm in my xorg.0.log (without KMS) i have "(II) AIGLX: Screen 0 is not DRI2 capable" [20:22] is normal? [20:29] ilPisano, no that is not normal, for ati KMS = DRI2 [20:30] i got that with no kms option, if i enable kms i should not see that error message? [20:30] ilPisano, right [20:30] ty, will try :9 [20:30] :9 [20:30] ilPisano, sorry I did not see you wrote "without kms" [20:30] :) [20:34] hrm, how easy it would be to merge libdrm if the changes since 2.4.12-1u1 were done in git.. [20:35] tjaalton, merging with Debian? [20:35] tormod: yes [20:36] .14-1 was pushed 1h ago [20:36] tjaalton, aha [20:36] I was just about to make one for x-updates, I'll wait a bit then :) [20:37] s/x-updates/xorg-edgers [20:38] huh, 2.4.12+git20090801.45078630-0ubuntu1 was a mess [20:38] tjaalton, so you are gonna get a new libdrm through in karmic? [20:38] based on 2.4.9-2ubuntu1 [20:38] sounds like fun [20:38] tormod: we were discussing it before you joined [20:39] let me browse the log then [20:39] we'll see what comes from this [20:40] jcristau: bad sarvatt :) [20:40] tormod, we reached a compromise last night to get mesa 7.6, etc. in; we need to have a good plan to roll back the changes if there are serious issues [20:40] bryce: what's "etc", intel 2.9 too? [20:40] tjaalton, why do look at 2.4.12+etc when there is 2.4.13-1ubuntu1? [20:41] tormod: I need to track the changed done between 2.4.12-1u1 and nwo [20:41] *now [20:41] *changes [20:41] damn [20:41] sticky kbd [20:42] tjaalton, indeed, since it is mostly a bug fix release I got a go ahead on it; but we should do it on a different day from mesa so it'll be easier for testers to bisect if there are problems. [20:42] bryce, sounds good, where was this discussed? [20:42] bryce: was xserver discussed? [20:43] tormod, unfortunately it was all off list [20:44] tjaalton, yes I got an ok on that too :-) [20:44] meh, I'll bypass 2.4.12+git200909... and just look at what's in .13-1u1 [20:44] debian #548045 is a (ums) regression in 2.9, fwiw [20:44] Debian bug 548045 in xserver-xorg-video-intel "video-intel: [945GM] DVI monitor not detected" [Normal,Open] http://bugs.debian.org/548045 [20:44] bryce: nice [20:44] who cares about ums anyway ;) [20:45] tormod, yeah I put in a complaint about how these decisions were reached, without involving us X folk, but we decided to separate the issue of how this all was decided, from making the correct decisions. The former needs sorted out better, but the latter is the immediate focus. [20:46] bryce, sounds good! [20:46] indeed it does [20:47] perhaps we could put a mesa 7.6-branch snapshot on a ppa right away, so if people report issues with 7.6 they could try it out immediately [20:48] I see some memleak fixes there [20:48] tjaalton, I've a copy of the package I'm working on at https://edge.launchpad.net/~bryceharrington/+archive/ppa/+packages [20:48] reading the log, what package is "2.6.0" ? [20:48] tjaalton, code and patches are all sorted, just need to fill out the changelog [20:49] tormod: a typo, I think [20:49] tormod, that should be 7.6.0 [20:49] tjaalton, x-updates? [20:49] tormod: makes sense [20:49] x-updates == xorg-edgers [20:49] tjaalton, you missed my e-mails on ubuntu-x ? [20:49] looks like it :) [20:49] I put mesa 7.6 into x-updates long time ago [20:49] many people have been testing iy [20:50] bryce, x-updates != xorg-edgers [20:50] xorg-edgers has 7.7 [20:50] right, but a snapshot of the branch, ie. what will become 7.6.1 [20:50] tjaalton, it has [20:50] ah ok [20:50] good [20:51] I updated it every day from before the RC1 [20:51] I had planned to make a new snapshot today [20:51] maybe I should merge libdrm in the morning when feeling more awake [20:52] I'll update my laptop to it [20:52] but was thinking of doing a libdrm first, but I'll hold that off until you've finished the merge :) [20:52] or, maybe via 7.6-1u1 first [20:52] is 7.6-1 out? [20:53] for a week now [20:53] debian is alive again \o/ [20:53] when was it not? [20:53] right :) [20:54] tjaalton, waiting til the morning is a good call [21:12] bryce, how's it going? [21:15] I stuck a preliminary version in my ppa to check that it builds - https://edge.launchpad.net/~bryceharrington/+archive/ppa/+packages [21:15] I've built it successfully locally [21:16] I want to fill in the changelog a bit more before uploading it [21:16] ok [21:16] seems that Steve has some quite valid concerns regarding intil 2.9.0 [21:16] -intel, that is [21:17] ah, I see you replied [21:17] apw, thoughts on -intel 2.9.0? [21:20] bryce, I'll install from your ppa [21:21] oops [21:21] still buidling [21:22] rickspencer3, just want to inform you that many people have been running mesa 7.6 packages from the x-updates PPA with luck [21:23] tormod, thanks [21:23] that is understood, and why we are considering it a fairly safe bet [21:23] the main problem is that we have limited time to complete the feedback loop on a wide set of machines [21:23] and if we want to update -intel as well, we are certainly complicating matters [21:24] rickspencer3, yes it should have been pushed in earlier. but I am pretty confident it fixes a lot more than it would break [21:24] tormod, understood [21:25] we are trying to do the right thing [21:25] sounds like a good plan [21:25] updating -intel as well is giving me some heart ache [21:25] tormod, offhand do you know of bug report#'s which will be solved with mesa 7.6? [21:26] iirc intel 2.8.1 was pretty solid, compared to earlier releases? [21:26] hello, could someone test the following thing for me please: http://pastebin.com/m13b90154 ? I'm tracking a strange performance regression [21:27] lp bugs? no I haven't looked much for it. but there are comments many places where people have been trying out xorg-edgers and say it's better - although that's mesa trunk [21:28] the scary part about intel is if kernel patches are needed [21:28] tormod, I don't think we'll be doing it if it requires kernel patches [21:28] perhaps we should send a summary of these changes to ubuntu-devel list [21:28] allow some discussion [21:28] tormod: well it should run just fine on 2.6.31.2 [21:29] I am not saying that 2.9.0 requires kernel patches [21:29] (and include qa and roll back planning) [21:29] just that many -intel bugs might need kernel patches (whether we ship with an old snapshot or with the 7.6 release) [21:29] ah [21:29] right [21:30] I think intel 2.9 is mostly bug fixes from 2.8. it's not the whole reorganisation we saw in earlier releases [21:31] 2.10 will be the 'no more ums' release [21:33] what is UMS? [21:33] tormod, if I install this: [21:33] https://edge.launchpad.net/~xorg-edgers/+archive/ppa/+sourcepub/756325/+listing-archive-extra [21:33] will I get the intended version of -intel? [21:33] rickspencer3, you should install the libdrm from the same ppa [21:34] so the changes are: [21:34] 1. mesa 7.6 [21:34] 2. libdrm [21:34] 3. -intel [21:34] If I install that now, i will have what will be in Karmic on Friday? [21:34] rickspencer3, all the packages in the xorg-edgers ppa kind of depend on each other, so you better take them all [21:34] oh? [21:35] rickspencer3, note that xorg-edgers has mesa 7.7 (that's the edge) [21:35] rickspencer3, you probably want to try mesa from x-updates ppa [21:35] tormod, I just want to set up my computer so it has the exact bits being proposed [21:36] ah [21:36] rickspencer3, get mesa 7.6 from x-updates and -intel 2.9.0 from drivers-only [21:36] tormod, so I don't need a libdrm as well? [21:36] just the mesa and -intel from x updates? [21:36] rickspencer3, no not for x-updates, it is built against the karmic libdrm [21:37] -intel from "drivers-only" ppa (also no new dependencies) [21:37] (sorry to be dense, but I want to be crystal clear) [21:37] oh [21:37] so, there is no proposal to update karmic's libdrm from what is currently in karmic? [21:38] rickspencer3, ideally you build: libdrm -> mesa -> xserver -> ddx [21:38] so could you educate me on how this is going to go down for karmic? [21:39] as it seems that what is proposed is just a surgical replacement of mesa, and another replacement of -intel [21:39] rickspencer3, there is I think. you _can_ take libdrm 2.4.14 from xorg-edgers, mesa from x-updates and -intel from drivers-only [21:39] when the new mesa goes in, that causes a rebuild of the other components? [21:39] this will give you pretty much what we anticipate for karmic [21:40] what's the "pretty much" factor? [21:40] modula future patches for bug fixes? [21:40] rickspencer3, no, you don't really need to rebuild xserver and dds after mesa updates, unless major rework has been done [21:41] pretty much = if some features in the mesa build checks for features in the installed libdrm, these will not be taken in in these ppas [21:41] I think I'll wait until stuff gets uploaded as normal [21:41] same for ddx, some features are built depending on the installed libdrm, hence the ideal build order [21:42] I think I'll spend so much time having you guys explain everything to me, that my testing will be of no hel [21:42] but, it's good to understand a little better what's going on [21:42] ok I think the mesa 7.6 package is good to go now [21:43] rickspencer3, it's just adding the xorg-edgers ppa, install libdrm, remove xorg-edgers, add x-updates and card drivers and update [21:43] rickspencer3, ok uploaded. [21:43] sweet [21:43] yeah this stuff can all get complicated [21:43] bryce, great [21:43] so dist-upgrade in a few hours, and we've got new mesa [21:44] in our situation right now, we're a bit lucky in that none of these pieces interdepend on each other or on anything else (like the kernel) that we don't have [21:44] tomorrow, same thing with -intel, I suppose [21:44] right [21:44] wasn't their a third piece to update? [21:44] rickspencer3, it will be much less dramatic than say, replace init after feature freeze ;) [21:44] tormod, please, don't go there [21:45] :) [21:45] * rickspencer3 clutches chest [21:45] libdrm and xorg-server are also in scope to do, those are both quite minor and just bug fix releases [21:45] tormod, we are quite worried because of our experience in Jaunty [21:45] "in scope as options to do" [21:45] bryce, ack [21:45] do you need freeze exceptions for those? [21:46] rickspencer3, jaunty shipped with -intel 2.5 instead of the released 2.6 IIRC [21:46] dunno, but I'll go ahead and file FFes for them anyway [21:46] tormod, right, I don't think the situations are comparible [21:46] I think they should be quite straightforward, but any extra public review cannot hurt [21:47] and for everything else than -intel, jaunty was a great step forward [21:47] so I was just referring to the emotions, not the logic of the situation [21:49] the -intel guys were open about things going backwards a bit for a while, and it did. the situation now is different for sure [21:50] rickspencer3, we have so few ubuntu X resources so we have to play well with upstream. but now I going into that longer discussion, let's focus on karmic now :) [21:50] hehe [21:51] I think the right things are happening now [21:51] rickspencer3, shall I put a note about mesa 7.6 to ubuntu-devel, or do you want to do that? === ripps_ is now known as ripps [21:51] bryce, could you please [21:51] karmic just got a lot more karma :) [21:51] bryce, you may want to mention *as planned* [21:51] *occording to our previous plan* [21:51] *as scheduled* [21:51] etc... [21:52] ;) [21:52] alright, on it [21:53] hehe [22:00] I have heard about only one regression on 7.6 (https://lists.ubuntu.com/archives/ubuntu-x/2009-September/000631.html) and it got fixed today [22:03] (just after I made the new x-updates snapshot, of course) [22:51] Hrm. [22:51] Rejected: [22:51] mesa_7.6-1ubuntu1.dsc: Version older than that in the archive. 7.6-1ubuntu1 <= [22:51] 7.6.0~git20090817.7c422387-0ubuntu8 [22:52] i guess you get to rename it to 7.6.0-1u1 [22:54] yep [23:00] bryce, maybe you want to cherrypick the above bug fix before you reupload :) [23:05] too late [23:06] but you're right [23:12] wait till the new libdrm anyway, so it builds in order :) [23:12] ok [23:12] doesn't matter, really [23:13] I guess not, in this case [23:19] how do I disable services at boot in the brave new world of native upstart scripts? [23:19] the services applet seems to have disappeared [23:23] I've seen suggestions to rename the /etc/init/foo.conf to foo.conf.disabled, but I'm not sure how Correct that is [23:25] I'll try it [23:25] wanted to be able to start it later possibly [23:29] hi jbarnes [23:29] rickspencer3: hi [23:44] that's not a bug, it's rendering in Pink for Breast Cancer Awareness month 8-) [23:47] jbarnes, I checked in #ubuntu-devel for you [23:47] indeed, you are kind of on your own, adding and removing files from /etc/init I am afraid [23:48] oh well [23:48] rickspencer3: thanks [23:48] jbarnes, sorry, I will log a bug for you [23:48] essentially, the applet will need to be ported [23:49] rickspencer3: btw did you see the X release process changes we discussed at XDC? [23:49] * jbarnes digs up a link [23:49] http://www.x.org/wiki/XServer [23:49] jbarnes, I did see a reference, but haven't had time to look closely [23:49] bryce, rickspencer3 ^^ [23:49] * rickspencer3 reads [23:49] if it works people could start thinking about moving things around [23:50] might be good to have kernel release, then X, then gnome, then distros [23:50] jbarnes, is there somewhere in there that I could help? [23:50] maybe, I haven't looked at the latest page [23:51] I'd ping peter & xorg-devel [23:51] peter hutterer that is [23:51] I'm not excatly made of free time, but I think we could spare some PM-type resources [23:52] nice to see that they RM lined up [23:52] that is great [23:52] yeah [23:52] we'll see if it sticks [23:53] well, I'll see if I can pick up a couple hours of busy work from it [23:53] free up the engineers [23:53] cool [23:53] bug herding and nagging would both be big helps I think [23:53] yeah [23:54] "those who can't do, nag" [23:54] * rickspencer3 feels hair get a bit pointier [23:55] haha === ripps_ is now known as ripps