[00:00] 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] Because we had a snapshot which had the per-crtc pixmap stuff in it that got dropped. [00:03] that won't affect abi though will it? [00:03] If I am reading the site correctly, xorg-edgers only packages the core wayland library, no compositors or clients? [00:05] I mean I doubt there's any x server that used it.. [00:07] and libxrandr builds just fine with new one [00:07] mlankhorst: Technically it breaks API; code which compiled on precise will fail to compile with 1.4.0. [00:08] except that it would already break api in a lot worse way if something used it.. [00:08] Whether or not there's any code which *uses* that is a different question; the server obviously doesn't. [00:08] libxrandr doesn't either [00:08] and those are the only useful cases [00:08] hm maybe libxcb *checks* [00:09] nope builds just fine [00:12] Oh, yeah. [00:12] I don't expect this to be a *practical* problem. [00:12] But maybe some crazy loon has written something directly against the xrandr protocol headers in precise, and it'll break :) [00:13] I will hunt them down, apply an industrial size magnet to their hard disk, then take it with me for physical destruction [00:13] any code that does depend on it would just get a badrequest anyway [00:13] Absolutely. [00:13] Actually, no it wouldn't. [00:14] ...or maybe it would. [00:14] * mlankhorst did his homework on that one! [00:14] It'd certainly error out, though. [00:14] The request structs are different sizes :) [00:15] in any case that would only be a problem when talking to a NEW xserver [00:15] Indeed. [00:15] But these are the things you learn to think about on the SRU team :) [00:16] don't try to drag me into the sru team! :P [00:26] but that should be enough to start uploading most of the quantal stack at least [00:27] hum. the fglrx-experimental-9 integration work looks a bit flaky. but the driver itself appears to be working ok. [00:28] RAOF: oh right, missing llvm-3.1 too, not sure how you want to approach that? [00:29] mlankhorst: I'll talk with the rest of the SRU team. [00:29] thanks [00:30] tjaalton: https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/804109 is missing the SRU information; specifically a test case and regression potential. [00:30] Launchpad bug 804109 in acpi-support (Ubuntu Precise) "drop synaptics from racy /etc/acpi/asus-touchpad.sh" [Undecided,In progress] [00:36] 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] Then we can't have mesa 9.0.1 in quantal :( [00:37] fortunately can be reverted [00:37] Why were those commits in the stable tree? Gah! [00:38] hey I did qa for nouveau in mesa9! [00:38] which seems to be more than it usually receives.. [00:39] well qa = check if game finally ran in wine with renamed stack and wayland from raring.. [00:41] Is there an official channel for xorg-edgers repo or is this unofficially it? [00:42] soreau: This is where everyone who can upload to xorg-edgers hangs out, yes. [00:42] If I am reading the site correctly, xorg-edgers only packages the core wayland library, no compositors or clients? [00:43] we only use it to satisfy mesa build-depends afaict [00:43] Sarvatt: ^ [00:43] ah.. [00:43] ok thanks [00:43] weston is in there too [00:44] Sarvatt: What branch does it build wayland and weston from, master? [00:44] yup [00:44] and still doesn't install weston clients since they're not installed by weston build system [00:45] 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] Sarvatt: thanks [00:46] 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] Is there a page that shows the build status of all the packages? [00:47] https://launchpad.net/~xorg-edgers/+archive/ppa/+builds?build_text=&build_state=all [00:49] Sarvatt: cool [01:56] 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] RAOF: oh, indeed it does [06:17] Sarvatt: do you have mesa master in edgers? if yes, any surprises in the packaging? [09:39] ohai new steam update [09:40] guess first time steam loaded succesfully here \o/ === broder is now known as broder_ [14:08] I'll play some more games later, found a nice way to reduce cpu use on nouveau [14:37] bryce: the bug-graphs for released versions don't seem to update? [16:57] I think that's on purpose === yofel_ is now known as yofel [17:01] me too, but I like them :) [18:35] 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] 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] wrong channel for that [18:36] hahaha [18:37] you are right below my luser ubuntu channel [18:37] wrong click [18:37] but just for the record, cheese is kinda cheesy [18:40] mlankhorst: thanks for the reminder ;) [18:40] np [18:40] bryce: ah, thanks [18:45] 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] bryce: hum, the quantal xserver has the broken barrier commit in it [23:03] that you pushed [23:04] tjaalton, oh dear did I break the non-functional multihead on nexus7? [23:04] well did you upload it to quantal ?-) [23:05] the branch looks like it [23:05] just a warning.. [23:06] tjaalton, nope, just to the ppa [23:07] which ppa? [23:07] ubuntu-quantal, not ubuntu-quantal-nexus7 [23:10] RAOF: bug bug llvm-3.1 ;P [23:11] mlankhorst: Thanks for the ping :) [23:11] also might do a new xorg upload for precise soon [23:11] but that could be part of the entire rename x push [23:20] bryce: just verifying; you didn't upload xserver ubuntu-quantal branch to quantal-proposed, but somewhere else? [23:21] tjaalton, no I did not upload it [23:22] ok good, then it should be marked back UNRELEASED? [23:22] well let's see [23:22] because it needs the revert from raring [23:23] yep, you're right. [23:24] 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] not sure how much mesa/llvmpipe actually 'needs' the latest llvm.. [23:25] but less work to have it [23:25] there [23:26] 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] 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] s/stack/llvm/ [23:27] bryce: oh ok :) [23:27] tjaalton, I'm guessing you fixed only the raring upload, not the quantal one? [23:27] didn't know that existed [23:28] yeah, was mentioned on bug 1069031 [23:28] Launchpad bug 1069031 in X.Org X server "intel gma3600: X unable to start" [Undecided,New] https://launchpad.net/bugs/1069031 [23:28] ah, yeah missed that one [23:29] I can fix it tomorrow and push 6.2 [23:30] no, 6.1 [23:30] can reuse the version since it didn't get through [23:30] actually... [23:30] wow, this is interesting [23:31] uploaded -intel 2.20.13 btw [23:31] looks like you'd attempted a 6.1 upload last month, and it got rejected [23:31] on purpose [23:31] it's a bad number :) [23:31] 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] no, it got dropped before it went past the queue [23:32] bad as in cursed? ;-) [23:32] something like that.. [23:32] anyway, sure thanks for taking care of it. :-) [23:33] the reason was that it had some extra cruft on it that I had on the tree (git status ftw) [23:33] and also one of the patches was a bit so-so, but confirmed later on [23:33] so with the revert added it should be good [23:33] 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] oh there it is [23:38] 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] altogether when doing 1.14 [23:39] hoping that we'd be able to drop most by then [23:42] hmm, I still find the numbers handy personally but whatever [23:42] the numbers, what do they mean ;) [23:44] they make it easier to refer to a patch, but then again the numbers are getting reused.. [23:46] true, noticing that a bit with some SRUs. Of course, this won't fix that [23:48] well, not right away. [23:50] yeah it'll take some time [23:51] maybe start the no-number scheme with 1.14 [23:51] and use whatever for 1.13 [23:54] anyway, night all