[00:09] RAOF, bryceh: going forward, how do we want to update our xserver tree with upstream changes from stable 1.11 and 1.12 stable releases [00:09] do we want to continually merge in the latest patches, or only when new releases are made [00:09] ie, only once 1.11.4 is released do we merge in everything since 1.11.3 [00:10] Either is reasonable at this point. If there are important patches they should be pulled in, or wait until the release and merge it in. [00:11] ok [00:11] it would make troubleshooting somewhat easier if we pull in only the official point releases, and specific patches to fix specific bugs in between [00:11] that's my thinking too [00:12] I don't think there's any particular reason to aggressively track the release branches. [00:12] yeah [00:13] it's easy enough to cherrypick fixes we know we need as we learn about them [00:18] bryceh, RAOF: any issues if I add this patch in to our server: ead968a4300c0adeff89b9886e888b6d284c75cc [00:18] sadly, I can't give you a link to the git diff because git.fd.o is down [00:18] the usefulness for us is that with the patch xorg-gtest can be run as non-root [00:18] cnd: Absolutely. [00:20] righteo [00:20] cnd, yep fine by me, assuming it causes no known issues [00:20] none that I'm aware of :) [00:57] tjaalton, for bug #921941, should -mtrack be included in -input-all ? [00:57] Launchpad bug 921941 in xf86-input-mtrack (Ubuntu) "No way for user to know that mtrack module is needed on upgrade to latest xorg with Apple trackpad (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/921941 [00:57] bryceh: no way [00:58] synaptics works fine [00:58] Sarvatt, apparently not [00:58] mtrack just provides some more features but its in no way needed [00:58] bryceh: i'm using it on the same system he posted the bug on [00:58] mtrack doesn't build in precise right now [00:59] oh weird, it did build, what the heck? [01:00] it just has a few extra features like multitouch gestures but its not even maintained on freedesktop and very rarely gets updates, really dont think its appropriate for input-all [01:00] bryceh: what happened was he had mtrack in an xorg.conf [01:00] and was trying to use it [01:00] thats what it looks like to me [01:01] all the macbook air setup guides recommend using it [01:01] alright [01:04] bryceh: I guess mtrack needs adding to the apport hooks? [01:05] Huh. You live and learn. [01:05] i responded on the bug and pinged him in #ubuntu-devel [01:05] yeah [01:05] oh heh, was just drafting up a reply myself [03:57] Sarvatt, bryceh: I think the only real feature people want out of mtrack is the click-and-drag support [03:57] I hope to get to that still in synaptics before feature freeze [03:57] cnd, awesome [03:58] the rest of mtrack is handled better by gestures on the client side of X [03:58] and I agree, it definitely shouldn't be in -input-all [05:00] morning [05:00] Sarvatt: well, we should've used -0~ubuntuN with mesa ;) [05:01] a goot guideline for the staging repo in general, I guess [05:01] good even [05:02] Sarvatt: oh well, just squash it I guess. we'll have rc3 soon anyway [05:02] not a big deal since the releases aren't tagged [05:02] tjaalton: ya mind doing that? its past midnight here, barely awake [05:03] sure [05:03] didn't upload -vmware either? [05:03] it'll just sit in depwait until mesa is done [05:03] now that it build-depends on libxatracker [05:04] * Sarvatt can't upload anything but did ask [05:04] haha, of course [05:05] so wayland first [05:05] got packages up here http://kernel.ubuntu.com/~sarvatt/packages/ if it's any easier [05:06] ok sure [05:06] ah wayland release is in git too [05:06] i do believe its time to look into getting upload privileges.. 118 uploads should be enough [05:06] please [05:06] and I should file the DD application.. [05:07] got the needed signatures at the sprint [05:07] wayland uploaded [05:07] heck its more than 118, launchpad only lists 1 upload per package per release and i do multiples usually [05:07] like the last 2 libdrm's to precise count as one on launchpad [05:09] thanks for the help tjaalton [05:09] hmm so mesa, I'll just squash it? [05:10] yw [05:10] i think that's the right thing to do but would be ok to do it either way :) [05:10] oh well, you'll get one upload more if I pull yours :) [05:12] you don't have xserver there? [05:12] oh heck [05:13] hmm mesa source.changes doesn't have 8.0~rc2-1 entries [05:14] oh sure does [05:14] push git too [05:15] sheesh making that mistake too much this past week, pushed [05:15] :) [05:15] looks like chase has something else queued for xserver [05:16] should i get that ubuntu9 ready or wait? [05:17] you mean 10? [05:17] yeah he's got a 10 in UNRELEASED state [05:17] I see it as 11 :) [05:17] oh yeah [05:17] sheesh [05:18] ping noise woke me up, sorry i'm half here :) [05:19] does xserver build-dep on the new mesa without the search path? [05:19] http://kernel.ubuntu.com/~sarvatt/packages/xserver/ [05:20] or break if it builds against the older one [05:20] they're doing some test rebuild, its probably worth uploading xserver without a drisearchpath in dri.pc dependency before mesadependency before mesa [05:21] ..ok so xserver before mesa.. got it [05:21] well mesa uploaded already though [05:26] vmware too [05:26] all done, thanks for preparing them :) [05:27] ah, breakfast/wakeup time -> === chrisccoulson_ is now known as chrisccoulson [09:27] * apw is seeing alll new shiney visual corruption on alt-tab in precise. anyone seen that? [09:27] https://launchpadlibrarian.net/91781478/BROKEN2.png [09:27] https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/925936 [09:27] Launchpad bug 925936 in xorg (Ubuntu) (and 2 other projects) "screen corruption on alt-tab in unity (affects: 1) (heat: 6)" [Undecided,New] [09:28] apw: apt-cache policy libgl1-mesa-dri [09:29] libgl1-mesa-dri: [09:29] Installed: 7.11-0ubuntu4 [09:29] Candidate: 7.11-0ubuntu4 [09:29] ok, so not 8.0~rc2 yet [09:29] what does "all new" mean? :) [09:29] what has changed? [09:30] oneiric -> precise [09:30] so in theory i have A2 on here [09:30] ok [09:30] i've no such issues with sandybridge [09:30] I'll upgrade my x61 (i965) [09:30] as there is X pending i could update just X, seems it wants to deinstall most of my machine otherwise ... sigh [09:30] huh? [09:30] there should be no such issues [09:31] The following packages will be REMOVED [09:31] how did you upgrade? [09:31] gstreamer0.10-plugins-good:i386 gstreamer0.10-x:i386 gtk2-engines:i386 [09:31] gtk2-engines-murrine:i386 gtk2-engines-oxygen:i386 gtk2-engines-pixbuf:i386 [09:31] its going to remove ... alll of my i386 things, i am told archive skew due to the rebuild test [09:31] ok [09:31] the upgrade i did yesterday was an update-manager -d update, and worked fine [09:31] its today thats the problem :/ [09:31] ah ok [09:32] * apw goes for an update, and will re-test [09:32] there is a new mesa available too, so test with that too [09:32] tjaalton, ok thanks [09:33] The following packages have been kept back: [09:33] evolution-common evolution-indicator evolution-plugins libgl1-mesa-dri [09:33] libgl1-mesa-dri:i386 libgl1-mesa-glx libgl1-mesa-glx:i386 libglapi-mesa [09:33] libglapi-mesa:i386 [09:34] tjaalton, bugger, the skew is holding back the mesa update [09:35] ok.. [10:13] tjaalton, ok ... by hook and by crook i got it upgraded, and the issue is still there [10:15] apw: hum, ok [10:16] try booting an older kernel.. trying to rule out variables [10:16] since the dri driver was the same as on oneiric [10:17] bah the upgrade has removed my older kernels [10:18] :) [10:18] hmm, shouldn't it leave the last of the old series? [10:18] newest abi [10:18] i recall it doing that here [10:18] it has left 3.0.0-5 and -9 [10:19] oh i wonder if its ordering textually when it makes the list [10:19] hense i have -9 [10:19] hah [10:52] tjaalton, ok same with the latest O kernel too [11:03] apw: ok, thanks [11:04] mind testing alpha1 livecd too.. just to get another testing point [11:04] it didn't have the new X yet [11:05] tjaalton, that'll have to go on my todo list [11:05] or unity [11:05] sure [11:05] no rush [11:05] tjaalton, where can i find the alpha1 image btw, so i can start it downloading [11:05] cdimages.u.c [11:05] or -s [11:06] hmm, not there [11:25] tjaalton, hrm ... so i don't see an old image, not sure if we keep them now i think abuot it [11:26] ok.. [11:27] tjaalton, ok this is only happening on my external monitor, not on the internal lcd in the same X session [11:27] I need to rejig my cobbler setup to support precise in order to test it on my X61 [11:27] apw: aha! now that's something then :) [11:28] so it didn't do it on oneiric? [11:28] I'll blame unity [11:28] its pretty obvious when it happens, and i don't recall seeing it [11:28] but i wouldn't like to say it wasn't there [11:28] it's as easy a target as they get [11:28] :) [11:28] at least there was the 4->5 bump in unity [11:29] iterestingly it also dammages windows in front of the scrolling window [11:30] tjaalton, and the fuzzed through stuff through the popup is in the right place, just the bits outside the popup are out of line [11:31] yep [11:32] and its any scrolling in any sized panel which trips it, not necessary for it to be anywhere specific on the screen [11:32] very odd indeed. [11:34] I'll try it on the sandybridge machine.. [11:37] seems to work fine on it [11:38] now I need to install the older one to see what happens there.. [13:08] apw: looks like there's a new unity pushed to precise, just in time for the weekend.. [13:09] tjaalton, well, it was tested in a ppa for the week and got quite some tester sending back feedback through checkbox, should be fine [13:09] famous last words [13:09] ;) [13:09] seb128: yeah, i bet it's better than during oneiric ;) [13:10] what could possibly go wrong? ;-) [13:10] just to give apw something to test again, since the bug might be unity related and possible fixed in this new version [13:11] tjaalton, 'yay' [13:12] you can use ppa:unity-team/staging if you want to try it [13:12] it's going to take an hour or two for the archive version to build [13:13] yeah, forgot about that [13:47] Hmm looks like mesa-utils is broken in precise. [13:47] I need my glxgears. [13:47] for benchmakring :) [13:47] broken how? [13:48] Can't find installation source, only referred to by other packages. [13:48] enable universe [13:49] ah ok [13:51] Okay... seems that for some reason Unity and ubuntu-desktop gets removed if I try to dist-upgrade to get the new 8.0 mesa... [13:51] Prf_Jakob, yep there is a unity upload in the archive, and only half compiled [13:52] apw: Ah, so I just need to wait and it will sort itself out? [13:52] Prf_Jakob, heres hopng [13:53] heh [13:54] if you apt-get install libxatracker1 manually, apt-get upgrade should pull the new mesa bits (and -vmware) [13:54] without removing anything [13:59] hmm, after killing X, it just seems to continously crash and restart the X server. [13:59] (just running of the Live CD). [13:59] with -vmware? [13:59] ok [13:59] which driver? [13:59] I'll install it properely. [13:59] -vmware [14:03] Ah, hmm, well this is awkward, I can't install it since the default screen is to small.... [14:03] 800x600? [14:03] yupp [14:03] isn't that your driver failing? :) [14:05] Its the default, 1024x768 is to big. [14:05] can't you change it then? [14:05] from the settings [14:06] Don't think so. [14:06] how is 10x7 too big.. cirrus for kvm uses that [14:06] 13" and small macs that will make the UI to big. [14:06] smaller* [14:07] then don't use the live-session installer, but start it directly [14:07] should work that way I guess [14:07] Can't set that setting in Fusion. [14:10] tjaalton: this is a problem for small netbooks as well [14:10] people run vmware on small netbooks? [14:10] No, but the installer not working [14:11] As per 869239 [14:11] bug 869239 [14:11] Launchpad bug 869239 in ubiquity (Ubuntu Precise) (and 1 other project) "webcam screen should be resized for netbooks (Eee PC, 10") (affects: 11) (dups: 3) (heat: 62)" [High,Fix released] https://launchpad.net/bugs/869239 [14:11] There we go [14:12] Hmm fixed... [14:12] webcam? [14:12] well as I said, don't run it from the live session? [14:12] but boot directly to the installer [14:14] I started the live session, changed the resolution and then started the installer. [14:17] so you _could_ do that.. [14:18] Right, but just picking install now fails. [14:19] so you did that before? [14:19] Yes [14:22] Changing the minimum default size for the new driver is a kernel patch. [14:37] tjaalton, Sarvatt: Any way I can see which git hash a package was built from? [14:37] You might have picked up a old version of -vmware. [14:41] Gtg, flying to FOSDEM. [14:51] Prf_Jakob: it's the11.99.901 tarball + 8ff19c2b2 vmwgfx: Avoid including a library header and use pixman for type conversion [16:46] jcristau, we are looking at creating a package for xorg-gtest [16:47] initially just ubuntu-only because of deadlines, but there's no reason it can't be packaged in debian and then we sync from there eventually [16:47] how can we get an xorg-gtest packaging repo on git.debian.org? === yofel_ is now known as yofel [18:14] cnd: it's created with /git/pkg-xorg/setup-repository on alioth. first check the path where it should go [18:15] the hierarchy follows upstream [18:20] tjaalton, ahh, thanks [18:22] maybe ping debian-x@ too [18:26] ppa's just aren't working anymore with the publishing/build time skew between arches, really going to have to change my workflow for xorg-edgers.. === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [19:55] RAOF: how hard is it to copy from x-staging to the archive? [19:55] its a really good idea to build mesa updates in there first from now on with the skew between i386 and amd64 builds, libegl1-mesa-dev is broken in the current one and needs a libxcb-glx0-dev dependency [19:56] who's using libegl1-mesa-dev? [19:57] wayland-demos, mesa-demos, i'm sure plenty of arm stuff like clutter [19:58] ok then [19:58] (clutter uses egl instead of gl on armel/armhf) [19:58] evening [19:58] i think RAOF is done for the day though ;) [19:59] so either let those be broken for now and cumulate more stuff in mesa git until monday (if something comes up) [19:59] or push it now to precise [20:02] oh I was just shooting a question at him, was curious how hard it was for him to do that for X before [20:02] like if it needs hand holding from other people to do or if it's possible to just copy it himself [20:17] Steve Langasek (vorlon) wrote on 2011-12-20: #7 [20:17] (Priority: OMG there's a game with "meat" in the name and it doesn't work on Ubuntu, must fix) [20:17] Changed in mesa (Ubuntu): [20:17] status: Confirmed → Triaged [20:17] importance: Undecided → Medium [20:17] ha [20:20] LLOL [20:21] the importance of the correct motivation [20:23] hehe [21:23] so yeah we'll need to get plymouth fixed or revert a few commits off libdrm next update [21:24] since it only builds libdrm-intel1 on amd64 and i386 now [21:25] you uploaded mesa 0u5 to staging? [21:25] oh no should i? [21:25] i dont know what screws you up [21:25] nah just noticed that the changelog is finalized [21:25] er, "released" [21:26] wall was unclear if you wanted to upload that as it was, or wait and amass some more fixes monday [21:26] yeah but now someone else could bump it to u6 :) [21:26] like what happened with xserver? lol [21:27] that [21:27] its just you and me touching that branch, we can just use dch -a :P [21:28] RAOF, bryceh: heads up if you commit anything to the ubuntu mesa branch, ubuntu6 wasn't released [21:28] ok, works for me then :) [21:29] i will try to get the PPU stuff sorted by next week [21:29] I'd like to drop the extra osmesa flavors [21:29] yeah that'd be freaking awesome [21:30] no-one else builds them [21:30] checked fedora, opensuse, gentoo, arch [21:30] that tends to be the most fragile part of the build too [21:30] noone builds them so people dont notice they broke it in git master [21:30] I tested it in september or so, cut the build time maybe by 40% [21:32] Sarvatt, nothing on my todo for mesa [21:32] btw, jeremyhu is asking for a commit to natty :) [21:32] (mesa) [21:33] bug 853667 [21:33] Launchpad bug 853667 in mesa (Ubuntu) "ATI Radeon HD 3850 is completely unusable with default configuration due to frequent lockups (affects: 1) (heat: 4)" [Undecided,New] https://launchpad.net/bugs/853667 [21:34] problem is that he's unable to test an sru for it, if it was made [21:52] tjaalton: I hate replying to bugs like this.. "Yeah we suck, our stable update criteria won't allow us to update to new stable version updates even though you guys try to maintain stable branches so distros can update it safely." [21:53] what else can we say, it's the truth. it's the same deal with xserver that he maintains the stable branches for.. our stable update criteria where every patch has to be verified even if it's an obvious fix that went through the criteria and testing for the upstream stable branch [21:53] yeah it sucks [21:54] that's not the case for microrelease exceptions, though [21:54] we really should ask for those, for mesa & xserver [21:54] it requires an extensive test suite [21:55] problem is stat the mesa pointreleases aren't that 'micro' [21:55] there's piglit which mesa stable is run against, but not run at build time and not packaged [21:55] *that [21:55] yeah they're borderline as many changes as in the kernel [21:55] only it's nowhere near as strick as kernel stable is [21:55] i don't think the criteria specfically require an extensive automated test suite [21:56] refactoring to allow a fix to apply cleanly is allowed [21:56] though it having one would certainly satisfy the criteria [21:56] strict rather [21:57] upstream has a sufficiently high level of regression testing for their stable releases [21:57] regression tests are enabled in the package's build [21:57] yes, but that does not necessarily imply "extensive regression tests are enabled in the package's build" [21:57] hmm might have misinterpreted it a but, but piglit (the mesa test suite) isn't part of mesa [22:58] bryceh: is ia32-libs version parsing still in apport? that should go too [22:58] for xorg bugs [22:58] yeah I've not stripped it out yet [23:01] Sarvatt: for some reason it was stuck on 11.0.99.901, its upgrading now. [23:01] *fingers-crossed* [23:03] oh that makes a bit of sense, 11.99.901 was waiting until mesa 8.0 went through the new package queue for libxatracker so might not have made the livecd yesterday [23:04] OpenGL renderer string: Gallium 0.4 on SVGA3D; build : RELEASE; [23:04] Whieeee [23:05] And Unity is smooth when running glxgears, good all the important bits are in place. === yofel_ is now known as yofel [23:19] Prf_Jakob: so it's working? truth be told I don't have the hdd space to test it and have been too busy with ivybridge drama [23:19] Sarvatt: Yupp [23:19] works just fine [23:19] AWESOME! [23:19] yeah! [23:19] so tomorrow's livecd will work, awesome [23:20] broder: I believe you were asking about vmware 3D passthrough? [23:20] broder: it's all in precise now, tomorrow's livecd will work out of the box [23:20] Amaranth: you too ^^ :) [23:20] Virtual highfive, or vFive in marketing term. [23:20] Sarvatt: yay [23:20] Hopefully gles unity works with it :P [23:20] a dist-upgrade should work as well now [23:20] gles? [23:22] Amaranth: is that whats in there now? [23:22] Prf_Jakob: nah he's working on gles compiz for linaro, its not in ubuntu yet [23:22] ah [23:23] Amaranth: is gles compiz going to make 12.04? [23:23] *shrug* [23:23] cedarview kinda depends on it being there :) [23:23] I'm not really involved anymore [23:23] making gl work? no sorry we only care about gles in meego [23:23] oh ok [23:24] Sarvatt: cedarview is PVR right? [23:24] yup [23:24] *shudder* [23:24] Sarvatt: The plan was to always only have it built with gles on ARM though [23:24] so same deal as clutter [23:25] and cedarview is fooked because its x86 [23:25] Time for lpia? :) [23:25] lol [23:25] thats basically the only option [23:25] So this sucks because nVidia and fglrx doesn't support GLES? [23:25] or you could have just used gles? [23:26] Prf_Jakob: And mesa doesn't support the extension needed to make GLES compiz efficient [23:26] NV_post_sub_buffer [23:26] Prf_Jakob: clutter and I guess compiz need to pick between gles or gl at compile time so it cant be done in the archive on x86/amd64, on arm we can just compile clutter with gles only support by default because noone will care [23:26] Amaranth: which would be? [23:28] Amaranth: Oh, the mesa copy region extension but for egl. [23:28] Amaranth: that shouldn't be hard to fix. [23:28] Prf_Jakob: Yeah, I wouldn't expect it to be [23:28] It already supports NOK_copy_sub_buffer or whatever its called [23:29] Which is the same thing with a different calling convention iirc [23:30] Ok, I'll put that on my todo. [23:37] Amaranth: http://lists.freedesktop.org/archives/mesa-commit/2011-December/034733.html <-- seems somebody beat me to it :) [23:38] KDE guy, guess the kwin folks came to the same conclusion [23:38] Amaranth: should be in 8.0 [23:38] Cool [23:39] You guys needs to package eglinfo up :) [23:41] Isn't it es2_info? [23:42] right you are [23:43] Yupp its there [23:44] Oh, es2gears oth does not throttle correctly. [23:44] Good second window dragging dealy. [23:45] nvidia-settings precise 285.05.09-0ubuntu1 [23:45] why isn't that at 290? [23:45] delay* [23:51] time to sleep