[00:52] <bandit5432> RAOF, thanks for the help last night
[00:53] <RAOF> No problem.
[00:54] <bandit5432> I wish #gnome was as responsive
[02:01] <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:20] <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:33] <bandit5432> nope just have to stop watching flash videos which now blead through every window i have open
[02:37] <bjsnider> bandit5432, what hardware is this?
[02:37] <bandit5432> 9800gtx
[02:37] <bandit5432> trying to replicate
[02:37] <bjsnider> oh
[02:38] <bjsnider> senior citizen
[02:38] <bandit5432> :|
[02:38] <bandit5432> i have gtx 560 coming tommorow
[02:38] <bandit5432> still old but better
[02:39] <bandit5432> oh i hate flash!
[02:40] <bandit5432> at least when i turn of hd accl i can watch a full video
[02:43] <bandit5432> replicated flash videos bleed through kind of cool
[02:43] <bandit5432> it appears to only bleed through the fonts
[02:53] <bjsnider> led-bandit, i'll bet the fermi card is a lot more bug-free
[02:53] <led-bandit> i am hoping 
[02:54] <led-bandit> 3 year old build and its time for a upgrade
[03:45] <RAOF> Man, the xserver build has ALL THE WARNINGS.
[04:22] <bandit5432> is that why i am getting flooded with info?
[04:24] <RAOF> No. Unless you're actually building the xserver :)
[04:25] <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:55] <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:56] <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:58] <tjaalton> hum ho
[04:59] <RAOF> It's not *that* annoying :)
[04:59] <tjaalton> ok :)
[05:21] <mlankhorst> morning
[05:25] <mlankhorst> RAOF: Depends, do you want to backport the exa fixes?
[05:26] <mlankhorst> Actually I might have to if cairo 1.12 is going to be backported for lts..
[05:28] <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:29] <Sarvatt> debian wheezy is shipping cairo 1.12, but libdrm-nouveau2 needs mesa 8.1 that wont ship until august at least...
[05:30] <Sarvatt> its a really screwed up situation
[05:30] <mlankhorst> I know
[05:31] <mlankhorst> it's not that hard to backport, it's hard to SUPPORT it afterwards :P
[05:33] <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:50] <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
[08:38] <mlankhorst> in either case, seems my beautiful hack works
[09:04] <tjaalton> great
[09:22] <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
[14:54] <mlankhorst> RAOF: http://www.phoronix.com/scan.php?page=news_item&px=MTEwNTc :D
[14:54] <mlankhorst> hahahaha
[14:56] <jcristau> he's good at writing crap about nothing
[14:56] <mlankhorst> jcristau: yes but its great amusement to see what he writes
[14:58] <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? :)
[17:55] <cnd> bryceh, where did you merge my utouch arsenal branch to?
[17:56] <cnd> it doesn't appear to be merged into lp:arsenal
[18:00] <bryceh> cnd, hang on
[18:01] <bryceh> cnd, 'tis up
[18:03] <cnd> ok, thanks
[18:53] <aquarius> bryceh, is there any moe useful debugging information I can provide tomorrow in  https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1003333 ?
[19:33] <bryceh> aquarius, no response through ssh over ethernet?
[19:38] <bryceh> aquarius, ello?
[19:39] <bryceh> > bug
[19:50] <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:51] <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:52] <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:56] <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:57] <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:58] <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.
[20:00] <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:01] <aquarius> but I'm not *running* that.
[20:01] <aquarius> confused, now.
[20:02] <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:03] <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:04] <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:06] <bryceh> well, if it doesn't respond on the ethernet port... if you HAD an ethernet port...
[20:07] <bryceh> but actually there's a few ways to hang a box that aren't *caused* by the kernel.
[20:08] <aquarius> yeah, if I had an ethernet port I'd try that. :)
[20:09] <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:10] <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:12] <mlankhorst> bryceh: also fun, firefox corruptions that are probably not ddx related, but mesa instead
[20:14] <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:15] <mlankhorst> sure thunderbird, use all the memory you need
[21:04] <RAOF> bryceh, mlankhorst: Good after
[21:04] <RAOF> bryceh, mlankhorst: Good afternoon/evening.
[21:05] <mlankhorst> meow
[21:06]  * bryceh waves
[21:11] <RAOF> Were we doing something at 2200UTC?
[21:11] <mlankhorst> think now
[21:12]  * 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:13] <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:14] <mlankhorst> thats just creating a dummy package for enablement that depends on most/all packages right?
[21:15] <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:16] <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:17] <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:18] <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:19] <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:20] <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:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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:27] <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:28] <tjaalton> what about the apps? xrandr/xinput comes to mind
[21:29] <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:30] <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:31] <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:33] <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:34] <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:35] <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:36] <bryceh> mlankhorst, right
[21:37] <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:38] <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:39] <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:40] <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:41] <bryceh> hmm, I should add those to the testing list
[21:41] <mlankhorst> where do you keep those docs?
[21:42] <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:43] <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:44] <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:45] <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:46] <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:48] <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:50] <bryceh> got it
[21:52] <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:53] <tjaalton> mlankhorst: no
[21:54] <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:55] <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:56] <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:57] <mlankhorst> those probably also need to be removed: xdmx, xauth (xfonts-* ?? discuss)
[21:58] <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.
[22:01] <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:02] <mlankhorst> bjsnider: ofc
[22:02] <RAOF> Anything that a Canonical employee does is immediately more important becase they're a Canonical employee ☺
[22:03] <RAOF> mlankhorst: Pixman might be a bit of trouble, then. New xserver releases have depended on a new pixman in the past.
[22:04] <mlankhorst> RAOF: does pixman bump soname?
[22:04] <mlankhorst> we could just provide a renamed package that could coexist
[22:05] <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:06] <RAOF> And then it would be parallel-installable.
[22:06] <mlankhorst> or static link
[22:07] <RAOF> Also possible, I guess.
[22:07] <mlankhorst> seems to be only for Xorg
[22:08] <mlankhorst> hm might be a pita though
[22:11] <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:12] <bryceh> xcb-proto?
[22:12] <bryceh> sufficiently client-side?
[22:12] <mlankhorst> if x builds without updating it, probably
[22:12] <RAOF> Yup.
[22:13] <mlankhorst> xtrans/xutils client side too?
[22:15] <mlankhorst> oh and regardless we still need to get the blueprints approved..
[22:16] <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:17] <mlankhorst> bryceh: fallout from ddx update is fun
[22:19] <mlankhorst> should probably have that as action point
[22:20] <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:21] <bryceh> RAOF, think seb's wanting you to write it up before marking it accepted?
[22:22] <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:23] <bryceh> mlankhorst, do you have any questions you need to know before you can put the stuff in the ppa?
[22:24] <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:25] <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:26] <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:27] <bryceh> mlankhorst, how do you mean?
[22:28] <mlankhorst> bryceh: do we just rename the quantal packages or do we rebuild them
[22:29] <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:30] <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:31] <mlankhorst> all the world is intel/nouveau/ati right? ;-)
[22:32] <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:33] <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:34] <mlankhorst> RAOF: I think we let leann handle that
[22:35] <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:36] <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:37] <RAOF> Feel free to sleep :)
[22:38] <mlankhorst> thanks for meeting and gnight )
[22:38] <bryceh> night mlankhorst 
[22:43] <bryceh> jeez, "xserver-xorg-video-siliconmotion-dev-lts-backport-quantal"
[22:43] <mlankhorst> -dev ?
[22:44] <bryceh> binary package
[22:44] <bryceh> mlankhorst, sleep. :-)
[22:44] <bryceh> RAOF, pushed up new list
[23:53] <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:54] <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:55] <bryceh> RAOF, mlankhorst I've sketched in the basics of a master script to iteratively grab and rename all the packages.
[23:56] <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:57] <bryceh> so... patch with impunity as you find bugs :-)