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