[01:32] <maxb> Karmic seems to have a bug where "Lock screen" doesn't DPMS-off monitors. Would this be likely to be an X server bug?
[02:31] <superm1> bryce, were you aware that the options to force VESA on the live disk don't appear to do anything anymore?
[02:31] <superm1> i bet ever since xorg.conf was removed that option stopped doing anything useful
[03:20] <bryce> superm1, no wasn't aware.  bug#?
[03:20] <superm1> bryce, someone in another IRC channel was just raising it
[03:20] <superm1> i dont know that there is a bug number for it
[03:21] <superm1> https://bugs.edge.launchpad.net/ubuntu/+source/casper/+bug/423969
[03:22] <bryce> thx
[03:51] <bryce> superm1, that bug is a bit ambiguous as to where things are failing exactly
[03:51] <bryce> I kind of hate it when people say "didn't work" - leaves too much open to interpretation ;-)
[03:53] <bryce> superm1, in any case the kernel doesn't pay any attention to xorg.conf, so whether it's there or not should have no bearing on whether or not the xforcevesa option works or not
[03:54] <superm1> bryce, well xforcevesa used to spit out a different xorg.conf
[03:54] <superm1> since xorg.conf is gone, nothing happens
[03:55] <bryce> hmm
[03:55] <bryce> yeah dunno on that.  what exactly produces the xorg.conf?  not the kernel surely...?
[03:55] <superm1> well originally was done by dpkg-reconfigure xserver-xorg which was called from casper
[03:56] <superm1> casper is just the package that gets put into the initramfs for all the live disk magic stuff
[03:56] <superm1> scripts/casper-bottom/20xconfig is what used to make an xorg.conf
[03:58] <superm1> so really it was capser that called into the xserver-xorg postinst that used to do it
[03:58] <superm1> *casper
[04:03] <superm1> but that guy has two separate issues in that bug
[04:03] <superm1> 1) Not working with the default config
[04:03] <superm1> 2) xforcevesa doesn't actually force VESA
[04:06] <bryce> mm
[04:06] <bryce> well if it is implemented by calling dpkg-reconfigure, yeah that no longer generates an xorg.conf anymore
[04:06] <superm1> yeah
[04:06] <bryce> but not sure how to work around that
[04:07] <bryce> I mean, it could just copy in a static xorg.conf that lists vesa as the driver, and that'd probably do just as good
[04:07] <superm1> i think so
[04:07] <bryce> in this case nothing else really needs configured
[04:08] <superm1> so if you just look for xforcevesa on /proc/cmdline in xserver-xorg.postinst, copy over a static file in such situations, nothing has to be changed for casper
[04:08] <bryce> tjaalton, I see you've dealt with breakages with this option before, do you have an opinion here?
[04:12] <bryce> uh, how did I walk into getting an action item on this one
[04:12] <bryce> :-)
[04:13] <bryce> I was thinking casper would copy in the xorg.conf so we didn't have to mess with any of the dpkg-reconfigure business
[04:13] <superm1> hehe
[04:13] <superm1> yeah i think ditching the dpkg-reconfigure business is the better solution and just doing it in casper
[04:14] <superm1> where would the static xorg.conf live though?
[04:14] <bryce> I'm imaging it'd be no more than half a dozen lines.  It could be as trivial as an echo or print statement in some script
[04:17] <superm1> bryce, http://pastebin.com/f44399ec1
[04:18] <superm1> if you can put a static xorg.conf somewhere on the system, that pastebin would do the trick in casper
[04:19] <superm1> bryce, or if you can give me the xorg conf i'll just put it in casper with a echo > /root/etc/X11/xorg.conf < EOF
[04:21] <bryce> ok standby
[04:21] <bryce> http://pastebin.com/m43aae492
[04:22] <superm1> wow that's all that's necessary? :)
[04:22] <bryce> we might be able to trim it down further, but that's one I've actually tested
[04:22] <bryce> like maybe we could leave out the Monitor section, but I'm not certain
[04:23] <bryce> (this is the xorg.conf.failsafe that we use for the bulletproof-x mode)
[04:23] <superm1> what's another 60 bytes, rather know it would work
[04:23] <bryce> right
[04:24] <superm1> okay i'll commit and upload this to casper then: http://pastebin.com/f4b671042
[04:24] <bryce> I really need to learn casper
[04:25] <bryce> ok, if that works in casper it looks good to me from an xorg pov
[04:25] <superm1> cool.  won't be able to (easily) test until a new daily iso
[04:27] <bryce> it occurs to me that we could actually make xorg-server itself recognize and respect xforcevesa
[04:28] <bryce> but that might be madness.
[04:28] <bryce> not sure
[04:28] <bryce> LL perhaps
[04:28] <superm1> oh you mean for any boot, not just live media?
[04:28] <bryce> yeah
[04:28] <superm1> well hopefully xforcevesa doesn't have to be used very often in the first place anyway
[04:29] <bryce> yeah
[07:32] <bryce> boy I tell you, having a kid really sucks up your freetime
[07:37] <tjaalton> try having three ;)
[07:38] <tjaalton> two of them on my lap right now
[07:40] <tjaalton> bryce: re: vesa, the solution looks good
[07:41] <bryce> ok great
[07:41] <bryce> tjaalton, btw I reviewed all changes for xserver 1.6.5
[07:41] <bryce> about a third of the patches we already have
[07:42] <bryce> another third I think we definitely want, even if we must cherrypick
[07:42] <bryce> the other third I think are lower importance, but look safe enough
[07:42] <tjaalton> yeah, great
[07:42] <bryce> there's just one patch that I worry about - the one that removed the DGA code and required the patch in 1.6.5
[07:43] <bryce> I'm debating about whether to put in a FFe for the whole thing, or just cherrypick
[07:43] <bryce> what do you think?
[07:43] <bryce> a plus to cherrypicking is that I can do that all in git
[07:43] <bryce> if it merges from debian, I'm not very good at that
[07:44] <tjaalton> heh
[07:44] <bryce> er, "if we merge"
[07:44] <tjaalton> I'm for pulling the whole thing, as usual :)
[07:44] <bryce> even though it'll take a FFe?
[07:44] <tjaalton> yes, if it was generally accepted already
[07:45] <bryce> and probably handholding me through a git merge (or letting xorg-server escape git control *grin*)
[07:45] <tjaalton> sure :)
[07:46] <tjaalton> the former :)
[07:47] <bryce> http://www2.bryceharrington.org:8080/files/xserver-1.6.4-patches.ods
[07:48] <bryce> that's my worksheet for how the patches all fall out
[07:49] <bryce> I'm thinking of reverting the DGA patch entirely.  AIUI it's removing dead code so is technically not a "bug fix" and seems to just introduce regression potential (evidenced by the .4 regression)
[07:51] <tjaalton> yep, that would work too
[07:54] <tjaalton> Saima (3), can already use the remote to select programs from the VDR menu.. makes my life easier :)
[07:55] <tjaalton> ..until she wants to build a puzzle
[07:56] <bryce> heh
[07:56] <bryce> Dutch and I spent the evening staring at the fish tank.  Quite fascinating
[07:56] <bryce> he can hold his head up on his own for the most part now, which is pretty amazing (he's only 4 weeks old)
[08:19] <tjaalton> boys are stronger ;)
[08:20] <tjaalton> bryce: when were you planning to merge xserver?
[08:20] <bryce> do you feel like walking me through it tonight?
[08:20] <tjaalton> like 12h from now?
[08:21] <tjaalton> or your night?-)
[08:21] <bryce> actually I meant now
[08:21] <bryce> 12h from now would work to though
[08:21] <tjaalton> works better, I need to get to work first
[08:21] <tjaalton> will take 15min
[08:21] <bryce> ok
[08:22] <bryce> ping me whenever you're ready
[08:56] <tjaalton> bryce: ok, I'm here
[08:56] <tjaalton> took a bit longer :)
[09:02] <bryce> heya
[09:02] <bryce> just finishing up FFe
[09:02] <tjaalton> ok
[09:02] <bryce> I figure even if we end up just doing cherrypicks, we'll want git updated for LL
[09:04] <bryce> bug 447010
[09:05] <bryce> alright, walk me through it
[09:05] <tjaalton> 1.6.5 isn't out yet btw, and if we revert the dga change we can just merge 1.6.4-2
[09:05] <bryce> okay
[09:05] <tjaalton> since 1.6.5 has only that one change to fix the mess
[09:05] <tjaalton> anyway
[09:05] <tjaalton> first the usual stuff: git fetch
[09:06] <tjaalton> that'll update the default remote branches, in this case origin/*
[09:06] <tjaalton> then if you are in the local ubuntu branch, run git pull
[09:06] <tjaalton> it'll update the local branch to match the remote
[09:07] <bryce> s/1.6.5/1.6.4-2/
[09:07] <tjaalton> yep
[09:07] <bryce> git fetch ; git pull done
[09:08] <tjaalton> ok, then it's just to merge the tag we want: git merge xorg-server-2_1.6.4-2
[09:08] <tjaalton> note that zsh tab-completes it ;)
[09:08] <tjaalton> now you'll see that some files have merge conflicts
[09:08] <bryce> 3 conflicts
[09:09] <tjaalton> right, and to resolve them, you can either edit them directly, or use git mergetool
[09:09] <tjaalton> there are a number of frontends for it, I've used meld
[09:09] <tjaalton> but I don't know if it's still broken in karmic
[09:09] <tjaalton> I'll check
[09:11] <tjaalton> seems to be
[09:11] <tjaalton> do you have meld installed?
[09:12] <bryce> nope
[09:12] <tjaalton> I think it helps in visualizing what happens, so install it
[09:12] <tjaalton> and then run git mergetool
[09:12] <bryce> alright
[09:13] <bryce> huh, reminds me of clearcase
[09:13] <tjaalton> heh
[09:13] <tjaalton> ok, so it has three versions of the changelog visible (the first file with a conflict)
[09:14] <bryce> do I edit the middle one?
[09:14] <tjaalton> the left one is from the ubuntu branch, the right one is the remote version, and the middle one is what you edit
[09:15] <tjaalton> so, it doesn't always figure out what chunks should go where, so you'll end up editing it by hand
[09:16] <tjaalton> you can delete the markers away, and move the debian changes on top
[09:16] <tjaalton> so that the versions are in correct order
[09:18] <tjaalton> the merged part will still look red though, bad meld
[09:19] <tjaalton> if the merge-arrows would work, it would be more straightforward
[09:20] <tjaalton> once you've finished editing it, quit meld
[09:20] <tjaalton> it'll offer saving the middle version, accept that
[09:21] <tjaalton> then mergetool will show debian/control being in conflict, and open meld again
[09:21] <tjaalton> hrm, libaudit-dev is still in universe
[09:22] <tjaalton> kees: ^^ :)
[09:22] <bryce> ok, merged changelog, control, and series
[09:22] <bryce> not 100% sure on control tho
[09:22] <tjaalton> that was fast :)
[09:22] <tjaalton> if you dropped libaudit-dev from the build-deps, it's fine
[09:22] <bryce> ah yeah wasn't sure what to do with libaudit-dev
[09:23] <tjaalton> since it's still in universe
[09:23] <bryce> I left it... shoudl I drop it?
[09:23] <bryce> ok
[09:23] <tjaalton> there was also avr32 added to the list of archs for libselinux-dev
[09:24] <bryce> yup
[09:24] <bryce> I like how meld showed just that bit in red
[09:24] <tjaalton> you can change it after mergetool has finished, no problem
[09:24] <tjaalton> yes, and the rest of the changes in green, so you can also review the diff
[09:24] <bryce> ok, edited 184_virtual_devices_autodetect.patch as well (fedora-vboxvideo.diff supersedes half of it)
[09:25] <bryce> btw is there a way to create a "reverse patch" in git?
[09:25] <tjaalton> I've just pulled the commit, and reversed the +/-'s :)
[09:25] <bryce> I'd like to do something like 'git show -R 1234567' 
[09:26] <tjaalton> there should be something like that though
[09:26] <bryce> huh, didn't think of that
[09:26] <bryce> that's a lot faster than the way I usually do it ;-)
[09:27] <tjaalton> now that the merge itself is done, commit the changes
[09:28] <tjaalton> the default msg is usually enough
[09:28] <bryce> [ubuntu ee53540] Merge commit 'xorg-server-2_1.6.4-2' from Debian into ubuntu
[09:28] <tjaalton> I've never changed that IIRC
[09:28] <tjaalton> also, it's a matter of preference to just commit the merge, and then work out the kinks in separate commits
[09:29] <tjaalton> whatever works
[09:30] <tjaalton> now you can push the branch, so I can review it :)
[09:30] <bryce> pushed
[09:31] <tjaalton> looks good
[09:32] <bryce> next... how to invert patch 507e57381fea6334f7dc8da6925e53d2c76fddcb
[09:33] <bryce> bet I could do a perl script to do it faster than doing it by hand...
[09:33] <jcristau> hrm
[09:33] <jcristau> why would you do that?
[09:34] <bryce> do what?
[09:34] <jcristau> revert that patch
[09:34] <bryce> jcristau, it's caused one regression already, the question is why would we take it?
[09:35] <bryce> AIUI, it's just dropping some dead code, doesn't actually fix a bug
[09:35] <jcristau> it's not dead code
[09:36] <jcristau> it's removing the ability for clients to directly mmap the framebuffer
[09:38] <tjaalton> fix-dga-removal.patch has worked so far?
[09:49] <bryce> http://pastebin.ubuntu.com/289155/
[09:52] <jcristau> tjaalton: yes
[09:54] <bryce> uh, well I should hope it's dead code since they're deleting it all
[09:55] <tjaalton> it's dead code in the drivers once the feature is removed from the server ;)
[09:55] <bryce> in any case, there's no reference to a bug# or other explanation as to why it's being removed, what it did, what's wrong with it, etc.  What might depend on this that could break?
[09:55] <bryce> tjaalton, heh ouch
[09:56] <tjaalton> clients directly mmapping the fb sounds bad
[09:57] <bryce> tjaalton, well then that makes me wonder, so is it a security issue?  If so, there's a process for those...
 has an explanation of sorts
