[00:52] RAOF, thanks for the help last night [00:53] No problem. [00:54] I wish #gnome was as responsive [02:01] mlankhorst: How hard would it be to fix nouveau EXA in quantal? Text poping in and out of corruption is getting slightly annoying. :) [02:20] dunno but nvidia 302.11 is not doing the best on text corruption for me [02:20] i might need to change the font smoothing or something [02:33] nope just have to stop watching flash videos which now blead through every window i have open [02:37] bandit5432, what hardware is this? [02:37] 9800gtx [02:37] trying to replicate [02:37] oh [02:38] senior citizen [02:38] :| [02:38] i have gtx 560 coming tommorow [02:38] still old but better [02:39] oh i hate flash! [02:40] at least when i turn of hd accl i can watch a full video [02:43] replicated flash videos bleed through kind of cool [02:43] it appears to only bleed through the fonts === bandit5432 is now known as led-bandit [02:53] led-bandit, i'll bet the fermi card is a lot more bug-free [02:53] i am hoping [02:54] 3 year old build and its time for a upgrade [03:45] Man, the xserver build has ALL THE WARNINGS. [04:22] is that why i am getting flooded with info? [04:24] No. Unless you're actually building the xserver :) [04:25] i dont want to build anything [04:25] just reminded me to look and see why plymouth is flooding my screen with info at shutdown and start [04:55] RAOF: we should just update nouveau past the api change, they've worked around it already [04:55] tjaalton: Does there exist a useful mesa past the api change? [04:56] RAOF: ah, not that I know of.. so it would need 8.1git :/ [04:56] Which does or does not build currently? ☺ [04:58] hum ho [04:59] It's not *that* annoying :) [04:59] ok :) [05:21] morning [05:25] RAOF: Depends, do you want to backport the exa fixes? [05:26] Actually I might have to if cairo 1.12 is going to be backported for lts.. [05:28] mlankhorst: if theres ANY way at all you could possibly work out the nouveau exa solid acceleration to the old libdrm-nouveau it would be so much appreciated in both ubuntu and debian [05:28] yeah.. I guess it depends if cairo 1.12 will be used in lts [05:29] debian wheezy is shipping cairo 1.12, but libdrm-nouveau2 needs mesa 8.1 that wont ship until august at least... [05:30] its a really screwed up situation [05:30] I know [05:31] it's not that hard to backport, it's hard to SUPPORT it afterwards :P [05:33] really? i had all kinds of problems just trying to backport it, its a huge change, i wouldn't worry about supporting it after :) [05:33] depends if you have experience with the previous api or not ;-) [05:50] mlankhorst: I don't believe we'll be backporting cairo 1.12 to the lts. [05:50] It's got a *lot* of rdepends, and we don't need it for hardware support [08:38] in either case, seems my beautiful hack works [09:04] great [09:22] beautiful hack sounds promising :) [09:22] seems to work here at least [09:22] http://people.canonical.com/~mlankhorst/xserver-xorg-video-nouveau_0.0.16+git20120523+5815644-1_amd64.deb [09:22] using a private copy of drm/nouveau === yofel_ is now known as yofel [14:54] RAOF: http://www.phoronix.com/scan.php?page=news_item&px=MTEwNTc :D [14:54] hahahaha [14:56] he's good at writing crap about nothing [14:56] jcristau: yes but its great amusement to see what he writes === debfx_ is now known as debfx [14:58] hey, all. My machine is repeatedly locking up hard with coloured static. Details at https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1003333 -- so far it's happened 15 times today, so I'm not getting anything done. It started on monday; before that, there was no problem. Help? :) [14:58] Launchpad bug 1003333 in xorg (Ubuntu) "Ubuntu snowcrashes frequently but with no obvious cause" [Undecided,New] [17:55] bryceh, where did you merge my utouch arsenal branch to? [17:56] it doesn't appear to be merged into lp:arsenal [18:00] cnd, hang on [18:01] cnd, 'tis up [18:03] ok, thanks [18:53] bryceh, is there any moe useful debugging information I can provide tomorrow in https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1003333 ? [18:53] Launchpad bug 1003333 in xorg (Ubuntu) "Ubuntu snowcrashes frequently but with no obvious cause" [Undecided,New] [19:33] aquarius, no response through ssh over ethernet? [19:38] aquarius, ello? [19:39] > bug [19:50] bryceh, sorry. No response over ssh, indeed [19:50] er, that's over wireless [19:50] I haven't tried over wired [19:50] 'cos the laptop doesn't have a wired ethernet port :) [19:51] I don't *believe* the problem is the kernel, since I was running the same kernel two weeks ago and didn't have the problem [19:52] of course, something may have changed on Monday which tickles a previously-existing-but-untickled bug in the kernel I'm running [19:52] I can try booting from a 12.04 usb image [19:52] would hardware borkedness only show up when using 3d? (that is: the hardware might be borked in such a way that it doesn't fail when being used by the vesa driver)? [19:56] aquarius, 3d does tend to exercise the hardware a bit more than 2d. hard to say without more testing [19:56] bryceh, kk. I am happy to test more (I'm happy *now*, anyway, now that I know that vesa works so that I can get work done -- 17 crashes today before I made that switch!), but I don't know what to test. :) [19:57] aquarius, do you know exactly what day the problem started? [19:57] Monday. [19:57] HOwever, I hadn't upgraded for a few days, i don't think. [19:58] so the actual change may have hit one of the repos I'm subscribed to at some point before that. [19:58] I *can* confirm that the change was not a new kernel. [20:00] aquarius, well these are the things you upgraded on monday: http://paste.ubuntu.com/1003605/ [20:00] ha! [20:00] clever. :) [20:00] upgrade linux 2012-05-22 08:46:49 3.2.0-24.37 3.2.0-24.38 [20:01] but I'm not *running* that. [20:01] confused, now. [20:02] I still think it's the kernel, but I see there were also some unity package updates there [20:02] (the kernel update was tuesday actually) [20:02] $ uname -a [20:02] Linux faith 3.2.0-24.37-u300acpifix1-generic #u300acpifix1 SMP Mon Apr 30 11:39:33 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux [20:03] http://paste.ubuntu.com/1003612/ [20:03] (that's a custom kernel built by cking, but it's a stock kernel with one patch to do with usb, and I've been running it for about two weeks) [20:03] watch, it'll be accomplishment-viewer [20:03] * aquarius laughs [20:04] much as i would like to blame jono for this, I don't think it's him this time :) [20:04] is it reasonable to say that by definition any bug which hangs the whole box is a kernel bug? [20:06] well, if it doesn't respond on the ethernet port... if you HAD an ethernet port... [20:07] but actually there's a few ways to hang a box that aren't *caused* by the kernel. [20:08] yeah, if I had an ethernet port I'd try that. :) [20:09] you could try configuring your wireless to system-wide [20:09] https://wiki.ubuntu.com/X/Debugging/WirelessWithoutX [20:09] oh, in case the problem is that my *session* is being closed rather than the box hung? [20:09] I never thought of that. [20:09] schneaky. [20:10] I shall give that a try! [20:10] (tomorrow, though.) [20:10] thanks, pal; that gives me some places to start! [20:10] aquarius, sure thing. [20:12] bryceh: also fun, firefox corruptions that are probably not ddx related, but mesa instead [20:14] mlankhorst, I think ubuntu should stop shipping X.org. Too many bugs. [20:14] the console works fine. [20:14] :> [20:14] 25868 mlankhor 20 0 3750m 2.7g 43m R 98 17.0 101:12.29 thunderbird-bin [20:15] sure thunderbird, use all the memory you need [21:04] bryceh, mlankhorst: Good after [21:04] bryceh, mlankhorst: Good afternoon/evening. [21:05] meow [21:06] * bryceh waves [21:11] Were we doing something at 2200UTC? [21:11] think now [21:12] * bryceh nods [21:12] so lets get those blueprints sorted out [21:12] the kernel team has their kernel in our lts point release ppa now [21:12] so the question is, can we get a renamed X stack in there too, for people to start testing upgrades [21:13] i think so [21:13] where "renamed X stack" just means same packages as currently in precise, just with new names [21:13] so we can demonstrate feasibility (or infeasibility) of the rename strategy [21:14] thats just creating a dummy package for enablement that depends on most/all packages right? [21:15] That should work, yes. It should be able to safely depend on less than all the packages, but for a first cut that's not a bad plan. [21:16] (Sarvatt and tjaalton if interested and around) [21:16] RAOF, I think you posted a list of what you thought the bare minimum set of packages were? [21:16] what about rest, still need to approve our blueprints [21:17] I'm trying to see if I can get some work done upstream for hybrid graphics too [21:17] It wouldn't surprise me if we could get things at least upstreamed this cycle [21:18] bryceh: Yeah, let me grab that email [21:18] who wants to do the renames and posting packages to the PPA? shall I, or would you prefer to handle it mlankhorst? [21:19] bryceh: considering i have to support things I'll probably try some of it tomorrow at least [21:19] heh, couple birds going crazy in my backyard. think one of them is a hawk [21:19] Well, that should be short-lived :) [21:19] do we have an oem approved rename postfix already?-) [21:20] probably doesn't matter for the ppa though [21:20] Huh. I don't have a minimal list; I've got a list of things in lts-pkg-mapping that I don't need to be there. [21:20] mlankhorst, sounds good. I think Rick would like seeing the ppa available by the end of the week (barring any problems) [21:20] Why don't I just commit that bit. [21:21] yeah but we should also discuss things we wouldn't rename [21:21] it can't be an either-or [21:21] tjaalton: I mean some x11proto headers [21:22] feel free to leave #'d comments in the lts-pkg-mapping file for future reference. Fairly sure the script skips hashed lines (and if not, easy to add). [21:22] also fallout from driver rewrite is fun :S [21:23] mlankhorst: ok, that's sounds scary though :) [21:23] also, we probably don't want to backport the xserver from every release [21:23] unless there's something of use [21:24] I thought the plan was to backport the full stack, including the xserver, at least in part because that combination will be the one that we've tested in the devel release. [21:24] i thought so too [21:24] true [21:25] some synaptics commit refer to X.org changes for example [21:25] but are we backporting the full stack, even with xserver included? [21:25] tjaalton: that was the idea [21:25] libs and all? [21:25] no just the server parts [21:25] DDXen, mesa, xserver. That's pretty much the full stack. [21:25] or where do we draw the line then? [21:25] ok [21:26] tjaalton: I think all userspace stuff is skipped [21:26] line is at client-facing stuff [21:26] apart from mesa [21:26] and libdrm [21:26] heh [21:26] although technically libdrm isn't client-facing [21:27] hm guess it depends on the parts [21:27] I'd consider it (and mesa handwavily) "part" of the server [21:27] There shouldn't be any reason to backport the libs, unless mesa picks up a versioned dependency that we can't easily turn off. [21:27] so any news from slangasek if this is changes anything? http://pastebin.com/wfNE6LTThttp://pastebin.com/wfNE6LTT [21:27] RAOF: well need new libdrm_nouveau at least [21:27] or do we just relax the deps [21:27] tjaalton, haven't heard anything from him about it [21:28] what about the apps? xrandr/xinput comes to mind [21:29] Neither have I, and I don't think it makes a huge difference; we were assuming we needed to backport & rename all the DDXes anyway. [21:29] tjaalton: they stay compatible [21:29] until hybrid graphics, at least.. [21:29] blegh [21:30] not for this cycle [21:30] As far as I can tell the set of backport-and-renamed packages can grow whenever we want it to. With the corollory that we should at least start with a minimal set :) [21:30] seems sensible [21:31] x11-xserver-utils has versioned depends on some libs, and assuming xrandr et al will get support for whatever new stuff the server gains, those would need to be backported as well [21:31] * bryceh ponders [21:33] tjaalton: but that could go into backports [21:33] so we have a list of packages that'll get renamed, and a list of packages we'll likely backport as-is, to the main repo? [21:34] tjaalton: we don't even know yet what will be needed. Most likely just the X server and no userspace tools [21:34] mlankhorst: think ahead :) [21:34] I'm not terribly worried about the tools [21:34] we'll get randr-1.4 & 1.5 at some point [21:34] but since newer tools will work on older servers its fine [21:34] Barring the protocol headers I don't think there's anything we could backport as-is to the main repo. [21:35] we just need to make it clear where to put them [21:35] tjaalton, we'll get randr-1.4, but since the gnome utility isn't going to be updated to use it with all of this, that's going to be kind of extraneous [21:35] tjaalton: but I think if we really had to backport tools the effects would snowball because you'd want to update gnome etc too [21:36] mlankhorst, right [21:37] Oh. Do we care about backporting non-xfree86-DDXes? (ie: xdmx, xnest, etc)? [21:37] RAOF, I think they're important but not super critical [21:38] RAOF: can they be made to be installed next to the new X? [21:38] im inclined to see them as userspace programs [21:39] Actually, I'm probably overthinking that. Those things haven't changed in a while, we won't need to do anything special for them. [21:39] I don't think we need to have newer versions backported, but I do think it's important that they continue working [21:39] RAOF: what i mean is, it might be better to not backport those since they're more userspace programs than part of the X stack we really care about [21:40] mlankhorst: Yeah. They're X11 clients, anyway, so a newer xfree86 will still run them. [21:40] yeah [21:40] it will probably save us some headaches [21:41] hmm, I should add those to the testing list [21:41] where do you keep those docs? [21:42] hmm, xdms, xnest etc are built from the same source, xorg-server? why would they need special treatment? [21:42] https://wiki.ubuntu.com/QATeam/AutomatedTesting/UpToDateKernel [21:42] *xdmx [21:42] tjaalton: because userspace can depend on it, so probably better not to build renamed ones.. [21:43] mlankhorst: the old ones work still? [21:43] they should [21:43] they're normal programs [21:43] ok so I don't see a problem then :) [21:44] every special-casing either makes the script a monster, or means more manual labor and things to remember [21:44] also it's going to be fun with regressions from nouveau ddx fallout.. [21:44] That does mean that the lts-backports script will need to munge the debian/control for the xserver to not build those packages. [21:45] RAOF: that's just the X server though, shouldn't matter [21:45] Yeah, but tjaalton's point that it either makes the script more complicated or requires manual work is salient. [21:46] Not a lot more complicated, though. [21:46] could just create a bunch of hooks for each package, see if a special file exists for them [21:46] That's not a terrible plan, if we need that power ☺ [21:46] lol [21:48] RAOF, so like have the script comment out those packages? shouldn't be too hard to do [21:48] Right. [21:48] one sed call later.. [21:48] * RAOF has pushed the revised lts-pkg-mapping to xorg-pkg-tools [21:50] got it [21:52] I'll add in the hashing functionality. So xdmx, xdmx-tools, xnest, xvfb. What about xserver-xephyr and xserver-xfbdev, those too? [21:52] occurred to me that all the packages that are rename-backported automatically become unsyncable from debian, since we carry at least the provides/breaks delta in d/control [21:52] but.. [21:52] the price we pay [21:52] tjaalton: we dont auto synch after a release right? [21:53] mlankhorst: no [21:54] bryceh/raof: is renaming x11 common really a good idea? [21:54] if raof's list is correct it's only a handful of packages that would usually be sync'd anyway [21:54] but in order to allow upgrades from the backported packages the "real" packages need the delta [21:55] all the ddx's? [21:55] um, drivers i mean [21:55] Stupid overloaded terminology :) [21:55] oho right, raof's list is a bit too short :-) [21:55] where is it? [21:56] xorg-pkg-tools:lts-pkg-mapping.txt [21:56] What was our 12.04.2 to 12.10 upgrade support again? [21:56] Do we not need to care about that until 14.04? [21:57] those probably also need to be removed: xdmx, xauth (xfonts-* ?? discuss) [21:58] RAOF: if there is no upgrade path then it's not an issue [21:58] That's something that I remember discussing in the session, but can't remember the outcome. [22:01] and libpixman-1 is scary since cairo uses it.. [22:01] RAOF, it's big news on phoronix that you pushed some xorg patches [22:02] bjsnider: ofc [22:02] Anything that a Canonical employee does is immediately more important becase they're a Canonical employee ☺ [22:03] mlankhorst: Pixman might be a bit of trouble, then. New xserver releases have depended on a new pixman in the past. [22:04] RAOF: does pixman bump soname? [22:04] we could just provide a renamed package that could coexist [22:05] That was my thought. [22:05] Pixman didn't bump the soname, because it was just new API that the xserver was depending on. [22:05] That doesn't mean that *we* couldn't bump pixman-lts-backport's SONAME, though. [22:06] And then it would be parallel-installable. [22:06] or static link [22:07] Also possible, I guess. [22:07] seems to be only for Xorg [22:08] hm might be a pita though [22:11] I think we can cross that bridge when we come to it. [22:11] Leave pixman out of the list for now, and then deal with it should xserver start depending on new features. [22:11] yeah [22:12] xcb-proto? [22:12] sufficiently client-side? [22:12] if x builds without updating it, probably [22:12] Yup. [22:13] xtrans/xutils client side too? [22:15] oh and regardless we still need to get the blueprints approved.. [22:16] suppose we can leave xkeyboard-config out too [22:16] mlankhorst, which ones, I can take a look [22:16] hybrid, xorg general, backports [22:17] bryceh: fallout from ddx update is fun [22:19] should probably have that as action point [22:20] mlankhorst, the lts one is already approved [22:20] ok :) [22:20] i mean for desktop-q-xorg-general [22:20] Yeah. [22:21] RAOF, think seb's wanting you to write it up before marking it accepted? [22:22] I added nouveau ddx item real quick [22:22] Yes, he is. [22:22] That and two others. [22:22] are we wrapping up in next 30 minutes? need sleep.. [22:23] mlankhorst, do you have any questions you need to know before you can put the stuff in the ppa? [22:24] I'm in the process of updating the package mapping list with the ddx's and other random bits, should have that within an hour [22:24] I'll have raof do another pruning on it, then that should be an actionable list [22:25] RAOF, also I'll try and do some cleanup on the work items. I just piled everything in from all the other blueprints but I think some items lost context and aren't sensible (and maybe not relevant anyway) [22:26] er, on the work items for the general xorg blueprint. [22:26] isn't the final goal that we rebuild the packages? I only see a rename [22:27] mlankhorst, how do you mean? [22:28] bryceh: do we just rename the quantal packages or do we rebuild them [22:29] mlankhorst, all the renamed packages will need rebuilt but that'll happen in the PPA [22:29] It should be renaming the source packages, and then you'll build those renamed packages in the PPA. [22:29] k [22:29] packages not being renamed don't need rebuilt [22:30] RAOF, although that makes me wonder about ddx's we don't maintain [22:30] We need to pull those in, too. [22:30] If they're in the archive. [22:30] alright, well I'm adding in the packages we do maintain to this list. maybe when you review you can pull in any other ddx's you know of. [22:31] all the world is intel/nouveau/ati right? ;-) [22:32] bryceh: I'll do so. [22:32] And add some of the craaaaaaazy arm DDXen, too :) [22:32] if the point of the backports is hw enablement, there's no reason to include drivers that never get any new hw support [22:33] tjaalton: abi breakage.. [22:33] mlankhorst: no need to update.. [22:33] That's a fair point. [22:33] Oh, no. Did we end up deciding whether or not 12.04.2 will use the new stack by default or not? [22:33] boo :) [22:34] RAOF: I think we let leann handle that [22:35] I think it's probably easier to just rebuild *all* the DDXen. They're totally self-contained, so not building them is basically just saving some buildd time. [22:36] [leannogasawara] Drive decision pre UDS-R whether or not the 12.10 stack is the only supported stack on 12.04.2 media, and if both are supported, which is the default boot option or end users: TODO [22:36] anyhow i cant stay up much longer [22:37] Feel free to sleep :) [22:38] thanks for meeting and gnight ) [22:38] night mlankhorst [22:43] jeez, "xserver-xorg-video-siliconmotion-dev-lts-backport-quantal" [22:43] -dev ? [22:44] binary package [22:44] mlankhorst, sleep. :-) [22:44] RAOF, pushed up new list [23:53] bryceh, mlankhorst: I've divvied out some xorg-general work items to you guys; feel free to complain if you don't want to do them ☺ [23:54] ok [23:54] bryceh, mlankhorst, tjaalton: There's also the WIs for testing plans; I haven't assigned them anywhere. If you want them, pipe up! [23:55] RAOF, mlankhorst I've sketched in the basics of a master script to iteratively grab and rename all the packages. [23:56] RAOF, mlankhorst oh and btw still need to shake out all the bugs of the lts rename script; I've really only run it on xserver and -intel; everything else is unexplored territory [23:56] :) [23:57] so... patch with impunity as you find bugs :-)