| RAOF | cnd: Nope. I think I've just fixed Mr Barriers, but that should bake for just a tiny bit longer. | 00:00 |
|---|---|---|
| cnd | cool | 00:00 |
| Sarvatt | bryceh: so from my own bugs i've filed, i'm getting a segfault, then stuff is happening in the signal handler that is causing a SIGABRT later, and it keeps getting duped to doko's SIGABRT bug by apport even though i dont think its the the same | 00:00 |
| cnd | it's uploaded now | 00:00 |
| bryceh | Sarvatt, interesting | 00:00 |
| Sarvatt | https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/948697 | 00:01 |
| ubottu | Launchpad bug 948697 in xorg-server (Ubuntu) "Xorg crashed with SIGSEGV in valuator_mask_set_double()" [Undecided,New] | 00:01 |
| bryceh | yeah I've noticed with a lot of these stacktraces, that there's a dozen lines of input related goo that happens *after* it enters the abort code | 00:01 |
| Sarvatt | thats definitely a segfault, the abort is later but apport only cares about the later stuff | 00:01 |
| bryceh | yeah, or see https://launchpadlibrarian.net/95731570/ThreadStacktrace.txt | 00:02 |
| bryceh | there's a Sigio one | 00:02 |
| RAOF | Huh. | 00:03 |
| Sarvatt | bryceh: wait, thats someone elses bug? thats the same bug i'm hitting from the looks of it | 00:03 |
| RAOF | You know what we should do? Block signals after we get a SIGSEGV | 00:03 |
| bryceh | yeah that's lp #948792 | 00:04 |
| ubottu | Launchpad bug 948792 in xorg-server (Ubuntu) "Xorg crashed with SIGSEGV in ___newselect_nocancel()" [Medium,New] https://launchpad.net/bugs/948792 | 00:04 |
| RAOF | If we're dying we don't want to handle input anyway. | 00:04 |
| bryceh | Jeroen's bug | 00:04 |
| bryceh | iirc he's able to repro that one fairly reliably | 00:04 |
| Sarvatt | its really really hard to reproduce, i only hit it because when my lids closed my touchpad wigs out thinking its getting touched from the lid and it takes like 10 hours closed to hit from what i can see | 00:05 |
| bryceh | Sarvatt, hey you're right these stacktraces do look the same | 00:06 |
| Sarvatt | both bcm5974 devices too | 00:06 |
| cnd | RAOF, so you want to block signals after a SIGSEGV from within a signal handler? | 00:07 |
| RAOF | Maybe? | 00:07 |
| Sarvatt | i'm amazed he got a crash report for the same thing apport actually retraced, i've filed 3 and all got duped to doko's totally different bug | 00:07 |
| RAOF | Once we hit the server abort path we should unhook the SIGIO handler at least. | 00:07 |
| cnd | RAOF, I guess the better question is why are we returning from the SIGSEGV handler? | 00:08 |
| bryceh | Sarvatt, interesting [291953.349] bcm5974: not enough space for touch events (max 5 touchpoints). Dropping this event. | 00:08 |
| Sarvatt | oh i get spammed with those constantly | 00:09 |
| RAOF | cnd: I think because we do strange things - particularly, we go through the SEGV handler and then re-raise SEGV so that apport can dump. | 00:09 |
| cnd | bryceh, Sarvatt: I wonder if that's due to the memory leak I just fixed | 00:09 |
| Sarvatt | except its 8 touchpoints here | 00:09 |
| Sarvatt | cnd: that would be freaking awesome | 00:09 |
| Sarvatt | i'll switch back to synaptics to check | 00:09 |
| cnd | Sarvatt, so that means we got stuck in sigio context long enough that many touchpoints came in before we were able to resize the touch record array | 00:10 |
| cnd | though if it's dying at only 8 touch points then you aren't seeing the memory leak | 00:10 |
| cnd | because the memory leak is the touch record array growing ad infinitum | 00:11 |
| bryceh | cnd, is there a bug # for that memory leak? | 00:11 |
| bryceh | oh wait, there is, you mentioned it already | 00:11 |
| cnd | yeah | 00:11 |
| cnd | it doesn't say it's a memory leak | 00:11 |
| Sarvatt | oh it changes | 00:11 |
| Sarvatt | [291953.349] bcm5974: not enough space for touch events (max 5 touchpoints). Dropping this event. | 00:11 |
| Sarvatt | [291953.349] [dix] bcm5974: unable to begin touch point 6 | 00:11 |
| cnd | but that's another symptom | 00:11 |
| bryceh | bug 929408 | 00:11 |
| ubottu | Launchpad bug 929408 in xorg-server (Ubuntu) "X does not send multitouch touch end events properly" [High,Fix released] https://launchpad.net/bugs/929408 | 00:11 |
| Sarvatt | [291958.903] bcm5974: not enough space for touch events (max 8 touchpoints). Dropping this event. | 00:11 |
| Sarvatt | [291958.903] [dix] bcm5974: unable to begin touch point 8 | 00:11 |
| cnd | Sarvatt, that sounds like the server regular context is hung | 00:12 |
| cnd | and the input sigio is still working | 00:12 |
| RAOF | cnd: Wow. The xserver build sure is chatty with the new xorg-macros. | 00:13 |
| cnd | RAOF, what do you mean? | 00:13 |
| cnd | the macros I added for CXX? | 00:13 |
| bryceh | cnd, what's the version number for this new xserver? | 00:13 |
| RAOF | I wanted to rebuild xorg-gtest, so I pulled the new xorg-macros, because you've made it depend on the newer macros. | 00:14 |
| cnd | 1.11.4-0ubuntu5 | 00:14 |
| bryceh | thanks | 00:14 |
| cnd | RAOF, it will still work with the older macros | 00:14 |
| RAOF | Someone has apparently added ALL THE WARNINGS to xorg-macros. | 00:14 |
| cnd | oh, they weren't there before? | 00:14 |
| Sarvatt | RAOF: fun isn't it! | 00:14 |
| RAOF | cnd: Not here it didn't; autogen bailed wanting a newer xorg-macros | 00:14 |
| Sarvatt | no debian hasn't updated to util-macros 1.16 yet | 00:14 |
| Sarvatt | for that reason :) | 00:14 |
| Sarvatt | 1.16.1 is a little better | 00:15 |
| cnd | RAOF, hmm, I thought it wouldn't require the latest xorg-macros | 00:15 |
| cnd | I guess I'll need to double check that | 00:15 |
| RAOF | Sarvatt: I pulled trunk. You mean this is the *less bad* version? :) | 00:15 |
| Sarvatt | if you think 1.16.2 with the gtest stuff in it is chatty you should have seen 1.16.0 | 00:15 |
| RAOF | Win! That *was* the problem. | 00:16 |
| RAOF | cnd: Once again, xorg-gtest is awesome. | 00:16 |
| cnd | RAOF, hmmm? | 00:16 |
| cnd | what was the problem? | 00:16 |
| RAOF | Oh, a problem in the barrier code. | 00:16 |
| cnd | ahh, cool | 00:17 |
| cnd | RAOF, where are your tests? | 00:17 |
| cnd | I want to see how you're using it | 00:17 |
| RAOF | Only the first barrier event on the screen edge was getting triggered. And because xorg-gtest is awesome, it was easy to find and verify. | 00:17 |
| cnd | so I can try to provide for us both :) | 00:17 |
| cnd | I'm going to add a method to xorg::testing::Test that will create a hierarchy of windows | 00:18 |
| cnd | that's next on my plate, since it's needed for testing of touch grabs and selections and such | 00:18 |
| RAOF | You can find them in the ubuntu-barrier-tests branch of xorg-server in my alioth repository. | 00:19 |
| bryceh | Sarvatt, think https://launchpadlibrarian.net/95610521/ThreadStacktrace.txt is the same? it's also got that <signal handler> ...fail... ...Device futzing... end style | 00:19 |
| bryceh | different stack trace though | 00:20 |
| Sarvatt | nope i wouldn't assume it was | 00:20 |
| RAOF | cnd: http://anonscm.debian.org/gitweb/?p=users/raof-guest/xorg-server.git;a=summary | 00:20 |
| cnd | just when I had already navigated to it... | 00:20 |
| Sarvatt | mine *always* segfaults in valuator_mask_set_double | 00:20 |
| bryceh | ok | 00:20 |
| cnd | RAOF, so it's all in a debian patch? | 00:20 |
| cnd | just checking | 00:20 |
| RAOF | cnd: Yes. Because now I'm going to submit MIRs for gtest and xorg-gtest, and this'll be enabled on the buildds. | 00:21 |
| Sarvatt | that ones in pixman_region_intersect | 00:21 |
| cnd | RAOF, are you planning to push the tests into precise? | 00:22 |
| RAOF | cnd: Yes. | 00:22 |
| cnd | RAOF, ok, before you do let me get integration tests proposed upstream at least | 00:22 |
| cnd | I hope to have that by the end of this week | 00:22 |
| RAOF | Integration tests for touch? | 00:22 |
| cnd | for anything | 00:23 |
| cnd | but the first proposed tests will be for touch :) | 00:23 |
| RAOF | Why should these tests block on that? | 00:23 |
| cnd | RAOF, actually, I suppose there's no reason they should | 00:23 |
| cnd | RAOF, you aren't using evemu replaying are you? | 00:24 |
| RAOF | No; just xtest. | 00:24 |
| cnd | I guess if you have it working with debuild, then it's good | 00:24 |
| cnd | sadly, evemu requires root or special udev rules | 00:24 |
| cnd | so we probably can't enable them by default during the build | 00:25 |
| cnd | RAOF, why do you have your own main()? | 00:25 |
| cnd | instead of linking against xorg-gtest_main | 00:26 |
| RAOF | cnd: So I can set options. Specifically, so I can set the Xorg binary to ../../hw/xfree86/Xorg, and have my own conf file. | 00:26 |
| cnd | oh, I see where you set those now | 00:27 |
| cnd | I thought you were just providing the default options | 00:27 |
| RAOF | Nope. | 00:27 |
| cnd | cool | 00:27 |
| RAOF | I'd also like to pass -dumbSched to the server; it makes debugging more pleasant. | 00:28 |
| cnd | is that not possible with xorg-gtest today? | 00:28 |
| cnd | hmmm, I guess not | 00:29 |
| cnd | RAOF, if you find the time, xorg::testing::Environment could use a dumbSched boolean option and a generic "extra parameters" option | 00:30 |
| RAOF | Yeah, was planning to do that. | 00:30 |
| cnd | cool | 00:31 |
| cnd | I'm glad it's been helpful :) | 00:31 |
| cnd | RAOF, for the SIGIO corruption, maybe --gtest_repeat=-1 for a day on a test machine would help? | 00:32 |
| cnd | though I think gtest_repeat may be broken due to it attempting to restart the server each time, and the shutdown not being handled properly | 00:33 |
| RAOF | But it's not going to receive SIGIO, is it? | 00:35 |
| cnd | ahh, good point | 00:35 |
| cnd | because it's XTest | 00:35 |
| RAOF | Indeed. It presumably would with evemu. | 00:36 |
| cnd | yeah | 00:36 |
| RAOF | cnd: gtest in Debian is going to lose the static lib entirely; I don't think building with -fPIC will be accepted. | 01:25 |
| cnd | RAOF, huh? | 01:25 |
| cnd | they just dropped the shared lib | 01:25 |
| cnd | so is it going to be source only? | 01:25 |
| RAOF | Yes. | 01:25 |
| RAOF | As Google intended :) | 01:26 |
| RAOF | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639795 | 01:26 |
| ubottu | Debian bug 639795 in libgtest-dev "[libgtest-dev] gtest-config missing" [Normal,Open] | 01:26 |
| cnd | interesting... | 01:27 |
| cnd | RAOF, I suppose that's ok, but then it raises the question of: how do we find the sources? | 01:28 |
| cnd | pkgconfig won't help, will it? | 01:29 |
| RAOF | Assume they're in /usr/src/gtest; we could provide a pkgconfig file. | 01:29 |
| cnd | but upstream doesn't provide a pkgconfig file, so that won't really help | 01:29 |
| cnd | I fear a future where we have to use --with-gtest-source=/usr/src/gtest | 01:30 |
| cnd | which then begs the question: should we be doing the same for xorg-gtest? | 01:30 |
| cnd | oh well, we'll deal with the fallout when it comes I guess | 01:31 |
| RAOF | Yeah. That won't actually be terrible, though. | 01:34 |
| RAOF | Just needs some autofoolery. | 01:34 |
| cnd | yeah | 01:36 |
| Sarvatt | yay non-crashy Xv fglrx finally released | 01:54 |
| bryceh | oh yeah? sweet | 01:57 |
| Sarvatt | the march fglrx is like a week away though, that was the target for precise | 02:08 |
| RAOF | I hate it when I realise that something only accidentally works. Bah! | 05:42 |
| jcristau | this gtest stuff sounds like xtrans all over again | 08:35 |
| FernandoMiguel | morning | 09:46 |
| === yofel is now known as yofel_ | ||
| === yofel_ is now known as yofel | ||
| cnd | RAOF, ping me when you are available, I want to chat with you about gtest | 18:00 |
| jussi | hello all! | 18:51 |
| jussi | anyone know if there are currently issues witht the nvidia driver in precise? I cant seem to get it to install - see: http://paste.ubuntu.com/874989/ | 18:51 |
| bryceh | jussi, have you had it installed on that hardware previously? | 18:58 |
| jussi | bryceh: yes, updated a few days back and it was gone | 18:58 |
| jussi | cant enable anymore | 18:58 |
| bryceh | jussi, here's the nvidia bugs reported against precise so far - http://bit.ly/wFEQec | 18:58 |
| jussi | bryceh: at first glance, seems similar/same as https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/949330 | 19:00 |
| ubottu | Launchpad bug 949330 in nvidia-graphics-drivers (Ubuntu) "nVidia driver won't load anymore" [Undecided,New] | 19:00 |
| bryceh | jussi, yeah was just looking at that myself | 19:01 |
| bryceh | sounds like jockey may be confused | 19:01 |
| jussi | bryceh: right. Is there any further info I can provide to help diagnose? | 19:02 |
| bryceh | hmm, doesn't look like nvidia-current has changed in the last couple weeks | 19:03 |
| bryceh | jockey did get a change on the 5th (minor stuff), and more major changes on t he 3rd | 19:03 |
| bryceh | jussi, perhaps try downgrading to jockey 0.9.6-0ubuntu1? | 19:04 |
| jussi | bryceh: forgive me, but how do I actually downgrade? | 19:05 |
| bryceh | three options: 1) apt-get install <package>=<version> | 19:07 |
| bryceh | 2) if the .deb is in your /var/cache/apt/archive, then dpkg -i <path-to-deb> | 19:08 |
| bryceh | 3) Go to the launchpad page for the package, and go to the version history section, find the version you want and drill down to get the .debs. Then as in #2. | 19:08 |
| jussi | right, Im on it. I assume I want jockey-common? (not just the kde frontend) | 19:09 |
| bryceh | jockey-common and whatever frontend you usually use (jockey-gtk maybe?) | 19:09 |
| jussi | nah, its kde :) but yeah. do I need hte dh-modaliases? | 19:11 |
| bryceh | possibly | 19:13 |
| jussi | bryceh: ok, it still fails: http://paste.ubuntu.com/875021/ | 19:15 |
| bryceh | jussi, which version of the nvidia driver did you have installed before? -current? | 19:15 |
| jussi | bryceh: I havent complete memory, but that is what I would usually install, yes. | 19:16 |
| bryceh | jussi, alright so we've ruled out a regression in jockey | 19:17 |
| bryceh | jussi, can you try purging all -nvidia from your system and then reinstalling it? | 19:17 |
| bryceh | (if you haven't already) | 19:17 |
| jussi | sure. sudo apt-get remove nvidia* ? | 19:17 |
| jussi | or do I need to purge? | 19:18 |
| bryceh | sudo apt-get purge nvidia* | 19:18 |
| jussi | ok :) | 19:18 |
| jussi | The following packages will be REMOVED: | 19:19 |
| jussi | kubuntu-desktop* nvidia-173* nvidia-173-updates* nvidia-common* nvidia-current* | 19:19 |
| jussi | nvidia-current-updates* nvidia-settings* nvidia-settings-updates* | 19:19 |
| jussi | curious that the 173 ones are there...? | 19:19 |
| bryceh | in fact I've been wondering if that could be the problem | 19:20 |
| jussi | right, do I need to reboot or restart something before attempting again? | 19:20 |
| broder | and the -updates ones, too | 19:20 |
| bryceh | I'm not great at grokking jockey logs however it keeps talking about 173 like it would prefer to install that | 19:20 |
| bryceh | however we don't have a compatible version of -173 yet, so it's uninstallable | 19:20 |
| jussi | 01:00.0 VGA compatible controller: NVIDIA Corporation G86 [GeForce 8500 GT] (rev a1) | 19:21 |
| jussi | is the HW | 19:21 |
| bryceh | hmm | 19:21 |
| bryceh | I think that's reasonably modern enough | 19:21 |
| bryceh | let's do the purge and then see what jockey thinks you should install | 19:21 |
| jussi | ok, purge is done, Ill give jockey a go now. | 19:21 |
| jussi | whoa, just got much faster. | 19:22 |
| jussi | right, so I can choose current and current updates | 19:22 |
| bryceh | you want current | 19:22 |
| jussi | ok | 19:22 |
| bryceh | (during development the two should be one and the same) | 19:23 |
| jussi | it appears to be installing now... | 19:23 |
| jussi | right, it installed. let me just reboot | 19:25 |
| jussi | bryceh: right, it seems to be working now. Im not sure what caused jockey to install all of the drivers there tbh. | 19:30 |
| jussi | Is there any other tests that are needed? or simply case closed forget about it? | 19:31 |
| bryceh | jussi, there was a jockey bug before where it'd prefer -173 over -current. I think that may be fixed now. Could be this is just fallout from that. | 19:32 |
| jussi | bryceh: ahh that would make sense. I guess I just dont want to leave the situation without a bug report or something if it would be useful for others. | 19:33 |
| bryceh | jussi, debugging this with you has been helpful. I'll keep an eye out for others with the same trouble, and if it appears to be a pervasive problem it may be worth deeper exploration, to see fi we can set up a reproducible case. | 19:33 |
| jussi | bryceh: sure. ping me if you need something, I idle here anyway :) | 19:34 |
| bryceh | jussi, well what I think we would need is to know how to get your system back into that broken state. If you have any ideas shout. | 19:34 |
| bryceh | -nvidia installs have never been perfect, and the purge trick is well utilized | 19:35 |
| jussi | bryceh: one thing I could try that just came to mind, is to see if its a bug with jockey not removing things - ie, if I now go try to install the current-updates, will it remove the current? | 19:35 |
| jussi | so if in the past, I tried to install all 3 at different times, but it never actually removed them | 19:36 |
| bryceh | I think it can cope with having both installed side by side, but only one will be in use at a time | 19:36 |
| jussi | ok | 19:36 |
| bryceh | you mention things had been slower, so I wonder if you had -173 loaded | 19:37 |
| jussi | it was strange, I had some slowness, as well as a disappearing mouse cursor | 19:37 |
| jussi | but not slow enough to really comment on, just a little. | 19:38 |
| bryceh | yeah, sounds like something that could be explained by an old driver | 19:39 |
| bryceh | fwiw, bug 949330 appears to be a missing kernel driver, which I think is different from what you saw. could be a weird dkms build issue (which is not unusual) | 19:40 |
| ubottu | Launchpad bug 949330 in nvidia-graphics-drivers (Ubuntu) "nVidia driver won't load anymore" [Undecided,Incomplete] https://launchpad.net/bugs/949330 | 19:40 |
| jussi | ok. well lets leave it at that for now, if you need more, feel free to ping, I am very willing to help out where I can. | 19:40 |
| bryceh | sure thing | 19:40 |
| jussi | thanks forall the help :=) | 19:41 |
| === himcesjf1 is now known as himcesjf | ||
| FernandoMiguel | anyone else having GPU crashes ? | 21:40 |
| bryceh | FernandoMiguel, you'd have to be more specific | 22:04 |
| FernandoMiguel | bryceh: I've seen traces replace my screen after login, and on shutdown it got locked on another trace | 22:05 |
| bryceh | FernandoMiguel, do you have a bug#? | 22:08 |
| FernandoMiguel | not yet | 22:08 |
| FernandoMiguel | trying to gather info and reproduce it | 22:08 |
| bryceh | FernandoMiguel, do you have a pastebin of the trace? | 22:08 |
| FernandoMiguel | couldn't capture it | 22:09 |
| FernandoMiguel | the 1st one was gone when I moved my mouse | 22:09 |
| FernandoMiguel | the other locked on shutdown, so I forced rebooted | 22:09 |
| bryceh | FernandoMiguel, alright well I going to be of little use to you without knowing some details ;-) | 22:09 |
| bryceh | FernandoMiguel, "yes" people have gpu lockups, kernel crashes, and so on all the time | 22:10 |
| FernandoMiguel | I know I know bryceh | 22:10 |
| FernandoMiguel | any typs to debug it furhter ? | 22:10 |
| FernandoMiguel | or to collect a log of what happened on last boot ? | 22:10 |
| bryceh | steps to reproduce are always helpful. See if you can reproduce it. | 22:10 |
| FernandoMiguel | will see on the next shutdown :) | 22:11 |
| bryceh | we need to have the trace. You can check dmesg or /var/log/kern.log, etc. | 22:11 |
| bryceh | file bug reports via 'ubuntu-bug linux' | 22:11 |
| bryceh | or 'ubuntu-bug xorg' if you're certain its X failing. Sounds like a kernel BUG or some such though, if it's printing on the screen | 22:11 |
| FernandoMiguel | k | 22:11 |
| bryceh | if it is a gpu lockup, then an i915_error_state.txt is required | 22:12 |
| bryceh | if it is an X server crash, then we want a full backtrace from gdb | 22:12 |
| FernandoMiguel | its on kern.log | 22:13 |
| FernandoMiguel | http://paste.ubuntu.com/875270/ | 22:13 |
| FernandoMiguel | filing a bug now | 22:14 |
| bryceh | aha | 22:14 |
| bryceh | cifs | 22:14 |
| bryceh | FernandoMiguel, so, looks like you had a filesystem error, perhaps related to crypto | 22:14 |
| bryceh | FernandoMiguel, you'd be wanting to speak with the kernel folks then | 22:15 |
| FernandoMiguel | ill | 22:15 |
| FernandoMiguel | danka | 22:15 |
| bryceh | no prob | 22:15 |
| === bryceh changed the topic of #ubuntu-x to: Before asking for help here, please file a bug report using 'ubuntu-bug xorg'. See http://wiki.ubuntu.com/X/Reporting for tips. | ||
| RAOF | cnd: Pong about gtest. | 22:27 |
| cnd | RAOF, let me get back to you | 22:27 |
| cnd | about to start a meeting | 22:27 |
| RAOF | :) | 22:27 |
| glosoli | Who is responsible for Ubuntu FGLRX ? | 22:38 |
| cnd | RAOF, ok, I am ready to chat :) | 23:20 |
| cnd | so xorg-gtest is undergoing a huge change so that it can be built by projects instead of using precompiled libraries | 23:20 |
| glosoli | Anyone knows who is reponsible of fglrx being 2 versions out of date ? | 23:20 |
| cnd | RAOF, I don't know if we should be including it in main for the LTS | 23:21 |
| bryceh | cnd, does anything depend on it? | 23:25 |
| bryceh | or, do you anticipate we'll be having large numbers of users running it? | 23:25 |
| cnd | bryceh, not yet, but RAOF wants to upload an xorg-server with tests that use it | 23:25 |
| bryceh | can it be an optional dependency in that case? | 23:27 |
| cnd | bryceh, I guess the bigger issue is that RAOF has asked for a MIR of xorg-gtest, but I don't think we can commit to support of xorg-gtest as it exists today | 23:29 |
| bryceh | in terms of security updates you mean? | 23:30 |
| cnd | any updates, really | 23:30 |
| cnd | I'm concerned about how we have a stack of precompiled libs | 23:30 |
| cnd | that upstream gtest says is the wrong way to do things | 23:30 |
| cnd | if the libstdc++ abi changes, we might be caught it a bad place | 23:31 |
| cnd | or something like that | 23:31 |
| bryceh | ah, gotcha | 23:31 |
| bryceh | however once the LTS is shipped, it's unlikely libs would go through ABI changes, right? Plus, you'd have the same problem if it's in universe | 23:32 |
| cnd | true | 23:32 |
| cnd | yeah, but I don't *have* to support universe :) | 23:32 |
| bryceh | anyway, guess it boils down to how RAOF intends to use it. having it in main does have some cost to it, but I don't think it's an unreasonable amount if there's sufficient value. | 23:36 |
| cnd | yeah, I suppose it will be ok | 23:36 |
| bryceh | there's lots of X packages we never update post-release, so this would be in good company ;-) | 23:37 |
| cnd | heh | 23:38 |
| RAOF | So, I'd quite like the tests to ship in the xserver. | 23:40 |
| RAOF | They *are* currently optional; they'll only build if xorg-gtest is installed. | 23:40 |
| RAOF | I guess there's not a high risk that the barrier tests get broken by post-release updates, so it's not terrible if they're not built on the buildds. | 23:43 |
| RAOF | cnd: So, if you don't want to support xorg-gtest in main, then I can live with that. | 23:43 |
| cnd | RAOF, I think it may be ok, but there will not be any further updates to xorg-gtest in precise | 23:44 |
| cnd | I guess that's an assumed thing since we're past FF anyways | 23:45 |
| cnd | meh, I'm getting my thoughts twisted in knots | 23:45 |
| cnd | I think it'll be fine | 23:45 |
| RAOF | Yeah. What sort of bugs are we likely to see in xorg-gtest that require an SRU? :) | 23:45 |
| cnd | heh | 23:46 |
| cnd | so I've spent the entire day so far trying to get gtest to build inside a project | 23:49 |
| cnd | I'm getting close | 23:49 |
| cnd | I think I have xorg-gtest itself all figured out | 23:49 |
| cnd | now I'm trying to convert xorg-gtest | 23:49 |
| RAOF | What problems were you running in to? | 23:51 |
| RAOF | I build gtest as a part of the xserver tests, and it's no biggy. | 23:51 |
| cnd | RAOF, just trying to get it all set up "correctly" | 23:52 |
| cnd | the google example Makefile is not very good... | 23:52 |
| * RAOF does need to add the autofoo to allow you to specify the source directory. | 23:53 | |
| RAOF | But I did it the cheater's way, by adding gtest-all.cc to _noinst_SOURCES :) | 23:53 |
| cnd | RAOF, you can see my work in progress at: http://cgit.freedesktop.org/~cndougla/xorg-gtest/log/?h=source | 23:53 |
| RAOF | Looks good. | 23:57 |
| RAOF | You'll still be shipping a pkg-config file, right? | 23:57 |
| cnd | no | 23:58 |
| cnd | what would be in it? | 23:58 |
| RAOF | The version, at least. | 23:58 |
| cnd | hmmm | 23:59 |
| RAOF | You could also include the path to the source directories. | 23:59 |
| cnd | how would you encode the path to the source directories? | 23:59 |
| RAOF | As a pkg-config variable. | 23:59 |
| cnd | you can define arbitrary vars? | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!