[00:00] <RAOF> If you check out the diff between what's in precise and the x11proto-randr in the precise-proposed queue, it drops protocol definitions.
[00:00] <RAOF> Because we had a snapshot which had the per-crtc pixmap stuff in it that got dropped.
[00:03] <mlankhorst> that won't affect abi though will it?
[00:03] <soreau> If I am reading the site correctly, xorg-edgers only packages the core wayland library, no compositors or clients?
[00:05] <mlankhorst> I mean I doubt there's any x server that used it..
[00:07] <mlankhorst> and libxrandr builds just fine with new one
[00:07] <RAOF> mlankhorst: Technically it breaks API; code which compiled on precise will fail to compile with 1.4.0.
[00:08] <mlankhorst> except that it would already break api in a lot worse way if something used it..
[00:08] <RAOF> Whether or not there's any code which *uses* that is a different question; the server obviously doesn't.
[00:08] <mlankhorst> libxrandr doesn't either
[00:08] <mlankhorst> and those are the only useful cases
[00:08] <mlankhorst> hm maybe libxcb *checks*
[00:09] <mlankhorst> nope builds just fine
[00:12] <RAOF> Oh, yeah.
[00:12] <RAOF> I don't expect this to be a *practical* problem.
[00:12] <RAOF> But maybe some crazy loon has written something directly against the xrandr protocol headers in precise, and it'll break :)
[00:13] <mlankhorst> I will hunt them down, apply an industrial size magnet to their hard disk, then take it with me for physical destruction
[00:13] <mlankhorst> any code that does depend on it would just get a badrequest anyway
[00:13] <RAOF> Absolutely.
[00:13] <RAOF> Actually, no it wouldn't.
[00:14] <RAOF> ...or maybe it would.
[00:14]  * mlankhorst did his homework on that one!
[00:14] <RAOF> It'd certainly error out, though.
[00:14] <RAOF> The request structs are different sizes :)
[00:15] <mlankhorst> in any case that would only be a problem when talking to a NEW xserver
[00:15] <RAOF> Indeed.
[00:15] <RAOF> But these are the things you learn to think about on the SRU team :)
[00:16] <mlankhorst> don't try to drag me into the sru team! :P
[00:26] <mlankhorst> but that should be enough to start uploading most of the quantal stack at least
[00:27] <bryce> hum.  the fglrx-experimental-9 integration work looks a bit flaky. but the driver itself appears to be working ok.
[00:28] <mlankhorst> RAOF: oh right, missing llvm-3.1 too, not sure how you want to approach that?
[00:29] <RAOF> mlankhorst: I'll talk with the rest of the SRU team.
[00:29] <mlankhorst> thanks
[00:30] <RAOF> tjaalton: https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/804109 is missing the SRU information; specifically a test case and regression potential.
[00:36] <mlankhorst> RAOF: btw for quantal, mesa 9.0.1 updated to new wayland 0.99 which unsurprisingly wasn't compatible with the old one from quantal..
[00:36] <RAOF> Then we can't have mesa 9.0.1 in quantal :(
[00:37] <mlankhorst> fortunately can be reverted
[00:37] <RAOF> Why were those commits in the stable tree? Gah!
[00:38] <mlankhorst> hey I did qa for nouveau in mesa9!
[00:38] <mlankhorst> which seems to be more than it usually receives..
[00:39] <mlankhorst> well qa = check if game finally ran in wine with renamed stack and wayland from raring..
[00:41] <soreau> Is there an official channel for xorg-edgers repo or is this unofficially it?
[00:42] <RAOF> soreau: This is where everyone who can upload to xorg-edgers hangs out, yes.
[00:42] <soreau> If I am reading the site correctly, xorg-edgers only packages the core wayland library, no compositors or clients?
[00:43] <mlankhorst> we only use it to satisfy mesa build-depends afaict
[00:43] <mlankhorst> Sarvatt: ^
[00:43] <soreau> ah..
[00:43] <soreau> ok thanks
[00:43] <Sarvatt> weston is in there too
[00:44] <soreau> Sarvatt: What branch does it build wayland and weston from, master?
[00:44] <Sarvatt> yup
[00:44] <soreau> and still doesn't install weston clients since they're not installed by weston build system
[00:45] <Sarvatt> i have no clue what its installing these days, ricotz does that
[00:45]  * soreau now sees weston listed after clicking the next button on the website
[00:46] <soreau> Sarvatt: thanks
[00:46] <Sarvatt> list of all the files it installs are at the end of https://launchpadlibrarian.net/121088081/buildlog_ubuntu-raring-amd64.weston_1.0.0%2Bgit20121025.00fbbe6b-0ubuntu0ricotz_BUILDING.txt.gz
[00:47] <soreau> Is there a page that shows the build status of all the packages?
[00:47] <Sarvatt> https://launchpad.net/~xorg-edgers/+archive/ppa/+builds?build_text=&build_state=all
[00:49] <soreau> Sarvatt: cool
[01:56] <Dandel> Sarvatt: is there a possibility of readding libwaffle to the piglit requirements on quantinal, also, i think there might be a build failure in the works.
[05:56] <tjaalton> RAOF: oh, indeed it does
[06:17] <tjaalton> Sarvatt: do you have mesa master in edgers? if yes, any surprises in the packaging?
[09:39] <mlankhorst> ohai new steam update
[09:40] <mlankhorst> guess first time steam loaded succesfully here \o/
[14:08] <mlankhorst> I'll play some more games later, found a nice way to reduce cpu use on nouveau
[14:37] <tjaalton> bryce: the bug-graphs for released versions don't seem to update?
[16:57] <mlankhorst> I think that's on purpose
[17:01] <tjaalton> me too, but I like them :)
[18:35] <bryce> tjaalton, it's on purpose, but I also would prefer if they kept updating.  Some day when I get time I'll investigate why they don't.
[18:36] <soreau> Hey guys, is there a webcam program that doesn't suck? Trying cheese here, can't even figure out how to get out of fullscreen :P
[18:36] <mlankhorst> wrong channel for that
[18:36] <soreau> hahaha
[18:37] <soreau> you are right below my luser ubuntu channel
[18:37] <soreau> wrong click
[18:37] <soreau> but just for the record, cheese is kinda cheesy
[18:40] <soreau> mlankhorst: thanks for the reminder ;)
[18:40] <mlankhorst> np
[18:40] <tjaalton> bryce: ah, thanks
[18:45] <Dandel> RAOF: i spotted a minor patch that might be worth pulling in and testing on the piglit packaging... care to take a look?
[23:03] <tjaalton> bryce: hum, the quantal xserver has the broken barrier commit in it
[23:03] <tjaalton> that you pushed
[23:04] <bryce> tjaalton, oh dear did I break the non-functional multihead on nexus7?
[23:04] <tjaalton> well did you upload it to quantal ?-)
[23:05] <tjaalton> the branch looks like it
[23:05] <tjaalton> just a warning..
[23:06] <bryce> tjaalton, nope, just to the ppa
[23:07] <tjaalton> which ppa?
[23:07] <tjaalton> ubuntu-quantal, not ubuntu-quantal-nexus7
[23:10] <mlankhorst> RAOF: bug bug llvm-3.1 ;P
[23:11] <RAOF> mlankhorst: Thanks for the ping :)
[23:11] <mlankhorst> also might do a new xorg upload for precise soon
[23:11] <mlankhorst> but that could be part of the entire rename x push
[23:20] <tjaalton> bryce: just verifying; you didn't upload xserver ubuntu-quantal branch to quantal-proposed, but somewhere else?
[23:21] <bryce> tjaalton, no I did not upload it
[23:22] <tjaalton> ok good, then it should be marked back UNRELEASED?
[23:22] <bryce> well let's see
[23:22] <tjaalton> because it needs the revert from raring
[23:23] <bryce> yep, you're right.
[23:24] <mlankhorst> but I think the lts stack is mostly ready for upload now, so when llvm-3.1 is ready I should be able to do a massive upload to precise after doing 1 more verification
[23:25] <tjaalton> not sure how much mesa/llvmpipe actually 'needs' the latest llvm..
[23:25] <tjaalton> but less work to have it
[23:25] <tjaalton> there
[23:26] <mlankhorst> tjaalton: It's completely untested on the old stack, and later mesa's will probably run into more and more troubles as you try it..
[23:26] <bryce> tjaalton, ah actually what I pushed to the tree *was* uploaded 5 days ago.  I'm guessing when we caught the original problem we pulled the package from -proposed (at least, it's not there now)
[23:26] <mlankhorst> s/stack/llvm/
[23:27] <tjaalton> bryce: oh ok :)
[23:27] <bryce> tjaalton, I'm guessing you fixed only the raring upload, not the quantal one?
[23:27] <tjaalton> didn't know that existed
[23:28] <bryce> yeah, was mentioned on bug 1069031
[23:28] <tjaalton> ah, yeah missed that one
[23:29] <tjaalton> I can fix it tomorrow and push 6.2
[23:30] <tjaalton> no, 6.1
[23:30] <tjaalton> can reuse the version since it didn't get through
[23:30] <bryce> actually...
[23:30] <bryce> wow, this is interesting
[23:31] <tjaalton> uploaded -intel 2.20.13 btw
[23:31] <bryce> looks like you'd attempted a 6.1 upload last month, and it got rejected
[23:31] <tjaalton> on purpose
[23:31] <tjaalton> it's a bad number :)
[23:31] <bryce> so... maybe the reason I'm not seeing my 6.1 upload didn't show up was because that earlier upload already used up 6.1?
[23:32] <tjaalton> no, it got dropped before it went past the queue
[23:32] <bryce> bad as in cursed?  ;-)
[23:32] <tjaalton> something like that..
[23:32] <bryce> anyway, sure thanks for taking care of it.  :-)
[23:33] <tjaalton> the reason was that it had some extra cruft on it that I had on the tree (git status ftw)
[23:33] <tjaalton> and also one of the patches was a bit so-so, but confirmed later on
[23:33] <tjaalton> so with the revert added it should be good
[23:33] <bryce> I've a feeling that patch 237 may be an important one to fix up more input rotation hijinks, but couldn't verify it beyond the vm use case mentioned in the bug
[23:33] <tjaalton> oh there it is
[23:38] <tjaalton> also, now that the xserver patches have been divided into categories, it's time to drop the nonsense numbers, at least from new patches :)
[23:38] <tjaalton> altogether when doing 1.14
[23:39] <tjaalton> hoping that we'd be able to drop most by then
[23:42] <bryce> hmm, I still find the numbers handy personally but whatever
[23:42] <mlankhorst> the numbers, what do they mean ;)
[23:44] <tjaalton> they make it easier to refer to a patch, but then again the numbers are getting reused..
[23:46] <bryce> true, noticing that a bit with some SRUs.  Of course, this won't fix that
[23:48] <bryce> well, not right away.
[23:50] <tjaalton> yeah it'll take some time
[23:51] <tjaalton> maybe start the no-number scheme with 1.14
[23:51] <tjaalton> and use whatever for 1.13
[23:54] <tjaalton> anyway, night all