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