[00:00] What I'd *really* like to do is to git cherry-pick -x on the ubuntu branch, but we don't do that :) [00:01] I'll document what I do on that wiki page. [00:28] awesome [00:29] Also, mesa accepted. [07:29] morning [07:30] same [07:31] Good morning :) [07:33] i was actually up 1:30-5:00, not a great idea to take a nap yesterday :P [07:33] heya [07:34] i'm on the 5am to 2pm sleep schedule [07:34] D: [07:34] airlied seems committed to the new api for 1.13.. i need to set up the build env for my laptop so I can test running it from a separate path. whot posted a nice howto about that [07:34] thesis writing is hell [07:34] oh that was fun [07:35] not really, but still [07:35] tjaalton, can we coerce keithp to merge the new api this year? [07:35] saying no in may seems really shortsighted [07:35] LLStarks: well I didn't read it literally [07:36] "I'll sit down this week and look them over more carefully" to me sounds like he'll review it soon [07:36] everything that gets pushed to 2013 gets pulled into the cluster**** of wayland/xwayland, classic x11, x12 in 2013 [07:38] and it already got acks from alanc and aaronp [07:38] the first push that is [07:38] real meat coming later [07:38] nvidia as an early adopter? i like [07:39] well, ack != adopt [07:40] still [07:43] right, it's good news in any case. [07:44] keithp is amenable to prioritization; might be worth mentioning the importance of this for us to him. [07:45] sure, though I do believe he knows the importance already :) [08:03] Do I need to do anything special to show up in http://status.ubuntu.com/ubuntu-quantal/people.html ? [08:05] Have work items assigned to you, I think. [08:09] So you should turn up next time the generator is run, I guess ;) [08:10] mlankhorst: Oh, incidentally - smspillaz was fiddling around with nouveau trying to get VSync with EGL working. Shall I point him in your direction should he ask? [08:10] (For EGL-compiz) [08:10] full vsync or just swap buffers? [08:11] I think just swap buffers. [08:11] atm im just playing with blueprints, how do I assign one to multiple people? [08:11] It seems to barf on this: [tjaalton, mlankhorst] build a ppa with the new api for testing: TODO [08:12] ah [08:12] oh woops that worked, it was just missing TODO before [08:12] Oh, that works? [08:12] I didn't think you could assign work items to multiple people. [08:12] i'm equally surprised:) [08:13] hm maybe not [08:14] shall I just assign it to the team then? [08:14] or me [08:23] running build.sh.. [08:23] just for the heck of it [08:42] sure [08:42] RAOF: if still awake, should hybrid graphics work item be coalesced into desktop-q-xorg-general? [08:42] nah [08:42] k [08:42] it's useful for the hwe tasks [08:43] oh you added the notes there, thought it was my task :) [08:44] its yours if ou want to work on it >:D [08:45] thanks for those, I'll edit it further as needed [08:46] regarding ARB_robustness, it's mentioned in mesa 7.11 relnotes, so maybe that should be removed from the list+ [08:46] ? [08:46] I changed it to investigate [08:46] ahh right [08:47] might be worth seeing if it can be triggered somehow for testing [08:50] yup [11:08] toying around a bit with dummy packages atm [11:22] hm.. anyone from X team awake at this point? [11:24] yup [11:24] EEST here :) [11:26] ah good, I'm just creating a bunch of ppa's atm to simulate LTS [11:27] on your personal page or elsewhere? [11:27] yeah personal page [11:27] I intend to make dummy, dummy-dev and dummy-enablement [11:27] one thing to note is that once a ppa is created, you're stuck with the name. and if you delete it you can't use the same name anymore [11:27] and some renamed ones to replace [11:27] ok that's good :) [11:27] xorg-lts-test-mechanics [11:28] and probably xorg-lts-test-mechanics-lts-q and xorg-lts-test-mechanics-lts-r [11:28] long names :) [11:29] double lts [11:29] yeah but it simulates a lts-q release and a lts-r release [11:29] ok, guess it doesn't matter [11:30] I should also create another one to simulate the next lts version I suppose [11:33] probably [13:16] yuck, no luck yet [13:17] I created a dummy-enablement package, but installing it doesn't pull in new versions automatically [13:20] The following packages will be REMOVED: [13:20] dummy dummy-dev [13:20] The following NEW packages will be installed: [13:20] dummy-lts-q [13:20] doesn't grab the new versions yet either. :( [13:33] do you have the packaging somewhere? [13:34] https://launchpad.net/~mlankhorst has 3 ppa's I'm using for testing atm [13:34] and I wouldn't worry about not getting it to work the second day after uds :) [13:34] normal one contains dummy dummy-enablement and dummy-dev [13:34] lts-q should force upgrade to renamed package [13:35] No, my big worry is that it won't work without transitional packages.. [13:37] or worse, incomplete mirroring and upgrading enablement package conflicting with everything causing it to remove x server [13:38] well, the q repo has a newer package still building [13:39] the current one has the same version as the first one [13:39] yeah I was trying to see what happened if I added a conflicts on dummy-enablement [13:40] note that in the real world you'd need to rename the source package as well [13:40] the normal one builds have failed [13:40] yeah but for now I'm just testing the mechanics of upgrading [13:43] Conflicts: dummy dummy-dev [13:43] there's one bug [13:43] missing comma [13:43] also, I don't think the metapackage should conflict [13:44] yeah I know, but if you enable both it won't upgrade. :/ [13:45] the mechanics I want is that the act of installing metapackage would automatically pull in the renamed packages, while removing it will force fallback to old ones. [13:46] hmm, I don't see where you're upgrading from, since the base repo has the same package [13:46] i don't think there's any way to fall back like that [13:47] ok then how do I at least go from dummy to dummy-lts-q automatically when I install the enablement? [13:49] dummy-enablement should depend on the new names [13:49] and the actual packages then break/replace the old ones [13:50] That would be hard for things like that dummy-dev package, which may or may not be installed. In my test installing dummy-lts-q will remove dummy-dev [13:50] (apt-get install dummy-lts-q) [13:50] the depends are wrong [13:51] Package: dummy-lts-q [13:51] Depends: dummy-enablement [13:51] Package: dummy-dev-lts-q [13:51] Depends: dummy [13:51] they don't need the depends at all [13:53] sorry, dummy-dev-lts-q would depend on dummy-lts-q, if you mean to simulate a library package [13:54] but then maybe create a libdummy or such, so these cases can be more easily noticed.. [13:54] and libdummy-dev [13:54] well, it's just to simulate things [13:54] you could also call it xserver-xorg-input-wacom or some other thing that doesn't get pulled in by default [13:55] but you have conflicting depends there causing the issues you see :) [13:55] ah [13:55] lts-q package depending on the old package which would need to get removed [13:55] so nothing happens [13:56] ok lets retry [14:05] i just realized how ugly this will get with packages like mesa, where the rules file is littered with references to the binary packages.. [14:05] I just fear it's going to break at one point, for example because you're a chromium pull dependencies script and you blindly do apt-get install dummy-dev, or you try to remove dummy-enablement to get back to original stack. [14:06] nothing breaks if you remove the metapackage [14:06] everything has a depends on it [14:06] there's nothing we can do to protect from people manually installing the renamed packages [14:06] mlankhorst: umm no [14:06] it's the other way around [14:07] ok so dummy-enablement should have a depends on dummy-lts-q for example? [14:07] yes [14:08] look at xserver-xorg, xserver-xorg-input-all etc [14:09] ubuntu-desktop depends on xorg, but xorg-lts-q would Provides: xorg, so the dependency is fulfilled even with the renamed package [14:09] hmm need to check the policy.. [14:09] no.. versioned provides won't work [14:11] there are no versioned depends for the metapackages [14:11] ubuntu-desktop depends on 'xorg' [14:11] no version attached [14:11] dinner -> === yofel_ is now known as yofel [21:45] Can someone please assign Bug #973096? https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/973096 [21:46] Launchpad bug 973096 in nvidia-graphics-drivers (Ubuntu) "Nvidia driver causes xorg crash" [High,Confirmed] [21:46] We have a lot of frustrated users out there... [22:00] seasons, anyone test the .49 driver? [22:01] I did, same results [22:01] bunch of people have [22:01] errr, 302.49 ? [22:02] no [22:02] 295.49 [22:02] seasons, no indications on the bug report that anyone's tested it [22:02] yeah, I did [22:02] same thing occurs [22:03] #13 [22:04] tried about everything I could, at first I thought it was my X conf, but turns out it doesn't matter [22:08] ok, then the bug should be escalated to nvidia. [22:09] I asked in #nvidia, they said it's ubuntu [22:09] nah, there's nothing in the backtrace to say it's ubuntu [22:09] can you assign it to someone at least? [22:09] already did [22:09] I don't know enough to point a finger at anyone [22:09] oh, thanks man [22:09] your welcome [22:10] personally, I want to believe it's NVidia [22:11] lol [22:11] appreciate the help [22:15] I love open source, at least people do the right thing here [22:16] my personal goal is to make the distrib a winner, I don't use other distribs anymore because of the "unofficial" support I get through various channels like this [22:17] so thanks again [22:17] yep [22:20] I think a lot of bug reporters don't really grasp what "closed source binary" means. [22:29] bryceh, can you take a look at bug 973297 for me? [22:29] Launchpad bug 973297 in xorg-server (Ubuntu Precise) "Xorg recognizes Logitech Headset USB dongle as input device then segfaults in XIChangeDeviceProperty" [High,Incomplete] https://launchpad.net/bugs/973297 [22:29] the last comment [22:29] I could use a sanity check [22:30] cnd, sure [22:30] thanks [22:37] cnd, seems plausible [22:38] bryceh, the ABI mismatch? [22:38] yeah [22:38] yeah, but how did it happen? [22:39] the function signature hasn't changed [22:41] xserver-xorg-dev (>= 2:1.11.3-0ubuntu1), [22:41] maybe -evdev needs its build-depends raised? [22:41] although I would think the buildds would have built it using the latest xserver bits at the time [22:42] yeah [22:42] I checked the logs [22:48] what did the logs say it got built against? [22:49] RAOF, if you're in yet, might see if you know why the archive's skewed on the abi versions here. [22:50] I'm just in. [22:52] ... [22:52] Yay for ABI changes? [22:54] RAOF: I didn't have much luck yet, I can make a meta package, but it will pull EVERYTHING in and not work right yet. I put up 2 ppa's for testing, so I can have some conflicting versions. It just worries me there might not be a good way to do it without transitional packages. :( [22:54] but bedtime, nn [22:54] I'll have a look at it. Good night! [23:33] bryceh, RAOF, evdev was built against 1.11.4-0ubuntu6, IIRC [23:33] well after the ABI change in 1.11.3-0ubuntu2 [23:36] cnd: So that's not it? [23:40] RAOF, well, it doesn't make sense [23:40] but nothing else makes sense :) [23:40] it's the closest thing to making sense [23:40] Does a rebuild fix it? [23:42] RAOF, yes [23:42] So it's probably *some* ABI change somewhere, then? [23:51] RAOF, yeah [23:51] and it's definitely hit at XIChangeDeviceProperty [23:51] I've used gdb to confirm