| maco | what packages did xutils and x-dev turn into? | 05:59 |
|---|---|---|
| andersk | xorg-dev? | 06:00 |
| maco | the pakage description for xutils said it turned into a bunch of smaller packages | 06:01 |
| maco | but i dont know where to find a list of what those packages are | 06:01 |
| andersk | aptitude show xutils | 06:01 |
| maco | the depends line? | 06:01 |
| andersk | Right. | 06:03 |
| maco | k thanks | 06:04 |
| RAOF | tjaalton: You suggested I provide a patch to make libdrm spit out a libdrm-nouveau package, so we can get a newer nouveau snapshot. This will require pulling in some post-2.4.4 commits from git; would you prefer that as a bunch of patches, or a new tarball? | 06:11 |
| RAOF | Sweet. autofoo during build. | 06:15 |
| tjaalton | RAOF: i'd prefer patches | 06:32 |
| RAOF | So would I, and since libdrm runs autoreconf during build, that's nice and easy. | 06:33 |
| tjaalton | yeah | 06:33 |
| RAOF | modesetting-newttm, I see. What fun! | 06:36 |
| tjaalton | hehe | 06:37 |
| bryce | kewl, xorg bugs squashed down to 100 now | 06:43 |
| bryce | (from ~200 earlier today) | 06:44 |
| tjaalton | wow :) | 06:45 |
| maco | bryce: as in Fix Released?? | 06:47 |
| RAOF | Hm. How does one generate the initial symbols file? | 06:47 |
| tjaalton | RAOF:build it, and you'll see it fails. grab the symbols and and edit the package version information | 06:50 |
| RAOF | Cool. That's what I was going to try first :) | 06:51 |
| bryce | maco: no; mostly moved to more correct packages (people dump all random X bugs in xorg if they don't know where they really go). Plus a couple handfuls -> invalid for various reasons. | 06:52 |
| tjaalton | and since you got access to git.d.o, you can push it there for review | 06:52 |
| maco | bryce: oh ok, my eyes were ready to pop out of my head :) | 06:52 |
| bryce | http://people.ubuntu.com/~brian/complete-graphs/xorg/plots/xorg-month-open.png | 06:53 |
| RAOF | tjaalton: Oh, that was aimed at me? Oh, wow. We *do* have an ubuntu branch of libdrm in there. I always thought the VCS field was wrong! | 06:53 |
| tjaalton | RAOF: no, they are mostly right. I'm on a crusade to convince bryce that having all changes in a git branch is a nice thing :) | 06:57 |
| RAOF | Oh, well. I guess I'll get to learn how to use git properly, then. | 06:58 |
| bryce | I await the sales pitch :-) | 06:58 |
| tjaalton | bryce: hehe | 06:58 |
| tjaalton | RAOF: you only need maybe five commands | 06:58 |
| bryce | (actually after last week I'm a bit more receptive to the idea) | 06:58 |
| tjaalton | once you get used to it, it's really simple | 06:58 |
| bryce | "get used to it" is the operative phrase it seems ;-) | 06:59 |
| tjaalton | yes, well, it has bitten me a couple of times, but I've tried to document those on the wiki | 06:59 |
| * RAOF is already hitting hard-edges. | 06:59 | |
| tjaalton | for instance when merging new upstream tags of mesa.. | 06:59 |
| tjaalton | it's fine if you follow a branch, but trying to move from a branch to a tagged devel release from master.. yuck | 07:00 |
| tjaalton | but it's easy now, and documented | 07:00 |
| tjaalton | bryce: well, for one thing, you always have the history, even if the package has been synced since | 07:01 |
| tjaalton | and it's nice to stage the changes on a shared repo instead on your hd | 07:01 |
| tjaalton | so the changes are less ad-hoc | 07:02 |
| RAOF | Ok. So, how do I make 'git diff' show the differences between HEAD and my working tree? | 07:02 |
| tjaalton | git diff HEAD? | 07:02 |
| tjaalton | hmm, which HEAD?-) | 07:02 |
| RAOF | Ah. Of course. Why doesn't 'git diff' give that to you? | 07:02 |
| RAOF | Or, alternatively, what is 'git diff' giving me? :) | 07:03 |
| tjaalton | git diff only shows uncommitted changes | 07:03 |
| RAOF | To files which were previously committed, it seems. | 07:03 |
| RAOF | It doesn't show file additions, which was freaking me out. | 07:03 |
| tjaalton | git status | 07:03 |
| RAOF | That makes sense of the output. | 07:03 |
| RAOF | OOOOOh, I get it now. | 07:04 |
| tjaalton | git clean -f; git reset --hard 1309t8h3g098h; those will become familiar to you ;) | 07:05 |
| RAOF | 'git diff' shows the changes to your working tree that _won't_ be committed when you commit. | 07:05 |
| * RAOF thinks that seems 100% arse-ended, but whatever. | 07:05 | |
| tjaalton | hmm, I'm lost now :) | 07:05 |
| RAOF | I was wondering why the patches weren't showing up in 'git diff' output, but debian/control etc was. | 07:06 |
| tjaalton | which branch are you on? remember to 'git checkout -b ubuntu origin/ubuntu' first | 07:06 |
| RAOF | Yup. I remembered that bit. | 07:06 |
| RAOF | This is because I'd run 'git add debian/patches/02_add_libdrm-nouveau.patch', but hadn't run 'git add debian/control'. | 07:06 |
| RAOF | Now that I've added everything, 'git diff' gives no output. | 07:06 |
| tjaalton | git diff only shows the changes to files that are already known by git | 07:06 |
| * bryce boggles why git is more popular than bzr. vhs vs. betamax I guess | 07:06 | |
| tjaalton | git status shows new file additions etc | 07:07 |
| tjaalton | RAOF: no need to git add d/c | 07:07 |
| tjaalton | bryce: well, I can't understand why I have to use 'bzr log|less' instead of just b | 07:07 |
| RAOF | tjaalton: Oh, because 'git commit -a' is now the defalt? | 07:07 |
| bryce | 'git commit -a' is a useful command | 07:07 |
| tjaalton | uh, bzr log | 07:07 |
| bryce | 'git show <commit-id>' is another | 07:08 |
| tjaalton | RAOF: yes, I only use that | 07:08 |
| RAOF | I have half-remembered git halucinations :) | 07:08 |
| bryce | tjaalton: yeah that bugs me too... I mentioned it to james_w last week (he was asking for bzr annoyances) | 07:08 |
| RAOF | There's the bzr-pager plugin; that should be installed by default :) | 07:08 |
| bryce | apparently the bzr guys did it that way intentionally, but dunno why | 07:08 |
| tjaalton | bryce: there were other similar cases too, but can't remember right now | 07:09 |
| tjaalton | maybe it's just me, but it feels like bzr pushes the changes upstream by default, and not on a local branch? | 07:09 |
| RAOF | If you 'bzr checkout', yes. | 07:10 |
| tjaalton | also, it's really annoying to have to specify the path _where_ to push every time | 07:10 |
| RAOF | If you 'bzr branch', no. | 07:10 |
| bryce | no, it uses local branches | 07:10 |
| RAOF | It remembers the default push location for me. | 07:10 |
| bryce | tjaalton: you do? I never have to do that... | 07:10 |
| tjaalton | every doc I've read says that | 07:10 |
| bryce | well, maybe one time | 07:10 |
| tjaalton | maybe they are not ment for me then :) | 07:10 |
| RAOF | Um. Does libdrm-intel1's long description really want to say that it's built from a snapshot of DRM code, and shouldn't be expected to be stable? :) | 07:11 |
| tjaalton | also, I need to rename the checked-out dir because it's always 'ubuntu' :) | 07:11 |
| tjaalton | RAOF: whoops, no :) | 07:11 |
| tjaalton | copy-paste ftw | 07:11 |
| RAOF | I'll roll that change up :) | 07:12 |
| bryce | tjaalton: having the history seems useful, but since I can also see it at https://edge.launchpad.net/ubuntu/+source/<package>, including debdiffs, the need is lessened a bit | 07:16 |
| bryce | staging the changes is useful, but given how often I forget to push anyway..... ;-) | 07:17 |
| tjaalton | hehe :) | 07:18 |
| bryce | I can imagine it helps when merging upstream + debian git into a new ubuntu version, however it seems this benefit comes mostly from the more complex packages, most of which we already have in git. Also you usually do all those merges yourself, so it's so far been a pain I've not had to endure. (for which I must give you thanks!) | 07:19 |
| RAOF | Is there any reason to use git-buildpackage? | 07:20 |
| bryce | my guess is that this latter point is the main sales point, but it's not one I understand very deeply so would need further selling on it to drive it home | 07:20 |
| RAOF | Oh, yes. To make it actually work :/ | 07:20 |
| bryce | for me, the question is not so much bzr vs. git, but vcs vs. no vcs | 07:20 |
| bryce | since adding the vcs adds several additional steps in the process, and thus adds extra spots I can forget to do stuff and screw things up | 07:21 |
| maco | tjaalton: i always make a directory with the package name, cd into it, and then branch because i once accidentally branched a "trunk" right over another "trunk" where i already had modifications | 07:22 |
| maco | (for two different programs) | 07:22 |
| tjaalton | maco: heh, right | 07:22 |
| bryce | otoh I've been getting used to using git with xorg-server now, and already have found it handy for xorg. I'm a bit at a point of wondering if it might be useful for -intel and xkeyboard-config | 07:22 |
| tjaalton | bryce: it does add a few steps, but once it's in your blood you don't think of those steps anymore, it just flows naturally :) | 07:23 |
| bryce | I've pretty much given up on ever seeing a viable bzr-git bridge things. If it did come I suspect it'd add as much complication as it saves | 07:23 |
| bryce | tjaalton: yeah and I'm sure if I wrote the GPL out for every commit, that would eventually get in my finger muscle memory as well. ;-) | 07:24 |
| tjaalton | bryce: this has much less typing, that's for sure :) | 07:25 |
| bryce | hey, sometimes I wonder ;-) | 07:26 |
| tjaalton | bzr-git; yes, and I'm not sure if it could solve the collaboration we now have with debian | 07:26 |
| tjaalton | um, I mean keep | 07:26 |
| bryce | what is the collaboration? | 07:27 |
| tjaalton | pulling changes from our branch in to debian-* | 07:27 |
| tjaalton | has happened a couple of times | 07:27 |
| bryce | only a couple times? | 07:27 |
| tjaalton | I've got no figures :) | 07:28 |
| bryce | yeah I can see that as a benefit - for instance, especially if they pulled bulletproof-x from us | 07:28 |
| tjaalton | but for the most part I've been pushing those there | 07:28 |
| tjaalton | hehe | 07:28 |
| bryce | however so far I get the impression that they would prefer our changes go upstream instead, so they pull from upstream, not from us | 07:28 |
| RAOF | Why are so many files deleted from the upstream tarball in libdrm? | 07:28 |
| tjaalton | RAOF: because they are shipped by the kernel | 07:29 |
| tjaalton | bryce: well, packaging changes | 07:29 |
| tjaalton | not so much upstream | 07:29 |
| RAOF | That's a reason to not install them, but they'll still be there after unpacking the source, right? | 07:29 |
| RAOF | Because the diff can't delete files. | 07:29 |
| tjaalton | oh upstream tarball.. what files? | 07:29 |
| RAOF | They're in the .orig.tar.gz, but not the debian tree. | 07:30 |
| RAOF | Almost all of shared-core | 07:30 |
| tjaalton | only userland bits are preserved | 07:30 |
| RAOF | Right. I think I know why I'm confused. | 07:31 |
| tjaalton | except for nouveau | 07:31 |
| RAOF | But also, I thought they weren't in the upstream tarball, either. | 07:31 |
| bryce | tjaalton: let me ask this differently... what do you personally find most useful/beneficial with using git for -evdev for example? What are the top things you would miss if you did not use vcs for it? | 07:40 |
| tjaalton | bryce: right, one point I've forgot to mention; using 'git show foo' to pull upstream patches | 07:41 |
| tjaalton | though you need to have the upstream repo in .git/config too, but it's a no-brainer | 07:41 |
| bryce | xorg ---> 88 now | 07:41 |
| tjaalton | so 'git show foo > 100_rad_feature.patch' | 07:43 |
| bryce | yep, I do this already both with -intel and -ati | 07:44 |
| mnemo | hmm, all my themes got borked when I install this mornings updates ;( | 07:50 |
| mnemo | http://temp.minimum.se/Screenshot-Calculator%20-%20Programming.png | 07:50 |
| mnemo | well, the default theme still works but I was using Dust and also clearlook theme has same problem etc | 07:50 |
| bryce | mnemo: don't see the issue | 07:50 |
| mnemo | mmkay | 07:50 |
| bryce | mnemo: look in your /var/log/dpkg.log for what exactly changed | 07:51 |
| bryce | then test reverting individual debs (which should be in /var/cache/apt/archives/) to find specifically what package causes the change | 07:51 |
| mnemo | oh nice, I didn't know you could revert stuff like that... that's _very_ useful for debugging | 07:53 |
| bryce | yep | 07:53 |
| mnemo | found a bug in LP for this now --> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/327793 looks like many people got hit by theme issues during the night | 07:55 |
| ubottu | Ubuntu bug 327793 in metacity "Window decorations in title bar missing with compiz enabled" [Undecided,New] | 07:55 |
| tjaalton | bryce: did it answer your question?-) Also, tracking new upstream releases is less error-prone, since you know exactly what you've done to make it build etc | 07:55 |
| bryce | tjaalton: well I agree git show is very useful in general, but don't see how managing my package in git would make it additionally more useful | 07:57 |
| bryce | for the second point, could you explain more? that sounds significant but not sure I understand the benefit completely | 07:58 |
| tjaalton | ok, so without a vcs you grab the new tarball, and copy debian/ from the previous version in it. then you build it and if it doesn't, make changes one at a time so it does, and document them in debian/changelog | 08:01 |
| tjaalton | this is nontrivial for libraries, where you have to update the shlibs files etc. and keeping track of things becomes harder | 08:02 |
| tjaalton | also, if you are interrupted, it's harder to pick up where you were | 08:05 |
| bryce | ah, okay. does this happen often? | 08:05 |
| tjaalton | interruptions? all the time :) | 08:06 |
| * crevette raises an INT13 | 08:06 | |
| bryce | heh, no, needing to update things for libraries ;-) | 08:07 |
| bryce | I'm well versed in the interrupt thing ;-) | 08:07 |
| bryce | (for instance, I get interrupted before I remember to push my changes to the vcs that I just finished uploading) | 08:07 |
| tjaalton | when there are new (or changed) symbols in the new version. happens with libdrm at least, haven't touched that many libs yet | 08:08 |
| bryce | xorg ----> 73 | 08:17 |
| tjaalton | looks like I'll be able to start my masters soon, at last | 08:31 |
| tjaalton | *thesis | 08:32 |
| bryce | tjaalton: congrats :-) | 08:32 |
| tjaalton | the paperwork will take a while, but I hope to be able to graduate before christmas | 08:32 |
| bryce | wow, that's not so long | 08:34 |
| bryce | less than a year | 08:35 |
| bryce | xorg ------> 61 | 08:36 |
| tjaalton | most of the topic is already done, it's just a matter of getting it written down and published | 08:37 |
| tjaalton | wow, they fit in one page now :) | 08:37 |
| tjaalton | bug 321340 should be fixed now, it's an openchrome bug | 08:38 |
| ubottu | Launchpad bug 321340 in xorg "Cannot install 7.10, 8.04 xubuntu, Kubuntu on Averatec 3280" [Undecided,Incomplete] https://launchpad.net/bugs/321340 | 08:38 |
| tjaalton | moving it | 08:38 |
| bryce | thanks | 08:39 |
| bryce | yeah, goal is to get xorg off of https://bugs.edge.launchpad.net/ubuntu/+upstreamreport. It was at #20 when I started. | 08:40 |
| RAOF | The symbols file should refer to libdrm-nouveau1, rather than libdrm2, right? | 08:42 |
| tjaalton | RAOF: depends on the symbols | 08:42 |
| bryce | yay, xorg -> 58; bumps it down off the +upstreamreport \o/ | 08:45 |
| bryce | wow, inkscape is in the top 100 now | 08:47 |
| tjaalton | cool | 08:59 |
| tjaalton | I've marked a bunch of sync candidates on the versions_current page | 08:59 |
| tjaalton | driver | 09:00 |
| tjaalton | s | 09:00 |
| bryce | tjaalton: cool | 09:01 |
| bryce | at some point here I'll get around to getting xkeyboard-config merged | 09:02 |
| bryce | erf, xorg jumped back up onto the chart | 09:02 |
| tjaalton | where's the chart? | 09:04 |
| bryce | http://people.ubuntu.com/~bryce/Plots/ | 09:06 |
| bryce | click X, then xorg | 09:06 |
| tjaalton | oh that one | 09:07 |
| bryce | also see http://people.ubuntu.com/~bryce/Graphs/totals.svg | 09:07 |
| mnemo | bryce: i wanted to help out test the new intel freeze patch but I cant get the kernel code using the method I typically use? --> http://rafb.net/p/MHBYuK52.html | 09:07 |
| tjaalton | weird, works here | 09:08 |
| bryce | mirror issue?? | 09:10 |
| tjaalton | probably | 09:10 |
| mnemo | I got "main server" configured in "software sources" at least | 09:10 |
| mnemo | is there any other way to get the code? | 09:11 |
| mnemo | there is a git repo for it right? | 09:11 |
| mnemo | found it, git://kernel.ubuntu.com/ubuntu/ubuntu-jaunty.git | 09:12 |
| mnemo | I guess it's okay to test the drm patches against that? | 09:12 |
| tjaalton | yes, but easier to just use the package and then copy the drm.ko in place | 09:14 |
| mnemo | cant I build drm.ko from the git tree? | 09:14 |
| tjaalton | yes | 09:14 |
| tjaalton | but it's a huge tree | 09:14 |
| mnemo | but I will just build that module dir? | 09:15 |
| tjaalton | don't know how to do that | 09:15 |
| mnemo | all the kernel makefiles have a target called modules | 09:15 |
| mnemo | so you can do: | 09:15 |
| mnemo | make -C /lib/modules/`uname -r`/build M=$PWD modules | 09:15 |
| tjaalton | just wget the package from http://a.u.c | 09:15 |
| tjaalton | k | 09:15 |
| bryce | tjaalton: do you think #226827 is actually an X bug? | 09:15 |
| tjaalton | bryce: hard to tell, can't reproduce that's for sure | 09:17 |
| bryce | xorg -------> 48 | 09:25 |
| tjaalton | heh | 09:25 |
| tjaalton | that's probably a new all-time-low | 09:25 |
| bryce | sweet | 09:26 |
| mnemo | I have a g45 bug I havnt filed yet so make that 49 =P | 09:33 |
| mnemo | or is that just for the xserver package? | 09:34 |
| bryce | xorg | 09:34 |
| mnemo | ok | 09:34 |
| bryce | also I knocked out a couple more so we're at 46 | 09:34 |
| mvo | has anyone of you played with kenrel-mode-setting yet? | 09:37 |
| bryce | mvo, not me | 09:38 |
| bryce | mvo, heya :-) | 09:38 |
| mvo | hey bryce :) | 09:38 |
| mvo | I did the other day on my i965 system and it did not quite work out (blank screen after the fb driver got loaded). and I was wondering if I was just unluky | 09:38 |
| bryce | possibly. there's a lot of things that can cause blank screens | 09:40 |
| crevette | like usplash :) | 09:40 |
| bryce | mvo, most recently was a usplash bug kees just fixed today | 09:41 |
| bryce | yeah | 09:41 |
| mvo | hm, I think I disalbled usplash on this machine. I haven't really diagnosed it in detail, funny thing that I was able to use vga= to force it into a mode and then it came up ok. but I guess its just the joy of pre-release kernels :) | 09:44 |
| bryce | ahh | 09:45 |
| bryce | ok, /me --> bed. cya tomorrow | 09:45 |
| mnemo | nn | 09:46 |
| bryce | tjaalton: there's still some xorg bugs I think could be moved to better homes. if you have some time to review them it'd be verry nicce | 09:46 |
| tjaalton | bryce: sure, I can look at them. night | 09:48 |
| tjaalton | mvo: umm, I'm not sure but I thought KMS was meant to replace the framebuffer driver, so using vga= would break things | 09:49 |
| mvo | tjaalton: but with kms it will still present a /dev/fb device, no? | 09:56 |
| tjaalton | mvo: I haven't tried, so don't know | 09:56 |
| tjaalton | but AIUI using vga= means that it'll use vesafb | 09:57 |
| mvo | when I checked the intelfb module was loaded, but again I could be wrong, just played with it briefly | 09:57 |
| mvo | having vesafb would explain why it suddenly worked :) | 09:58 |
| tjaalton | yeah :) | 10:00 |
| RAOF_ | tjaalton: OK. There's something that looks very much like a version of libdrm that builds libdrm-nouveau1 in pkg-xorg git. It'd be good if you could check it sometime to ensure I haven't made any howlers in git. | 10:27 |
| RAOF_ | I haven't actually built the new drivers to see that it works yet, though, so it's not ready to upload. | 10:29 |
| === crevette_ is now known as crevette | ||
| === mvo_ is now known as mvo | ||
| mvo | tjaalton: you are quite right, vga= loads the vesafb driver, so my tests earlier today were mood | 15:17 |
| tjaalton | mvo: that happens :) | 15:22 |
| superm1 | tseliot, i'm really wary of this solution to bug 326720 | 17:39 |
| ubottu | Launchpad bug 326720 in nvidia-graphics-drivers-180 "package nvidia-180-libvdpau None [modified: /var/lib/dpkg/info/nvidia-180-libvdpau.list] failed to install/upgrade: trying to overwrite `/usr/lib/libvdpau.so.1', which is also in package nvidia-glx-177" [Low,Fix released] https://launchpad.net/bugs/326720 | 17:39 |
| superm1 | that means that if a package builds against libvpdau that it also requires an nvidia driver installed | 17:39 |
| superm1 | vdpau wasn't available in nvida-glx-177, so this shouldn't have been a problem | 17:39 |
| bryce | heya superm1 | 17:39 |
| superm1 | hi bryce | 17:39 |
| tseliot | superm1: yes, I know but we need to make sure that it doesn't conflict with any other nvidia flavour 177 or whatever Nvidia decides to make available | 17:41 |
| superm1 | tseliot, I would rather that there is a conflicts/replaces then. adding that dependency won't work | 17:42 |
| superm1 | libvdpau was introduced in the 180 series, so this problem shouldn't have come up | 17:42 |
| superm1 | wasn't it? | 17:43 |
| tseliot | superm1: it was introduced in 177, I guess | 17:43 |
| tseliot | superm1: anyhow feel free to revert that change | 17:45 |
| superm1 | tseliot, ah yeah it was introduced in 177.82 it looks like. just looked at the deb | 17:47 |
| superm1 | tseliot, so this being the case, I think just replaces: is the right solution | 17:47 |
| tseliot | superm1: ok, fair enough | 17:48 |
| tseliot | superm1: to tell the truth Update Manager should remove 177 in dist-upgrades so there shouldn't be real problems any more | 17:49 |
| superm1 | okay i'll upload a fix with just Replaces then for that rather than depends. | 17:50 |
| superm1 | i wish nvidia would just release libvdpau as open source already so that this problem would resolve itself though | 17:50 |
| tseliot | yes, that would help too | 17:51 |
| superm1 | tseliot, other than you no one gave any feedback on that patch I had for the screen resolution tool. i was kinda surprised given how strong feedback was in both directions for the zapping feature. is there anyone else I should poke to ask about it you think? | 17:53 |
| tseliot | superm1: about your patch? No, I guess not. Your change doesn't affect all users and shouldn't clutter the UI | 17:54 |
| superm1 | tseliot, okay. when will you have your other changes ready so I can merge it into the branch? | 17:54 |
| tseliot | I gave seb128 my new patches therefore I think you should just wait for the new packages 25.90 to be available | 17:55 |
| tseliot | then you can ask either mvo or seb128 just to be sure | 17:55 |
| superm1 | tseliot, do you have a merge proposal branch for those? I'll just merge that locally and adjust my changes to take them into account now then | 17:56 |
| tseliot | superm1: also, wouldn't it be better if you defined the names of nvidia-settings and amdcccle in some macros in the patch instead of touching the makefile (which in turn is touched by other patches)? | 17:56 |
| tseliot | superm1: no, sorry my bzr was broken therefore I couldn't push my changes | 17:57 |
| superm1 | tseliot, I suppose that would make sense, I was hoping upstream would be willing to accept the changes too eventually, so it made sense to patch the makefile for them to take the patch as is | 17:57 |
| superm1 | i sent a feature request to gnome-control-center's bugzilla, but no one responded to it | 17:58 |
| bryce | heya tseliot, how goes? | 17:58 |
| tseliot | superm1: I wouldn't hold my breath on it. You did well though | 17:58 |
| tseliot | bryce: hey, fine, thanks, a bit anxious but I'm ok | 17:59 |
| tseliot | bryce: and you? | 17:59 |
| superm1 | tseliot,yeah i'm hoping it's not just denied because it supports closed drivers. closed drivers exist, might as well work around their deficiencies rather than try to make your tools work with them | 17:59 |
| bryce | tseliot: I'm ok. threw out my back the other day but otherwise stuff is going well | 17:59 |
| bryce | last week was pretty busy, but think I'll be caught up by today. | 18:00 |
| bryce | tseliot: was just wondering if there's anything you're waiting on me for? I got pretty behind on email last week. | 18:00 |
| tseliot | bryce: I sent you an email about the xorg-options-editor but there's no hurry | 18:01 |
| bryce | ok cool, yes I still have that on my plate to get to | 18:01 |
| tseliot | bryce: does you back hurt too much? | 18:02 |
| bryce | yeah | 18:02 |
| bryce | I think sitting in bad chairs in the hotel + bad bed + bad airplane seat did it to me | 18:02 |
| tseliot | the airplane can do that too | 18:03 |
| tseliot | I hope you get well soon | 18:04 |
| bryce | yep, I'm sure I will | 18:04 |
| * tseliot > dinner | 18:19 | |
| bryce | jcristau: how have you been finding -ati 6.10.99.0 compared with 6.9.0? I'm thinking of upgrading jaunty to that version; any major issues to worry about? | 18:38 |
| crevette | hello | 18:54 |
| crevette | I wonder why my session can't run compiz whereas my girlfried can ... | 18:57 |
| crevette | at least the capplet telle me I can't | 18:58 |
| bryce | what's your card? | 19:01 |
| crevette | Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller | 19:03 |
| bryce | ok, which version of ubuntu? | 19:04 |
| crevette | jaunty | 19:04 |
| bryce | should work | 19:04 |
| crevette | but I seen this behaviour since intrepid | 19:04 |
| crevette | this is weird because my girlfriend one the same laptop, in her session can run compiz :) | 19:06 |
| tjaalton | did she log in first? | 19:07 |
| crevette | she didn't log today | 19:07 |
| crevette | the only active session is mine | 19:07 |
| tjaalton | ok, the second running session has no dri with intel | 19:07 |
| crevette | but I'm the only one which logged in today | 19:08 |
| bryce | grep DRI /var/log/Xorg.0.log ? | 19:09 |
| tjaalton | it's a session problem, not in x | 19:09 |
| tjaalton | running compiz from a terminal should tell something | 19:10 |
| crevette | compiz.real (core) - Error: Could not acquire compositing manager selection on screen 0 display ":0.0" | 19:16 |
| crevette | compiz.real (core) - Fatal: No manageable screens found on display :0.0 | 19:16 |
| mnemo | hmm, I just found a "sync to vblank option" in ccsm.. I didnt know there was one | 20:20 |
| mnemo | seems to work too, if I enable the benchmark plugin I can see the FPS go down to ~60 | 20:20 |
| mnemo | pretty nice | 20:20 |
| bryce | ccsm? | 20:21 |
| mnemo | compiz config setting manager | 20:21 |
| mnemo | +s | 20:21 |
| bryce | ah | 20:22 |
| mnemo | by the way, at FOSDEM this year eric anholt said in a talk that "vblank is a mess" right now... he also said that their top priority ig going to be fixing that over the next releases (now that KMS, UXA etc is landing) | 20:22 |
| bryce | hrm | 20:25 |
| bryce | interesting; any particular reasons for the mess? Something we should avoid for now I gather? | 20:25 |
| mnemo | the talk was recorded.. phoronix will publish it eventually I think | 20:25 |
| mnemo | its up actually | 20:26 |
| mnemo | here it is: | 20:26 |
| mnemo | http://www.phoronix.com/scan.php?page=article&item=intel_rebuild_x&num=2 | 20:26 |
| bryce | thanks | 20:27 |
| bryce | darn, flash is busted for me right now | 20:27 |
| mnemo | ;/ | 20:27 |
| mnemo | crappy audio though | 20:27 |
| mnemo | actually the audio is useless all the way through, you'd probably be better of asking eric for the slides | 20:29 |
| bryce | ugh, so intel is going not going to merge uxa back into exa after all | 20:31 |
| mnemo | nah doesnt seem like it | 20:32 |
| bryce | too bad | 20:32 |
| mnemo | I wonder which one they are testing more carefully | 20:33 |
| bryce | neither? ;-) | 20:34 |
| mnemo | for me UXA works _much_ better but on the wiki site I saw many old cards handle UXA pretty poorly | 20:34 |
| mnemo | hehe | 20:34 |
| bryce | there's problems with new cards too | 20:34 |
| mnemo | maybe im lucky, UXA works perfectly for me.. nice FPS etc as well | 20:34 |
| bryce | me too | 20:35 |
| bryce | heya RAOF | 20:36 |
| tjaalton | RAOF: you forgot to include one patch | 20:40 |
| tjaalton | bryce: if the vblank madness isn't sorted out soon, we can disable it again in mesa | 20:41 |
| bryce | ok | 20:42 |
| bryce | tjaalton: yeah I think leading up to -beta there are going to be a few things we should look at disabiling | 20:42 |
| bryce | maybe we could use a checklist... | 20:43 |
| mnemo | fwiw, I'd also prefer vblank disabled at least one more release | 20:45 |
| mnemo | maybe fedora will ship it on and fix some of the bugs ;> | 20:45 |
| RAOF | tjaalton: Oh? Which patch? | 21:17 |
| RAOF | Oh. You mean I missed one from git? | 21:18 |
| RAOF | Oh. GAH! | 21:19 |
| bryce | https://wiki.ubuntu.com/X/BetaReviewChecklist | 21:19 |
| tjaalton | bryce: looks good | 21:29 |
| bryce | anything else we should think about? | 21:30 |
| bryce | guess we can add to it as we think of stuff | 21:31 |
| tjaalton | yeah | 21:31 |
| btQuark | just had a look at the betalist | 22:09 |
| btQuark | i'm having fun with some r500 cards on 8.10 here and my 2 cents is: XAA is nice but close to worthless for realworld usage aka 3D, i'm using EXA here and did not experience a crash | 22:10 |
| btQuark | in half a year | 22:11 |
| btQuark | although the missing DRI2 is painfull. but anyway its ATI so pain was one of the main features advertised on the package | 22:11 |
| btQuark | ah. yeah. well. there's that fglrx. that must've been included for those who did not yet have enough pain in their lives. definitly s/m stuff | 22:12 |
| RAOF | Right. Let's see if this new nouveau snapshot works, then... | 23:15 |
| RAOF | That seems to be a 'yes'. | 23:19 |
| bryce | :-)( | 23:19 |
| RAOF | Hm. How do you deal with copyright for a patch that adds a bunch of files under different holders? | 23:29 |
| RAOF | Ok. I think libdrm is OK. | 23:42 |
| bryce | xorg ----------> 36 | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