[10:05] <tjaalton> "Removing direct graphics access from DGA" Wed, 16 Sep 2009 15:34:03 -0700
[10:06] <jcristau> (http://article.gmane.org/gmane.comp.freedesktop.xorg.devel/1945)
[10:06] <bryce> tjaalton, actually the reply from keith on the 18th is the more detailed one
[10:06] <bryce> (reading it now)
[10:09] <tjaalton> bryce: yeah, read it now
[10:11] <bryce> hmm
[10:12] <bryce> well, I understand this code leads to badness (I never doubted it)
[10:12] <bryce> but I still just have a feeling this is going to gratuitously cause regressions somewhere... old games, proprietary apps
 refers to getting 'DGA-using games working again'
[10:15] <tjaalton> apparently it's been broken since randr-1.2
[10:15] <tjaalton> so we would've heard about it now :)
[10:16] <tjaalton> +by
[10:16] <jcristau> bryce: that was from before keith's patch
[10:22] <bryce> if it's broken anyway, it won't be doing any damage right?  ;-)
[10:22] <bryce> ok well we still have time to decide... the FFe has not been approved yet
[10:23] <tjaalton> broken as in apps needing it would have not worked, but the feature can still be used
[10:23] <bryce> what else needs done to complete this merge?
[10:23] <tjaalton> the changelog entry, and removing obsolete patches
[10:23] <tjaalton> that's it
[10:23] <tjaalton> oh and testing that the remaining ones apply & build, of course
[10:31] <tormod> bryce, still up :) I found it fairly easy to reproduce the kwin issues by installing kwin and running kwin --replace
[10:32] <bryce> tormod, can you verify the fixes I posted?
[10:32] <tormod> yes, the crash fix worked, the other I haven't tested
[10:35] <tormod> will you make a combined patch for the two? you will run out of colours :)
[10:45] <bryce> tormod, I added more colors ;-)
[10:45] <tormod> hi ara, on the mesa testing wiki, you wrote "ubuntu-bug xorg", I think mesa would be the right package, right?
[10:45] <bryce> tormod, it's probably not necessary to do another ppa; once they're confirmed sufficiently they can just go in
[10:46] <bryce> tormod, it's fine for people to file against xorg
[10:46] <ara> tormod, xorg apport hook will gather useful information
[10:46] <tormod> I think also suokko would come up with a real fix if he would be around...
[10:46] <tormod> ara, ok I see, we should maybe fix the mesa apport hooks if needed
[10:46] <bryce> tormod, I figure it's easier to just always remember 'ubuntu-bug xorg' rather than think about which package it might go to
[10:47] <bryce> nah the mesa apport hook is just symlinked to the xorg
[10:47] <bryce> so if you ubuntu-bug mesa, it's the same as if you did ubuntu-bug xorg
[10:47] <tormod> it's just that some of us keep a closer eye on the mesa package than the xorg bucket
[10:47] <bryce> the bug just ends up in a different package.  but all the same info is attached
[10:48] <ara> bryce, are you subscribe to the wiki page?
[10:48] <bryce> I move stuff out of xorg regularly
[10:48] <bryce> tormod, although I've not cleaned it out completely since before my leave
[10:48] <bryce> ara, no but I will get on it, thanks for reminding
[10:49] <ara> bryce, there is a tester already reporting: https://wiki.ubuntu.com/Testing/Mesa7.6
[10:50] <bryce> ara cool
[10:51] <ara> bryce, also, a random crash with the new mesa was reported https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/446653
[10:51] <bryce> ara, looks like he had no regressions and found that one existing bug was fixed... good!
[10:52] <bryce> ara, note that he is using nvidia... nvidia does it's own thing for 3D and doesn't actually make use of mesa
[10:52] <ara> bryce, yes, I just realized :D
[10:53] <bryce> tjaalton, pushed some of the work
[10:53] <bryce> since it's 3am I'll go to bed now and finish up in the morning, thanks for the tutorial.
[10:53] <tormod> good night bryce!
[10:54] <ara> night bryce!
[10:54] <bryce> oh before I go, ara here are the three confirmed mesa regressions I know of so far:
[10:55] <bryce>      - 446425: [Radeon R250] Artifacts on kwin (patch)
[10:55] <bryce>      - 446578: [Radeon RS690M] Crash with kwin (patch)
[10:55] <bryce>      - 446674: [Radeon M7LW] Memory corruption / googleearth crash
[10:55]  * bryce --> bed
[10:55] <ara> bryce, thanks!"
[10:55] <tjaalton> bryce: thanks, and night
[11:19] <jcristau> looks like bryce didn't git add the dga revert patch?
[11:20] <tseliot> jcristau: the one in xorg-server 1.6.4.901 ?
[11:20] <jcristau> no
[11:20] <jcristau> apparently he decided to revert dga to 1.6.3 state
[11:21] <tseliot> ah
[14:23] <asac> hi
[14:28] <rickspencer3> hi asac, hi ara
[14:28] <rickspencer3> hmmm, it just occured to me that this might be too early for bryce
[14:28] <ara> hey rickspencer3, asac
[14:28] <rickspencer3> I forgot that he was West Coast as well :(
[14:29]  * rickspencer3 has awesome attention to detail lately
[14:30] <ara> rickspencer3, these were the 3 bugs bryce could confirmed as related to the new mesa
[14:30] <ara> [10:55] <bryce>      - 446425: [Radeon R250] Artifacts on kwin (patch)
[14:30] <ara> [10:55] <bryce>      - 446578: [Radeon RS690M] Crash with kwin (patch)
[14:30] <ara> [10:55] <bryce>      - 446674: [Radeon M7LW] Memory corruption / googleearth crash
[14:31] <ara> bug 446425
[14:31] <rickspencer3> shall we start then?
[14:31] <rickspencer3> ara so it seems that the mesa brought some changes to radeon that were no too good
[14:32] <rickspencer3> for those first two bugs, upstream has identified the specific commits that caused them (in the radeon driver I believe)
[14:32] <rickspencer3> ara, thoughts?
[14:32] <asac> ok. i can come back later ;)
[14:32] <asac> (too early for bryce)
[14:33] <rickspencer3> asac, before you go, what do you think? I'd like to get an update on Monday and see if patches for these issues are available for the driver
[14:34] <rickspencer3> the problems seem localized and well understood
[14:34] <asac> i think its still fine. i suggested in my plan to make first check today and allow fixes over weekend and check on monday tuesday
[14:34] <ara> rickspencer3, https://wiki.ubuntu.com/Testing/Mesa7.6, there are some freezes as well, but they don't seem regressions
[14:34] <rickspencer3> ok
[14:34] <asac> and if there is indication that bugs are making good progress we can think about it then
[14:34] <rickspencer3> so we are agreed, check again on Monday?
[14:35] <asac> right. keep on listening and check on monday
[14:35] <rickspencer3> ara?
[14:35] <ara> rickspencer3, yes, I agree
[14:35] <asac> did we run the test thing?
[14:35] <asac> opengl?
[14:35] <ara> asac, not yet, it needs someone to set it up with intel or ati, I have a nvidia
[14:35]  * marjo waves
[14:36] <rickspencer3> hi marjo
[14:36] <asac> ara: what does that setup involve?
[14:36] <tormod> rickspencer3, did you notice that Bryce fixed 2 of these bugs in his PPA already
[14:36] <marjo> sorry i'm late; was w/ mdz
[14:36] <asac> ara: are you looking for specific ati hardware?
[14:36] <asac> hi marjo 
[14:36] <ara> asac, not too much I think, just installing the dependencies
[14:37] <rickspencer3> tormod, well, I noticed there were patches to try, but not sure I consider them "fixed" yet ;)
[14:37] <asac> ara: are there instructions or is it just running a command after installing a package?
[14:37] <ara> asac, 
[14:37] <ara>     git://anongit.freedesktop.org/git/piglit 
[14:37] <marjo> rickspencer3: i want to report that the rollback patch seems to work
[14:37]  * asac checks
[14:37] <tormod> they have been confirmed to work
[14:38] <ara> asac, the only thing I found was that git repository. there is a readme file with instructions
[14:38] <asac> k
[14:38] <ara> asac, if it is useful, we should consider creating a ppa for it
[14:41] <asac> yeah. let me check what happens if i build/run it ;)
[16:27] <hyperair> could someone familiar with intel, KMS and power management please look at this: https://bugs.launchpad.net/ubuntu/+source/pm-utils/+bug/417599
[16:56] <Ng> do we expect i945 to be failing to establish DRI and thus being mind-bogglingly slow at 2d?
[16:57] <jcristau> no.
[16:59] <Ng> I have two almost identical laptops upgraded jaunty->karmic, one opens DRI fine, one doesn't
[17:00]  * Ng hunts for the bug he just filed from the broken one
[17:00] <Ng> https://launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/447337
[17:02] <Ng> (I say 2d, I guess I actually mean 3d since it was probably still using compiz)
[17:03] <jcristau> [   20.870008] [drm:drm_fill_in_dev] *ERROR* Cannot initialize the agpgart module.
[17:04] <Ng> interesting, ProcModules.txt suggests that agpgart.ko and intel_agp.ko are loaded
[17:04] <jcristau> is intel_agp missing from initramfs?
[17:05] <Ng> is there a quick way I can check that?
[17:05] <Ng> (I'm trying not to disturb the laptop's owner too much)
[17:06] <jcristau> zcat /boot/initrd.img-$(uname -r)|cpio -i -t | grep intel-agp
[17:07] <jcristau> hrm
[17:07] <jcristau> actually the problem seems to be that intel-agp gets loaded too late
[17:07] <jcristau> like, .1 second too late
[17:08] <Ng> wasn't there some kernel change recently to make it load sooner/properly?
[17:08] <jcristau> no clue.
[17:10] <Ng> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/430694
[18:15] <bryce> rickspencer3, oops sorry I completely overlooked that the meeting was at 6:30am, for some reason I had it in my head that it was going to be this evening
[18:15] <rickspencer3> bryce, np
[18:15] <rickspencer3> next problem is that Monday is a US holiday
[18:15] <rickspencer3> :)
[18:15] <bryce> heh
[18:16] <bryce> rickspencer3, well I was thinking I could swap that for a day post-release
[18:16] <rickspencer3> bryce, I hear through the grapevine that your ppa'ed patches are confirmed to work?
[18:16] <bryce> correct
[18:16] <bryce> was hoping to hear from upstream on them by now, but no word so far
[18:16] <rickspencer3> can we apply the patches ourselves?
[18:17] <bryce> certainly
[18:18] <bryce> and I think it's entirely reasonable for us to do so
[18:20] <bryce> http://www.amazon.com/Olevia-747i-47-Inch-1080p-HDTV/dp/B000OCT5GE
[18:20] <bryce> wow, that must be a _good_ monitor at that price!
[18:22] <superm1> zomg, but you get 23% off! :)
[18:23] <bryce> superm1, and free shippin!
[18:24] <bryce> rickspencer3, what I'm going to do is try to get upstream's thumbs-up on those two patches and get them in today
[18:25] <rickspencer3> bryce, get them in upstream you mean?
[18:25] <rickspencer3> or get them into Ubuntu?
[19:22] <asac> hmm. seems i dropped the ball on checking piglit
[19:51] <bryce> rickspencer3, I touched base with upstream earlier - Alex is going to work up a better patch for us
[19:52] <rickspencer3> bryce, nice
[19:52] <bryce> rickspencer3, meanwhile I've been working on the xorg-server update - lp bug #447010
[20:46] <mdeslaur> darn, I hit the 1-click button on that 12 million dollar tv
[20:48] <bryce> mdeslaur, aha you've covered the cost of the patent
[20:48] <mdeslaur> hehe
[22:28] <bryce> xorg-server 1.6.4-2 uploaded
[22:28] <bryce> tormod, tjaalton_: let me know if I've missed anything but I think we now have everything in we want in
[22:29] <bryce> oh, an -ati update might be nice, hm
[22:36] <rickspencer3> bryce, yeah
[22:37] <rickspencer3> I mean .. yeah! \o/
[22:37] <rickspencer3> :)
[22:37] <bryce> :-)
[22:37] <rickspencer3> bryce, do you need me at the Monday meeting, which I haven't scheduled yet?
[22:37] <rickspencer3> do you still want to do it?
[22:38] <bryce> guess it depends mostly on if you think it'll be useful to do
[22:38] <bryce> I'm fine just chatting with people through email/irc/bugz
[22:39] <bryce> I think your prediction that we'd get to Friday and go "what were we so worried about?" has come to pass
[22:39] <bryce> btw, I've received and uploaded a fix for one of those radeon kwin bugs (the cosmetic issue rather than the crash... still working on that)
[22:42] <tormod> bryce, my opinion on -ati: https://lists.ubuntu.com/archives/ubuntu-x/2009-September/000630.html
[22:42] <bryce> tormod, ah excellent, thanks
[22:42]  * bryce adds to todo list
[22:43]  * tormod wonders if anyone reads the ML ;)
[22:44] <rickspencer3> k
[22:44]  * rickspencer3 will deal with Monday later
[22:44]  * rickspencer3 time to go
[22:44] <rickspencer3> bye bye all
[22:45] <bryce> tormod, I do read it, just that one came in while I was on leave.  :-)
[23:15] <tormod> bryce, I made a merge request for googleearth-package, can you please take a look (if lp recovers)?
[23:15] <bryce> lp#?
[23:34] <Sarvatt> tormod: that was a nasty little intel libdrm breakage yesterday huh? :D
[23:35] <tormod> Sarvatt, \o/
[23:35]  * tormod hugs sarvatt
[23:35] <Sarvatt> made the mistake of updating before i went out for 12 hours of work, couldnt figure out what was broken since i updated so many things and didnt have much time
[23:35] <Sarvatt> but your upload this morning fixed things up :)
[23:35] <tormod> hehe I got some complaints
[23:38] <tormod> uploading a new bunch now so cross your fingers
[23:40] <Sarvatt> upgrading the ibook to karmic now to play with ati kms some more, been waiting all day for the whole chain of x11proto's to build on launchpad to build so i can start uploading libs
[23:40] <Sarvatt> guessing karmic is going to stick with pixman 14.0?
[23:41] <bryce> heya Sarvatt!
[23:42] <Sarvatt> hiyo!
[23:42] <bryce> long time, wassup?
[23:43] <Sarvatt> not much, catching up on 2 months of open source development that I missed, crazy how much things change that fast :D
[23:43] <bryce> yup definitely
[23:43] <bryce> yeah being gone on leave 1 month myself it's been mad trying to catch up
[23:44] <bryce> btw I credit a lot of the reason we were able to get all the latest mesa/xserver/libdrm/intel bits updated for karmic is because they'd been getting good testing in xorg-edgers :-)
[23:44] <bryce> so the work you and tormod have done there has had a good payoff
[23:57] <tormod> bryce, bug 447143