[03:49] <darkxst>  I have a small patch that fixes pointer barriers under gnome-shell, would anyone here be able to review it?
[03:49] <darkxst> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1073724
[03:49] <ubottu> Launchpad bug 1073724 in xorg-server (Ubuntu) "Pointer barriers have gaps along the edge of the screen" [Undecided,Confirmed]
[07:03] <mlankhorst> darkxst: do you want it for quantal/precise or just for raring?
[07:16] <mlankhorst> ah nm got it :)
[07:17]  * mlankhorst should wake up before saying something
[07:38] <tjaalton> so, where's the patch?
[07:39] <tjaalton> oh
[07:41] <tjaalton> that's an ugly diff
[07:55] <mlankhorst> tjaalton: yeah it changes it to a onrmal diff from a git diff
[07:57] <darkxst> mlankhorst, raring and quantal
[07:58] <tjaalton> darkxst: please use at least "-p ab --no-timestamps --no-index"
[07:58] <darkxst> sorry I struggled with quilt on that one
[07:58] <tjaalton> QUILT_DIFF_ARGS="-p ab --no-timestamps --no-index --color=auto"
[07:59] <tjaalton> that's what I have in .quiltrc-dpkg
[07:59] <tjaalton> and dquilt='quilt --quiltrc=${HOME}/.quiltrc-dpkg'
[07:59] <tjaalton> alias
[08:00] <mlankhorst> or if you never use quilt just make put it in .quiltrc ;-)
[08:00] <mlankhorst> s/make//
[08:04] <tjaalton> darkxst: we won't pull from that branch anyway, this is just to make reading easier..
[08:04] <darkxst> ok, just redoing now
[08:05] <tjaalton> now I just need to clone 100+ repos back..
[08:08] <tjaalton> at least it's easy for pkg-xorg
[08:16] <mlankhorst> tjaalton: er how come?
[08:17] <tjaalton> mlankhorst: what?
[08:17] <mlankhorst> 100+ repos :)
[08:18] <tjaalton> oh sorry, pkg-xorg alone is 188
[08:18] <mlankhorst> ah
[08:18] <tjaalton> git clone git://git.debian.org/git/pkg-xorg/debian/xsf-tools.git
[08:18] <tjaalton> then read mrconfig.README
[08:19] <tjaalton> haven't used that before
[08:19] <darkxst> mlankhorst, tjaalton, is this better ? http://bazaar.launchpad.net/~darkxst/ubuntu/raring/xorg-server/lp1073724B/revision/256
[08:20] <tjaalton> darkxst: you didn't use -p ab?
[08:20] <tjaalton> it's better but not by much
[08:20] <darkxst> QUILT_DIFF_ARGS=-p ab --no-timestamps --no-index --color=auto
[08:20] <tjaalton> oh..
[08:20] <tjaalton> hmm
[08:21] <darkxst> I also have QUILT_REFRESH_ARGS=-p ab --no-timestamps --no-index
[08:21] <tjaalton> then the original was created with something else :)
[08:21] <mlankhorst> tjaalton: git diff probably
[08:22] <tjaalton> darkxst: why the change in line 176
[08:22] <darkxst> tjaalton, that not me
[08:23] <tjaalton> your diff changes that
[08:23] <darkxst> my patch only changes 395 and 422
[08:24] <darkxst> tjaalton, quilt must have done that
[08:25] <darkxst> so what should I do exactly, its a very simple patch, but patching patches seems hard
[08:26] <darkxst> 422
[08:26] <darkxst>  
[08:26] <darkxst> -            nearest = barrier_find_nearest(cs, dir, ox, oy, *x, *y);
[08:26] <darkxst> 423
[08:26] <darkxst>  
[08:26] <darkxst> +            nearest = barrier_find_nearest(cs, dir, ox, oy, unclamped_prex, unclamped_prey);
[08:26] <darkxst>  
[08:26] <darkxst> 403
[08:26] <darkxst>              nearest = barrier_find_nearest(cs, dir, ox, oy, *x, *y);
[08:26] <tjaalton> yes I saw that
[08:26] <tjaalton> should be possible to just revert the diff from the patch directly..
[08:27] <tjaalton> but I'm not that far yet, will take some time until these have cloned..
[08:27] <tjaalton> mlankhorst: btw I never sorted out the xserver upload to.. precise?
[08:27] <tjaalton> that got dropped from the queue
[08:37] <mlankhorst> hm what was wrong there?
[08:39] <tjaalton> some cruft left in the tree
[08:39] <mlankhorst> that was the quantal one right?
[08:39] <mlankhorst> but hey suppose i could give uploading a try now that i have the rights to
[08:40] <tjaalton> sure
[08:40] <tjaalton> I don't see either being accepted yet
[08:40] <tjaalton> so dunno which one it was
[08:41] <mlankhorst> didn't you ask for the quantal one to be dropped?
[08:41] <tjaalton> as if I remember :)
[08:41] <tjaalton> that was two weeks ago
[08:41] <tjaalton> deleted the archive emails too
[09:06] <mlankhorst> ah, glad I'm not the only one with bad memory then :P
[09:45] <mlankhorst> darkxst: i can get it in the next quantal sru, but first wondering if you want it for precise too, and second if you could ask raof if he's ok with the fix since I have no clue about the pointer barrier patch
[10:35] <darkxst> mlankhorst, yes I think it affects precise also
[10:37] <darkxst> I no longer have a precise box to test, however I did have the same issue on precise
[10:37] <tjaalton> it's basically the same patch there
[10:39] <darkxst> ok, I will try check with raof tomorrow, I'm off to bed now
[10:39] <mlankhorst> yeah was thinking of killing the sru for precise too then
[10:39] <mlankhorst> and add it to both
[10:40] <darkxst> mlankhorst, ok sounds good
[10:40] <tjaalton> http://pastebin.com/84uQm4ZM
[10:40] <tjaalton> that's enough
[10:40] <tjaalton> ?
[10:40] <tjaalton> diff of a diff is hard to read :)
[10:41] <tjaalton> but basically just edited the patch directly, and dropped that change
[10:41] <mlankhorst> syntax highlighting!
[10:41] <darkxst> tjaalton, I think that looks correct
[10:41] <tjaalton> mlankhorst: not with pastebinit :)
[10:42] <tjaalton> oh
[10:42] <tjaalton> it does support -f
[10:43] <tjaalton> mlankhorst: oh right, I used the wrong branch for the upload
[10:48] <tjaalton> mlankhorst: will you handle this or should I commit the diff?
[10:50] <mlankhorst> either is fine
[10:50] <mlankhorst> still trying to beat sense in my kernel patch series :)
[10:50] <tjaalton> ok I'll commit it to raring, you can then do quantal/precise?
[10:52] <mlankhorst> kk
[10:52] <mlankhorst> I'm waiting for feedback from raof first though
[10:52] <tjaalton> oh right
[10:52] <tjaalton> I'll leave it unreleased in any case
[10:56] <tjaalton> darkxst: it's in git waiting for review
=== ubott2 is now known as ubottu
[10:56] <darkxst> tjaalton, mlankhorst, ok thanks for the help
[10:56] <darkxst> I will chase up with raof tomorrow
[17:35] <salty-horse> hey. are there plans to build the ubuntu-x-swat packages for quantal?
[17:59] <mlankhorst> which ones
[18:00] <bjsnider> not the blob, because the latest one is in there already
[18:04] <mlankhorst> usually x is a bit later
[18:22] <bjsnider> well, i guess it's not there at the moment, but i'm sure it will be uploaded soon
[18:59] <bryceh> bjsnider, who's uploading it?
[18:59] <bjsnider> alberto i guess
[19:00] <mlankhorst> bryceh: what are our plans for x for raring, just leave it similar to quantal until x1.14 rc1 happens?
[19:03] <bryceh> mlankhorst, yeah that's what I'm thinking.  Focus on bugs and srus and don't worry too much about syncing in new stuff yet.
[19:03] <mlankhorst> yeah
[19:04] <mlankhorst> going to be fun with nouveau anyway because of new kernel module
[19:14] <bjsnider> bryceh, would you like to have the blob in x-updates for quantal?
[19:18] <bryceh> bjsnider, yeah
[19:18] <bjsnider> why do we have -updates and nvidia-experimental-xxx and all of the rest of it?
[19:19] <mlankhorst> experimental is for steam
[19:20] <salty-horse> sorry for the delay: I'm specifically interested in the new nvidia driver (304.64) for quantal
[19:21] <bryceh> bjsnider, yeah I know we have so many places to get drivers, I don't know why users keep bugging me about getting them from the ppas
[19:21] <salty-horse> ppas are comfortable :)
[19:21] <bryceh> bjsnider, think we should just focus on having them use the sru'd versions rather than the ppas?
[19:21] <bjsnider> well, i'm assuming the purpose of -updates is to have hte latest driver
[19:21] <bryceh> salty-horse, fine, it's just that it's extra work for us
[19:21] <bjsnider> right now it isn't even 60 let alone 64
[19:22] <bjsnider> salty-horse, i'll get it in there in a few minutes dude
[19:22] <salty-horse> thanks. I'm not pushing :)
[19:23] <bryceh> bjsnider, I figure -updates probably takes a while to get new drivers in, so the ppas are useful to get the latest stuff out asap
[19:24] <bjsnider> well i guess it does if it doesn't even have 60 yet
[19:24] <bryceh> bjsnider, also for experimental-304, I think we may not be updating that going forward
[19:24] <bryceh> experimental-310 we'll be updating for a while
[19:26] <salty-horse> the new nvidia driver is "important" to me because of the reported substantial speedup
[19:27] <salty-horse> aka the fix for the "performance issue"
[19:27] <mlankhorst> bryceh: yeah just hoping to resubmit my patch series soon for kernel, and hopefully get it in -next
=== yofel_ is now known as yofel
[19:32] <bjsnider> salty-horse, there's always a fix for a performance issue, and a new performance issue introduced that needs a fix in the next driver
[19:33] <salty-horse> bjsnider, so the reports of "doubled performance" are exaggerated?
[19:34] <bjsnider> which reports are those?
[19:36] <salty-horse> http://linux.slashdot.org/story/12/11/06/204238/nvidia-doubles-linux-driver-performance-slips-steam-release-date
[19:37] <salty-horse> silly me: I mentioned the 304 drivers, and these are 310
[19:37] <bjsnider> yeah, the 310 probably has a few showstoppers
[19:38] <bryceh> salty-horse, yeah for 310 you want experimental.  see your hardware drivers dialog
[19:43] <salty-horse> thanks! I was totally confused by the version mixup, and the version I wanted was available all along :)
[19:44] <bjsnider> ok, nvidia-settings and blob uploaded, will take the rest of the day to build
[19:56] <bryceh> bjsnider, thanks!
[20:17] <darkxst> RAOF, hi, would you be able to review my pointer barrier patch? https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1073724
[20:17] <ubottu> Launchpad bug 1073724 in xorg-server (Ubuntu) "Pointer barriers have gaps along the edge of the screen" [Undecided,Confirmed]
[21:58] <Duke`> this is strange: I have some OpenGL apps which suffer "jittering", unless I stress my computer (by quickly shaking another window for example)