[05:33] <RAOF> Well, looks like kernel panic output on radeon kms works…
[07:13] <RAOF> Well, that was rather silly.  Yes, --fvisibility=hidden *does* make it hard to link against those symbols…
[15:32] <ScottK> RAOF: FYI, we have the 'fix' for Bug 628930 in hand, just waiting for upstream review: http://reviewboard.kde.org/r/5774/diff/#index_header
[15:32] <ubot4> Launchpad bug 628930 in mesa (Ubuntu Maverick) (and 4 other projects) "[i945GME] KDE Desktop effects not active by default (affects: 14) (dups: 1) (heat: 122)" [High,Fix released] https://launchpad.net/bugs/628930
[17:16] <Sarvatt> bryceh: what was the link to the right versions_current.html on http://www2.bryceharrington.org:8080/ again? new pc and I only have http://www2.bryceharrington.org:8080/X/PkgList/versions_current.html bookmarked
[17:20] <Sarvatt> evdev and synaptics merges are looking to be "fun"
[17:21] <Sarvatt> pretty significant changes in both since we used the same version all through lucid and maverick and lots of gesture patches
[17:53] <bryceh> Sarvatt, http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/versions-current.html
[17:56] <Sarvatt> bryceh: thanks! /X/ just took me to a fake LP page so I couldn't browse and http://www2.bryceharrington.org:8080/X/reports/ didn't work (whoops)
[17:56] <bryceh> yeah I should fix that
[17:56] <bryceh> but not today... way too many things to do already :-)
[17:57] <bryceh> btw I got wayland packaged finally last night
[17:57] <Sarvatt> nice!!
[17:57] <ion> Nice
[17:57] <Sarvatt> you want to disable the ARB_fragment_shader disabling patch in mesa for it btw
[17:57] <bryceh> https://launchpad.net/~xorg-edgers/+archive/wayland/+packages
[17:58] <bryceh> oh?  whyso?  any other mesa tweaks needed?
[17:58] <Sarvatt> cairo-gl depends on that on 915-945 to work
[17:58] <bryceh> I've not tested this out at all yet
[17:58] <Sarvatt> shouldn't be any other mesa tweaks needed
[17:59] <Sarvatt> hmm
[17:59] <Sarvatt> actually Im not sure if you need to pick the drm backend or EGL for it to work on intel
[17:59] <Sarvatt> on EGL rather
[17:59] <bryceh> btw I'm basing this off of your mesa git snapshot from the 4th
[18:00] <bryceh> does that have the patch?  I'm not spotting it offhand
[18:01] <bryceh> Sarvatt, well there is one mesa/gallium issue I could use your help on
[18:01] <Sarvatt> ahh I dont add that patch in edgers, thats right
[18:01] <bryceh> Sarvatt, http://lists.freedesktop.org/archives/wayland-devel/2010-November/000068.html
[18:02] <Sarvatt> yeah thats exactly the problem I thought you'd have
[18:02] <Sarvatt> need to select the drm backend for egl in a launcher script
[18:02] <bryceh> how?
[18:03] <Sarvatt> unpacking my intel now to see how I've been doing it :)
[18:03] <Sarvatt> its just an env variable
[18:04] <Sarvatt> actually its in the mesa egl docs, that'll be faster. one sec
[18:05] <Sarvatt> EGL_DRIVER=egl_dri2 yourapp
[18:06] <bryceh> ok yeah I think that may be in the directions already
[18:06] <bryceh> actually doesn't appear to be
[18:06] <Sarvatt> its only for intel, everything else wants to use the default gallium backend
[18:10] <Sarvatt> ah yeah build guide is saying to not build gallium at all so its used automatically on intel
[18:21] <bryceh> yeah unfortunately when I flip gallium off I get build errors
[18:21] <bryceh> so I've built mesa with gallium on
[18:21] <bryceh> which means it probably won't work...
[21:08] <Sarvatt> so, do we want to ship mesa 7.10 snapshots until release or just wait until december and do the real release and have things potentially change drastically all at once?
[21:09] <ScottK> If you know you're shipping 7.10, the sooner you have something that ~works and you can switch the better.
[21:09] <ScottK> (IME)
[21:23] <bryceh> really, it depends on how much we want to be doing bug report management / forwarding
[21:23] <bryceh> if we definitely do want to engage heavily with bug reports, then period snapshots make lots of sense
[21:26] <Sarvatt> december is close enough that waiting might make sense, just worried about repeat the 7.9 problems. getting 7.9 in early wouldn't have mattered though because all the glx problems we hit were introduced a few days before our first snapshot :)
[21:29] <bryceh> between what's queued up on my todo list and time I'm taking off this month I think I'm unlikely to be contributing much bug time this month.
[21:31] <bryceh> but I'm going to try to get my bug forwarding tool stuff up and running by the end of the month, which should help make forwarding a lot simpler
[21:32] <bryceh> Sarvatt, I imagine you and raof are probably also going to similarly be busy with stuff so won't be forwarding or following up on bugs this month, in which case it may make sense to hold off on snapshots
[21:33] <bryceh> or, put out a call for testing of mesa in xorg-edgers on ubuntu-x@, with directions to file bugs upstream
[21:34] <RAOF> We should start shipping 7.10 snapshots at *some* point, but I don't think that has to be now.
[21:35] <Sarvatt> whoa, its weird having the aussies be online so early today :)
[21:35] <RAOF> 8:30?
[21:35] <RAOF> That's our normal start time :)
[21:35] <RAOF> Oh.  Have you dropped out of summer time?
[21:35] <Sarvatt> its 4:30 PM here
[21:36] <bryceh> yeah we gained an hour yesterday
[21:36] <Sarvatt> usually didn't see you guys on until closer to 7PM :)
[21:37] <bryceh> btw what's the state of xorg-edgers?  Is it on track for what we plan to ship for natty?  If so, would it be helpful to steer folks to start installing and testing on that?
[21:37] <bryceh> (helpful to us specifically)
[21:37] <RAOF> I'll let Sarvatt take most of that question, but I know it hasn't flipped to Xserver 1.10.
[21:38] <RAOF> It does have a useful mesa snapshot, though.
[21:38] <Sarvatt> I'm not sure its late enough in the dev cycle to start shipping xserver 1.10 yet
[21:39] <Sarvatt> I could if it'd be useful though but I wouldn't recommend it, been worrying about getting natty up to date today and been out of town the past 2 weeks :)
[21:39] <RAOF> Actually, that raises a question: how are we doing on the “everything should depend on xorg-video-abi-$X” front?
[21:40] <Sarvatt> its painful having the abi broken constantly and people using it will hit periods where their system is unusable while all of the packages are fixed and uploaded and built
[21:41] <RAOF> Yeah.
[21:41]  * bryceh nods
[21:41] <RAOF> At the moment it'll be more useful to be testing mesa from there, rather than X.
[21:42] <bryceh> one other thing to think about, we may want to hold off major updates until after the holidays.  not much use in risking leaving people's systems broken over the holidays and just racking up bunches of bug reports.  ;-)
[21:42] <Sarvatt> not sure a call for testing makes much sense until the abi is close to being finalized, but we could be putting a lot of the other components in x-updates
[21:42] <bryceh> but guess it depends on when things start rolling in
[21:42] <Sarvatt> like libdrm/ddx/mesa updates
[21:42] <bryceh> *nod*
[21:43] <bryceh> getting them all queued up and set up for people to test by xmas break would be a good goal
[21:43] <bryceh> then depending how that turns out, slam them in Jan 2nd
[21:43] <Sarvatt> sounds good, break things just in time for the plane trips to the sprint :)
[21:44] <bryceh> or if they look bad, we can hold off until the sprint, work on it there, and then upload during the sprint or after depending on how brave we are ;-)
[21:44] <RAOF> I've preciently planned ahead; I fly to the sprint a week early, so we can be staggered :)
[21:44] <bryceh> generally in the past I've waited until the week after the sprint to upload the major changing bits
[21:44] <Sarvatt> RAOF: noticed that on the wiki, taking a vacation first or is there another sprint before?
[21:44] <bryceh> that way I minimize people bugging me during the sprint.  but with 3 of us there maybe we would like being bugged about stuff, where we can put our hands on the machines...?
[21:45] <RAOF> Sarvatt: Vacation; A bunch of ex-Hobartians are catching up for some D&D :)
[21:45] <bryceh> RAOF, awesome
[21:45] <bryceh> a week of D&D?  gaaaa
[21:45] <Sarvatt> at the latest the major changes will all be in in febuary, 2 months to stabilize is quite a bit better than natty at least!
[21:45] <RAOF> bryceh: I liked uploading xserver-xorg-video-intel with the re-enabled pageflipping at the Prague sprint; its' nice to have the hardware on hand for that sort of simple “no” :)
[21:46] <Sarvatt> RAOF: bryce just sponsored a natty with page flip reenabled a bit ago :)
[21:46] <Sarvatt> need to keep an eye on the bug reports
[21:46] <RAOF> Well, now we get to see whether 2.6.37 has all the hangs worked out :)
[21:47] <bryceh> Sarvatt, actually I only uploaded that to wayland
[21:47] <Sarvatt> bryceh: https://lists.ubuntu.com/archives/natty-changes/2010-November/001141.html
[21:47] <bryceh> Sarvatt, oh that upload
[21:47] <Sarvatt> bryceh: ohh just noticed the changes to the changelog, ChangeLog is no longer shipped in natty btw!
[21:48] <Sarvatt> all upstream ChangeLogs are stripped at build time now to save cd space
[21:48] <bryceh> Sarvatt, yeah another reason I think it's worthwhile to put highlights into debian/changelog
[21:48]  * Sarvatt nods
[21:48] <bryceh> not that I think many users read changelog info...
[21:48] <Sarvatt> will be sure to do that from now on
[21:50] <Sarvatt> I get too sloppy when I go into mass update mode, need to work on that :)
[21:50] <bryceh> I used to also peruse the bug list to see if I could match up bug #'s to issues fixed in the upstream upload
[21:50] <bryceh> however that's *quite* time consuming, esp. with our glut of bug reports now
[21:50] <RAOF> I still do do that.
[21:51] <bryceh> I like seeing the auto bug closures :-)
[21:51] <Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=a44a63d2ff6c01c3dc61de6f736dd441ddd25e52
[21:51] <Sarvatt> we need that *so bad*
[21:52] <bryceh> also it used to be that brian maintained a list of "uploaders with most bug fixes" which looked only at bug #'s listed in changelogs, so was fun to try to get to the top of that list
[21:52] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/?field.searchtext=IPEHR:+0x01820000&orderby=-importance&search=Search&field.status:list=NEW&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=INCOMPLETE_WITHOUT_RESPONSE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_
[21:52] <Sarvatt> no_package=
[21:52] <Sarvatt> all of those are fixed by that commit
[21:52] <bryceh> Sarvatt, small enough patch
[21:52] <Sarvatt> the IPEHR: 0x01820000 bugs against intel
[21:53] <bryceh> any risks to it?
[21:53] <bryceh> or performance hits?
[21:54] <Sarvatt> only reason I didn't cherry pick it is because intel 2.13.901 will be merged soon with it
[21:54] <bryceh> well, would it be SRU-worthy?
[21:54] <Sarvatt> but need to try backporting it to 2.12 and have maverick people test
[21:54] <RAOF> It looks like the non-trivial code should only be hit on modeswitch, which isn't exactly in the hot-path.
[21:55] <Sarvatt> not really a performance problem, it happens on dpms events, lid closing, suspend/resume, etc
[21:55] <Sarvatt> enabling new monitors
[21:55] <RAOF> It looks like a perfect candidate for an SRU, in fact.
[21:56] <Sarvatt> that is a *major* problem though, one of the 3 major actual bugs apport caught
[22:06] <bryceh> sorry, system locked up.
[22:06] <bryceh> ironically
[22:06] <bryceh> it sounds worth SRUing to me as well
[22:15] <Sarvatt> x11-apps is painful, every single app has linking problems on natty
[22:17] <bryceh> hrm
[22:36] <Sarvatt> on the plus side maybe squeeze will ship over christmas and we can do the xserver 1.10/mesa 7.10 stuff directly in experimental
[22:37] <RAOF> We should ask if we can do that regardless.
[22:37] <RAOF> In fact, I'll send an email to that effect right now.
[22:37] <Sarvatt> its occupied largely with xorg 7.6 releases at the moment
[22:39] <RAOF> Do they care about the katamari particularly?
[22:39] <Sarvatt> i'm trying to help out as much as I can there merging stuff in git, KiBi is going nuts releasing everything \o/
[22:39] <Sarvatt> I do at least!
[22:39]  * Sarvatt ducks
[22:44] <Sarvatt> is it just me or does applying for PPU for all of X seem like a crazy idea?
[22:44] <ion> PPU?
[22:44] <Sarvatt> per package uploader
[22:45] <ion> ah
[23:02] <Sarvatt> bryceh: alrighty I'll backport libdrm and x-x-v-intel into x-updates as soon as we get 2.13.901 in, I just hate updating libdrm in there because all of the packages pick up the new libdrm dependency
[23:04] <Sarvatt> by now I would hope a majority of people have figured out you cant just install single deb's from most PPAs :)
[23:09] <ScottK> Sarvatt: It's probably enough packages that it might be worth creating a packageset for it.  
[23:14] <bryceh> Sarvatt, don't apply for PPU, just shoot for gaining MOTU and core dev
[23:15] <bryceh> the requirements for core dev are mostly about earned trust
[23:15] <Sarvatt> well MOTU is what I was unsure about, I was thinking it might make more sense to apply for PPU for the few X packages that are perpetually merged instead of synced if anything
[23:16] <bryceh> most anyone who does a lot of X uploads with care to not break stuff has demonstrated a sufficient amount of trust
[23:18] <Sarvatt> there are admittedly not many packages in universe that I would end up taking care of, X/mesa/libdrm stuff takes up all my time and then some
[23:19] <bryceh> Sarvatt, I think you more than sufficiently qualify for MOTU, but if it makes you feel more comfortable, do a dozen or so merges off of https://merges.ubuntu.com/universe.html and get them sponsored by pitti and one or two other guys
[23:20] <bryceh> most merges should be pretty trivial for you, probably you can bang them out in a couple hours ;-)
[23:21] <Sarvatt> I need more experience in non-xsfbs packages for sure, spoiled by the awesome xsfbs
[23:23] <bryceh> if none of the universe packages look interesting, there's also tons of stuff at https://merges.ubuntu.com/main.html
[23:23] <Sarvatt> so yeah I guess you're right MOTU is the way to go
[23:24] <bryceh> at this point early in the release, it's easy to do merges since we're not yet frozen, so can be a good idea to spend an afternoon a week just doing some non-X merges and gain sponsors to give testimonial
[23:33] <bryceh> next membership board meeting is the 22nd - https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda
[23:34] <bryceh> Sarvatt, RAOF, I think both of you ought to plan on attending to up your permission levels.
[23:35] <bryceh> todo list for what you two need to do is at  - https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess
[23:35] <Sarvatt> yeah, I'll fill out my application this week, started a skeleton some time ago https://wiki.ubuntu.com/Sarvatt/MOTUApplication
[23:35] <bryceh> and more info about expectations/abilities at https://wiki.ubuntu.com/UbuntuDevelopers
[23:36] <bryceh> Sarvatt, yep
[23:41] <Sarvatt> darn, looks like https://edge.launchpad.net/~sarvatt/+uploaded-packages only lists 1 upload per package per release when I've had multiples in a bunch of those
[23:51] <bryceh> Sarvatt, I'm sure there must be a way to get the history
[23:53] <bryceh> Sarvatt, btw see persia's comments on #ubuntu-devel
[23:53] <bryceh> sounds like you should go for either MOTU or PPU, then use that as stepping stone to core-dev
[23:53] <Sarvatt> argh, I knew I forgot to add a channel to auto-join on this new pc!
[23:54]  * Sarvatt reads the logs