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:00 |
---|---|---|
RAOF | I'll document what I do on that wiki page. | 00:01 |
bryceh | awesome | 00:28 |
RAOF | Also, mesa accepted. | 00:29 |
mlankhorst | morning | 07:29 |
tjaalton | same | 07:30 |
RAOF | Good morning :) | 07:31 |
tjaalton | i was actually up 1:30-5:00, not a great idea to take a nap yesterday :P | 07:33 |
bryceh | heya | 07:33 |
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:34 |
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:35 |
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:36 |
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:38 |
bryceh | well, ack != adopt | 07:39 |
tjaalton | still | 07:40 |
bryceh | right, it's good news in any case. | 07:43 |
bryceh | keithp is amenable to prioritization; might be worth mentioning the importance of this for us to him. | 07:44 |
tjaalton | sure, though I do believe he knows the importance already :) | 07:45 |
mlankhorst | Do I need to do anything special to show up in http://status.ubuntu.com/ubuntu-quantal/people.html ? | 08:03 |
RAOF | Have work items assigned to you, I think. | 08:05 |
RAOF | So you should turn up next time the generator is run, I guess ;) | 08:09 |
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:10 |
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:11 |
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:12 |
mlankhorst | hm maybe not | 08:13 |
mlankhorst | shall I just assign it to the team then? | 08:14 |
tjaalton | or me | 08:14 |
tjaalton | running build.sh.. | 08:23 |
tjaalton | just for the heck of it | 08:23 |
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:42 |
tjaalton | oh you added the notes there, thought it was my task :) | 08:43 |
mlankhorst | its yours if ou want to work on it >:D | 08:44 |
tjaalton | thanks for those, I'll edit it further as needed | 08:45 |
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:46 |
mlankhorst | might be worth seeing if it can be triggered somehow for testing | 08:47 |
tjaalton | yup | 08:50 |
mlankhorst | toying around a bit with dummy packages atm | 11:08 |
mlankhorst | hm.. anyone from X team awake at this point? | 11:22 |
tjaalton | yup | 11:24 |
tjaalton | EEST here :) | 11:24 |
mlankhorst | ah good, I'm just creating a bunch of ppa's atm to simulate LTS | 11:26 |
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:27 |
mlankhorst | and probably xorg-lts-test-mechanics-lts-q and xorg-lts-test-mechanics-lts-r | 11:28 |
tjaalton | long names :) | 11:28 |
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:29 |
mlankhorst | I should also create another one to simulate the next lts version I suppose | 11:30 |
tjaalton | probably | 11:33 |
mlankhorst | yuck, no luck yet | 13:16 |
mlankhorst | I created a dummy-enablement package, but installing it doesn't pull in new versions automatically | 13:17 |
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:20 |
tjaalton | do you have the packaging somewhere? | 13:33 |
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:34 |
mlankhorst | No, my big worry is that it won't work without transitional packages.. | 13:35 |
mlankhorst | or worse, incomplete mirroring and upgrading enablement package conflicting with everything causing it to remove x server | 13:37 |
tjaalton | well, the q repo has a newer package still building | 13:38 |
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:39 |
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:40 |
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:43 |
mlankhorst | yeah I know, but if you enable both it won't upgrade. :/ | 13:44 |
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:45 |
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:46 |
mlankhorst | ok then how do I at least go from dummy to dummy-lts-q automatically when I install the enablement? | 13:47 |
tjaalton | dummy-enablement should depend on the new names | 13:49 |
tjaalton | and the actual packages then break/replace the old ones | 13:49 |
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:50 |
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:51 |
tjaalton | sorry, dummy-dev-lts-q would depend on dummy-lts-q, if you mean to simulate a library package | 13:53 |
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:54 |
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:55 |
mlankhorst | ok lets retry | 13:56 |
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:05 |
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:06 |
mlankhorst | ok so dummy-enablement should have a depends on dummy-lts-q for example? | 14:07 |
tjaalton | yes | 14:07 |
tjaalton | look at xserver-xorg, xserver-xorg-input-all etc | 14:08 |
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:09 |
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 -> | 14:11 |
=== yofel_ is now known as yofel | ||
seasons | Can someone please assign Bug #973096? https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/973096 | 21:45 |
ubottu | Launchpad bug 973096 in nvidia-graphics-drivers (Ubuntu) "Nvidia driver causes xorg crash" [High,Confirmed] | 21:46 |
seasons | We have a lot of frustrated users out there... | 21:46 |
bryceh | seasons, anyone test the .49 driver? | 22:00 |
seasons | I did, same results | 22:01 |
seasons | bunch of people have | 22:01 |
seasons | errr, 302.49 ? | 22:01 |
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:02 |
seasons | #13 | 22:03 |
seasons | tried about everything I could, at first I thought it was my X conf, but turns out it doesn't matter | 22:04 |
bryceh | ok, then the bug should be escalated to nvidia. | 22:08 |
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:09 |
seasons | personally, I want to believe it's NVidia | 22:10 |
mlankhorst | lol | 22:11 |
seasons | appreciate the help | 22:11 |
seasons | I love open source, at least people do the right thing here | 22:15 |
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:16 |
seasons | so thanks again | 22:17 |
bryceh | yep | 22:17 |
bryceh | I think a lot of bug reporters don't really grasp what "closed source binary" means. | 22:20 |
cnd | bryceh, can you take a look at bug 973297 for me? | 22:29 |
ubottu | 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 |
cnd | the last comment | 22:29 |
cnd | I could use a sanity check | 22:29 |
bryceh | cnd, sure | 22:30 |
cnd | thanks | 22:30 |
bryceh | cnd, seems plausible | 22:37 |
cnd | bryceh, the ABI mismatch? | 22:38 |
bryceh | yeah | 22:38 |
cnd | yeah, but how did it happen? | 22:38 |
cnd | the function signature hasn't changed | 22:39 |
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:41 |
cnd | yeah | 22:42 |
cnd | I checked the logs | 22:42 |
bryceh | what did the logs say it got built against? | 22:48 |
bryceh | RAOF, if you're in yet, might see if you know why the archive's skewed on the abi versions here. | 22:49 |
RAOF | I'm just in. | 22:50 |
RAOF | ... | 22:52 |
RAOF | Yay for ABI changes? | 22:52 |
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! | 22:54 |
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:33 |
RAOF | cnd: So that's not it? | 23:36 |
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:40 |
cnd | RAOF, yes | 23:42 |
RAOF | So it's probably *some* ABI change somewhere, then? | 23:42 |
cnd | RAOF, yeah | 23:51 |
cnd | and it's definitely hit at XIChangeDeviceProperty | 23:51 |
cnd | I've used gdb to confirm | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!