#ubuntu-x 2007-05-14
<ubotu> New bug: #114520 in xserver-xorg-video-ati (main) "ATI Radeon 9250 PCI black screen and console freeze when X starts" [Undecided,Unconfirmed]  https://launchpad.net/bugs/114520
<ubotu> New bug: #114562 in xorg (main) "LiveCD Safe Graphics Mode fails IBM X41 Tablet" [Undecided,Unconfirmed]  https://launchpad.net/bugs/114562
<ubotu> New bug: #35890 in xserver-xorg-input-mouse (main) "Mouse doesn't work properly after boot up" [High,Needs info]  https://launchpad.net/bugs/35890
<ubotu> New bug: #50145 in xserver-xorg-input-mouse (main) "mouse sliders don't work after latest update" [Undecided,Rejected]  https://launchpad.net/bugs/50145
<ubotu> New bug: #114216 in linux-restricted-modules-2.6.20 (restricted) "Nvidia-glx-new makes my system crash" [Undecided,Needs info]  https://launchpad.net/bugs/114216
<ubotu> New bug: #114668 in xrdb (main) "[apport]  xrdb crashed with SIGFPE" [Undecided,Unconfirmed]  https://launchpad.net/bugs/114668
<ubotu> New bug: #113969 in xorg-server (main) "mythtv backend and video manager crashes" [Undecided,Unconfirmed]  https://launchpad.net/bugs/113969
<ubotu> New bug: #113549 in xorg (main) "xorg crashes on log in using xgl" [Undecided,Needs info]  https://launchpad.net/bugs/113549
#ubuntu-x 2007-05-15
<bryce> tepsipakki: you about?
<bryce> tepsipakki: first cut at xserver 1.3 ubuntu packaging: http://people.ubuntu.com/~bryce/xorg-server_1.3.0.0.dfsg-4ubuntu1.dsc.debdiff
<jcristau> might be a bit late in europe (2:25am here)
<bryce> ah, is he in europe?
<jcristau> .fi, I think
<bryce> ah ok
<bryce> well, it's almost end of day for me, so maybe he'll see this when he gets up
<jcristau> gtf in xserver-xorg-core.install is in debian, iirc, so you could remove that
<bryce> ah cool
<keescook> jcristau: hm, which version did that start happening in?
<jcristau> maybe i should add the other utils too, although i don't remember anyone asking for them
<bryce> keescook: I see gtf listed twice in that file
<jcristau> 2:1.2.99.905-2
<keescook> bryce: ah!  I'm blind.  :)
<jcristau> the referenced ubuntu bug (#37720) doesn't really explain why they would be needed
<bryce> ok I'm going to be taking off
<bryce> talk to you tomorrow kees
<keescook> bryce: cool! ttyl
<ubotu> New bug: #35758 in xinit (main) "startx leaks .serverauth.???? files" [Medium,Confirmed]  https://launchpad.net/bugs/35758
<tepsipakki> bryce_: hi, I'll have a look at it later today
<tepsipakki> but at a glance it looks good. I wonder if the "-Conflicts: xserver-xorg-video" diff could be dropped. I don't see why the conflict was dropped in the first place, no mention about it on the changelog (prior to my merge)
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #114747 in xrandr (main) "[apport]  xrandr crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/114747
<tepsipakki> patch 124 should be applied upstream, but it's not. I reopened the b.fd.o bug
<ubotu> New bug: #114659 in Ubuntu "keyboard stops working after upgrade to feisty (dup-of: 108382)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/114659
<jcristau> tepsipakki: it's not in master either?
<tepsipakki> nope
<tepsipakki> I checked 1.3 branch and master
<tepsipakki> https://bugs.freedesktop.org/show_bug.cgi?id=8537
<ubotu> Freedesktop bug 8537 in Driver/intel "dual head/non xinerama crashes server if aiglx is enabled" [Normal,Resolved: fixed]  
<tepsipakki> *cough* seems that the Conflicts: xkb-data change was made by me.. don't remember why
<jcristau> to make sure people had their xkb data in /usr/share?
<tepsipakki> yes, but the new version was there already since December
<tepsipakki> anyway, maybe there was a bug I forgot to mention
<tepsipakki> 11 drivers can be synced after xorg-server is uploaded
<tepsipakki> sweet
<ubotu> New bug: #40711 in xserver-xorg-input-keyboard (main) "Keyboard doesn't work (dup-of: 108382)" [Medium,Unconfirmed]  https://launchpad.net/bugs/40711
<ubotu> New bug: #79112 in linux-source-2.6.17 (main) "keyboard driver not loaded at startup/boot (dup-of: 108382)" [Medium,Confirmed]  https://launchpad.net/bugs/79112
<ubotu> New bug: #106289 in linux-source-2.6.20 (main) "PS/2 Keyboards Not Responding (dup-of: 108382)" [High,Confirmed]  https://launchpad.net/bugs/106289
<jcristau> why are kernel bugs reported here? :)
<tepsipakki> heh
<tepsipakki> good question, I'll check that out
<tepsipakki> one of the dupes was reported agains x-x-i-keyboard, maybe that pulled all the other dupes here, dunno
<tepsipakki> ah yes, the master bug has X SWAT as a subscriber (from the dupe)
<jcristau> aha
<tepsipakki> it could be removed though
<tepsipakki> done
<jcristau> I don't really care, I was just wondering :)
<tepsipakki> well, it annoyed me :)
<tepsipakki> too many bug msgs here anyway :P
<jcristau> :)
<jcristau> people should finally learn that X has no bugs
<tepsipakki> I've been telling that for some time now
<tepsipakki> there's a mirror for that nearby
<tepsipakki> good way to start the day looking at it..
<jcristau> :)
<tepsipakki> if that doesn't motivate you then what does :)
<kylem> https://wiki.ubuntu.com/MainInclusionXF86VideoIntel
<jcristau> kylem: it links to http://packages.qa.debian.org/d/dmraid.html :)
<kylem> jcristau, yeah, i'm a muppet. :)
<tepsipakki> yes, once the server is uploaded we can pull the new -intel
<tepsipakki> and drop i810
<kylem> no.
<kylem> we can't drop i810 yet. :)
<kylem> too risky.
<tepsipakki> why not?
<tepsipakki> risky how? it's gutsy :)
<kylem> lol
<tepsipakki> did you discuss it at UDS?
<kylem> i don't remember. :)
<kylem> i was so jetlagged for most of UDS it's a haze.
<tepsipakki> ah, "jetlag".. I'll remember that next Sunday ;)
<kylem> :)
<tepsipakki> oh well.. exam ->
<kylem> tepsipakki, good luck!
<tepsipakki> gah, I hate essays :P
<tepsipakki> kylem: thanks, maybe better luck in September :)
<bryce_> morning tepsipakki
<tepsipakki> hi bryce_ 
<bryce_> ugh, I think I picked up a bit of a headcold on the flight home.
<tepsipakki> working on x should make you feel warm again :)
<bryce_> hehe
<keescook> bryce_: hiya. you ready to finish off xorg-server?  The one I built it working fine.
<bryce_> yup, sure am
<bryce_> what's next?
<bryce_> tepsipakki said the xserver-xorg-video conflict diff could be dropped
<bryce_> also, what's on our list to ask seb?
<bryce_> (pardon if I'm a bit spacey - I apparently picked up a bit of a headcold last night)
<bryce_> (being severely dehydrated on airplanes for 18 hrs probably made a headcold inevitable; hopefully it passes quickly)
<bryce_> keescook: ping?
* keescook nods
<keescook> the xserver-xorg-video conflict is still required; I couldn't install it without it.
<keescook> we're at the stage of comparing our debdiffs again.
<keescook> the one that works for me is here: http://people.ubuntu.com/~kees/xorg-server_1.3.0.0.dfsg-4ubuntu1.dsc.debdiff
<keescook> bryce_: so, once you've got a debdiff ready, we can compare notes again.  once we've agreed on a debdiff, you can build and test it too
<bryce_> ok
<bryce_> http://people.ubuntu.com/~bryce/xorg-server_1.3.0.0.dfsg-4ubuntu1.dsc.debdiff
<bryce_> should we list the dropped patches in the changelog?
<keescook> bryce_: I don't think so, since it is by definition a list of "reamining changes"
<bryce_> ok
<keescook> so, the Conflicts line still needs xserver-xorg-video (I tested this last night)
<keescook> beyond that, I think our debdiffs are identical
<bryce_> ok I've added that
<keescook> alright.
* bryce_ rebuilds
<keescook> so, now, do a pbuild of it, and try out the resulting .debs on your gutsy install.  :)
<bryce_> oh I had a question on that
<bryce_> I was trying to sort out how to upgrade my laptop to gutsy...
<bryce_> upgrade-manager -c won't do it -- but I couldn't find docs on wiki
<bryce_> I assume it's some permutation of 'apt-grade upgrade' ?
<bryce_> I wish I'd kept notes when I did this for feisty
<keescook> afaict, just manually adjust the feisty->gutsy, do an apt-get update/apt-get dist-upgrade and try to wade through any conflicts
<bryce_> ok
<keescook> uh-oh... did I give you the wrong advice?  one sec...
<keescook> aaagh
<keescook> sorry, you were totally right, we do _not_ want to conflict with xserver-xorg-video.  I forgot which direction it needed to go
<keescook> your original debdiff was right.
<bryce_> ah ok
<bryce_> http://people.ubuntu.com/~bryce/xorg-server_1.3.0.0.dfsg-4ubuntu1.dsc.debdiff
<keescook> great, looks ready.  excellent changelog.
<bryce_> thanks, ok running pbuilder
<keescook> once that's built and the .debs have been tested, do a debsign and dput to somewhere I can snag it from, and I'll sponsor it into main
<bryce_> ok cool, I'll get working on that
<bryce_> first I'll need to get my laptop updated
<bryce_> since the trip I've been noticing the laptop working a bit oddly; I wonder if it might have overheated a bit
<keescook> ick.  might be worth it to add that "force it to 700MHz" thing to your rc.local or something
<bryce_> yeah
<bryce_> I'm going to order a new laptop once Dell has Ubuntu-ized ones orderable
<bryce_> also I've got top bid on one of the osdl em64t's that I think would make a nice devel box
<tepsipakki> bryce_: you are aware that 1.3 doesn't work with nvidia/fglrx?
<tepsipakki> or to be precise, the other way around
<keescook> tepsipakki: ... can you explain that a bit?
<keescook> I'm running the nvidia driver with the 1.3 xorg-server debs...
<bryce_> tepsipakki: I'd heard that xrandr doesn't work with those
<bryce_> I didn't know 1.3 did not work with those drivers in general
<tepsipakki> keescook: really?
<keescook> tepsipakki: yeah
<tepsipakki> at least fglrx should fail
<keescook> ii  xserver-xorg-core 1.3.0.0.dfsg-4ubuntu1 X.Org X server -- core server
<keescook> ah, fglrx I haven't tried
<tepsipakki> fglrx fails since the server now show a version "1.3" instead of "7.x"
<tepsipakki> maybe nvidia is a bit wiser
<tepsipakki> jcristau added a Conflicts: fglrx to git.d.o because of that
<tepsipakki> today ;)
<bryce_> what do you think we should do about this?
<tepsipakki> maybe do the same
<tepsipakki> until fglrx is fixed
<bryce_> ok
<keescook> binary drivers for the win!  :)
<tepsipakki> right on!
<keescook> tepsipakki: is there a debian bug for the fglrx issue?
<tepsipakki> yes, a sec
<tepsipakki> 420174
<tepsipakki> 420177 is the nvidia one, but maybe there's something else?
<keescook> bryce_: when you make the fglrx conflict, be sure to mention the debian bug #.
<bryce_> ok
<tepsipakki> hmm, seems that the nvidia breakage is partly about the installer
<keescook> yeah, I'm not having any glx issues either.
<tepsipakki> bryyce: you can drop patch 124, the issue has been fixed elsewhere in the GLX code
<bryyce> ok, do you have a reference for that I can show in the changelog?
<tepsipakki> yes, https://bugs.freedesktop.org/show_bug.cgi?id=8537
<ubotu> Freedesktop bug 8537 in Driver/intel "dual head/non xinerama crashes server if aiglx is enabled" [Normal,Resolved: fixed]  
<tepsipakki> that patch was applied to 1.1, and also in feisty where it was not needed after all
<bryyce> cool thanks
<ubotu> New bug: #114892 in linux-restricted-modules-2.6.20 (restricted) "kernel module ov511 does not work" [Undecided,Unconfirmed]  https://launchpad.net/bugs/114892
<keescook> bryyce: how goes your gutsy upgrade?  I'm itchin' to sponsor xorg 1.3  :)
<bryyce> keescook: the first set of upgrades just finished
<bryyce> so... coming along
<keescook> eeexcellent
<tepsipakki> night everyone ->
<bryyce> night tepsipakki
#ubuntu-x 2007-05-16
<bryyce> laptop is still upgrading...  not sure why it's so slow...
<ubotu> New bug: #35157 in linux-restricted-modules-2.6.15 (restricted) "Virtual terminal doesn't display after resume from suspend" [Medium,Fix released]  https://launchpad.net/bugs/35157
<bryyce> keescook, whew finally done
<keescook> bryyce: cool!
<bryyce> unfortunately I noticed my pbuilder wasn't generating .deps...  I'm rerunning it
<keescook> I thought it put them in /var/lib/pbuilder/... somewhere?
<keescook> I have a script "mydpkg" which takes a source package as an argument and prints out the binary packages that are currently installed from that source package.  it's handy for figuring out which .debs need to be installed when testing a build
<bryyce> yeah it should put them in /var/lib/pbuilder/results/ but it was empty when I looked
<keescook> http://people.ubuntu.com/~kees/scripts/mydpkg
<keescook> did it give any errors?
<bryyce> not that I saw, but I lost the output in my scrollback buffer 
<keescook> pbuilder stores its logs somewhere too, doesn't it?  If there was an error, it should have failed at the end too
<bryyce> oh, didn't know that
<bryyce> hmm, mydpkg xorg-xserver returned nothing
<bryyce> ah whoops, xorg-server
<bryyce> xserver-xorg-core_*.deb
<keescook> so that's what that machine needs to have installed from the build.
<bryyce> http://pastebin.ca/490421
<bryyce> keescook: hrm, I'm not sure what's wrong here
<bryyce> oh wait, maybe I do
<bryyce> aha, found them
<bryyce> ok, x came up 
<bryyce> log file looks good
<keescook> bryyce: sweet! so what do "dpkg -l xserver-xorg-core|cat" report?
<bryyce> it reports xserver-xorg-core 1.3.0.0.dfsg-4ubuntu1
* keescook claps
<keescook> \o/
<keescook> okay, so go ahead and create the source.changes file using the "merge-genchanges" script, and dput it to rookery or chinstrap, and I'll get it uploaded.
<bryyce> ok
<bryyce> http://people.ubuntu.com/~bryce/Uploads/
<keescook> bryyce: for the next version, it seems the gtf man page is already in there.  just add a note for the next time you do an upload.
<keescook> also, it seems the genchanges script went crazy (it should have stopped before 1:1.1.1-0)
<keescook> whoops, I mean 2:1.2.0-3ubuntu8
<keescook> oh wait, maybe I can sneak the gtf fix in
<keescook> bryyce: also "fglrx" is not a package.  you can see that with "apt-cache madison fglrx"
<keescook> I think you probably meant xorg-driver-fglrx
<keescook> though I worry, the fglrx thing should probably be super-double-checked
<keescook> actually... I'm so worried, I'm going to back that out until someone with an fglrx driver can check it for us.  :)
<keescook> alright... here goes nothing...
<keescook> you might want to send some email to ubuntu-devel including the notes about the fglrx driver and how to handle it, or ask seb128, etc.  I've uploaded the resulting package minus the fglrx issue since I'm not 100% sure if that's the correct method to deal with it.
<tepsipakki> great, now there are a bunch of packages that can be synced
<ubotu> New bug: #114968 in xorg-server (main) "xorg crashes inaspectately (sorry for my english)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/114968
<bryyce> kees, cool
<bryyce> kees, okay, I'll write up an email to send
<bryyce> good catch with fglrx; I meant to doublecheck that but forgot
<tepsipakki> bug 114982
<ubotu> Launchpad bug 114982 in Ubuntu "Please sync these from Debian" [Undecided,Unconfirmed]  https://launchpad.net/bugs/114982
<tepsipakki> 15 packages to sync
<bryyce> excellent
<tepsipakki> bryyce: what are your plans about xorg (the package)?
<tepsipakki> some of the changes have been merged in debian
<bryyce> well, I was told not to count too heavily on there being an official xorg 7.3 package soon, so I've not thought too much on it
<bryyce> the advice is to focus less on the xorg package itself, and more on the individual packages
<tepsipakki> ok
<tepsipakki> that package happens to hold all the xorg.conf bits :)
<bryyce> ahh
<bryyce> I guess I'll need to dig into it more
<bryyce> btw, I spoke with colin at UDS about git vs. bzr for us
<tepsipakki> what was the outcome?
<bryyce> he said since bzr can't sync from git yet, that it makes most sense for us to use git until that becomes available
<tepsipakki> oh, ok
<bryyce> btw, I've got the xserver-xorg-input-evdev package merged; I need to test it against xserver 1.3 but hopefully should have it uploaded in the next day or two
<tepsipakki> right, there was that one patch from upstream
<tepsipakki> a new version should be coming soon
<tepsipakki> in case you haven't noticed, the new server has a patch by gravity (also applied upstream) which is first in a series to allow dropping bits of the xorg.conf and using sane defaults
<tepsipakki> I guess he's now doing the Driver part
<bryyce> oh cool, yeah I was just looking for a list of what's new
<tepsipakki> after that it should never crash anymore ;)
<tepsipakki> in a perfect world that is
<tepsipakki> "crash" meaning that it can't find the driver
<bryyce> cool
<tepsipakki> so, IMHO; that's the correct way to deal with the bulletproof-x problem
<tepsipakki> s/;/,/
<tepsipakki> I can do the xorg merge
<tepsipakki> to see what changes there are left
<bryyce> ok cool
<bryyce> it's getting late, I'm going to bed
<bryyce> I emailed ubuntu-devel with a notice of the xserver 1.3 upload
<tepsipakki> yeah, good
<bryyce> I think it'll have to get moderated before it gets posted so might be a while before it shows up
<tepsipakki> btw, was it discussed where to put the git repo?
<bryyce> nope
<bryyce> what ideas do you have?
<tepsipakki> well, git.d.o was suggested, but if it's going to be "temporary" I don't know anymore
<bryyce> heya seb128
<tepsipakki> hi seb128 
<seb128> hi bryyce
<seb128> so you uploaded the server update? ;)
<bryyce> yup
<bryyce> well, kees did the actual upload
<seb128> I was going to have a look this morning, sorry I didn't do it yesterday but that was almost end of my work day when you pinged
<bryyce> ah, sorry, no prob
<bryyce> I'd still appreciate a review; it's very possible I missed something 
<seb128> I'll have a look
<seb128> nothing to be sorry about, the best way to get testing is to upload ;)
<bryyce> :-)
<seb128> and only experimented users should use gutsy at the moment anyway
<tepsipakki> hmm, maybe someone should be poked to look at the u-d queue, otherwise it could take a few weeks until that post is accepted :)
<seb128> ask on #ubuntu-devel
<bryyce> tepsipakki: hrm.  Is there another list that would be ebtter to post it to?
<tepsipakki> no that's fine
<tepsipakki> just that the list admin is aware that the post should be allowed through asap
<bryyce> hopefully matt will get to it tonight; I'll check in the morning
<seb128> bryyce: maybe ask Mithrandir if he cans accept it
<bryyce> seb128: ok
<tepsipakki> ok, xorg debdiff here: http:/users.tkk.fi/~tjaalton/dpkg/xorg/xorg.debdiff
<tepsipakki> uh
<tepsipakki> this works better http://users.tkk.fi/~tjaalton/dpkg/xorg/xorg.debdiff
<ubotu> New bug: #114646 in compiz (main) "Just installed Ubuntu, opened up the fancy graphics thingy, crashed. :/ (dup-of: 90850)" [Undecided,Needs info]  https://launchpad.net/bugs/114646
<seb128> tepsipakki: around?
<tepsipakki> yep
<tepsipakki> for a while
<tepsipakki> seb128: ^^ :)
<seb128> tepsipakki: why do you have 2 different lists on https://bugs.launchpad.net/ubuntu/+bug/114982 ?
<ubotu> Launchpad bug 114982 in Ubuntu "Please sync these from Debian" [Undecided,Unconfirmed]  
<tepsipakki> oh
<tepsipakki> the first list is syncable because they depend on xorg-server 1.2.99.x
<tepsipakki> the rest don't have such dependancies
<seb128> hum
<seb128> so they are both syncable?
<tepsipakki> they all should be
<seb128> k
<seb128> tepsipakki: synced everything out of libsm xserver-xorg-input-mouse xfs which having nothing to sync apparently
<seb128> tepsipakki: libsm is uptodate in Ubuntu (already synced)
<seb128> xserver-xorg-input-mouse is 1.2.1 is Ubuntu and 1.1 in Debian
<jcristau> I uploaded xfs today, for some reason it ended up in NEW
<seb128> tepsipakki: same for xfs, 1.0.2 Ubuntu, 1.0.1 Debian
<seb128> jcristau: new binary package likely?
<jcristau> seb128: nope
<seb128> weird then
<seb128> the upload mail doesn't say why?
<jcristau> probably a dak bug
<jcristau> the upload mail says:
<jcristau> (new) xfs_1.0.4-1_i386.deb optional x11
<jcristau> WARNING: Already present in main distribution.
<jcristau> so...
<tepsipakki> right, I missed that from the bug
<tepsipakki> didn't notice libsm got synced already
<tepsipakki> seb128: the new -mouse is in experimental
<seb128> tepsipakki: libsm was a build1 version, they are automatically synced
<tepsipakki> ah
<seb128> http://packages.qa.debian.org/x/xserver-xorg-input-mouse.html
<seb128> [2007-04-16]  Accepted 1:1.1.2-1 in experimental (low) (Julien Cristau)
<tepsipakki> uh, ok
<seb128> xserver-xorg-input-mouse | 1:1.2.1-0ubuntu1 | http://archive.ubuntu.com feisty/main Sources
<seb128> 1.2.1 > 1.1.2
<tepsipakki> yeah :)
<tepsipakki> confusing numbers
<seb128> :)
<tepsipakki> how about acecad, that should be syncable as well
<tepsipakki> oh, its new
<bryyce> morning guys
<seb128> hey bryyce
<tepsipakki> evening bryyce 
#ubuntu-x 2007-05-17
<ubotu> New bug: #24861 in xserver-xorg-video-nv (main) "bios thinks 1920x1200 lcd is 1280x1024 [nv no, nvidia ok]  (dup-of: 5801)" [Medium,Confirmed]  https://launchpad.net/bugs/24861
<ubotu> New bug: #115170 in xserver-xorg-video-intel (universe) "Flicker in VGA out with i810 driver" [Undecided,Unconfirmed]  https://launchpad.net/bugs/115170
<ubotu> New bug: #115179 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/115179
<ubotu> New bug: #115210 in xserver-xorg-video-i810 (main) "[gutsy]  Problems with xserver-xorg-video-i810" [Undecided,Unconfirmed]  https://launchpad.net/bugs/115210
<ubotu> New bug: #115233 in xmore (main) "[apport]  xmore crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/115233
<ubotu> New bug: #115188 in xorg (main) "[gutsy] [regression] [fglrx]  X doesn't start" [Undecided,Unconfirmed]  https://launchpad.net/bugs/115188
<keescook> cool, there's verification of the fglrx bug.  :)
<bryce_> heh
<jcristau> it tries to check the server version, and aborts because it's 1.3 instead of 7.something
<keescook> binary drivers yay
<bryce_> hmm, shouldn't apt have prevented him from installing 1.3 with fglrx?  
<ubotu> New bug: #115259 in xserver-xorg-input-spaceorb (universe) "[Sync request]  Sync xserver-xorg-input-spaceorb  (1:1.1.0-2) from Debian unstable (main)" [Wishlist,Confirmed]  https://launchpad.net/bugs/115259
<ubotu> New bug: #115261 in xserver-xorg-input-summa (universe) "[Sync request]  Sync xserver-xorg-input-summa  (1:1.1.0-2) from Debian unstable (main)" [Wishlist,Confirmed]  https://launchpad.net/bugs/115261
<keescook> bryce_: I removed the conflict since we weren't able to test it before the upload.  I didn't want to needlessly block fglrx unless we know for sure.
<jcristau> I added the conflict in debian for -5
<keescook> bryce_: for xserver-xorg-input-evdev did you run the "merge-genchanges" script?  It seems that you're missing the changelogs in your source.changes file.  If you can fix that, I'll sponsor the merge; it looks fine beyond that.
<keescook> (also, feel free to clean up your Uploads directory of things that have been uploaded)
<keescook> jcristau: yeah, I saw that, but I was feeling cautious -- none of us had hardware to test it with.  btw, I wrote a binary patch for the fglrx driver which seems to do the trick.  (it's a total hack though)  https://launchpad.net/bugs/115188
<ubotu> Launchpad bug 115188 in linux-restricted-modules-2.6.22 "[gutsy] [regression] [fglrx]  X doesn't start" [Wishlist,Confirmed]  
<jcristau> the other option would be to make the server lie about its version
<keescook> bryce_: for xserver-xorg-video-mga, I wouldn't mention what was done to merge with Debian ("Remove Fabio from uploaders")
<keescook> same for "Now depends on xserver-xorg-dev 1.2.0".  There should be a "Remaining changes:" in the first line of the changelog, too.
<keescook> also, check with someone more familiar with x packaging, but I think ${xserver:Depends} should stay, that looks like a Debian change.
<keescook> based on the prior changelog entries, I think the only change is the Conflicts/Replaces for xserver-xorg-driver-mga and the maintainer address
<keescook> also, the source.changes file looks broken (the opposite way).  It should include only those things since 1:1.4.6.1.dfsg.1-0ubuntu1
<jcristau> ${xserver:Depends} is replaced at build time with "xserver-xorg-core (>= foo)" where foo is the version in /usr/share/xserver-xorg/serverminver
<keescook> jcristau: ah! very cool.
<jcristau> i might as well upload -mga with the conflicts/replaces change, if that's the only diff
<keescook> jcristau: From the looks of it, yeah that's the only delta
<tepsipakki> keescook: the fglrx license prohibits distributing a binary patched driver btw, so your hack should do for now :)
<keescook> tepsipakki: yeah, that's why I wrote the script; we can't ship the patched driver, but individuals can try the hack.  :P
<tepsipakki> yep
<keescook> tepsipakki: I looked briefly at your xorg merge, it seems fine to me, but I was going to wait for bryce to look it over too.
<tepsipakki> yeah, no need to rush that
<tepsipakki> I wanted to do it to see what changes there were left
<ubotu> New bug: #44903 in Ubuntu "Turkish Q Keyboard Configuration Error" [Medium,Confirmed]  https://launchpad.net/bugs/44903
<bryce> sorry, my cable flaked on me there for a bit
<keescook> bryce: no problemo.  :)  let me know when your two merges are ready again and I can check/upload 'em.  :)
<bryce> hmm, when I run dput to re-send the merge to rookery it says it's already uploaded
<bryce> ahh
<keescook> it keeps track of what you've dput'd, check the man page, but I think to force it, you want -f
<bryce> I just deleted the *.upload file
<keescook> heh
<keescook> that works too
<bryce> ok the evdev package is up
<bryce> jcristau: are you going to do -mga, or shall I fix up mine?
<keescook> unless there's a rush, it probably makes sense to wait for jcristau's -mga to hit Debian, and then just do a sync request
<bryce> ok cool
<jcristau> bryce: i'll try to do it tomorrow or saturday
<bryce> kees, over lunch I went down to osdl and picked up a kvm and one of the em64t machines -- your old desktop in fact!
<keescook> nice! what'd you end up paying for the em64t?
<ubotu> New bug: #115319 in xorg-server (main) "Cannot switch display" [Undecided,Unconfirmed]  https://launchpad.net/bugs/115319
<bryce> thedac also threw in a pile of kvm cables
<keescook> heh
<bryce> $455
<keescook> decent
<bryce> and $50 for the avocent
<ubotu> New bug: #115320 in xorg-server (main) "Monitor detection fails when external monitor is turned off" [Undecided,Unconfirmed]  https://launchpad.net/bugs/115320
<keescook> seems like 115320 should be rejected, yes?  :)
<bryce> hum
<bryce> this is the "xorg doesn't hotplug monitors" issue
<bryce> jcristau: -via and -suncg6 look like they have the same issue as -mga
#ubuntu-x 2007-05-18
<bryce> keescook: I've read through timo's xorg patch, and I didn't see anything to complain about, although this is still newish to me so some of the changes I don't have a good feel for
<keescook> cool.  tepsipakki: hey, you're core-dev now aren't you?  upload whenever you're ready, I guess.  :)
<bryce> keescook, I notice in the nv driver that debian made a change outside the debian directory (adding some codes for GeForce 8500 and 8600 cards), but there's no record of the change in the changelog
<bryce> is there anything special I need to be doing here?
<keescook> If they're new changes relative to the prior ubuntu build, I'd mention it in the changelog.  If those changes have been there for a while, I don't think it's worth mentioning (it was accidentally skipped some time ago..)
<bryce> MoM flagged a conflict with it, but I'm not sure why since the debian change seems to simply add 3 lines
* keescook goes to check
<keescook> I think due to the #if/#endif, it make the area unpatchable
<bryce> really? weird
<keescook> I'm just guessing  :P
<keescook> what I _really_ don't get is why it blew up on src/g80_ddc.c
<bryce> it did?  I didn't see that file mentioned in the REPORT
<keescook> http://merges.ubuntu.com/x/xserver-xorg-video-nv/REPORT
<keescook>   C* src/g80_ddc.c
<keescook>   C* src/g80_display.h
<bryce> ahh, I was looking at DaD; it must be behind
<keescook> oh, ignore DaD.  Now that MoM is working, just forget DaD ever happened.  :)
<bryce> ah ok
<bryce> wow, haven't seen C* before
<keescook> that means it's an unresolvable full-file conflict.
<keescook> but, like I said, I'm not clear on why...
<bryce> yeah, those seem like pretty minor differences
<bryce> I'm a little mystified where those came from though; both MoM and DaD were listing the same debian version, yet DaD didn't have this conflict
<bryce> oh I see, Dad was using 1.2.0 as the base, whereas MoM used 1.2.2.1
<keescook> wild, this merge is pretty confused in general.. the debdiff is showing all kinds of weirdness
<bryce> greaat
<keescook> I'm digging through it, and hopefully I should have a clean example for you in a moment...
<bryce> ok cool
<keescook> ah, the reason for the C* is because upstream took both patches, which made it hard to sort out which was "right" debian or ubuntu.  :)
<keescook> bryce: okay, I've got nv merged.  do you want to work on your copy and compare notes, or do you want me to upload this and show you my resulting debdiff?
<bryce> upload and show me your debdiff
<bryce> meanwhile I've been looking at xutils-dev, which looks clean - MoM found no merge issues, so do I just run merge-genchanges, etc. from there?
<bryce> or is this where I run requestsync ?
<keescook> if it's a clean merge, MoM should have generated a .patch file that shows the differences
<bryce> yup, just changelog entry and control file
<bryce> (I'm not entirely sure why it didn't just automatically merge it)
<keescook> if the only diff is the maintainers field, then you can do a requestsync
<keescook> because even a clean merge needs humans to describe the remaining delta between debian and ubuntu, and sometimes a clean merge won't actually build.
<keescook> (for example, when patches in debian/patches were taken upstream)
<bryce> no, it also adds Conflicts: and Replaces: lines
<keescook> in that case, I'd see if jcristau is interested in adding that, and then wait for it to appear in Debian do a requestsync from there.
<keescook> in a perfect world, no merging will be needed because Debian and Ubuntu will always be on the same page.  :)
<bryce> ah ok cool
<keescook> bryce: http://people.ubuntu.com/~kees/xserver-xorg-video-nv_2.0.2-1ubuntu1.dsc.debdiff
<bryce> jcristau: would you like me to email you this patch for xutils-dev?  Or should I post it to bugs.debian.org?
<jcristau> either post it to the bts or email debian-x@l.d.o
<bryce> ok, cool
<bryce> kees, thanks for the debdiff, looks good, so basically you just created a new 102_ patch?
<bryce> keescook, what did you do about 102-dont-call-nvsync-in-entervt.patch?
<keescook> bryce: yeah, for the changes that were outside of the debian/ and due to seemingly previous ubuntu changes, I revert the change in the upstream, and created a patch to handle it in debian/patches
<keescook> the 102-dont-call was taken upstream, and all its changes are already visible in the source tree
<keescook> 100 and 101 are not, though.
<bryce> ah, ok, I was curious why you numbered it 102_ rather than 103_?  Do we always just number from the last patch present?
<keescook> the convention for the xorg stuff seems to be numbering starting at 100 and going up.  I tend to try and fill gaps where it makes sense.  Since this is the first upload for gutsy and the prior 102 was taken upstream, it seemed sensible to make the new patch 102 again.
* bryce nods
<tepsipakki> all the drivers which need replaces/conflicts have that change done to git.d.o
<tepsipakki> they just need to be released to be able to sync them
<tepsipakki> and -nv and rest; we should only have changes in debian/patches, nothing else
<tepsipakki> of nv; 101 can be dropped
<tepsipakki> it's been implemented upstream
<tepsipakki> the debian changes outside debian/ are git pulls, and should be left as is, imho
<tepsipakki> ..but looking at the diff that's the case ;)
<bryce> heya tepsipakki!  :-)
<tepsipakki> hey bryce 
#ubuntu-x 2007-05-20
<ubotu> New bug: #115698 in xorg (main) "LG L1740PQ monitor resolution not correctly detected" [Undecided,Needs info]  https://launchpad.net/bugs/115698
<ubotu> New bug: #115721 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV in xf86SetDGAMode()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/115721
<ubotu> New bug: #48556 in linux-source-2.6.15 (restricted) "ACPI-0517: ****Error Method parse/execudion failed" [Critical,Fix committed]  https://launchpad.net/bugs/48556
<ubotu> New bug: #111090 in xorg (main) "usb keyboard type as instead of a and qw and zx" [Low,Unconfirmed]  https://launchpad.net/bugs/111090
<ubotu> New bug: #115802 in xserver-xorg-video-intel (universe) "xserver-xorg-video-intel doesn't work with a Macbook" [Undecided,Unconfirmed]  https://launchpad.net/bugs/115802
<bryce> tepsipakki: do you know what the differences are between the i810 driver and the intel driver?
<bryce> is there any reason to still keep i810?
<tepsipakki> bryce: -intel is the new codebase, includes modesetting support and stuff.. apparently it has issues with some chips
<tepsipakki> but hopefully -i810 can be dropped before gutsy is done
<tepsipakki> btw, the xbase-clients split is done, and after I've tested (upgrades) they are uploaded to experimental
<bryce> excellent!
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #115854 in xorg (main) "After installing Ubuntu 7.04 I get an "Error activating XKB configuration." error message" [Undecided,Unconfirmed]  https://launchpad.net/bugs/115854
* Starting logfile irclogs/ubuntu-x.log
#ubuntu-x 2008-05-12
<pwnguin> not free to distribute or not free to modify?
<jcristau> i don't remember
<pwnguin> apparently its' not free Enough
<pwnguin> 7. Claims of Infringement. If Recipient learns of any third party claim
<pwnguin> that any disposition of Covered Code and/or functionality wholly or
<pwnguin> partially infringes the third party's intellectual property rights,
<pwnguin> Recipient will promptly notify SGI of such claim.
<jcristau> that one is nasty
<jcristau> i think we have some code in mesa or the x server under that license, still
<pwnguin> by my reading, all it means is that if ubuntu (or people ubuntu purveys the documentation to) is sued, they have to notify SGI about it
<pwnguin> is it the policy that ubuntu NOT contact SGI in such a situation?
<Q-FUNK> bryce: any objection to getting -geode 2.9.0 into hardy-proposed?
<Q-FUNK> it would close bug #214119
<ubottu> Launchpad bug 214119 in xserver-xorg-video-geode "[HARDY] Koolu W.E. (ION A603) does not detect higher resolution than 800x600" [High,Fix committed] https://launchpad.net/bugs/214119
<bryce> heya
<tjaalton> hi bryce 
<james_w> hi bryce 
<bryce> tjaalton: for bug #211759, do you think it's simply a matter of adding the pci id?  Or is there additional upstream work needed and we should upstream the bug?
<ubottu> Launchpad bug 211759 in xserver-xorg-video-ati "Live-CD (7.10, 8.04) fails to start X server (ATI Xpress 1250)" [Critical,Incomplete] https://launchpad.net/bugs/211759
#ubuntu-x 2008-05-13
<tjaalton> bryce: maybe diff the id's and ask upstream why radeonhd has more
<tjaalton> I'm not sure if -ati refuses to load if the id is not listed, like nv does
<tjaalton> but if yes, then it's probably the reason why it fails to load
<bryce> ok, that's essentially what I did (I posted a patch to add it to upstream)
<tjaalton> just that or all of them?
<bryce> just the one id
<tjaalton> ok
<bryce> I think the answer to all the id's in general is "work in progress".  I asked Alex at XDC about radeonhd vs. ati and he said he hoped to see the two get merged together, but didn't have a feel on when or how
<tjaalton> there are three id's missing from -ati that -radeonhd has
<tjaalton> comparing the versions hardy has..
<tjaalton> right, the current situation is a bit silly
<bryce> it's all due to that atombios stuff
<tjaalton> yep..
<tjaalton> the missing id's: 1002793F, 10027941, 10027942
<tjaalton> bryce: according to radeonhd, 7942 is a RS600 chip
<tjaalton> hah, alex made a proposed patch
<tjaalton> with the three id's that were missing and other stuff
<bryce> awesome
<bryce> hmm, I wondered about if it was a 600 but wikipedia said otherwise.  But alex will know best
<tjaalton> yes, it's confusing that the patch uses both 600 and 690, but I'll trust him :)
<bryce> erf, unfortunately alex's patch doesn't apply against 6.8
<bryce> hrm
<bryce> tjaalton: I uploaded the xserver git tree.  What do you think of the patch in 219424?
<tjaalton> bug 219424
<ubottu> Launchpad bug 219424 in ubuntu-ps3-port "xorg-server wrongly tries to load 'vesa' driver instead of 'fbdev' on PS3" [High,In progress] https://launchpad.net/bugs/219424
<tjaalton> bryce: apparently it works, and doesn't look too scary to me
<bryce> ok, I'll check it in tomorrow unless you beat me to it.  :-)  but bedtime for now.  night.
<tjaalton> night
<tjaalton> damn mini-flu, just in time for UDS
<Ng> what's the deal with i915tex_dri.so?
<Ng> the intel manpage suggests it's new and shiny, but almost never used, and we don't seem to ship it
<tjaalton> libgl1-mesa-dri: /usr/lib/dri/i915tex_dri.so
<tjaalton> so it's shipped, but I don't know which chips use it
<jcristau> it's only used with option legacy3d off
<jcristau> and it's merged with i915 in master
<tjaalton> ah, ok
<Ng> it sounds like it ought to be a good thing, but the manpage says it's defaulted to off for my chipset (965)
<jcristau> 965 uses a different dri driver anyway
<Ng> ah :)
<Ng> oh yes, i965_dri.so. wtg me for not ls'ing that directory ;)
<munckfish> Hi bryce, tjaalton. Re the patches for PS3. I've just been speaking with cjwatson I'm getting an idea now of how best to proceed.
<munckfish> Instead of worrying about Hardy could we get 
<munckfish> these fixes into intrepid first so we can try out on a daily CD build
<munckfish> ?
<tjaalton> munckfish: they are there already, uploaded today
<munckfish> tjaalton: cool! thx
<munckfish> tjaalton: I was looking here http://git.debian.org/?p=pkg-xorg/debian/xorg.git;a=shortlog;h=refs/heads/ubuntu
<munckfish> tjaalton: sorry there are 3 fixes I'm referring to I can only see the crash fix in the repos and the current intrepid release shown on LP
<munckfish> is this what you mean or am I looking in the wrong place?
<tjaalton> munckfish: oh right
<munckfish> tjaalton: ok np having the crash bug is uploaded is a great start
<munckfish> tjaalton: when would you or bryce likely have time to review the other two? (for ref I detailed all here: https://lists.ubuntu.com/archives/ubuntu-x/2008-May/000158.html)
<tjaalton> munckfish: bryce said he'd upload the other patch today, dexconf looks good to me as well
<tjaalton> I'm busy the next couple of days, preparing for fosscamp/uds and some work stuff
<munckfish> tjaalton: ok thx for the info.
<bryce> heya munckfish
<munckfish> Hi bryce how's it going?
<bryce> pretty good...  got distracted by the ssl advisory but am working on your patches.
<munckfish> oh great
<munckfish> thx v much
<mario_limonciell> hi bryce, just wanted to remind you on that white screen bug.  did'nt see any activity wrg to SRUs and what not
<bryce> mario_limonciell: ah sorry, been working through a backlog of requests.  Will get to it soon
<mario_limonciell> thanks :)  
<bryce> mario_limonciell: this was the compiz patch issue?
<mario_limonciell> yeah
<mario_limonciell> bug 160624 i think
<ubottu> Launchpad bug 160624 in xserver-xorg-input-synaptics "synaptics driver disregards some xorg.conf settings" [Undecided,Invalid] https://launchpad.net/bugs/160624
<bryce> ok
<mario_limonciell> nope um
<mario_limonciell> bug 160264 maybe
<ubottu> Launchpad bug 160264 in dell "[nvidia] compiz displays white screen when locked" [High,Confirmed] https://launchpad.net/bugs/160264
<mario_limonciell> yeah that's it
<bryce> mario_limonciell: I am finishing up a couple things for munckfish then will get on that, probably later today
<mario_limonciell> ok
<bryce> munckfish: is there a LP# for the dexconf change?
<munckfish> ah no fraid not
<munckfish> I discovered the problem
<munckfish> while trying to see if I could get dexconf to
<bryce> ok, well there will need to be a LP# in order to SRU it.
<bryce> I'll file one
<munckfish> set explicit driver
<munckfish> ok fine fine
<munckfish> sorry
<munckfish> I should've done it
<bryce> 230091
<bryce> would you mind subscribing to that?
<munckfish> sure
<munckfish> LP 230091
<ubottu> Launchpad bug 230091 in xorg "ps3 platform not detected correctly by ps3" [Medium,In progress] https://launchpad.net/bugs/230091
<munckfish> Ok subscribed
<munckfish> thx for uploading those fixes bryce!
<bryce> munckfish: sure!  make sure to test, and then file sru's as appropriate.  I'll get the xorg changes into hardy-proposed next.
<munckfish> ok sort of don't understand - if you're putting em into hardy proposed
<munckfish> then why am I doing SRUs?
<munckfish> or do you mean SRUs if I find anything else?
<bryce> in order to go from hardy-proposed to hardy-updates, it requires an SRU to be filed
<munckfish> ok I see
<munckfish> so they sit in proposed till I do that
<bryce> exactly
<munckfish> these fixes should be available on the next intrepid live cd build though right?
<bryce> right
<munckfish> perfect
<munckfish> cheers!
<bryce> if that's sufficient for you, we can skip the sru - but let me know
<munckfish> that's sufficient for me to get to a point where we can test installation
<munckfish> but the target is 8.04.1 so I guess I'll file SRUs to get them back into hardy
<bryce> ok cool
<munckfish> what sort of window of time should I leave before 8.04.1? A week or longer?
<munckfish> for filing the SRUs in time I mean
<bryce> expect it to take 2+ weeks for the SRU to go through
<munckfish> ok understood. right I'm off to sleep. See ya.
<bryce> cya
#ubuntu-x 2008-05-14
<tjaalton> bryce: we should probably branch xorg/xorg-server for hardy
<bryce> tjaalton: mm, not a bad idea
<bryce> tjaalton: if you wouldn't mind setting that up and documenting it, I'll try to follow it for future updates
<tjaalton> bryce: sure
<tjaalton> oh right, key-logins on alioth are disabled right now
 * tseliot casts a spell on tjaalton to heal him
 * tjaalton catches the spell and quickly recasts a spell on tseliot to regain his mana
<tseliot> tjaalton: when were you planning to leave for Prague?
<tjaalton> tseliot: arrival at 20:15
<tseliot> ï»¿tjaalton: which day?
<tjaalton> tomorrow
<tseliot> :-/
<tjaalton> it was kinda mentioned on the blog entry :)
<tjaalton> btw, I'll be staying in another hotel
<tseliot> I *should* go on Sunday (if I don't catch a cold)
<tseliot> are you coming???
<tjaalton> sure, cold or not
<tseliot> great. I thought you blogged to say that you were not going to attend the UDS
<tseliot> :-)
<tjaalton> ah
<tjaalton> I'll edit the post
<tseliot> good idea ;)
<Q-FUNK> will anyone have time during UDS to sit down with me and ogra to figure out if we're missing anything to get -geode to autoconfigure successfully both in configless mode via PCI ID matching and in LTSP?
<Q-FUNK> in principle, the X core PCI ID patch, plus the libDDC enabled -geode should fix both, but this needs to be checked.
<Q-FUNK> those differences in how X finds and configures the driver via -configure or via PCI ID matching are still unclear to me.
<Q-FUNK> jcristau had explained them well a while back, but the details faded here, over time.
<komputes> bryce: ping
<bryce> hi komputes
<komputes> bryce: hey there, when you have time can you please take a look at Launchpad Bug #224479
<ubottu> Launchpad bug 224479 in xserver-xorg-driver-sis "sisusbvga USB to VGA device not being detected and automatically configured" [Undecided,New] https://launchpad.net/bugs/224479
<bryce> sure
<komputes> thx man
#ubuntu-x 2008-05-15
<federico3> bryce: ping
<bryce> federico3: heya
<federico3> bryce: quick question - I'm seeing if we can kill resapplet, or if it still needs fixes. So I was looking at opensuse's/fedora's/ubuntu's patches for resapplet --- do you guys ship 0.0.7?
<bryce>  resapplet | 0.0.7+cvs2005.09.30-0ubuntu5 | http://us.archive.ubuntu.com hardy/universe Sources
<bryce> afaik we don't use it for anything
<bryce> federico3: heh, pretty ancient git snapshot at that...
<federico3> bryce: ok, thanks :)
<pwnguin> woo
<pwnguin> new flash
<pwnguin> that doesn't suck at rendering
<tjaalton> hmm? I don't see a new one released
<tjaalton> oh, beta
<tjaalton> no pulseaudio support :(
<tjaalton> fck, yet-another flight delay
<bryce> james_w: I'm baffled why soeren doesn't include the revert dialog.  I've asked but he won't explain what is wrong with it.
<bryce> maybe it's just NIH syndrome?  I don't know
<james_w> yeah, he said it's not the right way to do it, but I'm baffled too.
<james_w> it works, surely that's a good start?
<james_w> are you in Prague now?
<bryce> to be honest I'm rather surprised they shipped without at least some sort of revert capability
<bryce> no, still in portland.  
<james_w> ah
<james_w> I was going to suggest that we find a couple of hours next week to try and get it merged upstream, but that seems unneeded now.
 * bryce nods
<bryce> yeah I don't see much point into putting in more time into the revert dialog until we see what upstream does about it
<james_w> we could reply to his mail asking about the revert dialog again, so that upstream sees it
<james_w> or sees it again rather
<bryce> I thought about that, but I don't really care
<bryce> either they'll come up with something better than our quickie hack, or they won't and we'll continue using our patch
<pwnguin> did they reject the quickie hack?
<bryce> pwnguin: basically
<bryce> but without any explanation why
<bryce> just a cryptic "I want something different"
<pwnguin> hrm. in that case the best you can do is argue that accepting the quickie hack doesnt mean it can be redone later a more acceptable way
<bryce> pwnguin: I'm sure soeren knows that quite well
<bryce> pwnguin: I have to imagine he dislikes the idea of taking contributions from his distro's competitor ;-) ;-)
<pwnguin> redhat?
<pwnguin> redhat developers seem to believe no ubuntu developer actually writes code. when i mentioned displayconfig-gtk arlied got pretty upset
<bryce> yeah
<bryce> heh, I didn't know about that - what did he get upset about in particular?
<pwnguin> i said ubuntu wrote a display configuration thing and he was like NUH UH
<bryce> yeah the meme out there is that ubuntu never contributes upstream, so when we try to do it, they seem to freak out
<pwnguin> it wasnt anything in particular, except perhaps his own ignorance of history
<pwnguin> i'd have to dig the conversations out of my nouveau logs
<pwnguin> i might not even have logs of it =(
<Ng> remember to remind redhat guys with that attitude that one of our guys wrote their *init* ;)
<Ng> or if you're feeling more offensive, that while they might bring code to the table, we bring relevancy and users ;)
<Ng> bryce: thanks for the triaging of terminator event bugs, just pushed the patch into trunk. need to see if I can sneak some things like that in as SRU
<bryce> Ng, heh
<Ng> I find myself agreeing with murrayc a bit here - I'm upstream and I'm quite sure we can fix a bunch of bugs without regressing, and I would like to do so rather than leave people with the bugs for up to 3 years :/
<bryce> yeah
<bryce> sometimes I think it would be nice to have two categories for sru's - one for truly important things like the kernel, libraries, firefox, etc. that would trash your system if a bad update got out - and another for less critical end user apps and stuff
<bryce> like, point releases of terminator or inkscape ought to be sru-able. 
<Ng> definitely
<Ng> and I would totally put in the effort to do point releases for that
<bryce> same
<Ng> as it is, there's no point, so I'll just PPA up the next full release
 * bryce nods
<Ng> perhaps there is a case to be made for this to be allowed, particularly for universe stuff, in the LTS point releases
<bryce> yeah with inkscape I'm dragging my feet on doing a point release
<Ng> maybe not so much in the regular 6 month cycle
<bryce> I'm probably going to have to sru each individual patch
<Ng> :/
<bryce> which is a pita and time consuming
<Ng> fancy sounding slangasek out about it? :)
<bryce> might be a good idea.  pitti had some strict principles about it, but steve is good at considering things case by case
<james_w> I'd heard that the policy had been relaxed somewhat recently, but I'm not sure how that applies to point release exceptions.
#ubuntu-x 2008-05-16
<james_w> if gdm has the wrong resolutions how do I go about correcting it?
<tjaalton> james_w: which driver?
<tjaalton> james_w: if it's ati or intel, see http://wiki.debian.org/XStrikeForce/HowToRandR12
<tjaalton> III.5. Forcing a preferred mode
<james_w> intel, it's fine in gnome. Thanks.
<james_w> I messed it up somehow while testing the xrandr capplet.
<tjaalton> heh, ok
<tseliot> ï»¿tjaalton: did the travel go well?
<tjaalton> tseliot: 3,5h extra waiting for the plain, other than that yes
<tseliot> at least you had the connection there
<tseliot> internet connection
<tjaalton> straight flight helsinki->prague
<tjaalton> ah :)
<tseliot> lucky you
<tjaalton> 3G
<tjaalton> laggy as hell
<tseliot> for free?
<tjaalton> can't understand why there is no free wlan
<tjaalton> fixed-fee paid by my employer
<tseliot> your employer rocks :-)
<tjaalton> but roaming here would be expensive
<tjaalton> something like 10e/MB
<tjaalton> well, we get toys..
<tseliot> how can we connect at the UDS?
<tseliot> do we have to pay?
<tjaalton> no, Ng and elmo has built a free wlan here
<tjaalton> :)
<Ng> not me!
<tseliot> yay!!!
<Ng> Spads is on UDS duty this time
<tjaalton> Ng: oh, you are not here?
<Ng> tjaalton: nope :(
<tjaalton> too bad :/
<Ng> yeah, it's a shame, but it would be unfair for one sysadmin to get all the UDS trips
<tjaalton> oh righ
<tjaalton> t
<tseliot> we'll have no connection in our rooms but free connection in the conference room(s), right?
<Ng> the UDS conference space is always flooded with free ubutu wifi love
<tjaalton> I'm not sure.. maybe the hotel has it's own free access points or wired
<Ng> I'm not sure what the hotel room arrangements are, but you may find that someone has brought an AP and is re-broadcasting something else
<Ng> otherwise, find Claire Newman (clan) and ask her, she is the organiser
<Ng> she will know what the options are
<tseliot> Ng: ok, thanks
<tseliot> I will contact Claire Newman since "Iï»¿'ve been arbitrarily picked for UDS Crew duties" too ;)
<tjaalton> crew duties.. you get to fix the ip-phones? :)
<tseliot> no, I'll have to kick people out, etc. therefore if you act up I'll have to kick your a** :-P
<tseliot> I think I'll be on duty on ï»¿Wednesday
<tjaalton> heh, ok
<tseliot> ;)
<tseliot> ï»¿tjaalton: another thing. What's the weather like in Prague?
<tseliot> I would like to know what to put in my luggage
<tjaalton> tseliot: gray
<tjaalton> haven't seen any rain yet
<tseliot> tjaalton: cold?
<tjaalton> +15-20 maybe
<tjaalton> http://www.traveliana.com/prague-weather.html
<tseliot> ah, ok, I guess that short-sleeved t-shirts would be ok then
<tjaalton> oh, +16 shows my panel
<tjaalton> yes
<tseliot> ok. Any need to use firewalls at the UDS?
<tjaalton> na
<tjaalton> h
<tseliot> ok, perfect
<tseliot> thanks again
<tjaalton> well, I don't know how malicious the attendees are :)
<tjaalton> but now that Ng is missing you should be safe :=P
<tseliot> hehehe
<Ng> ;p
#ubuntu-x 2008-05-17
<bryce> hmm, bug #230350 seems broke
<ubottu> Launchpad bug 230350 in python-iplib "Missing Debian Maintainer field" [Undecided,Fix released] https://launchpad.net/bugs/230350
<bryce> wow, between fdo being borked up, and people.ubuntu.com slow, and plus the ssl madness, my versions page is really not good
<bryce> aha, ok this is finally looking accurate - http://people.ubuntu.com/~bryce/Xorg/status_current.html
<pwnguin> why are there bugs targeted for milestone 5?
<bryce> pwnguin: I put the input-hotplug ones there since I think it may take that long to get input-hotplug in place
<pwnguin> is input hotplug targeted for 5?
<pwnguin> or 4?
<bryce> it should be completed before milestone 5
<pwnguin> cool
<pwnguin> today's historical quote of the day
<pwnguin> [03:25] <jldugger-tablet> yes. i hear it works with USB hotplugging or something
<pwnguin> [03:25] <mjg59> Through indescribably ugly hacks
<pwnguin> [03:25] <jldugger-tablet> does debian's package really suck or something?
<pwnguin> [03:26] <mjg59> We'll have input hotplug for feisty
<pwnguin> [03:26] <mjg59> And be able to avoid this
#ubuntu-x 2008-05-18
<rzr> hi
<rzr> bryce: are you busy now at UDS ?
<rzr> bryce: I was wondering if you started to publish ati driver snapshot ?
<rzr> back
<tseliot> tjaalton: I'm in Prague (Corinthia towers), where are you?
#ubuntu-x 2009-05-11
<federico1> tseliot: ping
<federico1> tseliot: did you have a chance to test http://bugzilla.gnome.org/show_bug.cgi?id=572876 again?
<tseliot> federico1: pong
<ubottu> Gnome bug 572876 in plugins "gnome-settings-daemon does not load the saved RandR configuration" [Normal,Unconfirmed]
<tseliot> federico1: I haven't tested it recently but last time I tried to get a clue about what failed I didn't find anything useful
<federico1> tseliot: ok - if you can still reproduce it, please ping me and we'll go through it
<federico1> I basically want to see what errors out in gnome-rr
<tseliot> federico1: ok, I think I can do some tests tomorrow
<tseliot> I'll let you know
<federico1> thanks!
 * apw wonders if bryce is about ... wanted to talk about mtrrs ....
<bryce> yep
<bryce> apw: ask away
<apw> bryce, ok i am having trouble maintaining mtrr's for the AGP aperture ... the i915 driver installs one at load and wants to remove it at module unload time.  however the xserver seems to eat the mtrr on exit.
<bryce> apw: yeah, have you see the bug report about this?
<apw> bryce, looking at the debug produced by testers it is looking like the server is trying to install and remove mtrrs every login/logout
<apw> for the xserver?
<apw> bug #314928 is the one i am working
<ubottu> Launchpad bug 314928 in linux "[i915GM] MTRR entry gets removed when restarting xorg - causes corruption on ttys" [High,In progress] https://launchpad.net/bugs/314928
<bryce> right, bug 314928
<apw> heh so yeah seen that, thats the one i am trying to sort out but the xserver
<jbarnes> should probably be a GEM check around the mtrr fixup in the 2d driver then
<bryce> ok :-)
<apw> is mangling my mtrr, and worse seems to be doing so even it was not it that installed it
<apw> as i would expect it to install and remove one if it was going to do so
<apw> but it seems to fail to install one, but then does remove one
<bryce> ok, I know very little about the mtrr handling
<apw> jbarnes, possibly yes.  though the upstream code seems to install the mtrr for both all i915 loads
<bryce> jbarnes: is it the driver that should be doing the check or the server?
<apw> i am not partiucally worried if x wants to manage the mtrr, its just that x is doing half the job right now
<apw> and removing the mtrr and failing to put it back on restart, which might mean the install code is broken
<jbarnes> right it should be either all kernel or all userspace
<apw> and fixing that may be sufficient
<jbarnes> apw: you mean pre-gem i915 drivers do it too?
<bryce> seems to be in i830_driver.c
<jbarnes> bryce: I think the 2d drivers do it through pciaccess/X calls
<apw> i more mean that the newer drivers are doing it always whether gem is enabled or not, and that is where we are moving towards here
<jbarnes> right ok
<jbarnes> yeah seems like it was just an oversight from when gem was added
<bryce> jbarnes: can we just undef HAS_MTRR_SUPPORT during configure?
<apw> i was back porting mtrr fixes from upstream as we have no mtrr by default in jaunty
<jbarnes> bryce: I think it would be better to just add an if (pI830->memory_manager) or similar check
<apw> but i am thinking that is an error, and its xorg which is broken in that it should be enabling the mtrr
<apw> indeed from the bug it appears it is trying and failing, perhaps i should be fiddling kernel wise but we should jsut
<apw> find out why X fails to insert it
<apw> * i should not
<apw> as jbarnes is correctly saying one or the other needs to own the mtrr for the aperture.  it looks like X thinks it is at jaunty revs
<bryce> apw: ok, sounds like it is an X error
<apw> bryce, it feels like it from outside, but i am perfectly willing to fix the kernel if its broke.  just fixing it isn't helping with X "helping out" too.  so we do need to resolve what is meant to be happening and then plan a fix
<jbarnes> bryce, apw: see https://bugs.freedesktop.org/show_bug.cgi?id=21303 for my patch
<ubottu> Freedesktop bug 21303 in Driver/intel "[i945] acceleration loss when restarting X" [Normal,Assigned]
<bryce> thanks, I'll put that in my ppa
<apw> bryce, let me know when its up and i can try it with my machine, and make sure the kernel is doing samething sane still
<apw> i think we still need some change, if the kernel is maintaining it
<jbarnes> yeah GEM needs it anyway, so the kernel is the right place for it
<apw> yep.  just need the ducks in a line ...
<bryce> posted here https://edge.launchpad.net/~bryceharrington/+archive/ppa - may be a bit before it gets the debs built
<apw> an age no doubt
<bryce> apw: hmm, ppa failed to build the package.  seems there had been a newer version in the ppa at some point or something.
<bryce> apw: it builds fine on my system; are you able to pbuilder or dbuilder it locally?  If not, I could just toss the debs I built up somewhere
<bryce> apw: just let me know if you prefer amd64 or i386
<apw> i am sure i can build it, but if you have .debs' shove them on rookery, amd64 for me
<bryce> (some days I really hate ppa)
<bryce> apw: here you go:  http://people.ubuntu.com/~bryce/Testing/ - grab the ones labeled with the bug number
<apw> bryce, thanks
<jbarnes> bryce: posted a commit id that might fix lp #302227 too
<ubottu> Launchpad bug 302227 in xserver-xorg-video-intel "[i945] Cursor movement, screenshot clipping and redraw problems on dual-headed, Intel 945GME desktop after 20081125 compiz/X update" [Unknown,Confirmed] https://launchpad.net/bugs/302227
<bryce> jbarnes: on it
<bryce> apw: hang on, I didn't do that build properly
<bryce> apw: let me roll some corrected debs
<apw> bryce, no problem, will likely be my am before i get to test them
<apw> just drop me an email when they are done :)
<bryce> apw: http://people.ubuntu.com/~bryce/Testing/
<bryce>   xserver-xorg-video-intel_2.6.3-0ubuntu9.3~bug314928~2_amd64.deb
<bryce>   xserver-xorg-video-intel-dbg_2.6.3-0ubuntu9.3~bug314928~2_amd64.deb (optional)
<bryce> jbarnes: debs with patch posted
<jbarnes> bryce: cool thanks
<jbarnes> seems like I could spend all day, every day fixing bug and still lose ground
<bryce> I feel the same way
<bryce> in fact I think I could spend all day every day just reading and forwarding bugs and never get caught up
<jbarnes> yeah and at least I get to focus on just a couple of packages :)
<jbarnes> heh ouch
<jbarnes> we'll have to drown ourselves in sangria in barcelona
<bryce> well, I mostly have to ignore everything except -intel, -ati, and xorg-server anyway
<bryce> :-)
<bryce> ignoring the other drivers is probably going to end up biting me on the hiney as we move to KMS though.
<tjaalton> why, no-one uses them anyway :)
<bryce> heya tjaalton
<tjaalton> hodwy
<tjaalton> uh
<tjaalton> howdy, rather
<bryce> what's up?  haven't seen ya in a while.
<tjaalton> slowly getting used to the new condo
<bryce> tjaalton: cool, still enjoying the move?  Or have all the homeowner tasks worn you out now?
<tjaalton> and thinking about upgrading my laptop to karmic
<tjaalton> hehe, yes, a lot of space right now, but I don't know how long it'll last :)
<bryce> I put karmic on my laptop, it seems to be going well enough
<tjaalton> there are still a couple of curtain poles to hang, and the lights for the kitchen table :)
<bryce> although haven't updated it recently, so what I got on there is still mostly just jaunty+misc.
<bryce> I'm going to try to do a few merges today, but alpha1 is freezing tomorrow.
<tjaalton> yeah
<bryce> I'd like to see UXA switched on by default, but the quantity of bug reports open against it are worrying me.  I've upstreamed most of them, so am hoping to see progress on them in the next couple weeks, so we can switch over post-UDS.  but we'll see
<tjaalton> well, I wouldn't worry too much about stability in karmic right now, it's a playground ;)
<tjaalton> as long as it's moderately tested..
<bryce> actually I care about it being stable over UDS mostly to avoid a lot of people updating while there, breaking their machine, and coming and bugging me to make it work ;-)
<jbarnes> bryce: maybe we can have people turn it on as prep work for one of the debug sessions :)
<bryce> jbarnes: yep certainly
<tjaalton> bryce: right, that sounds sane :)
#ubuntu-x 2009-05-12
<bryce> tjaalton: you around?
<bryce> tjaalton: I'm trying to sort out how to update libdrm by doing a merge in git, but the directions in X/GitUsage aren't clear
<bryce> hmm, ok nevermind, I'll just do it by hand
<tjaalton> bryce: done already?
<tjaalton> I wonder if most of the libdrm changes could be dropped now
<mikaelhm> Hi, is there anyone good at finde the problem of my X restarting, i have the Backtrace from the Xorg.log?
<mnemo> mikaelhm: what does "lspci -nn | grep VGA" print for your machine?
<mikaelhm> 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon Mobility X1400 [1002:7145]
<mnemo> mikaelhm: do you know some special action that is guaranteed to trigger the crash?
<mikaelhm> no, earlier i had problem with mesa
<mikaelhm> but it is not the same backtrace in the log
<mnemo> paste the stack from xorg.log into paste.ubuntu.com
<mnemo> actually paste your whole xorg.log please :)
<mikaelhm> http://paste.ubuntu.com/170545/
<mikaelhm> oki
<mikaelhm> 2sec
<mikaelhm> http://paste.ubuntu.com/170547/
<mnemo> and when does the crash happen you say?
<mikaelhm> i was writing latex in kile.
<mikaelhm> i have activated Compiz, and some of its features, but i was not using them.
<mnemo> have you restarted the computer since the crash happened?
<mikaelhm> no
<mikaelhm> I just logged in agian
<mnemo> right, so you still have the backtrace in the xorg.log.old then?
<mikaelhm> jep
<mikaelhm> i have made a backup also.
<mikaelhm> jep=yes
<mnemo> please use the command "ubuntu-bug xorg" to open a bug on it (it will attach all the logs automatically)
<mikaelhm> oki, but how should i describe the bug?
<mnemo> just say "-radeon driver segv while editing latex in kile" or something
<mikaelhm> oki
<mnemo> and please install the packages xserver-xorg-core-dbg and xserver-xorg-video-ati in case the crash happens again (if you have these packages installed, the stackframe will be much better with proper function names instead of binary return addresses only)
<mikaelhm> hehe, oki ill install them now.
<mnemo> if the crash happens again and you see similar (but more complete stacktrace in xorg.log.old then find your bug on launchpad and add the improved stacktrace there)
<mnemo> mikaelhm: and paste the LP bug number to me here as well
<mikaelhm> LPB bug numbet?
<mikaelhm> sorry, LP Bug no, where do i find it?
<mnemo> yeah the URL to the bug inside launchpad (the bug you're opening using the ubuntu-bug command)
<mnemo> when you run "ubuntu-bug xorg" from a terminal it will open up firefox with the bug report
<mikaelhm> ahh, i didn't notisfy that...
<mikaelhm> 2 sec
<mikaelhm> what to fill in the 
<mikaelhm> 	
<mikaelhm> Further information:
<mnemo> skip it for now
<mnemo> you can edit the bug later and it's also to post comments to it, so we can request more info if needed etc
<mikaelhm> oki, I just wrote, you told me to report it :-)
<mikaelhm> https://bugs.launchpad.net/ubuntu/+bug/375414
<ubottu> Ubuntu bug 375414 in ubuntu "-radeon driver segv while editing latex in kile" [Undecided,New]
<mnemo> mikaelhm: ok great, can you attach the output of the "dmesg" command as well please?
<mikaelhm> jep
<mikaelhm> like that?
<mnemo> yes
<mnemo> thanks for the bug report
<mikaelhm> no problem.
<mnemo> mikaelhm: i'd like to see one of data point from you system... can you attach the output of "dpkg -l" as well please?
<mikaelhm> 2 sec
<mikaelhm> mnemo, done :-)
<mikaelhm> mnemo, isn't the card r300?
<mikaelhm> no, i guess thats just me....
<mnemo> im not entirely, sure but wikipedia seems to indicate it's r520? http://en.wikipedia.org/wiki/Radeon_R520#X1300_-_X1550_series
<mnemo> mikaelhm: how old is the card?
<mikaelhm> hmm dunno, its in my T60 laptop
<mikaelhm> oki, i thin its r500
<mnemo> yea, T60 is reasonably new... r300 is like radeon 9600 and stuff like that... was sold around 2003 or so
<mnemo> anyway your bug was previously reported actually
<mnemo> I will mark it as duplicate soonish
<mnemo> some norwegian guy found the same bug in the end april it seems --> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/365074
<ubottu> Ubuntu bug 365074 in xserver-xorg-video-ati "Spontaneous Xorg crash [EXA, radeon]" [Undecided,Confirmed]
<mnemo> but his stack was also partial ;(
<mikaelhm> :-(
<mikaelhm> but i will add a comment, with the backtrace if it happeds again.
<mnemo> yes please do, that would be very useful
<mikaelhm> oki.. i will leave for now. Thx for the help with reporting my first bug :-)
<mnemo> no problem, please keep the reports coming :)
<stgraber> bryce: any opinion on bug 375417 ?
<ubottu> Launchpad bug 375417 in inkscape "inkscape and gimp takes a minute to start when run remotely through X x11 in Jaunty - and inkscape draws slowly" [Undecided,New] https://launchpad.net/bugs/375417
<stgraber> bryce: it makes inkscape impossible to use and gimp is way too slow to start
<mnemo> stgraber: maybe you can try to generate a graph based on the system calls (strace) and see which ones are causing the delay?
<mnemo> this has been done to analyze nautilus startup delays for example
<mnemo> see --> http://www.gnome.org/~federico/news-2006-03.html#login-time-1
<mikaelhm> hey mnemo  i think i just happend again
<mnemo> mikaelhm: aah too bad (and good) ... hehe
<mnemo> so you got a better stack this time?
<mikaelhm> jep
<mikaelhm> but theres no backtrace in Xorg.0.log.old
<mnemo> so what happened, did it log you out so you returned to gdm login prompt?
<mikaelhm> jep
<mikaelhm> just blink, and then gdm login promt
<mnemo> and no stacktrace in xorg.log and nothing in xorg.log.old either?
<mikaelhm> no
<mnemo> run "dmesg"
<mnemo> anything about segv at the bottom of dmesg?
<mikaelhm> its funny., the xorg.log.old has not been modified since 14:36
<mnemo> for example, my firefox just crashed and at the bottom of dmesg I have this:
<mnemo> [179033.395844] firefox[28705]: segfault at a7bfad6c ip b03e73c3 sp a8ffe390 error 4 in libflashplayer.so[aff70000+96d000]
<mikaelhm> http://paste.ubuntu.com/170596/
<mikaelhm> nop
<mnemo> hmm ok so your xorg segv's doesnt show up in dmesg I guess
<mnemo> mikaelhm: i suggest you activate the apport crash reporter
<mnemo> please run this command:
<mnemo> sudo force_start=1 /etc/init.d/apport start
<mikaelhm> done...
<mikaelhm> :-)
<mikaelhm> this time i was writing in pidgin,:-p
<mnemo> it will start the crash monitor in the background (the crash monitor tool will be activate until you reboot, if you reboot you just manually run this command again because the crash reporter is off by default in the "stable" version of ubuntu)
<mikaelhm> ok
<mnemo> hopefully apport will detect your crash and tell you to submit a new bug report... if it asks, please do open a new bug
<mikaelhm> ok
<mikaelhm> can i put it in bashrc or
<mnemo> yeah sure, that works
<mnemo> well I never tried that myself but I mean.. think it works
<mikaelhm> what about the sudo...
<mnemo> aah, right that requires a password
<mnemo> not sure how to solve that
<mnemo> ..hmm and maybe .bashrc runs once for every terminal you start? that'd be bad I think
<mikaelhm> oki
<mikaelhm> don't mind i just start i every time.
<bryce> tjaalton: it'd be good if you could take a look at the libdrm merge.  The bulk of the stuff we're carrying is nouveau which we'll still need, but there's some intel bits and pieces that could use review.
<bryce> tjaalton: also I didn't commit to git, since I'm not sure how to do upstream+debian merges in git, so you could look at doing that
<apw> bryce, that change to the i915 works for me.  just need to clean up the kernel changes needed and will then write the conclusion in the bug and we can get things pushed
<bryce> ok
<jbarnes> apw: is there an apt source for the vanilla kernel builds?
<jbarnes> for jaunty I mean
<apw> nope.  ppa's just get all pissed off if you have more than one thing of the same source package in them
<jbarnes> oh lame
<apw> yeah its annoying
<apw> though they are also massive
<superm1> apw, cant you just append a ~jaunty1 and ~karmic1 etc to the source package version and it would be fine?
<apw> no cause one or other is still newer
<superm1> apw, we end up doing that for weekly mythbuntu builds of mythtv -fixes and -trunk and the PPAs appear to handle it sanely
<apw> and that deletes the binary packages for the previous one
<superm1> oh right
<apw> to put it a different way, yes we could have jsut the latest one in a ppa and we don't and we prolly should
<apw> as we wanted them all available for testing
<jbarnes> yeah a 'latest' ppa with just the last -rc or something would be helpful
<jbarnes> older ones can always be downloaded by hand, e.g. for bisection
<jbarnes> I just wanted one because I'm trying to narrow down a boot failure
<tjaalton> bryce: sure thing. what do you mean by "upstream merge"? there shouldn't be any git-pulls from upstream
<mnemo> jbarnes: not sure if this is what you need but you can just click the "image deb" for the correct arch from here and install it using gdebi --> http://kernel.ubuntu.com/~kernel-ppa/mainline/ 
<jbarnes> yeah thanks, already grabbed them from there
<jbarnes> and found that the boot failure seems to be generic with 2.6.30ish on my aspireone
<tjaalton> bryce: also, do you have the debdiff at hand, it would help in doing the merge in git
<bryce> tjaalton: sure - people.ubuntu.com/~bryce
<tjaalton> thanks
<bryce> tjaalton: by upstream merge I mean the case where you are not just merging new debian -N, but also pulling in a new upstream version
<tjaalton> ah, well it shouldn't be any different
<bryce> seems this scenario isn't documented in the wiki, and I didn't find it obvious how to do it on my own
<tjaalton> I'll see what happens
<bryce> well, I guess even the -N case isn't explicitly documented, although one section referred to updating against debian
<tjaalton> btw, it seems that hal has been dropped from the desktop seed, but we are the ones pulling it in :)
<superm1> is the only thing left needing hal xorg input stuff?
<tjaalton> superm1: I think so
<bryce> you're kidding
<tjaalton> I'm not sure though
<bryce> oh, wait, they're all moving from hal to that new thing aren't they
<bryce> devicekit?
<tjaalton> the quirks are moved to udev-extras, and the disk stuff to devicekit-disks
<superm1> so what about apps that say needed to rely on hal info to find stuff on the system via hal python interfaces.  are there equivalents made for device kit already?
<tjaalton> no idea :)
<tjaalton> I guess hal will still be around for some time though
<tjaalton> just that I'm not sure what's the way forward
<superm1> yeah. i'll just keep an eye open for what happens when it does disappear
<bryce> I find it ironically humorous
<tormod> bryce: ...that as soon as xorg has adopted it, hal is being ditched?
<bryce> tormod: right
<bryce> tormod: and all the pain we had to go through in switching over to it
<superm1> i dont think there is any devicekit equivalent for input devices yet is there then
<superm1> so it probably will be around a while
<bryce> I suppose now someone will contribute a really spiffy GUI admin tool for configuring input devices with hal, and then right after that someone will switch X from hal to something else
<crevette> bryce: just to inform you, I heard thay upstream decide to drop hal
<crevette> thay -> that
<crevette> decided also
<bryce> crevette: seriously?  Do you have a link handy?
<tjaalton> it's probably going to be replaced by udev rules
<bryce> ideas on a timeframe?  something we need to be worried about for karmic?
<crevette> the plan is to use libudev
<crevette> pitti should know I guess
<tjaalton> bryce: btw, I don't know if 'git pull . debian-foo <tag>' is even supposed to work, but I've used 'git merge <tag>', and it works just as fine even though the upstream version has changed
<crevette> trying to find a link
<tjaalton> bbiab
<bryce> tjaalton: yeah I couldn't get that to work.  Tried a bunch of permutations.
<tjaalton> ok, I'm to blame here, so fixing it in a minute :)
<tjaalton> bryce: https://wiki.ubuntu.com/X/GitUsage?action=diff&rev2=20&rev1=19
<bryce> tjaalton: thanks... I *think* I may have tried that too, but it failed.  Possibly my tree wasn't clean at the time or something
<tjaalton> first you need to rebase to origin
<bryce> do you mean by doing `git checkout -b ubuntu origin/ubuntu`?
<tjaalton> no, git rebase origin/ubuntu
<tjaalton> when you are in the local ubuntu branch
<bryce> tjaalton: the docs ought to include that step then, I'd never think to do that ;-)
<tjaalton> 'checkout -b foo origin/foo' would create a local branch, and would fail if foo already exists
<tjaalton> heh, ok I'll add it
<bryce> tjaalton: btw, I've merged/syncreq'd most of the outstanding X packages
<tjaalton> sometimes just doing 'git pull' works
<tjaalton> nice
<bryce> tjaalton: the input stuff is left to do, plus xorg/mesa/xorg-server
<bryce> guess xorg/mesa/xserver can wait until after UDS
<tjaalton> yeah
<tjaalton> bryce: ok, the wiki is now updated
<tormod> I think you should look at mesa soon
<tjaalton> tormod: you'd like 7.5?
<tormod> tjaalton: right :)
<tjaalton> figures ;)
<tormod> it could need some testing and is already past RC
<bryce> tormod: I'm starting to lean in the direction of "needs some more testing" != "ready to put into archive" ;-)
<tjaalton> s/more //
<bryce> heh, even worse
<tormod> karmic is playground isn't it?
<bryce> yes-ish
<tjaalton> OTOH, upstream has changed the meaning of the versions.. 7.5 isn't a dev-snapshot anymore, it'll have bugfixes as 7.5.x
<tormod> upstream already starts to comment in bug reports "this should be fixed in 7.5"
<tjaalton> we'd probably want 7.6 for karmic if it's released in time
<tormod> in that case we should definitely start using 7.5
<tjaalton> hopefully it'll have r6/7xx support, and the radeon-rewrite branch
<bryce> alright, well if either of you feel like doing the merge, go for it.  Probably post-alpha1 since we're frozen at the moment.
<tjaalton> of course
<bryce> mainly my concern is this
<bryce> it's good for upstream to get widespread testing feedback on rc's
<tjaalton> I'll ask on #debian-x if it could go to experimental as well
<bryce> however users are going to do this by filing bugs through us
<bryce> we simply don't have the manpower to forward those bug reports up to them in a timely manner
<bryce> meanwhile, we get buried under more bug reports :-)
<tjaalton> we need to keep the devel version unstable enough to keep the random-joe out ;)
<bryce> I would rather see users test rcs in a ppa (like edgers) on an opt-in basis and report problems directly to upstream, so they get the feedback more swiftly
<bryce> for stuff where upstream says "fixed in 1.2.3", to just update our bug's title to include "(Needs 1.2.3)", so when we pull in that released version, we can easily close all the bugs
<bryce> however, I'm still kind of mulling all these thoughts about
<tormod> yes, there seems to be plenty of people trying out PPAs, and the most eager are also those who would report upstream themselves
<bryce> I suppose to follow the logic through, we'd need some kind of an xorg-proposed ppa or something for putting rc's and pending package updates
<bryce> which seems like a bit extra overhead, not sure
<bryce> we've had good luck and results from xorg-edgers though
<tormod> isn't karmic = proposed ATM?
<bryce> xorg-proposed-proposed ?  ;-)
<tormod> we don't need something between xorg-edgers and karmic IMO
<bryce> certainly we're early enough in development that it's probably not a huge deal, esp. for mesa which we know is going to get many updates and a couple releases before we're through
<bryce> I guess it depends a lot on how desperately we need the fixes it contains, and how vigorously we plan to follow up on bug reports
<tormod> I am just thinking we will get the bug reports anyway, but better have them now 5 months before release than 1 month before
<bryce> but I'm reminded of the situation we went through with -intel in jaunty, where we merged it in fairly early on, and just got buried under bug reports
<tormod> minus the ones being fixed "by themselves"
<tjaalton> bryce: but that can't happen anymore <g>
<tormod> bryce: I think that tells more about intel than of early merging...
<bryce> perhaps
<tormod> of course, we save bug work by waiting, but we don't do our community duties
<bryce> I just think if we got a >little< bit more testing before sticking it in the archive, we could have had a better chance of making a better choice there
<bryce> community duties?
<tormod> helping upstream
<bryce> I think that's orthogonal though - if we have fewer bug reports about Ubuntu, we'd have more time to do upstream work / toolsmithing / etc.
<tjaalton> bryce: sure, I'll upgrade to karmic and test every package that it works somewhat before uploading
<bryce> mm, on the other hand, I guess we could get better about reverting things once they start accumulating a lot of bugs
<bryce> I'm not sure reverting -intel would have gained anything in the end really, but we've typically been more of the "damn the torpedo's, we'll fix the bugs as we go", which ends up with a lot of work to do late in the release
<bryce> tjaalton: unfortunately IIRC both you and I tested the -intel upload and didn't see the problems.  I think I did not test on compiz (I never saw problems until turning on compiz).
<bryce> anyway, hope I'm not sounding to ranty :-)
<tjaalton> and I didn't think the slowdown was critical
<tjaalton> :)
<bryce> heh, me either but seems we were in the minority ;-)
<tjaalton> x11perf --aa10text became faster though
<tjaalton> threefold
<bryce> tjaalton: fwiw, lately I've noticed a lot of the remaining perf/freeze bugs are being reported by kubuntu users, so I've wondered if Qt is misbehaving with X somehow
<bryce> I found a bug where the KDE upstream was lamenting that Ubuntu moved to the newer Qt since it wasn't as well tested and was expected to have problems (corruption, etc.) so I wonder if some of this is an outcome of that
<tjaalton> I've heard about that too
<tjaalton> too bad I have to maintain both DE's..
<bryce> yeah, we need another X guy from the Kubuntu side of things
<mnemo> to avoid uploading things with completely "unknown" quality we could create a "about-to-be-merged-version" that we then test ourselves by checking a finite set of core use cases / scenarios that we feel any upload _must_ pass... it would be a table with "core use case" on one axis and "chipset" on the other axis... if we offer a finite and fairly small todo list like that we could probably get more people to complete this sanity test
<mnemo> imo the focus for karmic should be to get kms, uxa and radeon-rewrite in a good state for the LTS... i'd rather have some mayhem now and then get something rock solid for the LTS
<bryce> that is a good point
<bryce> mnemo: certainly for 10.4 I think an "about-to-be-merged-version" ppa could be of value
<bryce> for karmic, I guess tormod is right, that it's intended to be a playground, so the extra overhead would slow us down
<tjaalton> yeah
<tjaalton> and it's hard to track all the ppa's
<bryce> at least, up until alpha-5 or so
<bryce> tjaalton: well, presumably we'd use xorg-edgers as tormod says
<bryce> although, I'm not sure about a case where we have 1.0 in the archive, and want to go to 1.1, but xorg-edgers has 1.2~git1234 in it
<tormod> meanwhile, I suggest updating mesa in git, which we'll pick up in xorg-edgers, and ask for testing there until alpha-1 is out
<tjaalton> very well then ;)
<bryce> sounds fine by me
<tjaalton> libdrm git merge pushed
<tormod> by the time we get really conservative and consider a released 1.1, a "proposed" PPA would make sense, since xorg-edgers should stay on the edge
<tormod> (referring to Bryce's example above)
<tormod> mnemo: radeon-rewrite = mayhem :)
<mnemo> hehe :)  bring it on
<mnemo> (my main machine is intel)
<mnemo> ;>
<Sarvatt> phew, fix for the no dri on intel in mesa 7.6 the past few days finally got fixed
<tormod> mnemo: you have mayhem enough on intel from what I hear
<tormod> Sarvatt: btw what's the status of the 102_dont-vblank patch?
<Sarvatt> that was me updating at 5 am and canceling auto-xorg-git after changelog update to edit it and it not having reverted 102 before, when i looked at the source it was patched but i didnt realize that till after
<Sarvatt> was planning on fixing it when i got home, just got done with 7.6 and doing 7.5 now
<tormod> Sarvatt: 5 am :)
<Sarvatt> yeah, bad idea to update mesa at 5 am, of course things go wrong and i end up staying up an extra hour or two :D
<Sarvatt> ya missed all the fun with dri being broken on intel and fixing the libglew1.5-dev conflicts while you were on vacation! :D
<tormod> Sarvatt: you can wait for tjaalton to update ubuntu/origin now :)
<tormod> *origin/ubuntu
<Sarvatt> tjaalton,:you know about mesa shipping libglew headers in 7.5+ to build demos now so a change is needed for mesa-common-dev.install right?
<Sarvatt> that darn glxew.h gets installed and causes a conflict without changing it since it calls usr/include/GL/glx*.h in the .install
<tormod> bryce, does blender (the menus) work on your radeons? blender was always good for testing since it uses OpenGL exclusively
 * bryce fires it up
<bryce> oops, not installed... standby
<tjaalton> Sarvatt: nope
<tjaalton> Sarvatt: I mean, no idea
<bryce> tormod: seems to work ok
<tormod> bryce: which card? on stock jaunty?
<bryce> 01:00.0 VGA compatible controller: ATI Technologies Inc RV535 [Radeon X1650 Series] (rev 9e)
<bryce> yes, stock jaunty; I've not upped to karmic yet
<jpds> Hey, does anyone here have any experience with Wacom?
<tjaalton> some
 * tjaalton wishes for a intuos4
<tjaalton> aN
<jpds> This was the original error I was getting: http://paste.ubuntu.com/170946/
<jpds> I've managed to fix it, GDM starts, it just doesn't recognize the keyboard and mouse.
<tjaalton> remove it from xorg.conf
<bryce> apw: for bug 314928, is that going to be fixed kernel side, or should I push the patch jbarnes suggested into -proposed, or?
<ubottu> Launchpad bug 314928 in xserver-xorg-video-intel "[i915GM] MTRR entry gets removed when restarting xorg - causes corruption on ttys" [Critical,In progress] https://launchpad.net/bugs/314928
<jpds> tjaalton: I did, now it's not recognized.
<jbarnes> bryce: that one has to be fixed in the 2d driver
<tjaalton> jpds: ok, then I'd like to see the lshal output, and the logfile
<jpds> I even tried dpkg-reconfigure xserver-xorg
<jpds> tjaalton: One sec.
<jbarnes> bryce: have you received test results for it?
<bryce> jbarnes: no not yet
<bryce> jbarnes: apw made a comment that it worked for him, but I was a little unsure what that meant we should do
<bryce> jbarnes, apw: anyway, if we want to push this to -proposed I've got it packaged and am good to go, I just need a go ahead from both of you that this is the right solution
<mnemo> tormod: fwiw, i have an old ATI machine with a radeon 9600 (r300) and karmic... and there the menus look fine
<jpds> tjaalton: New log: http://paste.ubuntu.com/170960/
<jpds> tjaalton: For some reason HAL can't seem start up.
<tjaalton> jpds: you've disabled it in xorg.conf?
<tjaalton> just move the whole file aside and restart gdm
<jpds> tjaalton: I did that too, not recognized.
<tjaalton> jpds: so start hal? X doesn't do that
<bryce> jbarnes: do you think bug 370292 is a dupe of 314928?
<ubottu> Launchpad bug 370292 in xserver-xorg-video-intel "[i855] Jaunty - X freezing on intel 855GM - MTRR issue (UXA/EXA)" [Undecided,Confirmed] https://launchpad.net/bugs/370292
<jpds> tjaalton: Weird, all fixed now.
<jpds> I wonder why dbus wasn't starting on boot the other times.
<jbarnes> bryce: sounds different
<tjaalton> jpds: heh, ok
<jbarnes> the mtrr thing should just cause a big slowdown but not a hang
<bryce> ok
<Sarvatt> are you using karmic jpds? there was a dbus problem all day yesterday screwing up hal that got fixed last night
<mnemo> Sarvatt: is it safe to run update manager normally in karmic now?
<Sarvatt> yup
<Sarvatt> unless you're on kubuntu that is :D
<mnemo> nah im not
<Sarvatt> good to see the progress bar works in KMS usplash now with 2.6.30-rc5
<tjaalton> usplash works with kms?
<Sarvatt> yup
<Sarvatt> it always has, only the progress bar didnt work before
<tjaalton> ok
<tjaalton> I'll defer the new mesa until "later", it has a truckload of conflicts with the previous version, just like I feared
<Sarvatt> if it helps any the changelogs have what we have to do to build it on here https://launchpad.net/~xorg-edgers/+archive/ppa
<tjaalton> it could, thanks
<tjaalton> just merging the upstream branch is painful, like with every major mesa release
<Sarvatt> --disable-egl in the confflags-[dos] targets, making the glx*.h change in mesa-common-dev.install and disabling patches 02 103 104 106 are the only things needed really after merging debian from origin/ubuntu 
<mnemo> bryce: once intel 2.7.1 is out we're gonna put it into X-Updates right?
<bryce> yes
<mnemo> just wanted to confirm
<mnemo> thx
<mnemo> bryce: what should put in title for a bug that's fixed in 2.7.1 and later... suffix with "(needs intel 2.7.1 or later)" or do you have some specific string you search for?
<Sarvatt> another bug I'm hitting on -intel UXA now in 2.7+ - font corruption when the system starts swapping. I didn't notice because I dont usually use a swap file :(
<bryce> (needs intel 2.7.1) is good
<mnemo> Sarvatt: interesting.. i've never seen that either (but I have 8gb of ram) however I've seen many people with old intel chipsets talk about such corruption... I guess those boxes tend to have less ram as well so their are more likely to swap
<Sarvatt> http://bugs.freedesktop.org/show_bug.cgi?id=21415
<ubottu> Freedesktop bug 21415 in Driver/intel "corrupted layout with intel-2.7.0 and xorg-1.6.1" [Normal,New]
#ubuntu-x 2009-05-13
<mnemo> Sarvatt: btw, you should get some sleep..  :)
<maxb> Can anyone point me at any documentation which explains how X gets its xkb_layout these days? Since today's hal upload ceasing to deal with keymaps in favour of leaving it to udev-extras, my X no longer picks up the "gb" layout for my system and defaults to "us" instead
<Sarvatt> i'd be interested in knowing that too, i have to customize my layout because i use a gateway bios from a clone of this aspire one and i can't just change the acer hal fdi to match Gateway anymore
<maxb> Why a Gateway BIOS in an Acer, ooi?
<Sarvatt> acer limits the number of backlight brightness levels in their bios
<maxb> ah, ues
<maxb> *yes
<Sarvatt> gateway one is the exact same thing minus that part because they never used the panels with flickering problems at the lowest levels
<Sarvatt> i get 30 minutes more battery life with the gateway one :d
<maxb> I have a flickery one unfortunately
<maxb> Though I'd still like to have the option of the lower brightnesses
<Sarvatt> i do too, otherwise I would use the acer bios because it only blacklists the flickery one from the lowest levels
<Sarvatt> flickering during hdd access is a small price to pay for 30 minutes more battery life :d
<Sarvatt> http://macles.blogspot.com/2009/03/brightness-table.html#comments
<Sarvatt> oh good, looks like libdrm is getting updated to 2.4.10 and adding drm_intel_bo_disable_reuse that might fix that swapping/font corruption problem
<bryce> mnemo: btw, there's a technique I use in launchpad when asking questions - if the bug is already set to 'Incomplete', I move it to 'New', and then 'Incomplete' after asking my question.  This resets the "without reply" toggle on the bug
<bryce> mnemo: it is a hassle, but by doing this it makes it easier to do a search for "Incomplete with response" bugs to see ones that the reporter (or some me-tooer) has answered
<bryce> unfortunately launchpad is not smart enough to realize when us triagers comment on an Incomplete bug, it doesn't count as a "response" :-)
<Sarvatt> bryce: I build -intel 2.7.1 final release here using your 2.7.0 debian instead of merging debian's like we do on edgers incase you want to copy it to x-updates https://launchpad.net/~sarvatt/+archive/sarvatt-graphics
<Sarvatt> so it's got all of the patches except 119_drm_bo_unreference_needs_null.patch which is already in 2.7.1
<bryce> Sarvatt: ah, excellent thanks
<bryce> probably I should do the merge using the official tarball
<Sarvatt> oops, forgot to change the commit id it was based on in the changelog. ah well, wanted to rebuild it against the new 2.4.10 drm anyway
<bryce> ok, 2.7.1 packaged and in process of building:  https://edge.launchpad.net/~ubuntu-x-swat/+archive/ppa
<bryce> once it's built and a couple people verify it's good to go, I'll move it to x-updates
<tjaalton> upgraded to karmic, now reboot..
<tjaalton> hmm, wrong layout
<Sarvatt> have you guys considered backporting http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_4_branch&id=63cde0ea0e2bc85005136c353c363777488804d2 to jaunty's mesa?
<Sarvatt> re: bug 359392
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/359392/+text)
<tjaalton> haven't seen it before, but looks sane
<Sarvatt> i was just looking over https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/359392 again and have seen they backported that patch to all the branches
<ubottu> Ubuntu bug 359392 in compiz "[i965] X freezes starting on April 3rd" [Undecided,In progress]
<tjaalton> it's just a matter of workflow management
<tjaalton> I'd like to put these in a git branch (ubuntu-jaunty for instance) where such fixes can be staged and uploaded to a ppa or -proposed
<jpds> Sarvatt: No, this was a hardy -> intrepid -> jaunty upgrade.
<apw> bryce, hey ...
<apw> it seems that your test version of x does seem to have changed behaviour on mtrr for the better, but it still seems to remove the mtrr ...
<apw> 2:2.6.3-0ubuntu9.3~bug314928~2 is installed
<apw> by w
<bryce> apw, ok, that's good... is there removed mtrr's causing further problems I take it?
<apw> it seems to still badly interact with the kernel, as in it still removes the mtrr on exit
<apw> i see this both for logout and for guess session exit
<apw> it is better in that for a rather more invasive kernel patch which adds and removes the mtrr on vt switch the mtrr does survive with your new xserver.  but the viable patch to add and remove mtrr at load/unload still gets broken by it
<bryce> hrm
<apw> [  203.861744] Pid: 3553, comm: Xorg Tainted: G        W  2.6.28-13-generic #44~
<apw> lp314928apw5
<apw> that is the process which is calling the ioctl ... 
<bryce> what is the "viable patch"?
<apw> the clean backport of upstream behavour is to add and remove the mtrr at load/unload time.  the patch matching the further normal semantics is the one i am looking at as viable
<bryce> ahh
<apw> the other was a bodge i did to see if i could get round things the xserver was doing, doing it at enter/leave vt time.  but that seemed to get hurt by the xserver also fiddling at VT switch time
<bryce> ok, so either there is another bit of code removing mtrr's, or the code I if'd still gets called in some circumstances
<apw> your change i _think_ has removed the vt switch fiddle, but perhaps not the exit fiddle
<apw> yeah something like that
<bryce> would it help for me to add some debug comments on each call so you can sort out which is being called?  or have you been able to sort that out via gdb?
<apw> i've been tracing it with kernel debug thus far
<bryce> (or maybe it'd be obvious if I skim through the code for similar mtrr stuff)
<apw> but we can try it pretty easy as it exhibits on guess sessions too, so its not sooo iintrusive to test
<hyperair> anyone familiar with the issue of intel's gpu driver leaking memory like a bloody sieve?
<apw> which version?  kernel memory?  what workload?  many of us are using intel successfully
<bryce> apw: hmm, the driver seems to call i830_fixup_mtrrs in just the one place
<bryce> apw: there's mtrr code in the xserver which I wonder about
<apw> in the generic part you mean?
<bryce> yeah
<bryce> I grepped "mtrr" in the xserver core and it spewed a bunch of stuff, but then jbarnes pointed us at this patch so I ignored it.  But now I wonder if it's worth looking at.
<jbarnes> bryce: was my patch not sufficient?
<jbarnes> I think with libpciaccess the server won't mess with mtrrs anymore
<bryce> jbarnes: no apw says he's still getting mtrr's removed, although it's considerably better
<jbarnes> hm
<bryce> apw: do you get any messages "Removing bad MTRR range" or "Failed to remove bad MTRR range"?
<apw> yeah its definatly happening less often.  i beleive it was happening at vt switch into another x-server and is not now
<apw> bryce, in Xorg.0.log ?
<bryce> yes
<apw> nothing about mtrr at all in there
<bryce> hmm
<bryce> well, from what I understand of the code, if the -intel driver is removing MTRRs it should be printing at least one of  those messages
<bryce> so if it's not -intel, and if the xserver isn't messing with mtrrs anymore... could it be something besides X doing it?
<jbarnes> I think the mtrr code removes any ranges set by the process when it exits
<jbarnes> iirc
<bryce> by mtrr_remove_offending() ?
<jbarnes> I was thinking the kernel
<bryce> ah
<jbarnes> yeah, I *think* when the mtrr file gets closed or the process exits its additions will be removed
<jbarnes> unless some other process added them too
<apw> jbarnes, i am seeing an explicit removals occuring via an ioctl on the mtrr control file, i added a warning to the kernel and it logged the Xorg process as culprit
<jbarnes> oh ok
<jbarnes> with the intel driver huh?
<jbarnes> the only place in the server that should hit that path is xf86MapVidMem, which we don't use anymore afaik
<apw> perhaps its time for a version with some explicit debug in that routine to tell us if it is called
<apw> just in case somehow my machine is mad and still using it somehow
<apw> bryce, so what do you think?  perhaps a bit of debug in userspace might help here?  am able to test here
<jbarnes> apw: if you have debug symbols, gdb could help too
<jbarnes> set a breakpoint on the setWC callback and backtrace
<jbarnes> or in one of the mtrr fns
<apw> jbarnes, ok i think bryce did make some dbg ones
<bryce> yep, you'll want -dbg's of both -intel and xorg-server
<apw> hrm i think i only have the -intel one
<bryce> xserver-xorg-core-dbg specifically
<mnemo> bryce: -intel only prints those two messages to xorg.log if it tried to delete the mtrr but the operation failed
<mnemo> well no sry.. the first one should have been in the xorg.log
<mnemo> nevermind
<bryce> right
<tjaalton> huh, Xorg uses 100% cpu but everything seems to work
<mnemo> tjaalton: on what gfx card? and what is it doing if you sample stacks with gdb?
<tjaalton> mnemo: intel, karmic
<tjaalton> can't use gdb since there's no other machine to ssh from
<tjaalton> but I remember hearing something similar recently
<mnemo> i've a bunch of -ati bugs for jaunty with constant 50% or 100% cpu (i guess the 50% cpu reports are for dual core users etc)
<mikaelhm> mnemo, hi. Remember me:-)
<mnemo> mikaelhm: yea, did you find a proper stacktrace yet?
<mikaelhm> nop, it just happend again (first time today)
<mikaelhm> there is nothing in the log
<mikaelhm> but.
<mikaelhm> When i look in the dmesg
<mikaelhm> I see this http://paste.ubuntu.com/171815/
<mikaelhm> and when i booted up I got this apport bug thingy-dingy
<mnemo> yea thats like another bug probably
<mikaelhm> Sorry the program "firefox" closed unexpe
<mikaelhm> it said...
<mnemo> mikaelhm: whenever something crashes, just send bug reports using apport.. doesnt matter if its pidgin or firefox or whatever.. they can often be useful for us
<mnemo> mikaelhm: also, in some rare cases gfx driver bugs can also show up as application crashes
<mikaelhm> should it be a new bug or related? I'm new to bugreporting.
<mnemo> when it's a new program, always file a new bug
<mikaelhm> oki
<mikaelhm> it says, firefox chrashed in SIGSEGV in pthreaths_mutex_lock
<mikaelhm> but i'll report it.
<mnemo> please do
<mikaelhm> Could not upload report data to crash database:
<mikaelhm> <urlopen error The read operation timed out>
<mnemo> that's because canonical cant run their servers properly :(
<mikaelhm> I could only cancel it
<mikaelhm> :-(
<mnemo> it happens quite often with firefox because the debug dumps are so big that the server times out... i've filed a bug about it to the LP team but they havn't fix it yet
<mnemo> this happens only for firefox crashes though
<mikaelhm> ok
<mnemo> so for those you might want to consider checking the checkbox "reduced report" (and not "complete") because that one works and it still gets us a stacktrace
<mikaelhm> but how to report then? just manually,, or? can i get apport again?
<mnemo> mikaelhm: if you want to re-submit the firefox that just happened you can look in /var/crash and then double click the .crash file that has firefox in the name (and select "reduce report" this time)
<mikaelhm> cannot select reduce report
<mnemo> strange.. why not? is that option grayed out?
<mikaelhm> there is no option.
<mikaelhm> damnit
<mikaelhm> about 95% done
<mikaelhm> there is only a ratio butten for complete report (106mb recommended) but its grayed out
<mnemo> mikaelhm: when you click the .crash file you should see this --> http://temp.minimum.se/apport.png
<mnemo> if you cant select "reduced report" then you probably can't report this bug unfortunatly.. :(
<mikaelhm> i only see this http://i-dyllen.dk/apport.png
<mnemo> ah, strange.. ok so then this bug cannot be submitted
<mikaelhm> mnemo, cannot or might not, if i try several times will it work, i dont no the report bug,
<mnemo> at least i've never managed to submit one of those, but I didn't try a lot of times..
<mnemo> the bug that prevents this bug from being submitted is this bug: https://bugs.launchpad.net/malone/+bug/357907
<ubottu> Ubuntu bug 357907 in malone "+filebug is timing out when processing large blobs" [Undecided,Confirmed]
<mikaelhm> I think I managed it.
<mikaelhm> no, this time the webpage gave me a timeout error
<mikaelhm> https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+filebug/fuAN2CdKMInjhg7HGPiB7uPlNkV?field.title=firefox+crashed+with+SIGSEGV+in+pthread_mutex_lock()
<tjaalton> ok, got a backtrace from my hung xserver
<tjaalton> well, not hung but cpu-hungry
<tjaalton> hmm backtrace wont do, need to use a profiler
<mnemo> tjaalton: so what did the backtrace say?
<tjaalton> mnemo: nothing of interest, because the server works
<tjaalton> something is just eating resources
<mnemo> WaitForSomething ?
<tjaalton> yes
<mnemo> i guess "info threads" also says just one thread?
<mnemo> afaik X is always single threaded
<tjaalton> sigh, profiling made easy.. not!
<mnemo> which one did you use?
<tjaalton> trying oprofile
<mnemo> i've never tried it myself but I heard they use sysprof in #intel-gfx sometimes
<tjaalton> ok, trying it
<tjaalton> "in kernel"
<tjaalton> right, thanks
<tjaalton> not very helpful
<mnemo> sysprof can split that up as well I think
<mnemo> but then you need kernel debug symbols installed first
<tjaalton> sigh^2
<tjaalton> don't think they're apt-gettable
<tjaalton> ah, found it
<mnemo> tjaalton: cool, what package was it?
<tjaalton> mnemo: no I mean found the ddebs
<mnemo> tjaalton: where did you get them? i'd like to try it as well..
<tjaalton> ddebs.ubuntu.com
<tjaalton> apt-get doesn't seem to work though
<mnemo> tjaalton: was that a replacement kernel with debug info or was it added debug symbols for the existing normal package? (i.e. like how -dbgsym works)
<tjaalton> just the symbols
<mnemo> they dont even seem to have symbols the stock jaunty kernel in there... i just find 2.6.28-12 in http://ddebs.ubuntu.com/pool/main/l/linux/  but im still on -11 (maybe -12 is in proposed?)
<tjaalton> I dont think sysprof is meant for debugging the kernel
<tjaalton> it still doesn't split it up
<tjaalton> great, opreport doesn't work
<tjaalton> needs a rebuild
<mnemo> tjaalton: did oprofile give you anything yet?
<tjaalton> mnemo: not yet
<tjaalton> need to learn how to use it first
<tjaalton> bah, opreport doesn't work, and doesn't build
<tjaalton> so that's it then
<tjaalton> huh, I can't suspend.. grr
<Sarvatt> i just started getting this too yesterday tjaalton, are you on karmic too?
<tjaalton> Sarvatt: yes
<tjaalton> the hotkeys don't work, and the applet only has logout
<Sarvatt> systems too darn slow to do anything when it happens, takes about 3 minutes for the VT to come up but I'm on a slow atom cpu :D
<Sarvatt> yep no suspend/hibernate on my faster-user-switch applet either, hotkeys are screwy too since the change to udev-extras
<Sarvatt> been a rough last few days for karmic
<Sarvatt> i get a devicekit battery fully charged notification every time i plug ac in too no matter the charge level
<mnemo> bryce: ping?
<mnemo> i was going to ask you if you've seen any like this before? --> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/376220
<ubottu> Ubuntu bug 376220 in mesa "package libglu1-mesa 7.4-0ubuntu3.1 failed to install/upgrade: package libglu1-mesa is already installed and configured" [Undecided,New]
<bryce> mm
<bryce> looking
<mnemo> its my mesa SRU so im a bit paranoid
<mnemo> its probably nothing
<mnemo> it was copied from proposed to updates today
<bryce> guess would be that it's a foss-vs-proprietary issue
<mnemo> how so?
<bryce> wait, no
<mnemo> the log doesnt actually show any error for mesa so I was thinking it might be a bug in apport
<mnemo> because those ttf fonts seem to fail
<mnemo> and maybe then it gets the package wrong?
<bryce> 2009-05-08 11:00:47 ERROR -1: Malformed status line.
<bryce> maybe an error in sources.list?
<mnemo> i think the malformed status thing could be a bad reply from sourceforge when its wgetting the proprietary fonts
<bryce> ok
<mnemo> my other theory was that maybe he tried the mesa upgrade from proposed and so thats why he already had it
<mnemo> but if apport triggers on that then i guess i should have seen something like it before
<mnemo> anyway, its probably nothing
<bryce> yeah not sure
<mnemo> im going to sleep now so.. 
<mnemo> i hope this doesnt blow up overnight :)
<bryce> night mnemo :-)
<mnemo> nn bye
<bryce> tjaalton: do you know if we need mdetect for anything anymore?  Isn't that no longer needed with dexconf, etc.?
<bryce> if not, we can just sync -vmmouse from Debian I think.
#ubuntu-x 2009-05-14
<bryce> guess it doesn't hurt to keep it for now
<bryce>  I've updated this page to latest http://people.ubuntu.com/~bryce/symptoms_intel.html
<jbarnes> bryce: wow you've put a lot of work into that
<bryce> well, at least my scripts put in a lot of work ;-)
<jbarnes> heh
<jbarnes> I see we won't have any shortage of topics at uds
<bryce> actually Geir and mnemo and others have been working hard getting the appropriate tags added
<jbarnes> cool
<bryce> I did run a script that looks for obvious things like "freeze" or "corrupt" in the subject and add those tags
<bryce> jbarnes: one thing we need to get figured out is whether to target -intel 1.7, 1.8, or 1.9 for karmic
<jbarnes> right, we can talk about that
<jbarnes> to kms or not to kms
<jbarnes> ok back to the bbq
<bryce> cya
<tjaalton> bryce: it needs vmmouse_detect from mdetect
<bryce> tjaalton: debian has a hal tool for this now it seems
<tjaalton> checking
<bryce> but I think it hurts nothing to retain mdetect, if we think it's still necessary
<bryce> I suggested the person attempting the merge doublecheck with you
<tjaalton> oh right, the driver includes vmmouse_detect now
<tjaalton> so the dep can be dropped
<tjaalton> the hal callout script uses that, but the version in jaunty didn't include vmmouse_detect.c, so the dependency was added
<bryce> http://people.ubuntu.com/~bryce/symptoms_ati.html
<tseliot> bryce: are you still there?
<tseliot> maybe it's a bit late there
<tseliot> tjaalton: ping
<tjaalton> tseliot: yo
<tseliot> can you sponsor this fix, please? https://bugs.launchpad.net/ubuntu/+source/libxi/+bug/373711
<ubottu> Ubuntu bug 373711 in libxi "_XiGetDevicePresenceNotifyEvent can't be used from C++" [Medium,In progress]
<tseliot> the last debdiff is the right one
<tjaalton> the version is wrong, SRU's should use -xubuntux.1
<tjaalton> s/x/X/g
<tjaalton> otherwise, sure
<tseliot> aah, -1ubuntu1.1 ?
<tjaalton> yes
<tseliot> ok, let me correct the debdiff
<tseliot> tjaalton: done. Thanks again :-)
<tseliot> pitti is going to review the SRU today
<tseliot> tjaalton: BTW are you going to the UDS?
<tjaalton> tseliot: unfortunately not, didn't fit the schedule
<tseliot> :-(
<tseliot> so there will be only 2 X guys at the UDS...
<tjaalton> and I think I'll miss the next one too, since I'll be in South Korea the first two weeks of November, so even if they don't overlap it's unlikely I'll get to go to the next UDS :P
<tjaalton> you'll manage ;)
<tseliot> South Korea? On a vacation, I hope ;)
<tseliot> hehe
<tjaalton> kind of, a choir competition in Busan
<tseliot> nice
 * tseliot can't sing...
<tjaalton> heh :)
<tjaalton> libxi uploaded
<tseliot> tjaalton: you rock ;)
<tjaalton> I know ;)
<tjaalton> heh
<tseliot> tjaalton: can you upload the fix to karmic, please?
<tseliot> pitti thinks it's better this way
<Sarvatt> i think it might be more complicated than just being fast user switch applet now tjaalton, slowdown started up again every time i use sudo and hal-acl-tool runs
<tjaalton> Sarvatt: it doesn't do that anymore after I removed FUSA from my panel, logged out and back in and added FUSA back
<Sarvatt> i did the same but it popped back up about 12 hours later
<Sarvatt> well I left it removed since I dont need it
<Sarvatt> so weird, i just did a sudo apt-get install acct so i can track down what its doing and after it lagged through installing that it completely stopped doing it again
<Sarvatt> ahh it swapped out a big 400mb chunk at the same time, here comes the intel font corruption :D
<tseliot> tjaalton: did you see my request?
<tseliot> ^^
 * tseliot is sorry about being a pain
<tjaalton> tseliot: ah, right
 * tjaalton doesn't multitask too well ;)
<tjaalton> zsh should tab-complete 'debsign -k...'
<james_w> you can set DEBSIGN_KEYID
<james_w> obviously doesn't help if you have multiple keys though
<tjaalton> hmm, fails
<tjaalton> doing something wrong
<james_w> DEBSIGN_KEYID fails?
<james_w> it's a devscripts option, not an env var
<james_w> took me ages to work that one out
<james_w> % cat ~/.devscripts 
<james_w> DEBSIGN_KEYID=B577FE13
<tjaalton> argh
<tjaalton> :)
<james_w> sorry :-)
<tjaalton> don't be, this is useful :)
<tjaalton> I had that file already with stuff on it
<tjaalton> but didn't remember it
<tjaalton> tseliot: uploaded
<tseliot> tjaalton: thanks again
<tjaalton> oh hmm, forgot the freeze
<tjaalton> Sarvatt: btw, I don't have hal-acl-tools installed, nor can I find it
<Sarvatt> /usr/lib/hal/hal-acl-tool
<Sarvatt> i was hoping it would be something like this bug since its strange every time its happened has been when i was using sudo or gksudo for something, but it isnt  https://bugs.launchpad.net/ubuntu/+source/hal/+bug/361223
<ubottu> Ubuntu bug 361223 in hal "hal-acl-tool crashed with SIGSEGV in polkit_authorization_db_is_session_authorized()" [Medium,New]
<Sarvatt> dont have time to try to narrow it down anymore today, at least it goes long enough without happening rebooting isnt that much of a hassle :D
<tjaalton> right, there it is
<tjaalton> was looking for hal-acl-toolS
<mnemo> bryce: fyi.. I changed the description for the intel freeze test so it recommends .30-rc5 instead of .30-rc2
<bryce> mnemo: alright, thanks
<mnemo> bryce: to facilitate LTS -> LTS upgrades, will it be necessary to fix and SRU all bugs that make X unbootable for intrepid and jaunty? I mean even for stuff like openchrome etc ? I guess so right?
<mnemo> or does it skip right to the new LTS packages?
#ubuntu-x 2009-05-15
<bryce> I'm pretty sure it skips directly to the LTS
<mnemo> mmkay
<pwnguin> heh
<pwnguin> "ubuntu needs to stop shipping new kernels and xorg builds every release"
<pwnguin> http://lunduke.com/?p=429
<bryce> pwnguin: heh
<bryce> pwnguin: of course, would we skip revving xorg for a release, we'd get equally skewered
<bryce> hmm, what if we hadn't revved jaunty
<bryce> today we'd be on xserver 1.5.2-ish, mesa 7.2, librandr 1.2, -intel 2.4.1
<bryce> we could have stuck with fglrx 9.3, which would be nice.
<bryce> ATI hardware would not be as well supported, but Intel stuff could probably have been backported
<pwnguin> oh, the guy is full of crack
<LLStarks> ?
<LLStarks> did i miss something?
<jcristau> no
<pwnguin> LLStarks: nothing X related
<LLStarks> i'm not sure if you guys are following the conversation in #intel-gfx but i was wondering if dri2 swapbuffers even has a shot at making karmic.
<LLStarks> ?
<Sarvatt> LLStarks: I'm about to add jbarnes' cursor flicker patch to edgers in a bit after the new drm builds and everything incase you dont want to build it yourself :D
<LLStarks> i know how to build, but i miss out on all the debian patches.
<LLStarks> also, i posed this question a few minutes and it went unanswered: "i've always been curious as to how good (quality and performance-wise the linux intel driver is when compared to windows or mac. i can understand that windows likes to abandon device support and forces the user to use older drivers. i like how linux drivers are furiously updated on almost a monthly basis."
<LLStarks> any thoughts?
<jcristau> seems pretty obvious that drivers for other platforms are more mature..
<Sarvatt> i havent compared them because i dont use intel video on anything i care about performance on
<jcristau> also get more development effort put into them, since they actually matter.
<superm1> bryce, er intel 2.4 driver /does/ work on jaunty though.  siretart set up a backport on his ppa :)
<superm1> been the only way i could confidently get decentish performance
<bryce> superm1: yep I know
<quentusrex> Ok, what is the best way to check the ram usage of Xorg?
<tjaalton> bryce: sounds like the lunduke guy didn't get the memo
<tjaalton> also, he seems pissed that fglrx dropped support for the old hw, although it's not mentioned
<bryce> tjaalton: link?
<tjaalton> http://lunduke.com/?p=429
<tjaalton> a lot of handwaving
<bryce> ah, right was looking at that earlier
<bryce> wears me out.
<bryce> fscking backseat drivers.
<tjaalton> yeah
<bryce> it's scary when I can just listen to people describe their problem with no mention of the hardware and know what driver they're using
<tjaalton> heh
<bryce> yeah this guy doesn't understand X.org
<pwnguin> indeed
<pwnguin> he could have been much more specific with his hate
<bryce> yep
<pwnguin> three letters
<pwnguin> xkb
<bryce> I don't agree with his assertion that "good Linux software can only be made by well paid developers"
<bryce> I would offer Inkscape as a counter-example.
<tjaalton> bryce: ok to sync -keyboard and drop the hangul hack? evdev is used by default anyway
<bryce> tjaalton: yes, that sounds ok by me
<tjaalton> good, I'm filing the rest that are syncable
<bryce> awesome
<tjaalton> aiptek, suncg3, suncg6, suntcx
<tjaalton> I should merge the input packages next
<pwnguin> bryce: don't worry, inkscape is obviously crap because he says so
<pwnguin> artists need adobe because that's the standard
<pwnguin> i dont even know why you Free Software hackers bother trying
 * bryce snorts
<pwnguin> on the hubris scale, i think this guy takes second place
<pwnguin> the ex-microsoftie who declared ubuntu was violating the spirit of the GPL by forking debian still holds king
<bryce> hehe
<pwnguin> s/holds/is/
<pwnguin> who, by his own logic, debian itself largely violates the GPL spirit
<pwnguin> grammar's not on my side tonight
<pwnguin> he does have a point though; the community college i work for runs a graphic design program that feeds into places like hallmark
<pwnguin> unfortunately, he murders this point by declaring nobody anywhere can avoid adobe
<bryce> yeah, anything that goes "Everyone does foo" ends up just being a straight man for something new.
<pwnguin> bringing peace to the middle east by converting everyone to hinduism
<pwnguin> that reminds me to polish up my Linux Packaging form reply
<bryce> right
<tjaalton> hmm, evdev is syncable
<tjaalton> sorry, isn't
<tjaalton> actually, it is. having an extra fdi file that loads evdev for mice & keyboards isn't harmful, and those can be then dropped from hal
<jcristau> tjaalton: it's probably doable to make debian/rules only install the fdi if(!ubuntu)
<tjaalton> jcristau: yeah, but it might go away later, so it's not a huge deal right now
<jcristau> ack.
<jcristau> is there any replacement for http://people.ubuntu.com/~bryce/Xorg/versions_current.html? that seems to fail.
<tjaalton> hmm, works here
<jcristau> hrm
<jcristau> f*cking firewalling.
<tjaalton> heh :)
<jcristau> works when i work around that.  thanks :)
<tjaalton> I'll merge mesa 7.4.1 and clean up the diff, waiting for 7.5rc2 before working on it..
<tjaalton> +start
<jcristau> 7.4.2 looks like it should be coming soon
<tjaalton> heh, so it seems
<Sarvatt> 7.5rc2 was supposed to be out 2 days ago, was waiting around to update the ppa for it but gave up :D
<tjaalton> 7.4.1-1u1 uploaded
<tjaalton> jcristau: what was the command again you use to check the consistency in the git repo?
<tjaalton> s/in/of/
<jcristau> git clean -dnx
<jcristau> to check if there are no spurious files
<tjaalton> thanks, I'll add it to the wiki
<tjaalton> bryce: seems you have stuff to push to xorg-server git?
<jcristau> there.  Subject: [Mesa3d-announce] Mesa 7.4.2 released
<Sarvatt> there's 7.4.2 like 30 minutes after you pushed it, repeat of intel 2.7.1 right after bryce pushed 2.7.0 :D
<tjaalton> hah
<jcristau> xorg-server's 100_xserver_exa_force_greedy.patch looks weird.  how do you make sure EXA_MIGRATION_GREEDY doesn't conflict with EXA_HANDLES_PIXMAPS?
<tjaalton> sshh, it'll go away
<apw> jbarnes, hiya ... wondering about KMS, i see you are poking that ship quite a bit
<jbarnes> apw: yep, I wrote big chunks of it
<apw> am struggling to find any up to date patches or even discussions on it and wondering what is planned to hit soon and where i might find patches
<apw> so i can eval what might make karmic
<apw> obviously intel mostly hit the tree in .29, wondering about ati etc.
<jbarnes> yeah intel support is in 2.9
<jbarnes> .29
<jbarnes> with tons of bug fixes since it first landed
<jbarnes> 2.6.x was the first 2d driver to really support it
<jbarnes> ati support should be coming in .30
<jbarnes> err .31
<apw> yeah we are tracking for at least .30
<apw> so ati is likely .31 material
<jbarnes> but airlied has a branch he's shipping in F11 with all the ati bits
<jbarnes> so if you ended up on .30 you could take the upstream ati development driver
<apw> is there a a preview branch for the planned ati stuff?  against currentish heads?
<apw> where might i find that ... i need to get my ducks lined up to help make some decision on what we are shooting for
 * jbarnes digs up the urls
<apw> thanks ... that'll make my life a lot easier :)
<jbarnes> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=summary
<jbarnes> the drm-rawhide branch has the latest radeon support
<apw> hmm i poked about in his repo and it all seems 2.6.29-rc based.  which seemed wrong
<jbarnes> yeah he hasn't updated in awhile it looks like
<jbarnes> but I think all you need is the drivers/gpu/drm and include/drm stuff anyway
<apw> yeah i am sure its not beyond me to rebase it should it be neeed
<jbarnes> lemme ping glisse, he might have a tree too
<apw> any idea where the nv supprot is kms wise?
<jbarnes> I know the red hat guys are working furiously on it
<jbarnes> but I don't know what the current status is
<apw> thanks for your help :)
<jbarnes> you might try sending a note to dri-devel too, Jerome Glisse is the main radeon kms guy right now afaik, and Ben Skeggs is the nouveau guy iirc
<apw> cool.  will do that ...
<jbarnes> ah apparently glisse has a kms tree for radeon: git://anongit.freedesktop.org/~glisse/drm-next drm-next-radeon
<jbarnes> http://neo-technical.wikispaces.com/kms-glisse
<jbarnes> http://jglisse.livejournal.com/1822.html
<jbarnes> apw: the things you get when you ask a simple question on #dri-devel :)
 * apw adds that to his list of irc channels
<jbarnes> seems like there's a lot of interest in ati kms so everyone jumped on me when I asked ;)
<tormod> you can find those things on planet.freedesktop.org
<apw> heh i bet there is :)  i am sure we will be shouted at if we don't have it in kk
<tormod> there will be shouting whatever you do
<tormod> I am a bit worried now with all bugs moving into the kernel, will X debugging gets a lot more difficult? will we need serial console to sort out mode problems?
 * tormod didn't try kms yet
<tormod> anyone here understanding MTRR ranges? http://launchpadlibrarian.net/26765241/dmesg
<LLStarks> bryce, you there?
<jbarnes> bryce: btw fix for https://bugs.freedesktop.org/show_bug.cgi?id=21488 is a good one, might be the root cause of the 965 hangs
<ubottu> Freedesktop bug 21488 in Driver/intel "[GM45] [UXA] [KMS] lockup while using opera" [Critical,New]
<rzr> tormod: hi
<tormod> hi rzr
<rzr> tormod: my membership is about to expire and https://bugs.launchpad.net/bugs/189393 is still open :)
<ubottu> Ubuntu bug 189393 in xorg-server "[U1] TV not detected with Radeon IGP 320M" [Unknown,In progress]
<rzr> tormod: i have to track this
<tormod> rzr: membership?
<tormod> rzr: do the Options mentioned in the upstream bug help?
<rzr> no
<tormod> rzr: I suggest following up upstream - they are aware of the problem. make sure you always try latest git, just in case
<rzr> i have the git changelog in my rss feed 
<tormod> I am not there yet, but I check cgit.freedesktop.org quite often :)
<tormod> Sarvatt: did you make that mesa hook? otherwise I'll take a stab on it
<Sarvatt> tormod: sprry. no i didnt
<Sarvatt> sorry too :)
<bryce> tjaalton: pushed.
<bryce> tjaalton: just flipping the debug patch back on
<bryce> we can probably get rid of 100_xserver_exa_force_greedy.patch; we've not been forcing greedy on intel for a while so that patch is obsolete.  besides, -> uxa.
<LLStarks> hey bryce
<bryce> heya LLStarks
<LLStarks> bryce, i'm not sure if you've overheard my interest in seeing dri2 swapbuffers get backported into karmic.
<LLStarks> but i am of the opinion that we shouldn't have to wait until next april to have it in a release.
<LLStarks> i can easily see the requisite code for dri2proto, mesa, xserver and xf86-video-intel making the cut
<LLStarks> the problem will most certainly lie within a decision to use 2.6.30 rather than 2.6.31
<LLStarks> in that case, a backports to 2.6.30 may be in order.
<LLStarks> bryce, what do you think?
<bryce> mm
<bryce> I don't know enough about the patch in particular, but yes I do sense we're going to need a lot of kernel stuff backported just in general, if we're going to make kms work well
<LLStarks> this code will be very desirable if karmic is dri2+uxa+kms
<bryce> LLStarks: can you file a bug with the git url for the thing that needs pulled, so we can keep track of it?
<LLStarks> bryce, the patches in question will allow tear-free output
<mnemo> i guess it will be decided at UDS, but is it more likely at this point that we get .30 for karmic?
<LLStarks> bryce: http://virtuousgeek.org/blog/index.php/jbarnes/2009/05/07/pageflipping_blocking_etc
<LLStarks> the 3rd comment has the requisite bits
<bryce> LLStarks: set a milestone for it and target it to the karmic release.  That will ensure it gets reviewed
<LLStarks> what packages should i file against? all requisites?
<bryce> LLStarks: mm, how about linux and -intel?
<LLStarks> gotcha
<bryce> even though it sounds like there's nothing to do for -intel, it'll help us keep track of it.
<bryce> mnemo: well, I would guess .30 but it's a kernel team decision ultimately, and I think they plan to decide it at UDS
<bryce> mnemo: apw knows about the -ati/.31 stuff so I suspect they'll be factoring into the decision whether to do the backport in .30 or move ahead to .31
<mnemo> ok nice
<bryce> mnemo: I'm also a bit concerned that X bugs are going to be moving into the kernel, which could make them tricky for us to debug, however we've got a good kernel team, so it may be a net win for us
<bryce> mnemo: in any case I'm hoping to chat with with them about bug process
<mnemo> yea its going to be different for sure
<mnemo> i guess no more EDID in xorglog with KMS, heh
<bryce> dunno, maybe; people will still want to xrandr their screen to other rez's
<LLStarks> bryce: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/377090/
<ubottu> Ubuntu bug 377090 in xserver-xorg-video-intel "[RFC Karmic] DRI2 swapbuffers" [Undecided,New]
<tormod> oops already a 7.4.2 regression, fdo #21756
<mnemo> sounds like the whole intel QA team was playing ut2004 ;)
<mnemo> ops no I looked at the wrong bug :)
<Sarvatt> tormod: thats also present in 7.5 and 7.6, have had that problem for awhile.
<Sarvatt> mnemo: you dont get EDID in the log? I do - http://sarvatt.com/downloads/Xorg.0.log.txt
<bryce> Sarvatt: it seems inconsistent.  Some logs have it, some don't.  I haven't figured what makes it show sometimes, and not other times
<bryce> I'd really like to force the edid to always be printed in the log.
<mnemo> yea that'd be nice
<mnemo> im upgrading my intel box to karmic right now and it got hosed big time when I turned on edgers
<bryce> there's a few things I'd like to change about the logs, if I ever get the time
<mnemo> its a G45 though, was that a know issue?
<bryce> like, I'd like it to consistently put the nicely formatted lspci stuff in the log, so we can stop asking people to post their lspci -vvnn
<bryce> mnemo: 'hosed'? sure
<mnemo> yeah doesnt boot at all
<mnemo> i get that "the greeter program crashed, trying another one"
<mnemo> but this is after I added edgers
<bryce> well you'd need to look at your Xorg.0.log and gdm logs to see why it failed
<mnemo> hehe... yup
<Sarvatt> was it kubuntu?
<mnemo> nah
<mnemo> rebooted it again now with no changes and now it started... xorglog says im now 2.7.99 now
<mnemo> I get 4:3 resolution though which is wrong
<Sarvatt> what type of input?
<Sarvatt> vga?
<mnemo> dvi
<mnemo> apport found an intel oops now it seems
<mnemo> bug 377107
<ubottu> Launchpad bug 377107 in linux "WARNING: at /build/buildd/linux-2.6.30/drivers/gpu/drm/i915/i915_gem_tiling.c:320 i915_gem_set_tiling+0x1d6/0x1e0 [i915]()" [Undecided,New] https://launchpad.net/bugs/377107
<mnemo> nothing on fdo for that one
<mnemo> the dmesg keeps spamming "unable to read EDID from VGA-1" ... and i just doubled checked, its connected using dvi for sure
<Sarvatt> ah of course you're on x64
<Sarvatt> i was going to say you might want to try it with the latest drm-intel-next code added to the kernel and i have it here http://sarvatt.com/downloads/2.6.30-5.7/ but didnt build it for x64
<Sarvatt> hopefully that stuff gets pulled into rc6 that should be coming in the next day or two
<Sarvatt> speak of the devil, already did
<Sarvatt> mnemo: http://lists.freedesktop.org/archives/intel-gfx/2009-May/002391.html looks sort of relevant, https://bugs.freedesktop.org/show_bug.cgi?id=21210
<ubottu> Freedesktop bug 21210 in Driver/intel "[G43 KMS] VGA wrongly detected as connected (actually disconnected)" [Normal,New]
<Sarvatt> i can apply the patch and throw the driver up on a ppa if you want to test it
#ubuntu-x 2009-05-16
<Sarvatt> oh what am i talking about, thats a kernel patch :D
<tjaalton> bryce: great, thanks. yeah that patch can be purged now
<tjaalton> bryce: intel; debian-experimental has 2.7.99.1, I'm willing to test that next week
<Sarvatt> might be better off with 2.7.1, 2.7.99.1 snapshot in debian doesnt have any of the updates from 2.7.0 to 2.7.1 that fixed alot of crashes
 * albert23 thinks 2.7.99.1 will break systems where dri is disabled, i.e. because they have width>2048 (it breaks on my 945 in that case)
<bryce> do we have 2.7.99.1 in a ppa?  that probably ought to be sufficient for testing purposes for now
<hyperair> bryce: if you're around, i'd like to bring your attention to the fact that dropping dh_installchangelogs completely in debian/rules ends up forgetting to install debian/changelog to /usr/share/doc/<pkg>/changelog.Debian.gz as well.
<bryce> hyperair: I can't imagine many people care about that??
<bryce> hyperair: anyway, file a bug, we'll look into it when there's time
<hyperair> bryce: i do. i like to keep track of intel's driver progress, but really, i could just drop by launchpad and see
<hyperair> it helps to... erm... increase my despair after having my hopes of a release without the memory leak + performance regression + stability issues thrashed.
<bryce> I'll keep it in mind next time I merge.  upstream didn't put in the ChangeLog with the tarball
<hyperair> yeah i noticed from debian/changelog.
<bryce> sometimes I take the time to generate it myself, but this time was just copying another packager's work who had simply disabled installing it
<bryce> hmm, I have a patch that supposedly should fix all that
<hyperair> well yes, but the point here is that instead of # dh_installchangelogs ChangeLog, it should be just dh_installchangelogs
<bryce> ah good point
<hyperair> bryce: when you mentioend you have a patch that supposedly fixes all that, by all that, did you mean memory leak + performance regression + stability issues by any chance?
<hyperair> =D
 * hyperair has a hopeful look
<bryce> right
 * hyperair looks forward to seeing it in the ppa =)
<bryce> I might post it to a ppa
<bryce> to be honest the behavior of certain people on some of the freeze bug reports has really turned me off from working on it.
<hyperair> i can understand.
<hyperair> but this bug is one hell of a frustrating bug, as i'm sure you know
<hyperair> i'm pretty sure most of the intel gpu users around are facing the memory leak problem at the very least
<hyperair> i don't really mind the hangs. i'm used to them, and they're infrequent enough. but the memory leaks really get on my nerves.
<hyperair> because i end up staring at my unblinking hard disk light for ~5 minutes at a time
<hyperair> and eventually my swap reaches 100%
<bryce> well, this patch probably doesn't fix that
<hyperair> ah. =(
<hyperair> what does it fix then?
<bryce> inadvertent use of unallocated memory
<bryce> which they think may help solve hang problems
<hyperair> that would be a segfault, wouldn't it
<hyperair> i see
<hyperair> that would be a help (but i'd really love to see a fix to the memory leak)
<bryce> I'm going to be tied up at conferences the next 2 weeks, so won't really be working on any bugs myself
<hyperair> i'd love to work on them, but i don't think i'd understand the code.
<bryce> also I need to focus exclusively on DRI2/UXA/KMS stuff going forward
<hyperair> this is UXA stuff.
<bryce> well, understanding code isn't really necessary
<hyperair> the memory leak happens on UXA. and pretty badly too.
<bryce> it's mostly just patching and testing
<hyperair> hmm?
<hyperair> you need to understand the code to write patches, don't you?
<hyperair> unless you're saying that this patch is already upstream.
<bryce> sure, but for the most part the trick is to analyze it from different angles, communicate what you find to upstream, and let them write the patches
<hyperair> hmm
<hyperair> what angles can i analyze it from?
<bryce> well, there's an established collection of tools for analyzing memory leaks
<bryce> so you'd run those, capture their output during leak behavior, and show anything interesting to jbarnes
<bryce> of course, it is also useful to build and test against upstream's git tree
<bryce> just in case there is already a fix.
<bryce> if that works, then it is a matter of doing a git-bisect search to find the patch
<hyperair> hmm, right.
<hyperair> i doubt i could keep X running in valgrind anyway.
<bryce> it's not really hard.  It's a bit technical to learn the first time through.  Mostly it's just kind of time consuming
<hyperair> technical how?
<hyperair> the compiling bit, the git bit, or something else?
<bryce> compiling
<bryce> if you've not done it before
<hyperair> i run enough compilations a day to feel the pinch when my system screws up my i/o.
<hyperair> i.e. swapping like crazy
<hyperair> i'd probably just script the copying of the packaging bits to the upstream bits and then run debuild -b or something similar.
<bryce> yeah that should work
<bryce> probably you'd want to disable most of the patches in the package in that case (comment out the lines in debian/patches/series)
<hyperair> however, considering that the memory being consumed doesn't seem to appear to origin from any processes in particular, and that around 1G of RAM is said to be free (according to free -m, +/- buffer/cache line) when it begins shoving everything into swap and filling it up..
<hyperair> i'd actually reckon a guess taht the memory leaking bits are actually kernel-space.
<hyperair> stuff leaking memory that's actually in xserver-xorg-video-intel would show up as Xorg's memory, yes?
<bryce> definitely a possibility.  -intel has moved a lot of memory management code into the kernel
<hyperair> mmhm
 * hyperair groans
<hyperair> there have been two particular pieces of software i've avoided touching the source code of in the past: X, its drivers, and the kernel (and its drivers). 
<hyperair> frankly speaking, they terrify me, simply because they work on a level i don't understand.
<bryce> there's an easy way to solve that ;-)
<hyperair> O_o?
<bryce> X is not deep magic that people think it is
<bryce> neither is the kernel really
<bryce> there's advanced algorithms and stuff in there, but that's nothing unique
<bryce> a lot of the code is just register poking in hardware
<hyperair> yeah, and that's probably the deep magic part =p
<bryce> if you have the docs that explain what the various registers are, it isn't that deep of magic ;-)
<bryce> anyway, most of the bits I usually have to fuss with to fix bugs is not that complicated of code
 * bryce shrugs
<hyperair> hahah i see.
<hyperair> well the PM parts of the kernel certainly look like deep magic to me =p
<hyperair> i've been messing around with uswsusp recently
<hyperair> the usplash patch that got removed.
<hyperair> just when i thought i fixed it, the 2.6.30rc5 kernel blew it up with a stacktrace.
<hyperair> and i gave up.
<bryce> oh, I didn't notice, the patch I mentioned before is a kernel patch
<bryce> so I couldn't ppa it even if I wanted to ;-)
<crevette> hey good evening (or day)
<bryce> heya crevette
<hyperair> bryce: you could talk to the kernel-team to dump it in the kernel-ppa
<hyperair> well it's not really a ppa, it's a folder on kernel.ubuntu.com
<crevette> I've a small question is UXA activated as the default for karmic now, I owuld like to know if I can remove my xorg.conf 
<bryce> hyperair: nah, not without getting someone to verify it does indeed solve it
<hyperair> crevette: Try It And Seeâ¢
<crevette> (I prefer to remove xorg.conf to stick with default behavior)
<crevette> hyperair: :)
<bryce> crevette: not yet, maybe after UDS
<hyperair> bryce: i could, if you're willing to compile. i'd like to think that my kernel compiling days are over.
<crevette> hyperair: I don't even know how to check if UXA is on or not :)
<hyperair> crevette: grep UXA /var/log/Xorg.0.log
<bryce> hyperair: sorry I have my hands full just building X packages for people ;-)
<hyperair> bryce: i can understand ;)
<bryce> hyperair: also technically I'm supposed to be taking the weekend off ;-)
<hyperair> bryce: do you have a link to that patch anyway?
<bryce> yeah https://bugs.freedesktop.org/attachment.cgi?id=25806
<hyperair> ah right, it's weekend. i forgot people don't work on weekends =p
<hyperair> normal people, thati s
<bryce> heh
<Sarvatt> bryce: that patch is already upstream and in 2.6.30-rc6
<hyperair> =O
 * hyperair wonders when it'll enter the kernel-pap
<Sarvatt> why bother putting it in a ppa when the full kernel will probably be out in the next day or two? 2.6.30-6-7 that is :D
<bryce> Sarvatt: sounds good
<bryce> Sarvatt: scary how many of these "X" bugs are fixed by kernel changes...
<crevette> :)
<Sarvatt> yeah not a good thing for jaunty..
#ubuntu-x 2009-05-17
<bryce> hmm, I've been thinking more about these X-bugs-fixed-by-kernel-changes and how we can track them better
<bryce> so far we've been adding an -intel task in addition to the linux task
<bryce> however I'm wondering if just tagging the linux bugs as "xorg-issue" or some such would be better
<bryce> anyone around to give an opinion?
<bryce> I'll tag them xorg-needs-kernel-fix for now
#ubuntu-x 2010-05-17
<Sarvatt> yay, working now :)
<Sarvatt> ok origin/ubuntu builds fine now on i386, other arches are still waiting for the libxfont rebuilds
<Sarvatt> mind if I make mesa stop building mach64 in git? theres no point to it, needs external drm modules that don't even exist in libdrm git anymore
<Sarvatt> just wasting livecd space :D
<tjaalton> sure
<Sarvatt> RAOF: back from UDS yet? xserver-xorg-video-nouveau needs some lovin pretty badly :)
<bryceh> he's probably recovering from jetlag
<Sarvatt> bryceh: did you get all my messages about UDS? it looked like you didn't get the first on monday since you asked a few days later and i'm not sure you got the second since you signed off after
<bryceh> Sarvatt, no my irc has been real spotty this past week
<Sarvatt> anyone have a description of what exactly libkms is so I can add it to the new package description? :)
<tjaalton> has something to do with vmwgfx
<tjaalton> kms abstraction library or such
<bryceh> http://www.pagetable.com/?p=324
<bryceh>  ^ new logo for -intel?
<Sarvatt> fitting with how broken it's been this week :)
<Sarvatt> going to attempt to fix this accidental epoch in xorg-edgers libdrm.. 
<Sarvatt> things may be broken for a bit :)
<Sarvatt> i'll have to post everywhere telling people to downgrade too, fun stuff
<Sarvatt> worried about leaving it since it's screwing with the symbol versioning, maybe I should just leave it..
<Sarvatt> phew looks like xserver-xorg-video-intel is the only thing screwed up by the bumped epoch libdrm, i rebuilt everything i uploaded since the 12th though just incase
<Sarvatt> scrapped the libkms idea for now, it requires libdrm to build... lol
<Sarvatt> weird, libgl1-mesa-dri-gallium pulls in oprofile
<Sarvatt>   libgl1-mesa-dri-gallium libllvm2.7 libopagent1 llvm llvm-dev oprofile
<Sarvatt> ah llvm-dev depends on it..
<Sarvatt> xorg-server from origin/ubuntu currently brings in nvidia-current...  :D
<Sarvatt> The following NEW packages will be installed:
<Sarvatt>   dkms nvidia-current nvidia-settings xserver-xorg-video-radeonhd
<Sarvatt> and xserver-xorg-core held is back
<Sarvatt> is held back rather
<Bernardo> good morning
<tjaalton> Sarvatt: how's that possible?
<oc13> hi, i am using an old tablet (compac tc1000) with 10.04 installed. 
<oc13> now i want to get the touchscreen working:
<oc13> installed fpit. i works but i cannot configure it.
<oc13> does anyone know what values for maxx and maxy needed to be set in xorg.conf?
<Sarvatt> oc13: man fpit should give you some default values to play with, since you said it installed and worked i'm guessing you're on karmic or older?
<Sarvatt> i uploaded an fpit that works with lucid to the x-updates ppa since the one in lucid/debian doesn't work with xserver 1.7, but some people are having configuration problems with it still
<Sarvatt> wow thats a change, I have to install gallium dri to use GL with xserver master, mesa classic i915 just segfaults all over the place 
<Sarvatt> http://pastebin.com/kNN5MVL0
<Sarvatt> thats odd, SIS doesn't compile against xserver master here because it needs mibank.h thats been removed, but it compiles fine on tinderbox?
<jcristau> tinderbox may have old headers still around
<Sarvatt> had to disable udeb building for xserver master until i have time to look into it, fails like this http://launchpadlibrarian.net/48590426/buildlog_ubuntu-maverick-i386.xorg-server_2:1.8.99.0%2Bgit20100517.345eb171-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz
<Sarvatt> i keep getting into weird situations I can't figure out with the new xserver abi stuff since 1.7.6.901, the breaks make it odd. like tslib needed to be updated in the archive before i could even install xserver-xorg-core even though i didnt have it installed
<Sarvatt> we have an older version in the archive than the breaks: in xserver
<jcristau> Sarvatt: you only get that in the udeb build?
<Sarvatt> yeah
<Sarvatt> disabled udeb works fine
<Sarvatt> builds fine rather
<jcristau> Sarvatt: http://people.freedesktop.org/~jcristau/0001-Fix-build-without-XACE.patch
<Sarvatt> oh nice! will add that and rebuild in a minute when I test this SIS change out to be sure it works. thanks for that jcristau, sorry to bug you with problems all the time! I'm not pointing them out asking for them to be fixed, just trying to get the issues I run across out there :)
<jcristau> yeah.  i should work instead.  but instead i jump on the chance to not work ;)
<jcristau> anyway, sent this one to the list
<Sarvatt> should I just drop the mibank.h header completely or conditionalize it for #if XORG_VERSION_CURRENT >= XORG_VERSION_NUMERIC(1,8,99,0,0) ya think?
<Sarvatt> it builds fine without the header against 1.8.99.0 at least
<Sarvatt> oh whoops I meant <=
<jcristau> i couldn't find anything in the driver that needed that header
<jcristau> so i'd say drop it
<Sarvatt> http://pastebin.com/RNM0ZPqC works, phew.. logs sure are ugly these days though
 * Sarvatt needs to get a MTA set up for git one of these days
<Sarvatt> building the udeb with your patch now
<jcristau> ugly because of the timestamping you mean?
<Sarvatt> yeah 
<Sarvatt> breaks a lot of the driver messages
<Sarvatt> xserver with your patch is building here btw if you're interested - https://edge.launchpad.net/~sarvatt/+archive/xorg-testing/+build/1742884
<Sarvatt> i'll reply on xorg-devel with a tested-by and the details if it works
<jcristau> cool :)
<jcristau> 2 concurrent configure runs makes understanding what's happening quite hard..
<Sarvatt> yeah, for sure
<Sarvatt> it builds quite a deal faster than 1.7.x though even with the extra udeb build since theres no tests
<jcristau> oh you disabled the tests?
<jcristau> i guess it's not very useful to run them for the ppa
<Sarvatt> ../../dix/gc.c: In function 'ChangeGC':
<Sarvatt> ../../dix/gc.c:152: error: dereferencing pointer to incomplete type
<Sarvatt> ../../dix/gc.c: In function 'ChangeGCXIDs':
<Sarvatt> ../../dix/gc.c:439: error: dereferencing pointer to incomplete type
<jcristau> same deal i guess..
<Sarvatt> only in udeb build
<Sarvatt> oh the tests still run? i thought they didn't since it was so fast, guess i didnt look hard enough
<Sarvatt> didnt explicitly disable them
<jcristau> the main build has xace enabled
<Sarvatt> whoops, sorry to spam your mail there, replied to just you there and resent it :)
<jcristau> ok now i've actually tested the build...
<chrisccoulson> RAOF - could you ping me when you're available? i would like to discuss bug 546578 with you at some point
<ubottu> Launchpad bug 546578 in xserver-xorg-driver-ati "black screen after a few user switches" [Unknown,Confirmed] https://launchpad.net/bugs/546578
<Sarvatt> thats related to the fade problem isn't it? :(
<chrisccoulson> Sarvatt, yes. i don't know if there are multiple issues or not, but there's definately a race in lucid thats contributing to some peoples issues
<chrisccoulson> if the VT switches before the fade is finished, then the gamma doesn't get reset
<Sarvatt> its happening on other distros too and not limited to ati
<chrisccoulson> so, i was going to disable fade-on-lock in gnome-screensaver for now (it will still fade on idle though)
<Sarvatt> i've talked to people on arch and gentoo using intel nouveau and ati having the same problem and disabling fade fixed it
<chrisccoulson> but i wanted to discuss with RAOF first. i'm not sure if you have an opinion too though
<chrisccoulson> yeah, i'm leaning towards switching off fading for now
<chrisccoulson> it's a 1 liner in gnome-screensaver
<Sarvatt> have you checked other distros patches by any chance?
<chrisccoulson> not yet
<chrisccoulson> but i imagine they will probably be pretty similar
<chrisccoulson> i see one reporter already posted a patch to one of the bug reports, but i'm not going to do it like that, as that globally disables fade
<chrisccoulson> i still want fading to work on idle ;)
<chrisccoulson> Sarvatt - btw, the nvidia binary driver doesn't seem to exhibit the issue. i can still use xgamma to control the gamma on X servers that aren't on the active VT
<chrisccoulson> although that probably doesn't help much
<Sarvatt> binary drvier uses vidmode gamma fading though not xrandr ramps
<chrisccoulson> Sarvatt - yeah, that's also what xgamma is doing though
<chrisccoulson> both methods fail in lucid
<Sarvatt> chrisccoulson: do you think this is related? I dont understand the patch completely - http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=blob;f=debian/patches/121_only_switch_vt_when_active.diff;h=e35467bf84a2f8327bc907246c92b26b42da19a6;hb=refs/heads/ubuntu
<Sarvatt> i can't find any context on why we have that patch, was added *years* ago
<chrisccoulson> Sarvatt, i'm not too sure really. i don't understand the patch completely either
<Sarvatt> making it bug me even more, arch carries that patch too
<ricotz> Sarvatt, hi, what do you think about copying the kernel to edgers? https://edge.launchpad.net/~ricotz/+archive/unstable/+sourcepub/1137152/+listing-archive-extra
<Sarvatt> i kind of would prefer to wait a few hours and just use the ones straight from maverick if we're not changing any options but go ahead
<Sarvatt> ricotz: btw did you see the notice at the top of the xorg-edgers ppa page? i screwed up and added an epoch to libdrm for a few days and people have to manually downgrade back or it wont update :(
<Sarvatt> keeping the epoch would suck more than that pain IMO so i got rid of it, it screwed up the symbols and stuff
<Sarvatt> ia32-libs might be screwed up by that :(
<Sarvatt> not sure if the update script checks for a newer version and grabs that since the newer one will be older
<ricotz> oh, didnt noticed is, let me look
<Sarvatt> i can upload a new ia32-libs source package, the bandwidth isnt an issue here (got 20Mbps up and no quota)
<Sarvatt> not sure how though, need to look at it
<ricotz> Sarvatt, i have updated the ia32-libs just now
<ricotz> should be fine
<Sarvatt> thanks ricotz, sorry about all the trouble
<Sarvatt> i'm working on xserver master for maverick :D
<ricotz> sounds like trouble ;-)
<Sarvatt> but i'm going to hold off on it for at least a month or two, learned my lesson following master too closely in lucid
<Sarvatt> people actually expect xorg-edgers to work :)
<Sarvatt> chrisccoulson: you know, i should boot up a fedora 13 livecd and see if test-fade has the same problem there
<chrisccoulson> Sarvatt - could do. remember though that test-fade has the additional issue where the buffer if not flushed properly, and the last SetCrtcGamma command never gets to the server
<Sarvatt> theres no way thats related to this problem?
<chrisccoulson> Sarvatt - i'm fairly sure it's unrelated. people could still recreate it even with the fix for that in
<Sarvatt> seems like it could be to me but i dont understand it that well, people saying it happens when you switch users in quick succession
<Sarvatt> ah, test-fade is fixed in ubuntu?
<chrisccoulson> Sarvatt - not yet. i uploaded a test build to my PPA a while ago, but it's not there any more
<Sarvatt> didn't know ya fixed that, i haven't looked since i dont even use gnome-screensaver and just reported the bug to condense a bunch of duplicates
<Sarvatt> ahh ok
<Sarvatt> gnome-screensaver in karmic didn't have xrandr fade right? i know it was upstreamed in november but not sure if it was added in -backports or something
<Sarvatt> or a point release later
<chrisccoulson> Sarvatt, yeah, xrandr fade was only introduced in lucid
<bryceh> chrisccoulson, RAOF usually comes on in about +2 hrs
<chrisccoulson> bryceh, thanks
<bryceh> chrisccoulson, maybe drop him an email in the meanwhile
<Sarvatt> sheesh, put off setting up git send-email for so long and it was so easy :D
<Sarvatt> ricotz: gconf was updated so your mutter ppa works again \o/
#ubuntu-x 2010-05-18
<RAOF> chrisccoulson: Ping.
<Sarvatt> after setting up gimp for the wife i can really understand why that person wanted multiple stylus support back
<Sarvatt> heyo RAOF! nouveau needs your loving if you get around to it, 2.6.34 is in maverick, libdrm is updated without the abi reverts too
<RAOF> Sarvatt: Yeah, I saw that.  Thanks!
<RAOF> Sarvatt: I also see that you're working on xserver master?  We'll want to follow that moderately closely for Maverick - we should start shipping pre-releases in the archive once 1.9 branches off, I think.
<Sarvatt> don't know what you want to do with nouveau so I didn't touch it, could just sync it with debian since they fixed it up to build like the rest of the X packages but it's a big change
<RAOF> Oh, libdrm-nouveau broke ABI, didn't it (without bumping SONAME, bad dogs!).  That's why x-x-v-nouveau's broken.
<RAOF> ?
<Sarvatt> 1.8.1 is merged and builds in git, running into a few dependency problems with it though (it dragged in nvidia-common and x-x-v-radeonhd for some reason..?)
<Sarvatt> yeah, we had it broken anyway since there was a 2.6.34 kernel in maverick that didn't work with the lucid userspace anyway
<Sarvatt> it's like the new dependency system pulls in anything providing xserver-xorg-video-7 or something, I dunno
<RAOF> That seems odd.
<Sarvatt> gradually hitting more and more roadblocks building packages against debian git since they are using the ${xviddriver:Depends} stuff :(
<Sarvatt> error: xserver-xorg-dev >= 1.7.6.901 needs to be installed
<Sarvatt> make: *** [serverabi] Error 1
<Sarvatt> (xserver-xorg-dev 1.8.1 is installed there..)
<RAOF> :(
<Sarvatt> ugh, need to be sure to cc: stable@kernel.org next time I submit a patch obviously meant for stable, trying to figure out how to submit http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8d06a1e1e9c69244f08beb7d17146483f9dcd120
<Sarvatt> btw RAOF - http://pastebin.com/7vjm2Stt
<Sarvatt> (just saw you updated the non root X blueprint)
<Sarvatt> non root vesa patch from meego
<RAOF> matches[i++].  I love statements with side-effects.
<Sarvatt> sheesh meego has a rediculious amount of dri2/glx backports to server 1.8 branch too, everyones just bypassing upstream
<RAOF> Well, wasn't dri2 moderately broken on the 1.8 branch?_
<RAOF> Still...
<Sarvatt> +            } else if ((dev->device_id == 0x8108) || (dev->device_id == 0x8109) || (dev->device_id == 0x4102)) {
<Sarvatt> +		driverList[0] = "psb";
<Sarvatt> +		driverList[1] = "pvr";
<Sarvatt> i guess 4102 = moorestown and the driver name is pvr..
<RAOF> Fun!  More crazy!
<Sarvatt> anyone mind if I delete this patch? it's pointless unless i'm missing something - http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=blob;f=debian/patches/184_virtual_devices_autodetect.patch;h=2b03e929dfc85329eec0be851800fb5ccd32c166;hb=refs/heads/ubuntu
<Sarvatt> probably made sense when we had pci.id files and cirrus matched 1234
<Sarvatt> it's not doing anything though, it's not a cirrus pci id anyway and already defaults to vesa
<Sarvatt> 1234 looks like it's the QEMU stdvga device and not cirrus, the cirrus emulated device actually has a cirrus pci id (0x1013)
<Sarvatt> if you boot with a 1234 pci id device without that patch you get vesa and fbdev, if you boot it with that patch you get vesa vesa and fbdev right?
<RAOF> Sarvatt: From that context, yes.  This seems like something that would be trivial to test to make sure, though.
<RAOF> :)
<Sarvatt> yeah looking into how to set up qemu to test it
<Sarvatt> about to extract all patches from meego's and put them on my server since they dont have any kind of VCS..
<Sarvatt> they have a vesa patch to remove DGA usage that i'm not sure if its needed for non root as well
<RAOF> It clearly isn't - the first patch you posted was âdon't fall back to VESA if we're not rootâ.
<Sarvatt> they renamed -cirrus to -kvm too :D
<RAOF> I don't think we'll actually need that one - the plan was to start X as root, check whether we actually need it, and drop privs if we don't.  Which means we'll only be dropping privs in the presence of KMS, which means vesa's already stuffed.
<Sarvatt> haven't seen this before either, xf86-input-mrstouch for moorestown. says its a combination of plpevtch and evtouch 0.8.8
<Sarvatt> been around for 3 years...?
<Sarvatt> i've never even heard of plpevtch before, it's a fork of evdev
<RAOF> Doesn't evdev basically just forward kernel events up?
 * RAOF hasn't looked at it in any depth.
<Sarvatt> RAOF: were you at the X on ARM session?
<bryceh> there were two, he was at one, I was at the other
<Sarvatt> did you catch what the plans are regarding gles/EGL and different clutter backends and such? 
<Sarvatt> i know we need to start packaging up libEGL for the wayland stuff anyway which I can do in the next few days
<Sarvatt> http://www.imgtec.com/powervr/insider/powervr-vframe.asp - woohoo
<RAOF> Sarvatt: Yeah, we need to start packaging libegl.
<Sarvatt> hmmmmm, EGL_NOKIA_texture_from_pixmap, haven't seen that before
<RAOF> That makes it the second EGL_*_texture_from_pixmap I've seen.
<Sarvatt> and EGL_OES_image_pixmap
<bryceh> oh is libegl required for wayland?  that might be the last piece I'm missing
<bryceh> don't recall that being discussed in the meeting I attended, tho it could have gotten lost amongst all the hand waving
<RAOF> That was the point of krh's mesa branch, wasn't it?
 * RAOF is pretty jet-lagged, so DISCLAIMER: Sense-making is not guaranteed.
<bryceh> I was working from the dx team sprint notes
 * bryceh doublechecks
<Sarvatt> well got a list of what my phone supports on android, http://paste.ubuntu.com/435264/
<bryceh> https://wiki.canonical.com/DesktopExperienceTeam/Wayland
<bryceh> weird, no mention of libegl, but I'm definitely getting errors about it
<bryceh> Sarvatt, ok if you don't get to packaging libegl, I'll take care of it when some of my launchpad work's done
<Sarvatt> yuck, looks like clutter's egl backend is limited to one application at a time, and only works with tslib for input
<Sarvatt> bryceh: how old a snapshot are you using?
<Sarvatt> he's been doing EGL stuff in mesa like mad for the past 2-3 months
<bryceh> the mesa snapshot is pretty recent
<bryceh> the wayland snapshot is from March; seems he's not been doing much there
<RAOF> I'd guess that you could try master; there's a lot of egl commits happening in there.
<Sarvatt> bryceh: packaging names are the only things that have stopped me from doing it for months, i dont want to pick something that isn't going to be used later when debian picks it up :D
<RAOF> Sarvatt: This sounds like a job for Debain Experimentalâ¢.
<Sarvatt> except debian experimental seems to be the new unstable now until squeeze is released :D
<RAOF> But with even less of an implicit support guarantee.
<Sarvatt> libegl1-mesa?
<bryceh> Sarvatt, maybe you could pop a Q on debian-x@, or ask jcristau for a quick recommendation?
<RAOF> Yeah.  That's what I was going to suggest.
<RAOF> I'd also like to ensure that we don't duplicate work on xserver & mesa; we're going to be pretty aggressive on the version front, and I'm going to ask whether working in the debian-experimental branch + syncing would make the XSF happy.
<Sarvatt> well I still need to wrap my head around everything that builds, i'm not sure what the arm people are planning on doing too, like are they going to make libgles-omap libgles-sgx and such with all of the proprietary blob crap and headers for those in -dev packages?
<RAOF> Frankly I'm not totally clear on the ARM driver stack; it seems like a den of madness.
<Sarvatt> for sure
<Sarvatt> libegl is no big deal to add, its the libgles stuff i'm trying to figure out
<bryceh> RAOF, btw in the past a couple times following UDS I'd post to debian-x@ briefly outlining the blueprints that got decided at uds, to solicit debian's feedback on them and make them aware in case they wanted to collaborate
<bryceh> usually I'd do it after I'd finished drafting the blueprints, but in hindsight it's probably better to do it before the blueprints have been written, else it might require extra work rewriting stuff.
<Sarvatt> one package with the libs and egl_dri2.so, one package with the dev stuff (just 4 headers and a libEGL.so), another package with the demos
<Sarvatt> dont know if we need to put libEGL in /usr/lib/mesa though, if the proprietary arm drivers use a different libEGL?
<bryceh> Sarvatt, did the egl_dri2.so, etc. bits use to live in mesa?  that could explain the discrepancy
<RAOF> bryceh: That's a good idea.  I'll prioritise getting that mail out a bit.
<bryceh> RAOF, starting to see why I got into using gtg so much?  ;-)
<Sarvatt> bryceh: they still do
<bryceh> Sarvatt, oh... what does libegl provide then?
<Sarvatt> oh they moved to mesa after you packaged it a long time ago
<RAOF> bryceh: :)
 * Sarvatt looks at the ppa to see whats n there
<Sarvatt> digging up your old ppa
<Sarvatt> libeagle
<Sarvatt> that was dropped and everything moved to mesa
<bryceh> no, I'm referring to this:
<bryceh> <RAOF> Sarvatt: Yeah, we need to start packaging libegl.
<Sarvatt> we never shipped any egl stuff in mesa
<Sarvatt> if we need to ship libegl in /usr/lib/mesa its not really applicable to debian
<Sarvatt> argh
<Sarvatt> the proprietary sdk's do ship egl headers with the same names as the mesa ones and they are different
<Sarvatt> oh nope the same reference ones, phew
<Sarvatt> they do have their own libEGL though :(
<Sarvatt> almost done with libEGL, i'll finish it by tomorrow probably
<Sarvatt> http://sarvatt.com/downloads/patches/egl.patch
<Sarvatt> what i got so far
<Sarvatt> oh thats missing some stuff
<Sarvatt> there we go
<Sarvatt> chromiumos is using gentoo now instead of ubuntu? tried it out earlier and was a sad panda
 * RAOF heads out for a walk to lunch.
<Sarvatt> interesting.. looking through the moblin psb kernel source - http://paste.ubuntu.com/435292/
<Sarvatt> xf86-video-psb-5.1.0.0112-1.3.moblin2.i586.rpm  too
<RAOF> Ah, so they're actually using gallium for their proprietary driver now?  I understand that was one of the goals.
<Sarvatt> this moblin psb isn't using a special libdrm, and uses http://cgit.freedesktop.org/mesa/libwsbm/ that i never heard of before, it's just basic 2D without the gallium component that never made it and they support IGED out of the box
<Sarvatt> also the mrst patches from meego that apply to 2.6.34 will work for it
<Sarvatt> interesting
<Sarvatt> this is all open source 2D thats not vesa though, wonder why they never pushed this anywhere
<Sarvatt> doesnt look like it even needs any kind of firmware
<Sarvatt> xpsb-glx will work with it too
<Sarvatt> for 3D
<Sarvatt> as long as you dont pass --enable-dri2 when building the ddx
<oc13> Hi, i have got some trouble with fpit touchscreen driver.
<oc13> looking at the source there seems to be a typo in the code
<oc13> concerning initialization of the driver. changed it, recompiled & works for me
<oc13> please take a look at:http://pastebin.com/pZC3c16Q
<oc13> line 60, the changed code.
<RAOF> oc13: Have you filed a bug?
<oc13> no corrected it
<RAOF> Could you produce a patch?  It's not obvious what is wrong.  Also, file a bug so that we know that there's something wrong, and attach the patch so that we know we can easily fix it :)
<RAOF> It's also not obvious what the symptoms of the problem you're fixing is :)
<oc13> submitted a bug report: Bug #582123 
<ubottu> Launchpad bug 582123 in launchpad "xorg-input-fpit gets wrongly initialized" [Undecided,New] https://launchpad.net/bugs/582123
<RAOF> Thanks.
<RAOF> oc13: Hm.  Where are you getting that driver from?  That code doesn't match what we've got in the xserver-xorg-input-fpit package.
<oc13> i checked out from git
<RAOF> Ah.  You probably want to post a patch to the appropriate driver mailing list, then.
<RAOF> Whatever bug you're running into doesn't (yet!) affect Ubuntu.
<tjaalton> xorg-devel@ is probably the best match
<RAOF> If you're not familiar with the process of submitting a patch, we can probably help you.
<oc13> i will try it.
<tjaalton> I can send the patch and add a reported-by:
<oc13> ok, submitted a patch to xorg
<tjaalton> heh, ok
<Sarvatt> argh, is it me or do lucid livecd's totally not boot with -vga std?
<Sarvatt> in qemu
<Sarvatt> maybe its just being completely silent and not actually dead, took 30 minutes to boot with cirrus :D
 * Sarvatt kicks his atom cpu
<RAOF> git status: changes to be committed... no unchanged files.  git commit: âIt is not possible to commit because you have unmerged filesâ.
<RAOF> I hate you, git.
<Sarvatt> git diff show anything?
<Sarvatt> aahh 10 minutes later I see the splash, phew
<RAOF> Hah.  It does.  Changes in .gitignore, which git has erroneously decided has been moved to debian/clean
<RAOF> Ah.  And now .gitignore has an empty diff, but still counts as changed.  Superb!
<tjaalton> oc13: probably stuck in the queue
<Sarvatt> git reset --hard
<Sarvatt> this is neat, i didnt know qemu had a vmware graphics option now, goodbye cirrus
<Sarvatt> if i can get this working it'll give me a good excuse to get the gallium vmwgfx stuff going
<RAOF> Which means you'll want libkms?
<Sarvatt> yeah which still needs libdrm to compile, yay
<Sarvatt> already packaged up libkms
<RAOF> It's not in 2.4.20-2ubuntu1, though, is it?  I didn't notice it at least.
<Sarvatt> nah did it on xorg-edgers but backed it out since it needed libdrm to compile
<RAOF> But it's in the same source tree as libdrm?  How can it need libdrm to compile?
<Sarvatt> yeah, crazy aint it?
<RAOF> Like a frikkin cut snake.
<Sarvatt> you had a patch for libkms to compile against the source instead of the system libdrm at one point didn't you?
<RAOF> I certainly patched *something* - it may well have been libkms.
<RAOF> I don't think it would have been for that, though.
<Sarvatt> it was back when libkms first started being enabled by default
<eagles0513875> have you guys been getting reports of the nvidia current driver breaking peoples x server ?
<RAOF> I certainly filed that upstream; I don't know if it got applied.
<RAOF> eagles0513875: I haven't seen such, but UDS didn't leave me with a lot of bug browsing time.
<eagles0513875> RAOF: i have no x or i can start it but with rather cruddy looking graphics
<eagles0513875> and also having problems with apt and package dependencies but thats a different issue
<Sarvatt> guess i saw it on the lists somewhere
<eagles0513875> RAOF: i think the mailing list has somethign floating around if i saw right but then again i didnt bother to read as it wasnt affecting me
<Sarvatt> hah RAOF!
<Sarvatt> http://bugs.freedesktop.org/show_bug.cgi?id=26852
<ubottu> Freedesktop bug 26852 in libdrm "Build libkms against in-tree xf86drm.h" [Normal,New]
<Sarvatt> you really did forget :)
<RAOF> J'accuse jetlag!
<eagles0513875> RAOF:  or Sarvatt eitherone of you can help 
<Sarvatt> i dont know what you did to get into the broken state
<eagles0513875> but on reboot i get this error mess saying im running in low graphics mode drm failed to open device and failed ot initialize glx extension compatible nvidia x driver not found 
<eagles0513875> whats not making sense 
<eagles0513875> i can get on to kde in low graphics mode 
<eagles0513875> i check jockey and it is saying its activate 
<Sarvatt> guessing you either installed from nvidia.com or a screwed up PPA package at some point and messed up the package manager
<eagles0513875> runnign apt-cache policy nvidia-current shows
<eagles0513875> Sarvatt: i didnt use a ppa and didnt install from the nvidia website
<RAOF> And without the relevant logs (dmesg + /var/log/Xorg.0.log) we can't really say anything useful.
<eagles0513875> everythign from ubuntu repos
<eagles0513875> let me try paste it hold on 
<Sarvatt> do you have a bug?
<Sarvatt> with the logs we can look at?
<eagles0513875> no i dont 
<eagles0513875> as this only happened this morning after a reboot 
<eagles0513875> it was working up until that point
<Sarvatt> pastebin your /var/log/jockey.log please
<eagles0513875> gonna try if i can get into a console
<eagles0513875> this is even better :9
<eagles0513875> :(
<eagles0513875> !paste
<ubottu> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<Sarvatt> if it's saying drm failed to open device that means you dont have nvidia-current installed though
<eagles0513875> http://paste.ubuntu.com/435381 <--dmesg
<eagles0513875> http://paste.ubuntu.com/435383 <---Xorg.0.log
<Sarvatt> eagles0513875: whats your /etc/X11/xorg.conf?
<Sarvatt> ah that works, looking
<Sarvatt> you dont have an xorg.conf
<Sarvatt> eagles0513875: just run sudo nvidia-xconfig
<eagles0513875> why all of a sudden wouldnt i have one
<eagles0513875> ok Sarvattshould i reboot
<Sarvatt> i have no idea, something wonky with jockey, might be able to tell from your /var/log/jockey.log
<Sarvatt> yeah
<eagles0513875> give me sec
<eagles0513875> http://paste.ubuntu.com/435387 <-----jockey log
<eagles0513875> gonna reboot 
<Sarvatt> did you install nvidia-current with a package manager instead of jockey? that doesnt create the xorg.conf if so
<eagles0513875> no i havent
<eagles0513875> and atm apt is messed up :(
<eagles0513875> well that fixed it
<eagles0513875> O_o
<Sarvatt> ...madwifi?
<eagles0513875> ?
<Sarvatt> did you upgrade from hardy maybe?
<eagles0513875> is this the official ubuntu x channel
<eagles0513875> Sarvatt: no 
<eagles0513875> clean install of lucid 
<eagles0513875> had to use ubuntu server though
<eagles0513875> as i need gpt to be able to use my 2tb hdd
<Sarvatt> how did you say you installed nvidia-current again?
<eagles0513875> jockey
<Sarvatt> i dont see that in that log :(
<Sarvatt> rereading the scrollback..
<eagles0513875> O_O
<Sarvatt> so you activated nvidia-current in jockey, rebooted, then this started?
<eagles0513875> my install has been working for about 2 weeks or so 
<tseliot> the installation in jockey failed
<eagles0513875> i just rebooted to day and it happened
<eagles0513875> tseliot: ?
<Sarvatt> nvidia-current was working and just stopped with no intervention this morning?
<tseliot> DEBUG: nvidia_173 is not the alternative in use
<eagles0513875> tseliot: im using the latest one 
<eagles0513875> the one that jockey recommended
<tseliot> yes, but somehow it failed to set the correct alternative
<eagles0513875> tseliot: should i uninstall nvidia current and reinstall it
<Sarvatt> the alternatives were fine going by his xorg.0.log because it wouldn't have loaded the nvidia libglx
<tseliot> eagles0513875: what's the output of "update-alternatives --display gl_conf" ?
<eagles0513875> brb really fast
<Sarvatt> nouveau was properly blacklisted too, it only loaded drm while trying to load nouveau and that failed so it fell back to vesa
<tseliot> then maybe the jockey log file shows the uninstallation process of nvidia
<tseliot> as I can see:
<tseliot> got handler xorg:nvidia_current([NvidiaDriverCurrent, nonfree, enabled] NVIDIA accelerated graphics driver)
<Sarvatt> what could have deleted his xorg.conf?
<tseliot> and then a few lins below
<tseliot> got handler xorg:nvidia_173([NvidiaDriver173, nonfree, disabled] NVIDIA accelerated graphics driver)
<tseliot> so an uninstallation would explain it
<tseliot> uninstalling the driver means removing xorg.conf if none was available before the installation from jockey
<Sarvatt> uninstallation of what?
<tseliot> of the nvidia driver
<tseliot> hey wait a sec
<Sarvatt> because he had the nvidia-current kernel module loading and the alternatives had to be right because it loaded the nvidia libglx
<tseliot> NvidiaDriverCurrent and NvidiaDriver173 are not the same...
<tseliot> replacing coffee with tea is not working well for me :-/
<tseliot> so that's correct
<ripps> Hi, I'm trying out the xorg-edgers ppa, but it seems to fail on boot. According to the Xorg.0.log, it's failing to load the fbdev module
<tseliot> Sarvatt: maybe just uninstalling and reinstalling nvidia from jockey will do it
<Sarvatt> ripps: xorg-edgers not xorg-testing right?
<Sarvatt> ripps: sudo apt-get install xserver-xorg-video-all if so, you must have let it get removed at some point
<eagles0513875> tseliot: what was that command you want me to run
<tseliot> eagles0513875: as I said, maybe just uninstalling and reinstalling nvidia from jockey will do it. Please try
<eagles0513875> ok
<Sarvatt> xserver-xorg-video-fbdev - 1:0.4.2+git20100422.7ec9d466-0ubuntu0sarvatt is in xorg-edgers and compiled against xserver 1.8
<eagles0513875> its running fine since i added an xorg.conf file
<ripps> Sarvatt: okay, I installed that, but just so you know, it failed to load fbdev_drv.so because of a requirement mismatch
<Sarvatt> whats the version on your xserver-xorg-video-fbdev?
<eagles0513875> tseliot: its uninstalling atm
<ripps> Sarvatt: huh... it's using the main lucid one, not xorg-edgers.
<Sarvatt> eagles0513875: delete your /etc/X11/xorg.conf too before you reinstall
<eagles0513875> ok sar
<eagles0513875> Sarvatt: 
<tseliot> eagles0513875: and after you install, please post your xorg.conf
<eagles0513875> ok tseliot
<Sarvatt> it should make the right one when you do it that time, it's still a mystery as to what deleted it randomly :(
<ripps> Sarvatt: I think I figured it out, I needed to run a full-update, it wasn't pulling in all the video drivers
<tseliot> eagles0513875: and the output of "update-alternatives --display gl_conf"
<eagles0513875> well hell this isnt good 
<Sarvatt> ripps: yea sudo apt-get dist-upgrade
<eagles0513875> jockey isnt starting and my apt is messed up atm :( 
<eagles0513875> should i just do a clean install 
<eagles0513875> and go from there
<ripps> be back in a reboot
<Sarvatt> eagles0513875: did you already remove nvidia-current?
<eagles0513875> Sarvatt: 
<eagles0513875> ya
<eagles0513875> wait there it goes
<Sarvatt> open a terminal and sudo jockey-text -e xorg:nvidia_current
<Sarvatt> ah ok
<eagles0513875> im getting an error when trying to remove the driver 
<eagles0513875> systemError: installArchives() failed
<eagles0513875> i think i managed to screw up my install royally
 * eagles0513875 is gonna reinstall
<Sarvatt> eagles0513875: do you have a package manager running?
<Sarvatt> synaptic?
<Sarvatt> cant have that open at the same time as jockey
<eagles0513875> Sarvatt: no i went to instal tex live and it has unmet dependencies and its kinda got me locked outa installing anything
<Sarvatt> thats usually what that error means
<eagles0513875> hummm 
<Sarvatt> sudo apt-get -f install?
<Sarvatt> yeah its stuck waiting for you to resolve that problem first
<eagles0513875> Sarvatt: tried that still nothing
<eagles0513875> how can i resolve it sudo apt-get -f install doesnt work neither does dpkg --configure -a
<Sarvatt> whats it say when you do a sudo apt-get dist-upgrade?
<Sarvatt> packages on hold?
<Sarvatt> try installing each one individually to see where the problem is
<eagles0513875> says that this dependency is missing but it wont be installed
<eagles0513875> and even individually says the same thing about unmet dependencies
<Sarvatt> do you have -proposed enabled?
<eagles0513875> ya
<Sarvatt> yah looks like a problem with packages in proposed right now, hmm
<Sarvatt> can you just purge all of the ones waiting?
<ripps> Sarvatt: Awesome everythings working great, XV performance in mplayer is outstanding
<eagles0513875> Sarvatt: tried purging it just mentioned there are unmet dependencies
<Sarvatt> its not recommended to enable proposed globally for that exact reason btw
<eagles0513875> ya i know actually this reinstall i wont
<eagles0513875> especially since i need to do work on this desktop
<Sarvatt> just gotta find what you have installed that is depending on those things that it cant fulfill
<eagles0513875> Sarvatt: whats even more annoying is it took me bout 2 weeks of swearing and headaches to find out that gpt partition table isnt compiled into main stream ubuntu kernel
<Sarvatt> sudo apt-get purge texlive-binaries libkpathsea5 libkpathsea-dev ?
<Sarvatt> err wait
<eagles0513875> Sarvatt: im gonna do a clean install 
<eagles0513875> ty for reminding me i need to get some stuff i downloaded off u tube off of there hehe
<eagles0513875> Sarvatt: gave me an idea ctually 
<Sarvatt> can you paste the output after you sudo apt-get dist-upgrade?
<Sarvatt> really its not something you have to reinstall over, knowing how to recover from that is extremely handy and once you do it once you wont forget :)
<eagles0513875> Sarvatt: i might have solved it
<eagles0513875> sudo apt-get purge texlive*
<eagles0513875> all of texlive gone for now a
<eagles0513875> and im gonna disable proposed
<Sarvatt> that works too :)
<Sarvatt> if you needed it you could disable proposed, sudo apt-get upgrade and then sudo apt-get install package1/lucid package2/lucid..etc to downgrade back to the lucid versions
<eagles0513875> and also strangly enough it started up just fine
<Sarvatt> yeah it definitely sounds like something decided to delete your xorg.conf out of the blue, maybe it even got corrupted and it was gone after a fsck at boot
<eagles0513875> tseliot: iand Sarvatt  start up just fine with out an xorg.conf and without the driver
<eagles0513875> Sarvatt: i removed it as well as the driver and it starts up just fine without the xorg.conf
<Sarvatt> ah you're using nouveau then
<Sarvatt> its supposed to work that way
<eagles0513875> ahhh ok 
<eagles0513875> now to install the driver 
<eagles0513875> should i do it form jockey or commandline
<tseliot> right
<Sarvatt> its just screwed up if you have the binary driver installed with no xorg.conf
<eagles0513875> let me try with binary
<eagles0513875> driver now
<Sarvatt> jockey, yeah
<eagles0513875> restarting now
<ripps> hmmm... weird, mplayer using opengl video output renders ass subs incorrectly... perhaps it's because of the mesa/xserver version. Let me try a mplayer rebuild using xorg-edgers as a ppa dependency.
<eagles0513875> it booted up just fine wiht the driver
<eagles0513875> woohoo :) 
<tseliot> \o/
<Sarvatt> i'm putting money on it just having been corrupted and removed during a fsck it since it happened at boot
<Sarvatt> ripps: define incorrectly? :D
<Sarvatt> timed wrong? wrong fonts? graphics glitches?
<ripps> ripps: some letters have a weird graphic glitches and artifacts in over or in place of a few letters
<ripps> Sarvatt: ^
<ripps> Don't see the glitches with XV though.
<Sarvatt> work any better if you sudo apt-get install libgl1-mesa-dri-gallium? :)
<Sarvatt> are you using mutter?
<ripps> no
 * ripps is d/l gallium dri now...
<Sarvatt> you had a x1400 mobility or something close to that didnt you?
<ripps> Sarvatt: older, 9600 pro
<ripps> rv350 chipset
<Sarvatt> oh dont think that works with whats in libgl1-mesa-dri-gallium :(
<Sarvatt> only r300g in there
<ripps> Sarvatt: rv350 is r300
<Sarvatt> well you'll know if you install it and glxinfo :)
<ripps> *essentially*
 * ripps is restarting X now
<Sarvatt> oh i was thinking it was an r200
<Sarvatt> darn rv's
<Sarvatt> was off a generation
<Sarvatt> RV250 = r100
<ripps> OpenGL renderer string: Gallium 0.4 on RV350
<ripps> :)
<Sarvatt> err RS250=R100, argh :)
<eagles0513875> tseliot: and Sarvatt ty for your help
<Sarvatt> RS350=R200 too ahh
<tseliot> np
<Sarvatt> no worries eagles0513875, hope it doesn't happen again since we dont know what caused it :)
<eagles0513875> Sarvatt: ya i hope so too 
<eagles0513875> if i can digup the mention of nvidia issues on the mailing list i can pastebin for you guys to take a look at
<Sarvatt> ah yeah it was RS350=R200 that I was thinking of, I have an RS350
<ripps> Sarvatt: okay, much better now. However, it seems that GL video playback has taken a performance hit
<ripps> oop, compiz suddenly crashed
<ripps> restarted okay though
<ripps> okay, there are still a few ass rendering issues. Some slight graphical hiccups with punctuation (,'.) and the dot in i's.
<ripps> (performance wasn't hit that much, my awn was making a signal that was soaking a few cpu cycles)
<Sarvatt> and it works fine with the normal lucid packages?
<ripps> yes
<ripps> I'm not using a normal mplayer btw, I'm using the mplayer-build git repo to build ffmpeg-mt mplayer packages
<ripps> I rebuilt it with xorg-edgers -dev files though
<Sarvatt> try recompiling libass against xorg-edgers?
<Sarvatt> i think theres a newer libfontconfig in there, need to look
<Sarvatt> no idea if its related though
<ripps> Sarvatt: mplayer-build builds in internally into mplayer a compile-time
<ripps> *build libass
<ripps> no exteranl ffmpeg/libass dependencies
<ripps> I'm trying to contact the mplayer-build developer now to see if he has any ideas, but he might be asleep
<Sarvatt> oh whoops that was libfontenc
<Sarvatt> ripps: do you  have a ~/.drirc?
<Sarvatt> if so try deleting it and purging libgl1-mesa-dri-gallium and try again?
<ripps> Sarvatt: deleted it before installing xorg-edgers, as per the ppa description
<Sarvatt> nice!
<ripps> hold on, mplayer-build dev just pm'd me
<Sarvatt> hot damn I didn't think anyone read that :)
<Sarvatt> only other thing I can think of would be to try without compiz, but i like to blame all my problems on compiz
<Sarvatt> does your mkv have embedded fonts? are you using those?
<ripps> Sarvatt: actually, it looks like I get different render glitches depending if it's windowed or fullscreen. Window = static. fullscreen = patially missing
<ripps> embedded fonts I think
<Sarvatt> could try changing your font hinting settings too
<ripps> uau (mplayer-build dev) thinks there might be a bug with how gl is scaling the font
 * Sarvatt is really reaching at straws here
<ripps> but that wouldn't account for the glitches in windowed mode
<ripps> the problem might be with freetype
<Sarvatt> -nofontconfig maybe?
<Sarvatt> or -ass-hinting 0
<ripps> woop, compiz crashed again
<Sarvatt> so friggin many -vo gl options
<Sarvatt> the compiz crashes will probably go away if you move /usr/lib/dri-gallium/r300_dri.so to /us/lib/dri/ and restart X
<ripps> AHA! I figured I out, I was using render=1, because it gave me a slight boost in older versions of ubuntu, but it's what was causing the graphical issues
<ripps> Sarvatt: okay, how do I uninstall this gallium stuff, it's causing to compiz to crash constantly
<Sarvatt> just purge libgl1-mesa-dri-gallium
<ripps> btw, gallium can't do popup menu opacity correctly. It's either all or nothing with it.
<ripps> I used to set it to 90%, but now it's looks like 10%. 
<Sarvatt> yeah both of those issues i've been told are resolved by moving r300_dri.so to /usr/lib/dri and restarting
<ripps> okay, I'll try that
<Sarvatt> back up the r300_dri.so in /usr/lib/dri first :D
<ripps> Sarvatt: is it okay to symlink, or should I copy it?
 * ripps is restarting X
<ripps> woot, opacity is working again :)
<RAOF> Sarvatt: You were looking at merging xserver 1.8.1 from Debian, right?
<Sarvatt> its already done
<Sarvatt> http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=shortlog;h=refs/heads/ubuntu
<RAOF> But hasn't been uploaded yet?
<tjaalton> no
<ripps> well, opacity is fixed, but compiz still crashes occasionally
<ripps> it'll be nice if gallium gets xvmc/vaapi/vdpau. Right now, it takes almost my entire cpu just to decode a 720p video.
<Sarvatt> new psb code drop, version 5.3.0.001-1.1
<Sarvatt> (in meego)
<Sarvatt> all the links to their git repos must be internal, dont work here :(
<Sarvatt> http://moblin.intel.com/git/cgit.cgi/umg-moorestown-pvr/commit/?h=img-1.5-m2&id=f91616e5029ee0282575f075bbcc932372fa9e09
<lucazade> Sarvatt: any info on new psb code?
<Sarvatt> not until intel actually releases it for meego :)
<lucazade> ok.. hope will be compatible with xserver 1.7
<Sarvatt> the kernel side is public though - #define PSB_PACKAGE_VERSION "5.3.0.32L.0007"
<Sarvatt> yep, finally made sure that virtual devices patch is bogus - http://paste.ubuntu.com/435510/ 
<Sarvatt> vesa/vesa/fbdev
<Sarvatt> in qemu with -vga std
<Sarvatt> normal vesa/fbdev with the patch dropped
<Sarvatt> awesome that -vga vmware works in kvm now, hope the 3D stuff works too
<BUGabundo_remote> good afternoon
<BUGabundo_remote> any X dev that can join me in #nx ?
<BUGabundo_remote> trying to debug a evdev bug with NX
<BUGabundo_remote> (2010-05-18 17:59:52) adrenaline: Here is the deal. Ubuntu took the keyboard and mouse out of xorg and put them in evdev I believe that is the issue you are facing with the keyboard
#ubuntu-x 2010-05-19
<RAOF> Hm.  Why is mesa_7.8.1.orig.tar.gz different to what's on freedesktop.org?
<tjaalton> RAOF: it's built from the upstream tarballs
<tjaalton> there is no single released tarball
<tjaalton> RAOF: got my msg?
<RAOF> tjaalton: No.
<RAOF> (Sorry, lunch)
<RAOF> As in: was having lunch.
<tjaalton> 06:57 < tjaalton> RAOF: it's built from the upstream tarballs
<tjaalton> 06:57 < tjaalton> there is no single released tarball
<tjaalton> though git has
<tjaalton> the tagged tarball
<tjaalton> but it's not the same thing
<RAOF> Where in git has the tagged tarball?
<tjaalton> cgit shows it
<tjaalton> it's probably just a dump of the tagged contents
<RAOF> On alioth, or on freedesktop?
<tjaalton> freedesktop
<tjaalton> as in, the web frontend shows it ;)
<RAOF> Ah, right.
<RAOF> Sweet.  Mesa builds now.
<tjaalton> nice
<tjaalton> it's the next one to go in?
<RAOF> I might just update debian/watch so that in future I don't get confused about where to grab the tarball from :)
<tjaalton> yeah
<tjaalton> i use the versions_current -page links to get to the debian package page, but it could be easier.. :)
<hyperair> Sarvatt: seems that 2:2.11.0+git20100518.5e04a813-0ubuntu0sarvatt~lucid makes X unstartable.
<Bernardo> good morning
<RAOF> Bernardo: Good morning.  How is our intrepid psb adventurer?
<Bernardo> lol
<Bernardo> Haven't looked at it since the weekend
<Bernardo> Lucazade seems to have done a good job on the packages, tying up a couple of loose ends so things now install and work (without 3d and video) directly from the ppa without the need for any tuning (except for kernel options for a couple of specific models)
<Bernardo> I've looked at tseliot's test patch for xorg-core this weekend, but didn't advance there
<Bernardo> RAOF: we need some X expert to look at the code, I haven't done any significant coding in more than 10 years, and even though I can still read code, I'm very much lost when looking at X source, I need to learn everything and don't have the time
<Bernardo> maybe tseliot will be able to do more work on his patch one of his days
<Bernardo> one of "these" days
<RAOF> Where's that patch?
<RAOF> And what is it meant to do?  I haven't been following the psb saga closely - you all seemed to have it well in hand :)
<Bernardo> it's in tseliot ppa - albertomilone
<Bernardo> It just stops the crashes if a null pointer is passed to fbcopynton, from what I saw
<Bernardo> but the side effect is that it breaks bitmaps, and scrolling in firefox and console
<RAOF> Oh.  So to test anything I'd need actual hardware.  Yay.
<Bernardo> I'd lent you my 1101HA, but I do need it avary day
<Bernardo> every
<Bernardo> of course, if I'm online, you can always ask me to test any patch
<Bernardo> I've already built xorg-core a few times here
<tjaalton> RAOF: umm, we _don't_ use the cgit tarball of mesa
<tjaalton> but build it from the three released tarballs
<tjaalton> maybe I was unclear about that, sorry
<RAOF> tjaalton: Aah, ok.
<RAOF> get-orig-source it is, then.
<tjaalton> yeah it could also do the cleanup of the extracted tarballs before building it
<tjaalton> unless you mean only to fetch from debian
<RAOF> That wouldn't be very useful for debian now, would it? :)
<tjaalton> no :)
<tjaalton> can't remember what was deleted from the extracted tree before building the tarball, but it's easy to check
<RAOF> Hm.  This seems like something for source-format 3.0 was designed for...
<jcristau> RAOF: hopefully anholt's demos repository will land soon, then we'll just need the MesaLib tarball, instead of MesaLib+MesaDemos
<RAOF> jcristau: And, in the mean time, this get-orig-source target can document what to do :)
<jcristau> yeah
<lucazade> hi tseliot I would like to know if you have foundÂ a solution forÂ PSB glx?
<chrisccoulson> hey RAOF - did you see the scrollback on monday between me and Sarvatt?
<chrisccoulson> (sorry, i'd fallen asleep by the time you replied) ;)
<tseliot> lucazade: no but there's an upstream bug open: https://bugs.freedesktop.org/show_bug.cgi?id=28077
<tseliot> also Sarvatt mentioned the fact that a new psb driver has been released
<lucazade> ok thanks.. gma500 ppa now set also xorg.conf with shadowfb enabled, so should works without hacks
<lucazade> new psb or iegd ?
<jcristau> why set it in xorg.conf when you can just make it the default in the driver?
<lucazade> because i don't know where to change jcristau :) lol
<lucazade> poulsbo.conf ?
<jcristau> no.  the driver.
<lucazade> or permanent like ignoreacpi?
<lucazade> ok
<lucazade> i hope this is only a temp workaround btw
<jcristau> just switch the default around
<lucazade> ok i'll look into
<RAOF> chrisccoulson: The stuff about gnome-screensaver and xrandr gamma fade?
<chrisccoulson> RAOF - yeah, that's right
<RAOF> Let me get back into the contextâ¦
<RAOF> Ok.
<RAOF> So, it looked like disabling fade was a safe work-around.
<RAOF> chrisccoulson: Oh, someone reported that it didn't work?
<chrisccoulson> RAOF, the SRU i uploaded has several fixes in, but one of the crasher fixes doesn't work
<chrisccoulson> so, it's an unrelated issue
<RAOF> Ah, ok.
<RAOF> We just need to ensure that Maverick doesn't require the same workaround.
<Sarvatt> hyperair: got any logs or more info?
<hyperair> http://paste.debian.net/73968/
<hyperair> Sarvatt: ^
<Sarvatt> thats it?
<Sarvatt> gdm log say anything?
<Sarvatt> err guess its just that too
<jcristau> it probably says 'undefined symbol'
<hyperair> hmm? undefined symbol?
<jcristau> Sarvatt: fdo 28166
<hyperair> i dunno, gdm just terminates immediately, from what i can tell when i can actually switch to a tty
<Sarvatt> someone else emailed me about that happening with kdm too
<Sarvatt> fdo #28166
<Sarvatt> (just getting the link)
<Sarvatt> bah lol
<jcristau> bugs.freedesktop.orog/28166
<jcristau> argh
<jcristau> bugs.freedesktop.org/28166
<jcristau> there, you have your link
<Sarvatt> yeah i got it.was just being lazy, thanks jcristau
<Sarvatt> i'm confused about it though, maybe because I just woke up :
<Sarvatt> we have that commit in xorg-edgers
 * Sarvatt just reverts that commit for now
<Sarvatt> AH i see the problem
<Sarvatt> ./debian/patches/copy-fb.patch:+	intel_sync(scrn);
<hyperair>  O_o
<hyperair> just that?
<jcristau> hyperair: it turns out calling a function that doesn't exist ends badly :)
<Sarvatt> yep
<hyperair> heh
<hyperair> i see =p
<Sarvatt> thats the plymouth-X transition patch
<hyperair> i see.
<Sarvatt> intel is the only one that doesn't have it upstream
<hyperair> i see.
<Sarvatt> uploading it with the patch dropped for now, i'll fix it up but want to make it at least not broken asap :)
<Sarvatt> sorry about that, wasn't around yesterday and didn't catch that
<hyperair> np
 * hyperair always has a few xxvi debs to revert
<Bernardo> hi
<LaMs> Hi 
<ripps> I'm pretty impressed by how stable xorg-edgers is, I was expecting constant crashes all the time. The only issue I'm getting is problem I'm getting is resuming from suspend, and I've already figured out that it's being caused by my mainline 2.6.34 kernel, not xorg.
#ubuntu-x 2010-05-20
<RAOF> tjaalton: In the mesa merge, why did you keep the âunexport LDFLAGSâ?  I've test-built on amd64 without it, and it builds fine.  Was there some other subtlety that this change was fixing?
<Sarvatt> RAOF: I believe you can nuke that, it was over a year ago and Tormod fixed it upstream afaik
<RAOF> Yeah, I've been checking.
<RAOF> AMD64 builds just fine.
<RAOF> And now that we actually build the intel DRI on i386 again, it's time to find a sponsor!
<Sarvatt> back in the mesa 7.4 days
<Sarvatt> think it was this - http://cgit.freedesktop.org/mesa/mesa/commit/?id=9cb3cdec76b679f15c591955084bd48e91a32142
 * Sarvatt can't wait for xrandr 1.4 to stop all these virtual screen resolution > max texture size and compiz broken bug reports
<RAOF> Oh? 1.4 is the magical version that will fix that?
<Sarvatt> yeah adds per-crtc pixmaps
<Sarvatt> +   â¢ Per-crtc pixmaps. This provides for multiple scan-out buffers
<Sarvatt> +     which applications can create and assign to arbitrary collections
<Sarvatt> +     of crtcs. These pixmaps can be associated with a window for use
<Sarvatt> +     with OpenGL or drawn to directly.
<Sarvatt> oh i totally missed the later discussion - http://www.mail-archive.com/xorg-devel@lists.x.org/msg07846.html
<Sarvatt> ack they're uploading backported kernels to lucid? do you know if they know about how nouveau is going to be totally broken by that RAOF?
<RAOF> Sarvatt: Yes; we discussed that at UDS.
<RAOF> I was vaguely aware of that blueprint before, but hadn't quite twigged as to the consequences.
<RAOF> The answer is: there shall be madness.
<RAOF> Or, rather, that we'll do some ungodly symlink-the-appropriate-libdrm-on-boot hack.
<Sarvatt> i guess we can drop libgl1-mesa-swx11-i686 here soon huh? :D
<Sarvatt> noticed gcc-4.5 uses i686 as the default arch
<Sarvatt> oh gcc 4.4 now too, nice
<RAOF> Sarvatt: That's a good point.
<Sarvatt> RAOF: oh wow good catch on that mesa problem, I didn't notice since I use an external debian/ with all of the gallium changes
<Sarvatt> the i686 arch changes.. 
<Sarvatt> actually it does affect me too, hah!
<RAOF> Are you not testing your built packages? :)
<Sarvatt> only popped up in the past few days since maverick is using gcc-4.4 still as default and that was just switched, looks like i915 and friends are still the old versions
<Sarvatt> i dont think i've even built mesa since the gcc change
<Sarvatt> looking now though
<Sarvatt> nope it was today - Date: Wed, 19 May 2010 11:28:26 +0200
<Sarvatt> built mesa yesterday
<Sarvatt> ugh going to cause hell for lucid, i'll have to add more conditionals instead of just changing things
<RAOF> We don't support lpia; why not switch on i386 arch rather than DEBIAN_HOST_GNU_CPU?
<tjaalton> RAOF: yeah that was overlooked for some time, nice that it got dropped
<tjaalton> I can upload mesa if it's ready
<RAOF> Luke's got it in #ubuntu-desktop, unless you'd prefer to take it yourself.
<tjaalton> nah that's fine
<Bernardo> hi
<Sarvatt> not sure what the proper method to bring in llvm is in for libgl1-mesa-dri-gallium, llvmpipe needs it to be used but its not picked up. recommends?
<Sarvatt> doing it as a recommends brings in llvm-dev and oprofile also
<RAOF> What requires llvmpipe?
<tjaalton> RAOF: the swrast driver aiui
<RAOF> Do the other drivers fall back to swrast for anything?  If so, we need it.  If not, meh.
<tjaalton> we have the non-gallium version of it
<tjaalton> so yes
<tjaalton> umm, no we don't need the gallium one, but it's a lot faster :)
<RAOF> Yeah, I've heard.
<RAOF> But the gallium drivers don't care which swrast gets used?
<tjaalton> actually llvmpipe is the gallium version of swrast
<tjaalton> don't think so
<tjaalton> and then there's softpipe, which is probably closer to swrast performance wise
<RAOF> With the interesting converse: do users of non-gallium drivers get faster software fallbacks with llvmpipe?
<tjaalton> it it'd replace swrast then yes
<tjaalton> well, at least that's how I'd see it but I've no evidence of how it works
<RAOF> Heh.
<tjaalton> so, don't count on my words ;)
<tjaalton> Sarvatt: probably need logs about the "didn't pick it up" part
<jcristau> mesa should likely have used DEB_HOST_ARCH_CPU rather than the GNU version
<jcristau> looks like this was my fault, sigh
<tjaalton> :)
<jcristau> hmm raof left :(
<coz_> hey guys...anything change on lucid where we can now install the official nvidia driver??
<tjaalton> nope
<coz_> tjaalton,  ooo darn... do you have any information that that will change? i really dont want to go back to karmic
<tjaalton> coz_: it won't change, lucid is released
<tjaalton> installing the driver from nvidia.com breaks your system
<coz_> tjaalton,  you mean in general^^?
<tjaalton> and fills launchpad with obscure bugs
<tjaalton> it replaces system libs and then upgrades won't work etc
<coz_> tjaalton,  thats not the true at all.. depending on card  and who manufactured it along with system configuration...the nvidia driver offered via hardware drivers doesn always work across the board... chaning drivers  can reduce the amount cpu useage  by X  considerably... 
<coz_> tjaalton,  thats why nouveau is not going to be any different for that matter
<coz_> a single driver on all systems with all configurations is a pipe dream
<tjaalton> eh, there are three blobs to choose from, depending on your card
<tjaalton> or four, I've lost count
<coz_> tjaalton,  thats not workable though   only one driver is current
<tjaalton> and not current enough I take?
<coz_> tjaalton,  well again depending on system config and video card  no  not current enough...considering that nvidia puts out beta drivers with many bug fixes  but none of those fixes make it into ubuntu for 6 months at best5
<coz_> best
<tjaalton> go blame them
<tjaalton> I don't know if there are plans to update the driver
<coz_> tjaalton,  well no   its not their fault I cant install on lucid
<tjaalton> in lucid
<tjaalton> it's their fault to have their release schedule
<tjaalton> and bugs in the driver
<coz_> tjaalton,  you mean like lucid relesing with bugs?
<tjaalton> some bugs can be fixed
<coz_> right
<tjaalton> nvidia's blobs always bring new ones
<jcristau> Sarvatt: fix in debian-unstable git for mesa's debian/rules, fwiw.
<tseliot> coz_: I've uploaded the latest nvidia driver to lucid-proposed but it hasn't been approved yet
<coz_> tjaalton,  ok thats cool :)
<coz_> tseliot,  sorry 
<coz_> tseliot,  thats cool
<coz_> tjaalton,   sorry
<asac> in mesa source there seem to be GLES headers et al ... are those packaged somewhere?
<jcristau> probably not
<asac_> jcristau: sorry had reconnect. did you say anything besides "probably not" ?
<jcristau> no
<asac_> why is that: "probably not"?
<Sarvatt> because we dont ship libGLES in mesa
<jcristau> because there hasn't been a reason to package them
<asac_> Sarvatt: but we could produce that from that source or do we need some other source packaged for that?
<asac_> ok so how can we get that packaged? would like to provide clutter gles packages, but i think i need this first ;)
<jcristau> i have no idea if the ES stuff in mesa is production quality, what it's useful for, how it's built, or whatever
<jcristau> also i don't know if there are any free gles drivers
<Sarvatt> asac_: i'm pretty sure you are going to need the sdk libgles/egl headers for each target to build against instead of the mesa ones, that really needs looking into
<asac_> Sarvatt: hmm. so you say the mesa ones are useless? if we move to real drivers?
<asac_> otherwise i wonder what kind of packages to produce for "egl"
<asac_> just libgles0-mesa* i guess
<Sarvatt> i'm not sure, but thats the impression i'm under. mesa is going to ship libegl here soon for this wayland stuff
<Sarvatt> egl is seperate from libgles though
<Sarvatt> http://sarvatt.com/downloads/patches/egl.patch
<Sarvatt> started it but haven't done much yet if you want to use any of that
<Sarvatt> i really was under the impression you'
<Sarvatt> re going to need to build things against the vendor sdk's headers though
<jcristau> Sarvatt: so there's no unified ABI like there is for libGL.so.1?
<Sarvatt> comparing the headers to the powervr now
<Sarvatt> for egl at least it looks like there is, theres just some egl_dri2 specific stuff added to the mesa ones it looks like but gles is the one i'm not sure of
<asac_> Sarvatt: ok so we get egl ... hmmm
<Sarvatt> libGLES_CL.so libGLES_CM.so -- those are in the powervr sdk and not in mesa, doesn't look promising :)
<asac_> Sarvatt: does mesa have libGLES.so at all?
<Sarvatt> oh i could be wrong there, haven't actually built mesa libgles, thought it was libGLES.so and libGLESv2.so
<Sarvatt> Name: glesv1_cm
<Sarvatt> Description: Mesa OpenGL ES 1.1 CM library
<jcristau> #elif defined(_EGL_PLATFORM_X)
<jcristau>    const char *es1_libname = "libGLESv1_CM.so";
<jcristau>    const char *es2_libname = "libGLESv2.so";
<Sarvatt> src/mapi/es1api/Makefile
<Sarvatt> configs/linux-opengl-es
<jcristau> hmm.  docs/opengles.html.  seems it can use the dri drivers if built with --enable-gles1 --enable-gles2
<Sarvatt> oh i'm doing everything on master, looks like theres a bunch of stuff missing in 7.8 thats in a seperate branch - http://cgit.freedesktop.org/mesa/mesa/log/?h=7.8-gles
<Sarvatt> jcristau: thanks for fixing the mesa cpu mess, much cleaner than what I was going to do :D
<asac_> jcristau: does that mean we could package something up?
<asac_> with egl and gles?
<asac_> you think you could give that a stab? i would then see what clutter says when i build it against it ;)
<jcristau> ENOTIME
<jcristau> i can take patches though
<jcristau> :)
<jcristau> but raof sounded like he wanted to work on that.  from the mail he sent to {debian,ubuntu}-x
<asac_> thx. will talk to him
<Sarvatt> sheesh i'm starting to like bzr more and more, bzr branch git://whatever.git works :D i pushed the mesa packaging changes to https://code.edge.launchpad.net/~xorg-edgers/mesa/packaging so other people can commit unlike http://sarvatt.com/git/cgit.cgi/mesa/
<ripps> Hi, I'm having an issue with 2.6.34 radeon drm. I'm not sure if this is the right place to ask, but I figure you guys might have an idea what's going on. Whenever I resume from suspend Xorg fails to resume properly, instead just giving me a black screen and a mouse cursor that has glitched graphics. When I switch to a VT, I have "drm:radeon_cs_ioctl failed to schedele IB" repeating constantly. Stopping X makes them stop, but it resumes 
<jcristau> #radeon would probably be better.
<Bernardo> hi
<Sarvatt> it sure would be nice if abi breaks in xserver were required to put something in the subject about it :)
<jcristau> i think most mention it
 * Sarvatt bookmarks http://cgit.freedesktop.org/xorg/xserver/log/hw/xfree86/common/xf86Module.h
<Sarvatt> looks like theres a bunch of abi bumps queued up, just want to get ready for it
<Sarvatt> eh wait it's the abi bumps without actually bumping the version numbers that screw me up
<Sarvatt> wow the libxfont rebuild has been queued for almost a week
<ripps> is there an easier method to move dri-galluium/r300_dri.so to dri/r300_dri.so. Having to move and replace the file every time xorg-edgers updates is kind of a hassle
<ilmari> dpkg-divert?
<Sarvatt> ripps: still not sure what I want to do there
<Sarvatt> the gallium stuff really is just for testing and it works fine with the dri-searchpath thingy outside of aiglx :(
<Sarvatt> tormod has a seperate ppa where he builds it with gallium by default (and only r300) 
<Sarvatt> https://edge.launchpad.net/~xorg-edgers/+archive/radeon
<Sarvatt> really would hate to start adding diverts there and risk screwing things up
<Sarvatt> hmm maybe have libgl1-mesa-dri-gallium replace libgl1-mesa-dri and install to /usr/lib/dri?
<Sarvatt> but then if someone removed libgl1-mesa-dri-gallium the libgl1-mesa-dri libs wouldn't be there, and ppa-purge wouldn't downgrade it
<ripps> Sarvatt: I like that last idea
<ripps> If dri-gallium is a marked as a replace for mesa-dri, wouldn't it then just install mesa-dri during a downgrade?
<Sarvatt> do you know a way to make libgl1-mesa-dri be reinstalled if someone removed libgl1-mesa-dri-gallium? thats too nasty of a problem to do
<Sarvatt> i hit this *alot* when we had libdrm-dev replacing linux-libc-dev, it would be real bad with the dri drivers hitting it
<ripps> I honestly don't know the particulars of the downgrade system in apt as well as I should. Most devs, when asked about it, tell me not to try it :/
<Sarvatt> it doesn't reinstall the replaced package on removal, no :(
<Sarvatt> it would just remove the libs in /usr/lib/dri 
<ripps> Sarvatt: is tormod's ppa in sync with xorg-edgers? or will it always take precedence over xorg-edgers?
<Sarvatt> and it thinks libgl1-mesa-dri is still installed in that state
<Sarvatt> no you'd have to only get mesa from the radeon ppa, xorg-edgers is usually newer
<Sarvatt> i dont update the radeon one when i do xorg-edgers, tormod uses a different set of hooks to build those and i have too much to update as it is :D
<ripps> Y'see, that's a problem, I want to test out all the newer xorg components, not just mesa...
<Sarvatt> cant you just pin the mesa packages to only download from that ppa?
<ripps> Technically, it would be easy to setup a secondary gallium ppa that depends on xorg-edgers, and than just increase the epoch on the gallium mesa package
<Sarvatt> ask tormod to do that, thats what it is now outside of the epoch :)
<ripps> Sarvatt: I'm not very familiar with pinning, last time I tried it I kinda screwed up my apt, is there a guide with a decent description?
<Sarvatt> https://edge.launchpad.net/~tormodvolden -- shoot him an email and ask him to bump the epoch, it makes sense to do that
<Sarvatt> just a matter of adding -e 1 to his auto-xorg-git invocation
<Sarvatt> oh wait, he doesn't build that PPA against xorg-edgers, sorry about that
<Sarvatt> thought he did..
<Sarvatt> guess i could always just drop classic swrast and r300 and throw the gallium ones in -dri for a bit and see how many complaints we get :D
<Sarvatt> no, bad bad idea, what am I thinking
<Sarvatt> KMS only
#ubuntu-x 2010-05-21
<Bernardo> good morning
<RAOF> Ooh.  xserver 1.8.1+git.  Now with 35.7% less DRI2 craziness!
<hyperair> eh? DRI2's getting removed?
<hyperair> why?
<RAOF> Not removed, fixed.
<hyperair> oh
<hyperair> O_o
<hyperair> what was broken with it?
<RAOF> You know that âxserver crashes whenever you close a clutter appâ bug that got fixed with a patch that caused the GEM leak?  The work upstream to fix it has gone through a number of iterations, most of which broke something in DRI2 at some point.
<hyperair> um no i don't know that bug.
<Bernardo> the one that almost delayed lucid release?
<RAOF> Right.
<tjaalton> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/versions-current.html
<tjaalton> yess, we are done :)
<RAOF> Hurray!
 * Bernardo wonders if he'll have the time this weekend to try and trace meego's psb drivers
<Bernardo> bbl
<asac> RAOF: hey
<asac> RAOF: you might have met alf__ at UDS; he is helping on our graphics story for embedded ...
<asac> RAOF: from what i understand from chatting here yesterday with jcristau and Sarvatt you appear to plan working on making egl/gles packages available for mesa?
<asac> RAOF: could you share your ideas/progress etc. on that with me and alf__ ? thanks a bunch
<RAOF> asac, alf__: So, there are two separate egl/gles stacks in mesa at the moment; classic mesa and gallium.
<RAOF> The classic mesa has dri, glx, and dri2 egl backends, so should be usable on random desktop hardware.
<asac> RAOF: oh.... so what is gallium about ;)? (guess you are still typing)
<RAOF> I haven't yet played with the gallium egl/es stack.  It's likely to not work well on intel, but nouveau has gallium drivers, and the radeon gallium driver is getting better than the classic mesa driver.
<asac> hmm. 
<asac> RAOF: is it possible to package both up?
<asac> or do we need to decide?
<RAOF> Yes, it should be possible to package both.
<asac> RAOF: nice. are you planning on working on that?
<RAOF> Yes.  If you want it faster, I can prioritise.  So far I've just run it past the debian guys and poked around the mesa tree.
<asac> we somewhat need to get a clutter gles out asap ... wonder if there is anything else blocking a first iteration
<alf__> RAOF: Will there be any conflicts if both the classic and gallium stacks are present on the system? Eg does one have to explicitly choose?
<RAOF> You do have to choose which driver you're using, yes.
<asac> RAOF: we want it fast, because we just dont know what happens and if that is good enough to start seriously checking drivers and clutter for unity
<asac> and we want to give vendors and unity folks something to play with in order to get the embedded experience out.
<RAOF> Ok.  I'll get that done Monday.
<asac> wow
<asac> thats amazing
<asac> RAOF: do you see anything else we might need to do to do a clutter gles?
<RAOF> Perhaps I should backpedal somewhat - I'll get mesa building the appropriate libs Monday.  No guarantees it'll be in the archive yet :)
 * asac hugs RAOF 
<asac> RAOF: thats fine. if you get the package in a ppa that would be good enough. we want to play with lucid for now i guess
<RAOF> When I tried to build the egl backend previously all I noticed that we were missing was egl.
<asac> but we can backport if mesa hasnt moved away too much 
<asac> RAOF: hmm. isnt that in mesa itself?
<RAOF> Yes, but we don't build that at the moment.
<RAOF> You want to play on Lucid; is there any reason why I shouldn't be working on Maverick's mesa, giving it a bit of a test in lucid, and then pushing it to a lucid PPA?
<jcristau> sigh closed ubuntu-x list.
<RAOF> Is that the level of support that you need in Lucid?
<RAOF> jcristau: Yeah, it still bites me - always a game of âwhich one of my email addresses is subscibed there?â
<asac> RAOF: sure. go for mesa+maverick
<asac> just would love if it doesnt cause too much pain to get for lucid ;)
<Sarvatt> asac: need to package the proprietary libgles/egl with -dev packages for it for one thing if you actually want 3D :)
<Sarvatt> RAOF: meego is shipping libegl/libegl-devel in mesa btw if it helps too look at their packages
<Sarvatt> still havent figured out what they are doing for gles
<Sarvatt> ahh ok looks like mameo is where to look for the gles stuff, it hasn't made it over to meego yet - http://wiki.maemo.org/OpenGL-ES
<Sarvatt> libgles1-sgx-img libgles2-sgx-img opengles-sgx-img-common libgles1-sgx-img-dev opengles-sgx-img-common-dev libgles2-sgx-img-dev - those packages
<alex_mayorga> Hi! I'd like some guidance on https://bugs.launchpad.net/bugs/551668
<alex_mayorga> It's killing my battery life
<alex_mayorga> Also on the same laptop nouveau refuses to work https://bugs.launchpad.net/bugs/581385
<alex_mayorga> anything I can do to get those going?
<Bernardo> hi
<alex_mayorga> Bernardo: hi
#ubuntu-x 2010-05-22
<Sarvatt> well glxgears and friends were moved out of mesa now
<Sarvatt> anyone up for debianizing it? :D
<Sarvatt> well dropped it from the mesa packaging for now so things at least build
<Sarvatt> any ideas on how to debianize mesa/demos? mesa-demos package that provides mesa-utils? still only ship the 4 demos?
<Sarvatt> now that is a crapload of warnings building this
<jg> ping bryceh
<bryceh> jg, what?
<jg> bryceh: there are some patches in the xorg bugzilla for my edp problem to try out.  What's the easiest way to get something that I might be able to get installed on this new laptop of mine? is there some way to easily spin an installation, say by updating a package on a USB key, by any chance?
<Sarvatt> argh half these tests crash the server
<Sarvatt> (in xdemos)
<bryceh> jg, yeah probably.  I'm not working on xorg now though, so you probably should check with RAOF if you need to have patches packaged into debs for your testing.  I think he's away for the weekend though.
<jg> bryceh: ok, I'll check Monday.
<jg> bryceh: thanks.
<bryceh> jg, no prob
<Duke`> ati/radeon driver is in bad shape for R200 these days... the screen is all blurry o_O
<Sarvatt> craploads of packaging changes needed for nvidia 256.25
<Sarvatt> hmm maybe not
<Sarvatt> just a bunch of changes to account for the new source layout and the dropping of -pkgX it looks like so far, test building it here - https://edge.launchpad.net/~sarvatt/+archive/nouveau
<bjsnider> Sarvatt, the names of all of the shared libs have changed
<bjsnider> and so all of the links have to be changed too
<Sarvatt> it already installs the new named ones though
<bjsnider> cool
<bjsnider> i wonder i the changelog they've provided is really comprehensive
<bjsnider> there must be a lot of changes to the code that's shared between platforms, and that is 90% of it
<bjsnider> it's disappointing to see that they did not add randr1.2 support, and it doesn't say they fixed the hdmi audio issue
<bjsnider> also we were expecting fixes to gnome-shell issues
<Sarvatt> a little annoying how everything is in the root directory and /kernel/ after extracting it now, have to manually install everything to the right place
<Bernardo> Sarvatt: I saw a comment from you that meego has a newer source for the PSB drivers that might be all open for the 2d driver, did you try packaging it?
<bjsnider> Sarvatt, yes and why separate the one tls file like that? and why have an empty 32/vdpau directory?
<hyperair> Sarvatt: how does one go about getting nouveau+coompiz working?
#ubuntu-x 2010-05-23
<Sarvatt> jcristau: yeah I sent the disable FBC commit to .33 stable earlier this week but not .32 yet since it needs changing
<Sarvatt> i'm not sure if http://sarvatt.com/downloads/patches/disable_fbc.32.patch is correct and haven't had time to test it
<Sarvatt> (for .32)
<Sarvatt> GM45 has FBC problems on .32 and .33 too though, we're disabling it there as well soon :(
<Sarvatt> screen flicker for GM45, getting stuck on a single color screen for 915-945
<jcristau> oh thanks for doing this
<jcristau> i'm not too bothered about .32 at this point
<bjsnider> Sarvatt, did you get the nvidia 256 driver into x-updates?
<jcristau> haven't had any issues on my gm45, but apparently some guy on bugs.debian.org/580601 does
<Sarvatt> bjsnider: nope needs adjustments to the .install.in's to install all of the headers right, if you want to do it everything but that is in my nouveau ppa i linked earlier
<bjsnider> wha?
<bjsnider> i didn't understand that
<bjsnider> i just finished earlier packaging it for pre-lucid distros, and it was a pain
<Sarvatt> jcristau: yeah that guy is has the same problem as all of these - https://bugs.launchpad.net/bugs/538648
<Sarvatt> bjsnider: well the packaging tries to install things from the old locations, everything is in the root directory after you extract it now
<Sarvatt> all the headers in one place, need to manually put them in the right places in the install files
<jcristau> Sarvatt: is there a fdo or korg bug i can link to?
<Sarvatt> there's one on that bug where I upstreamed it but they haven't said anything on there
<jcristau> sigh
<bjsnider> Sarvatt, how about i take care of it here and send you the updated packaging scripts?
<jcristau> thanks
<Sarvatt> loading it up to link it
<Sarvatt> http://bugs.freedesktop.org/show_bug.cgi?id=27589
<Sarvatt> we're dropping FBC on that pci id (which happens to be the only GM45 anyway) though to work around it, odd that you dont experience it
<jcristau> a month old..
<Sarvatt> it took RAOF a few days to even see the flicker once on his
<Sarvatt> but for some people its really bad, maybe dual channel/single channel memory configuration related I dunno
<Sarvatt> would be nice of FBC was a module option that defaulted to off at this point :)
<Sarvatt> bjsnider: send me a link to the PPA or whatever, i'll copy it over :)
<Sarvatt> thanks a million if you do it btw
<bjsnider> i thought i'd just build it in pbuilder here and then email the scripts to you as a tarball.
<Sarvatt> that works if its easier for you, sarvatt@ubuntu.com
<bjsnider> very well
<bjsnider> oh my god this is a nightmare
<bjsnider> nvidia did this just to screw us over
<bjsnider> the whole directory structure of the -dev package has been lost. what should i do, just throw all of the cuda, cl, gl, and vdpau headers into one directory?
<bjsnider> or recreate the existing structure in the install script?
<bjsnider> that's what i'll do. screw them, too
<Sarvatt> bjsnider: yeah I said screw it and stopped when I saw that too :D
<Sarvatt> its just like 10 headers though, just add each one to a seperate line in the -dev.install.in and have a second section after each pointing to usr/include/CL and stuff
<Sarvatt> not sure, something like #DIRNAME#/cl.h                       #INCLUDEDIR#/#DRIVERNAME#/usr/include/CL/cl.h?
<Sarvatt> (for each one)
<Sarvatt> oh it installed everything to /usr/include/nvidia-current/foo/bar.h before
<Sarvatt> so yep that should work? just gotta get the list of where everything goes from the current from the current nvidia-current-dev
<Sarvatt> i thought it installed stuff straight into /usr/include/ hmm..
<Sarvatt> anyway thats just 11 lines like i pasted in the nvidia-current-dev.install.in, i'll try that out
<Sarvatt> oops meant #DIRNAME#/cl.h                       #INCLUDEDIR#/#DRIVERNAME#/usr/include/CL
<Sarvatt> http://pastebin.com/Bv5fcMNb
<Sarvatt> like that
<Sarvatt> gotta fakeroot debian/rules regen-from-templates after of course
<bjsnider> i'm testing now
<bjsnider> it worked hahaha
<bjsnider> Sarvatt, but the headers are only in that structure because that's how nvidia originally packaged them. if they think the headers don't need that kind of specific structure then i guess they don't
<bjsnider> vga_arbiter_workaround.patch has to be disabled as it will not apply
<Sarvatt> they do need that structure, nvidia-installer handles it now
<Sarvatt> they just shoved everything in one directory :(
<bjsnider> ok, i have it your way now except a bit shorter with wildcards
<Sarvatt> guess XF86Config.sample is gone
<bjsnider> yep
<bjsnider> ok, i just successfully installed the module
<bjsnider> so i guess the scripts i've got are appropriate
<bjsnider> i'll pack them and email them immediately
<bjsnider> or maybe i should reboot first?
<bjsnider> Sarvatt, i have emailed the scripts to you
<Sarvatt> think i've got it going too, checking the contents of every deb just incase and i'll compare to yours after
<Sarvatt> only diff in our rules - http://paste.ubuntu.com/438134/
<Sarvatt> looks like thats the only change lol
<Sarvatt> includes are screwed up
<Sarvatt> needs to go to /usr/include/nvidia-current/CL and stuff, got them in /usr/include/nvidia-current/usr/include/CL whoops
<Sarvatt> #INCLUDEDIR#/#DRIVERNAME#/CL instead of #INCLUDEDIR#/#DRIVERNAME#/usr/include/CL
<bjsnider> i changed the nv directory to kernel because of the change in nvidia's file obviously
<bjsnider> i can't really think of any good reason for them to change the locations like they did
<Bernardo> good morning
<Bernardo> Sarvatt: can you point me where to find the meego psb drivers? Do I need to clone their whole git repo? I was looking through gitorious last night and couldn't find them
<Sarvatt> what meego psb drivers?
<Sarvatt> they are internal only still
<Sarvatt> there's the kernel driver in the meego kernel-source git repo though
<Sarvatt> there are also moblin ones with the 5.1 versioning in the moblin repos
<Sarvatt> the meego ones are 5.3 and work with moorestown, meego has 5.1 with the appropriate kernel source in the src rpm (it's called like 2.6.32-msrt-rollup.patch I think)
<Sarvatt> the ones in the latest moblin release from january were the ones you probably caught me talking about that were 2D only (3D needs gallium)
<Bernardo> ok, thanks. 
<Bernardo> So those won't work with xpsb-glx?
<Bernardo> we could live a little more without 3D, if at least xv works
<Bernardo> I'll look into moblin then, since I am making no progress with freedesktop bug 28077
<Sarvatt> bjsnider: tried the drivers out yet?
<Sarvatt> i just uploaded them to x-updates since the debs look correct, wont be able to try for a few hours until the wife passes out
 * Bernardo wonders why moblin devs had to hack the struct backlight_device
<Bernardo|away> hi lucazade
<lucazade> hi Bernardo
<Bernardo> the mobline guys decision of including the module on the kernel sources is giving me a lot of trouble... :)
<Bernardo> moblin
<lucazade> are you trying moblin psb patches?
<lucazade> or meego?
<Bernardo> yes, I got their src rpms, but the patches are huge
<Bernardo> moblin for now
<Bernardo> meego doesn't have yet the xorg driver
<lucazade> ok
<Bernardo> at least that I could find
<lucazade> didn't know
<Bernardo> moblin guys decided to make a huge monolythic patch for psb
<Bernardo> and change some drm files, and also redefine backlight_device in backlight.h
<Bernardo> So I am trying to reduce the changes and build it as a dkms module,
<lucazade> could you point me to this patch? 
<Bernardo> I extracted it from the kernel source rpm, but let me pastebin it, just a sec
<lucazade> ok when possible :)
<Bernardo> this is the big one - http://pastebin.com/aCFwLe3z
<Bernardo> MRST-GFX-driver-consolidated.patch
<lucazade> huge
<lucazade> :O
<Bernardo> there is also some psb related stuff in linux-2.6.31-drm-mem-info.patch - http://pastebin.com/P2Vn6NSq
<Bernardo> I just got the 2.6.32 kernel from lucid, applied those two (correcting what wouldn't apply), then went to get it building out of tree, doing something like what is done in our current module
<lucazade> so all these patches are related to psb drivers and not to iegd.. instead the new code drop for meego is for iegd,... right?
<Bernardo> when I get it to build out of tree I'll have a go packaging it as a dkms module like the current one
<Bernardo> There is also a big monster (though smaller) for IEGD
<lucazade> *terrified*
<Bernardo> http://pastebin.com/4eWVi81E - linux-2.6.31-iegd.patch
<Bernardo> I left that one for you... ;)
<lucazade> heheeh
<lucazade> this stuff is known to work?
<Bernardo> I think so - at least 2D
<Bernardo> [05:36:47] <Sarvatt> the ones in the latest moblin release from january were the ones you probably caught me talking about that were 2D only (3D needs gallium)
<lucazade> ok now is a bit clearer
<Bernardo> I had to re-add a definition ubuntu had removed from drmP.h (DRM_PROC_PRINT)
<Bernardo> later will see if I can remove that again and the calls to it
<lucazade> tell me if i can help you
<Bernardo> I'm fighting the makefile now... It seems easier to put all stuff in a single dir like the old module
<bjsnider> Sarvatt, the build failed. your rules file is wrong in the 32-bit compat libs section. nvidia has removed some of the 32-bit compat libs.
<bjsnider> the rules file i sent works
 * Bernardo hates monolythic patches
 * Bernardo gives up on moblin drivers for today
<Sarvatt> still can't find libXvMC.so.1
<Sarvatt> dont tell me that got moved to an alternative somewhere too..
<tjaalton> libxvmc1: /usr/lib/libXvMC.so.1
<tjaalton> apt-file search is your friend
<Sarvatt> oh dangit I know the problem, I was adding the dep to the control not the control.in so it was getting removed
<bjsnider> i already took care of this in my scripts
<bjsnider> Sarvatt, did you remove the .so.1 links too?
<Sarvatt> weird, glxinfo takes about 15 seconds to complete and I'm getting (WW) May 23 13:34:59 NVIDIA(0): WAIT (1, 6, 0x8000, 0x00004758, 0x00004858) in xorg.0.log when it happens, everything stalls
<bjsnider> it's fine here
<Sarvatt> i get it with 195 too apparently :(
<Sarvatt> bjsnider: are you on karmic still?
<bjsnider> negative
<bjsnider> have you got an old card?
<bjsnider> what opengl version does glxinfo give you?
<bjsnider> mine is 3.3
<Sarvatt> 8400M GS, 3.3 here too
<Sarvatt> can you pastebin your ~/.nvidia-settings-rc?
<bjsnider> http://pastebin.com/YkT7Ax4E
<bjsnider> 'it's just defaults though
<Sarvatt> 4x anisotropy and 12x FSAA is default?
<Sarvatt> and texture sharpening enabled?
<bjsnider> well, i have those things on full blast
<bjsnider> everything else is default
<bjsnider> besides i doubt any of those settings make any difference
<bjsnider> except on windows
<Sarvatt> enabled MSI and it's down to about 3 seconds for the freeze
<Sarvatt> no, it didn't take the module parameter so its just luck it was faster that boot
<Sarvatt> this doesn't happen on a 32 bit livecd with nvidia-current installed, ugh
<bjsnider> is it really an irq issue though?
<Sarvatt> its hanging polling the performance profile state looking at the strace
<bjsnider> is it on a shared irq?
<Sarvatt> nope
<bjsnider> have you got a crap system there?
<bjsnider> maybe the hardware's broken
<Sarvatt> it worked fine for years with <=190 drivers
<bjsnider> maybe it's the x server
<bjsnider> what happens in karmic?
<bjsnider> have you got any crazy stuff in the xorg.conf?
<Sarvatt> its fine, its fine on a 32 bit livecd too
<Sarvatt> nope stock
<Sarvatt> thats highly annoying :) i forgot i disabled compiz because of this problem when we moved to 195 series
<Sarvatt> 14 seconds to open the display 8 seconds to quit after it displays everything for glxinfo
<bjsnider> is the cpu spiking at that point?
<bjsnider> i don't see what the difference is in this context between a livecd and a hdd install
<coz_> I know I have lucid on a 64 bit system with 32 bit install  ...also had 64  bit install with no issues with the 195.xx.xx drivers on either and no compiz issues..just thought I would comment :)
<bjsnider> i think he has a hardware problem
<coz_> I would guess the same
<coz_> although the inability to install official nvidia drivers is a real  down side of lucid at this point  in terms of testing drivers for hardware configuration
<Sarvatt> the livecd install is 32 bit my install is 64
<Sarvatt> i give up on those darn 256 drivers for now, gnome panel is corrupted horribly every single boot too
<Sarvatt> the whole display blinks on and off real quick when glxinfo is done showing the info before it actually quits too (was testing things remotely and didnt notice)
<Sarvatt> ah should try nvidia-173 out
<Sarvatt> hmm the panel corruption looks exactly like this guys - http://www.nvnews.net/vbulletin/showthread.php?t=149361
<Sarvatt> oh jeeze dont tell me https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/456637 is affecting me too
<Sarvatt> i might as well use nouveau if i have to use the highest perf state
<bjsnider> Sarvatt, did you change powermizer settings like recommended in that thread?
<Sarvatt> not yet, had to give the laptop back :)
<Sarvatt> i'm just going to edit the video bios so the highest power state is the medium one if it does work
<bjsnider> well, on that train of thought, my card doesn't have power management options because of a chip on the board being locked in position or whatever. so my card is always on full blast
<bjsnider> and that might explain why mine works
 * Sarvatt nods
<Sarvatt> i mean i see it hung polling the power state info when i strace glxinfo
<Sarvatt> just didnt have time to test forcing it
<bjsnider> of course forcing a laptop gpu to full throttle isn't helpful in terms of power usage
<bjsnider> nouveau is always on fullthrottle too so i bet nouveau works fine
<Sarvatt> yeah, will try out 173 too incase that works
<Sarvatt> it a huge hit, over 1.5 hours less battery life at max speed
<Sarvatt> maybe i'll see how low i can push the GPU voltage at max speed instead, this GPU overclocks like crazy so it might have the headroom to go a lot lower
<bjsnider> the changelog for the 256 blob doesn't explicitly say they fixed the powermizer issue
<Sarvatt> i had it stable at 640mhz core clock up from 400mhz at one point with default voltages
<Sarvatt> the windows drivers always were horrible at powermizer crap
<Sarvatt> had to use specific releases because it was broken for months at a time
<bjsnider> if the windows drivers were bad at it then i wonder if the problem is the shared code instead of anything linux-specific
<bjsnider> or perhaps it's a design flaw
<coz_> could be the card itself ?
<coz_> could be the power supply is diing also.... change power plugs on the card to see if that helps incase it is just a bad plug
<bjsnider> yes but this is a laptop
#ubuntu-x 2011-05-16
<tjaalton> way to go mandriva.. only svn+ssh checkouts possible
<cnd> Sarvatt: have you uploaded the patch I sent you for x input coordinate transformation to xorg-edgers?
<cnd> I was wondering if there have been any regressions noted
<cnd> if not, I'm going to push to SRU it
<Sarvatt> cnd: yeah I did about an hour after you asked and only responded in IRC, sorry about that
<cnd> I may have just forgot :)
<cnd> thanks!
<Sarvatt> haven't heard any regressions and i've been dogfooding it for weeks now :)
<cnd> good
<Sarvatt> cnd: synaptics is being a PITA though, i've been trying to reproduce this since I got back -  https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/774978
<ubot4> Launchpad bug 774978 in xserver-xorg-video-intel (Ubuntu) "xserver seg'd [945GM] (affects: 18) (dups: 4) (heat: 112)" [High,Incomplete]
<cnd> hmm
<Sarvatt> looks like its just machines that were affected by the 100% cpu usage bug
<cnd> ugh
<lilstevie> bleh
<lilstevie> cnd: samsung still hasn't released the damn source
<cnd> lilstevie, that's alright
<lilstevie> heh not for me it isnt
<cnd> they'll probably release it after they release gingerbread
<cnd> why not?
<lilstevie> they have already released it in ita
<cnd> ita?
<lilstevie> thats why I have been pushing for it
<lilstevie> italy
<cnd> oh
<lilstevie> samsung have cleaner code
<lilstevie> in the new codebase
<apw> can anyone point me at documentation on having per keyboard layouts
<tjaalton> apw: not sure that's even possible
<apw> tjaalton, hmm someone mentioned it was, but it was hard last time i asked ... i think
<tjaalton> ok...
<jcristau> setxkbmap has a -device option
<bjsnider> ricotz, i'm getting prompts about a partial upgrade because it's holding back gedit and gnome-system-monitor
<bjsnider> nm, fixed it
<ricotz> bjsnider, good ;)
<bjsnider> ricotz, what is the point of having a huge libgweather package when there doesn't seem to be any way of displaying all the data it is supposed to collect?
<ricotz> bjsnider, i think there will be a gnome-shell-extensions with a dedicated weather information panel or a more sophisticated date-time-panel soon if there isnt already
<ricotz> s/panel/drop-down-thingy ;)
<bjsnider> it had better display a lot of weather info, because libgweather is huge for something that's supposed to be scraping google or whatever for weather info
<bjsnider> i'm expecting it to predict the weather for the next 100 years
<ricotz> heh
<bjsnider> "Estimated disk space required: 254 MB"
<ricotz> hmm, havent noticed this size amount
<bjsnider> http://www.linuxfromscratch.org/blfs/view/svn/gnome/libgweather.html
<bjsnider> apparently that's how much space is required if you build it from source
<ricotz> this looks more like the build-environment usage
<ricotz> yes
<bjsnider> the final package is still bigger than a web browser. it's almost twice the size of chromium
<bjsnider> i find that highly strange
<bjsnider> the only thing the description says it is doing is collecting weather info from online sources
<ricotz> bjsnider, it includes the weather station location for every locale
<ricotz> doesnt seem to be compressed well though
<cnd> bryceh_, is there a schedule for SRUs for xorg-server?
<cnd> I have a patch I want to push in
<cnd> still need to format the bug for the SRU and such, but I'm wondering if you are meaning to upload one soon
<cnd> so I have a deadline :)
<cnd> ahh, now I'm remembering the SRU process
<cnd> I need to get the fix into oneiric first
<cnd> I guess I'll bug you after that :)
<cnd> bryceh_, ok, I've pushed the patch to the ubuntu branch for it to be uploaded to oneiric
<albert23> Sarvatt: there is no need to get RSI from trying to reproduce the x crash. The crash generally happens in less then 10 attempts for me.
<albert23> Most important is to make sure both RecordAReply and DRI2WaitMSC are being hit (breakpoints in gdb).
<albert23> synaptics must be installed an active, i.e.  you will need a touchpad
<albert23> If you are not using synaptics from the archive, make sure it has record included (was build with libxtst-dev). Otherwise you have my current fix :-)
#ubuntu-x 2011-05-17
<Sarvatt> albert23: yeah disabling record in synaptics is what I was mentioning that we could do to work around it at UDS, definitely think we should go that route
<tjaalton> Sarvatt: so edgers mesa has llvmpipe?
<tjaalton> hmm doesn't pull llvm, so probably no
<pcjc2> hi guys...
<pcjc2> does anyone know who to ping (on IRC) about a unity bug?
<pcjc2> Unity breaks tablet input with gimp for some reason
<pcjc2> I'm hoping to track the problem down, as it is rather nasty
<tjaalton> pcjc2: i guess didrocks would be one candidate, when he's online
<tjaalton> pcjc2: but start with a bugreport :)
<pcjc2> meh - overrated, I like to know where the bug lies before filing ;)
<pcjc2> ideally with a  patch to attach
<pcjc2> currently debugging it from the gimp end, as it may well be  a gimp bug
<tjaalton> can you reproduce with classic session
<pcjc2> no - fixes it nicely
<pcjc2> (Rather.. metacity --replace fixes it)
<pcjc2> something to do with grabs breaking
<pcjc2> Apparently certain xscreensaver versions have the same effect
<pcjc2> I'm actually quite liking Unity now I'm getting used to it
<tjaalton> well, doesn't hurt filing against unity now, and let the devs toss it on our side if they think it's something else :)
<pcjc2> still a few bugs, but its coming along nicely
<pcjc2> Wish NVidia could make a driver which doesn't suck though - I can't believe they still can't do rotation of a single monitor in Twinview
<tjaalton> bug 740933 i guess?
<ubot4> Launchpad bug 740933 in xorg-server (Ubuntu) "Option "RandRRotation" "true" added to xorg.conf, ot rotation option with nvidia XServer settings, but it does not work (affects: 1) (heat: 12)" [Medium,Triaged] https://launchpad.net/bugs/740933
<tjaalton> with a patch
<pcjc2> not bug 740933
<ubot4> Launchpad bug 740933 in xorg-server (Ubuntu) "Option "RandRRotation" "true" added to xorg.conf, ot rotation option with nvidia XServer settings, but it does not work (affects: 1) (heat: 12)" [Medium,Triaged] https://launchpad.net/bugs/740933
<pcjc2> according to the driver docs, it just isn't supported - you can't rotate one of the two twinview monitors
<tjaalton> ah
<pcjc2> the nearest you can do is a Xinerama setup, but then the composite extension breaks
<pcjc2> xrandr doesn't work etc..
<pcjc2> I'm looking forward to good open source drivers being able to support the 3D, that or NVidia deciding to do proper xrandr support
<raevol> anyone know anything about the xorg-edgers ppa? adding it to my repos doesn't seem to pull the kernel update
<raevol> i see the kernels available in the ppa, but linux-generic stays at the kernel version available in the ubuntu repo
#ubuntu-x 2011-05-18
<bryceh_> raevol, you'd need to specifically install it; nothing in the ppa has a direct depend on it so it won't get pulled in automatically
<raevol> bryceh_: even though the note on the package says not to specifically install it?
<bryceh_> raevol, I'm fairly sure, but sarvatt could tell us for certain
<RAOF> The package description is copied from the main archive one which, indeed, you don't want to install explicitly.
<RAOF> But in edgers you do, because we don't upload a new linux-meta that would pull it in.
<bryceh_> the edgers docs could stand some freshening
<bryceh_> tjaalton, I've pushed the xorg changes to migrate failsafex and the apport hook; would appreciate your review, I had to fight with git a bit to get it in
<tjaalton> bryceh_: the failsafex-extraction -branch? yeah new branches need force to push them to origin
<tjaalton> hum no, I think the other branch was mistakenly pushed, and the ubuntu branch already has the changes?
<tjaalton> looks like there are some changes in the extraction-branch that need to be merged with ubuntu
<tjaalton> em, pulled to ubuntu
<tjaalton> bryceh_: so the versioning at least is messed up :)
<tjaalton> natty has 1:7.6+4ubuntu5, while the current git has u4
<tjaalton> and natty didn't get u4 at all
<tjaalton> and sru's should use X.N
<tjaalton> and be in their own branch, IMO, but that hasn't been discussed
<tjaalton> that's the only way we'll be able to keep sanity when doing point-release updates
<tjaalton> bryceh_: also, I think we should use name the patches as '.diff', so git will complain if you haven't added it
<tjaalton> re: libxi missing a patch from git
<tjaalton> and xorg-server upload not pushed :)
<tjaalton> to git
<tjaalton> bryceh_: sorry, now I saw the natty upload, and it has 4ubuntu3.1 which is correct
<tjaalton> and indeed there is no xorg upload to oneiric yet, so ubuntu4 is the right version for it
<tjaalton> just got confused about the other branch
<tjaalton> bryceh_: so I'll just merge the failsafe-branch and delete it from origin, i believe you pushed it by mistake
<janimo> what is a good tool to monitor/debug X window messages in a running session, seeing which window/app sent what and when
<tjaalton> janimo: can't think of one, but iirc there was something similar that I accidentally bumped into recently..
<tjaalton> if only i could remember the name
<janimo> tjaalton, I saw xmsgtrace but it is old and not packaged so I suspected there must be something better
<tjaalton> janimo: well, if it does the job then use it :)
<janimo> tjaalton, did not try it yet, hence my inquiry for one that can be apt-get installed first
<cnd> bryceh_, thanks for uploading the xorg-server with the fix to oneiric
<cnd> for natty, would you be able to upload an sru to proposed for me?
<cnd> do you want me to generate the package, or is that simple enough for you to do?
<cnd> should just be a changelog edit from 2:1.10.1-1ubuntu2 to 2:1.10.1-1ubuntu1.1 and oneiric to natty-proposed right?
<tjaalton> yep, and preferably in another branch
<tjaalton> *in a branch of its own
<cnd> tjaalton, ahh yes, I'll make a new branch
<tjaalton> note that the current branch doesn't have the commit closing the version
<tjaalton> which isn't an issue in this case though
<tjaalton> and, I have another patch to push there
<tjaalton> for an sru
<cnd> tjaalton, the current branch has been released
<cnd> just fyi
<tjaalton> released yes
<cnd> wasn't sure if you knew that
<tjaalton> oh wait, maybe I'm trusting debian-x@ commit logs too much
<cnd> tjaalton, bryceh_: I just pushed a new branch ubuntu-natty
<tjaalton> nope, the ubuntu branch is still UNRELEASED
<bjsnider> why does natty have a 2 year old version of ia32-libs?
<ScottK> It doesn't.
<jcristau> it just has a silly version number
<ScottK> https://launchpad.net/ubuntu/+source/ia32-libs/20090808ubuntu13 <-- Less than a month old.
<bjsnider> it is not 20090808 at the present time, and it hasn't been for almost 2 years
<bjsnider> and it's not likely to be 2009 again any time soon
<bjsnider> debian packages that depend on 20101012 are uninstallable
<bryceh_> bjsnider, the package itself is from 2009 but the contents have been updated with newer packages.  So like jcristau says it's just a silly version number, not an indication of internal ancientness
<bjsnider> bryceh_, i understand, but by not syncing the version number with debian, the debian packages built around the newest version there fail to install because of dependency issues
<jcristau> so don't install debian packages on ubuntu
<tjaalton> it's hopefully going away this cycle
<tjaalton> bryceh_: did you get my msgs from earlier today? you forgot to git push xorg-server
<bryceh_> tjaalton, no missed that
<bryceh_> tjaalton, there's no changes though, only a changelog bump
<tjaalton> bryceh_: right, just wanted to let you know :)
<tjaalton> i have pending patches
<tjaalton> to push
<bryceh_> pushed
<tjaalton> thanks
<tjaalton> well, patch
<bjsnider> tjaalton, the package in question doesn't exist in ubuntu
<tjaalton> bjsnider: i meant ia32-libs gets removed iff multiarch is finalized by 11.10
<bjsnider> tjaalton, i didn't even know multiarch was on the table for oneiric.
<tjaalton> natty already has some of it completed
<tjaalton> bryceh_: also, did you mean to push the ubuntu-failsafe-extraction -branch to alioth?
<bryceh_> tjaalton, is that a problem?
<bryceh_> tjaalton, it's no longer needed if you want to remove it
<tjaalton> bryceh_: no, just wondering since there only is a few lines diff
<tjaalton> the ubuntu proper is missing the removal of po-failsafe and dh_installinit failsafe-x
<tjaalton> but that's all
<bryceh_> tjaalton, if you were just wondering if yesterday I was finding git frustrating, well the answer would be an affirmative
<tjaalton> well merging changes to the changelog surely will make you feel miserable :)
<tjaalton> i bet no vcs would be different there
<bryceh_> hmm, po-failsafe is not in my local copy
<tjaalton> of the ubuntu-branch?
<bryceh_> yeah
<tjaalton> hang on, I'll pastebin the diff
<bryceh_> well, the most frustrating bit was deleting debian/apport/source_xorg.py
<tjaalton> http://paste.ubuntu.com/609677/
<tjaalton> maybe I'm reading the diff wrong :P
<tjaalton> grah, yeah
<tjaalton> damnit
<tjaalton> so, no worries, I'll just purge the extraction-branch
<bryceh_> (dammit is spelt without an n; go english consistency)
<bryceh_> ok, so no other changes needed in the branch?
<bryceh_> if it looks ok, should I go ahead and push it, or should I wait until xdiagnose is in main?
<tjaalton> maybe I'll check it out properly tomorrow, this kinda held me back so I did other things
<tjaalton> well, not maybe, but definitely :)
<bryceh_> tjaalton, also review 7eda07c4dea6e6f2ae6e6892bf6f77af0834f231 on -intel
<tjaalton> bryceh_: sure thing
#ubuntu-x 2011-05-19
<fei> Hello,e'rbody
<fei> I'm a kubuntu user from China
<fei> anyone here?
<fei> hi,dantti
<RAOF> tjaalton: I don't think the nvidia/fglrx blacklists won't actually affect nouveau/ati.  They end up explicitly loading the kernel driver, which should bypass the blacklist, right?
<RAOF> tjaalton: That said, doing that will likely race and will not necessarily do anything but make X explode as nouveau initialises before KMS is fully up, bails, and then VESA stomps all over KMS state.
<tjaalton> RAOF: then why do they install the blacklist if it doesn't work ?-)
<RAOF> tjaalton: Because it prevents *autoloading* by pciid.
<RAOF> So without the blacklist there's a race between nvidia and nouveau kernel modules, and whichever loads first locks the other one out.
<tjaalton> ok, so nouveau would load anyway if nvidia wouldn't autoload?
<RAOF> Now that we no longer install an xorg.conf, I think the answer is âyesâ.
<tjaalton> ookay
<RAOF> This sounds like a job for The Experimental Methodâ¢!
<tjaalton> :)
<RAOF> Although I don't think I've got a system fast enough to break with the kernel/DDX kms race.
<RAOF> But first, to the running around!
<tjaalton> i need to get my head around the race thingy, last week was the first time I heard about it
<RAOF> Which race?  The kms/DDX race?
<tjaalton> that
<tjaalton> you mean the xserver might start before kms is up?
<RAOF> Yes, absolutely.
<tjaalton> ugh..
<RAOF> I'm *sure* I've seen you comment on bugs where this has happened :)
<tjaalton> ok, bad memory then :)
<RAOF> Particularly - if the module is blacklisted, then it'll only start to get loaded once X has loaded the DDX.
<tjaalton> i do have an ssd system, though the cpu isn't on par with the disk
<tjaalton> now that part i don't get, that how it'll still load the module if it's blacklisted
<tjaalton> but I guess it's easy to test
<tjaalton> if no nvidia, X will try nouveau, and then it would forcibly load nouveau.ko?
<tjaalton> hmm right
<tjaalton> modprobe.d blacklisting doesn't prevent 'modprobe foo' from working
<tjaalton> maybe I'll delete the comment from the blueprint then
<tjaalton> done
<tjaalton> would be great to have a diagram of all the various ways to break the system, then it would be easier to plan the failsafe stuff so that it's more robust
<RAOF> tjaalton: :)
<bryce> or some sort of artificial way of reproducing those conditions so we can write a test suite
<cnd> bryce, tjaalton: do you know what the timeline is for an upload to natty-proposed for xorg-server?
<cnd> I just got another email about the coordinate transformation bug that's waiting to be pushed
<bryce> cnd, if you have a branch set up with the change I could upload it right now
<cnd> bryce, it's up
<cnd> ubuntu-natty
<cnd> in the git repo
<tjaalton> yeah fine by me to upload it now
<cnd> cool
<bryce> uploaded
<cnd> bryce, ta
<tjaalton> bryce: bad release :)
<bryce> sigh
<bryce> reuploaded
<bryce> stupid git won't let me push the branch change
<tjaalton> what does it say?
<bryce> $ git push origin ubuntu-natty
<bryce> To ssh://bryce-guest@alioth.debian.org/git/pkg-xorg/xserver/xorg-server.git
<bryce>  ! [rejected]        ubuntu-natty -> ubuntu-natty (non-fast-forward)
<bryce> error: failed to push some refs to 'ssh://bryce-guest@alioth.debian.org/git/pkg-xorg/xserver/xorg-server.git'
<bryce> To prevent you from losing history, non-fast-forward updates were rejected
<ubot4> bryce: Error: I am only a bot, please don't think I'm intelligent :)
<bryce> Merge the remote changes (e.g. 'git pull') before pushing again.  See the
<bryce> 'Note about fast-forwards' section of 'git push --help' for details.
<tjaalton> have you done rebases on your local tree?
<bryce> no, just git commit --amend
<tjaalton> http://stackoverflow.com/questions/253055/how-do-i-push-amended-commit-to-the-remote-git-repo
<tjaalton> it rewrites the history, so you need to force it
<tjaalton> and don't amend in the future :)
<tjaalton> if you've already pushed
<tjaalton> maybe this is why things have failed in the past?
<bryce> it's probably the source of the problem I had yesterday.  Didn't realize --amend was actually useless post-push
<tjaalton> in this case forcing the update would only break my local three, but that's probably ok :)
<bryce> no, I didn't want to do that, I just started over as a regular commit
<tjaalton> and force that?
<bryce> no force needed
<tjaalton> ah, there it is
<tjaalton> yeah looks good now
<bryce> evidently I should hold off on pushing ;-)
<tjaalton> on the contrary, more practice :)
<bryce> how many years have I been using git?  it's still such a time sink for me
<bryce> 1 minute to upload something, 30 min to fight git to let me commit it
<tjaalton> do a change, dch, debcommit -a, git push origin
<tjaalton> that's it, and don't use .patch but .diff for patches :)
<tjaalton> so git status will complain loudly
<tjaalton> about files not added to the branch
<bryce> don't you have to do 'git push origin ubuntu'?
<tjaalton> well yeah if you just want to push that branch, it'll just complain if the other branches are not uptodate
<bryce> I dislike the idea of using .diff instead of .patch.
<tjaalton> why?
<tjaalton> they are in debian/patches, so the path tells they are patches
<bryce> 'patch' is descriptive of what the file is, 'diff' just indicates how it was produced
<bryce> seems like it would be better to just make git stop rejecting .patch files
<tjaalton> besides, libxi git doesn't have the latest patch
<tjaalton> bryce: that change would have to be made to every .gitignore where we have an ubuntu branch, not that practical
<bryce> tjaalton, we typically add patches to only a handful, and could be done on a case-by-case basis as needed.  not that big of a deal
<tjaalton> mmh, i don't like case-by-case decisions, it's either-or :)
<bryce> actually looks like we can just add debian/patches/.gitignore with "!*.patch"
<tjaalton> it's still ugly, for the sake of a postfix
<bryce> aha, figured it out
<bryce> can be set globally
<tjaalton> that's good then
<bryce> hmm, can be set globally but project level .gitignore always takes precedence :-/
<tjaalton> bryce: ah..
<tjaalton> i'll upload current xorg-server git to oneiric, need to get the patch there too
#ubuntu-x 2011-05-20
<tjaalton> hum, https://wiki.ubuntu.com/DebuggingXorg and https://wiki.ubuntu.com/X/Backtracing seem identical
<tjaalton> i'll delete the former
<tjaalton> wow, X/Config/Input was way out of date, refreshing
<RAOF> tjaalton, bryce: I'd appreciate some review for the latest commit on xkb-data on pkg-xorg.
<tjaalton> checking
<tjaalton> RAOF: i guess you've tested this :)
<RAOF> It's not quite enough, obviously; it also requires that console-setup gets reconfigured.
<tjaalton> the debconf values? yes
<RAOF> tjaalton: Indeedy.  Perhaps not quite *enough*, but it's certainly tested.
<tjaalton> value
<tjaalton> hmm you already set the debconf value, what's left for console-setup?
<tjaalton> actually, doesn't this belong there to begin with?
<RAOF> Rebuilding the initramfs if necessary.
<RAOF> The problem is that console-setup doesn't have the necessary information; I'd have done it there if it did.
<RAOF> This change needs to be made on the transition from xkb-data < 1.9 to xkb-data > 1.9, and console-setup can't know that in it's postinst.
<tjaalton> well, we could check what versions of console-setup was used with 1.9?
<tjaalton> anyway, if cjwatson is ok with this then I am too
<RAOF> Hm, and infer?  There's a very weak version dependency there, but I guess it's not an unreasonable herustic.
<RAOF> I'll run it past cjwatson too :)
<tjaalton> isn't the compare-versions logic reversed there though, lt-nl means <<
<tjaalton> hum no
<tjaalton> $2 is the installed version, duh
<RAOF> This would be why I call for review, yes :)
<tjaalton> checked x11-common.postinst, so your version should be correct
<tjaalton> bryce: ok, reviewing xorg atm
<tjaalton> x11-common.preinst.in removes "/etc/gdm/failsafeXBackup", when it should probably be "/etc/gdm/failsafeBlacklist"
<tjaalton> hmh, and I still have all the old files on my desktop that were supposed to be purged by -4ubuntu1
<tjaalton> bryce: also make sure that xdiagnose has Replaces/Breaks x11-common (<< 1:7.6+4ubuntu4)
<tjaalton> hmm, installing the new version didn't remove any of the conffiles
<tjaalton> and how could it, since the script doesn't even have remove_conffile_commit() :)
<tjaalton> something wrong with the build
<tjaalton> yeah "#INCLUDE_SHELL_LIB#" doesn't expand
<tjaalton> grr, my fault :)
<tjaalton> hum no, weird
<tjaalton> for some strange reason remove_conffile_commit doesn't work on the failsafe-stuff :/
<tjaalton> argh
<tjaalton> would make sense to use the functions as advised
<jcristau> there's dpkg-maintscript-helper(1) these days which may (or may not) be better than the xsfbs functions
<tjaalton> so it seems
<tjaalton> well, i guess the xsfbs version is more familiar at this point, now that I can see how it's supposed to work
<tjaalton> sigh
<tjaalton> bryce: I'll fix those issues that I mentioned, since the x11-common.post/pre* -scripts are broken because of my bad example :)
<tjaalton> yeaahaw, no more /etc/gdm/failsafe*
<tjaalton> bryce: pull the new version from git, it should be ok and removed all the conffiles here
<tjaalton> nice, been playing my music collection on random since early february, and now I have 27 songs left that all make banshee crash
<tjaalton> or most of them anyway
<bryce> tjaalton, great thanks
<Sarvatt> hrm, stable 270.41.19 or beta 275.09 for x-updates I wonder..
<Sarvatt> 270.41.19 it is, will put 275 in another PPA. its going to have problems because debian/nvidia_supported stopped working for extracting the pci ids from the blob
<Sarvatt> tseliot: I'm not sure just using the pci ids in the readme is a good idea, missing 242 ids.. DEBUG: readme:413 object:655 deletions:0 additions:242
<Sarvatt> oh whoops he's gone
<bjsnider> that script will have to be updated
<bjsnider> i don't understand this line "Fixed a bug that caused corruption on the menus in OpenOffice.org when the screen is rotated."
<bjsnider> since when cant he screen be rotated in linux?
<Sarvatt> it's just been broken since december
<Sarvatt> http://cgit.freedesktop.org/xorg/xserver/commit/?id=d1107918d4626268803b54033a07405122278e7f broke rotation with the blob and went to the stable xserver branches
<bjsnider> i didn't know the blob had introduced xrandr support
<bryce> xorg/xorg-ubuntu-git$ git pull
<bryce> ssh: connect to host alioth.debian.org port 22: Connection refused
<bryce> fatal: The remote end hung up unexpectedly
<bryce> git.debian.org down?
<Sarvatt> yeah been down for a few hours now
<jcristau> http://lists.debian.org/debian-infrastructure-announce/2011/05/msg00000.html
<bryce> ah
<bryce> oh, already -fglrx has broken for oneiric?  that didn't last long...  bug #776895
<ubot4> Launchpad bug 776895 in fglrx-installer (Ubuntu) "fglrx 2:8.840-0ubuntu4 fails to build against 2.6.39 kernels, due to missing linux/smp_lock.h (affects: 3) (heat: 16)" [Undecided,Won't fix] https://launchpad.net/bugs/776895
<Sarvatt> I'll fix the build in x-updates for now and point tseliot at the fix, just updated it to 8.850 in there about 20 minutes ago
<bryce> Sarvatt, thanks
<bryce> Sarvatt, btw didn't you mention a fix you ran across that'd solve bugs like 762080?
<Sarvatt> nope doesn't sound familiar :( are you thinking of the _CallCallbacks one that needs libxtst-dev removed from the build deps for x-x-i-synaptics to work around so synclient doesn't use record?
<Sarvatt> (bug 774978)
<ubot4> Launchpad bug 774978 in xserver-xorg-video-intel (Ubuntu) "xserver seg'd [945GM] (affects: 26) (dups: 8) (heat: 160)" [High,Incomplete] https://launchpad.net/bugs/774978
<Sarvatt> hmm catalyst 8.850 might already work with .39 looking at it
<Sarvatt> dont see it including <linux/smp_lock.h> that was causing the problems in 8.840
<Sarvatt> darn, there it is
<Sarvatt> phew that took forever due to wonky dkms install paths but got fglrx patched up, someone else is going to have to test if it actually works though :)
<Sarvatt> Building initial module for 2.6.39-1-generic-pae
<Sarvatt> Done.
<Sarvatt> uploaded it for oneiric and natty to x-updates
<liviumirea> hello
<liviumirea> i just updated nvidia-current to the latest version 270.41.19 that was released a few hours ago and now the GLX module fails to load
<liviumirea> can anyone offer some help? :-s
#ubuntu-x 2012-05-14
<clement_> Hello guys. I have an Elantech touchpad on an Asus Zenbook running 12.04 kernel 3.2.0-24-generic and the touchpad suddenly stopped working few hours ago. It no longers appears in /proc/bus/input/devices and xinput can't see it neither. Any idea on how to have it back ? Thanks.
<tjaalton> does dmesg show something related
<clement_> It doesn't seem :-(   http://pastie.org/3909615
<tjaalton> right, what about the xserver log, does it show it unloading the driver?
<clement_> I can't see anything about it :-(   http://pastie.org/3909642
<tjaalton> ah, so it doesn't work after reboot either?
<clement_> Neither :-(
<tjaalton> ok, hardware problem then
<clement_> F*** !!!
<clement_> I'm gonna boot on the windows recovery partition see if it works.
<clement_> See you  o/    Thanks for diagnose.
<bgamari`> bryceh: ping
<bgamari`> RAOF: ping
<bgamari`> bryceh, RAOF, We're waiting on some sort of acknowledgement on bug #980017
<ubottu> Launchpad bug 980017 in xserver-xorg-video-intel (Ubuntu) "[i965gm] GPU lockup render.IPEHR: 0x02000004" [High,Triaged] https://launchpad.net/bugs/980017
<bgamari`> it should just be a cherry-pick yet it's been a month since I identified the fix and yet precisely nothing has happened
<bryceh> bgamari`, we're quite busy with other things, but I can take a look for you.
<bgamari`> bryceh: I would appreciate it greatly
<bryceh> bgamari`, done
<bgamari`> bryceh: Thanks! I'll make it into Precise eventually I take it?
<bryceh> bgamari`, depends on if someone tests/verifies it out of precise-proposed
<bryceh> but I've filed the sru and uploaded the candidate package for proposed, so the engineering for that is completed.
<bryceh> bgamari`, once it's accepted into -proposed, the more testing feedback you can drum up, the sooner it will get released.
<bgamari`> bryceh: alright, excellent. Thanks again!
<RAOF> bryceh: You seem to have uploaded mesa to precise-updates rather than precise-proposed.  That's a mistake, I take it?
<bryceh> RAOF, hrm, indeed
<RAOF> Rejected from the queue :)
<bryceh> reuploaded
 * RAOF will get to that after processing the proposedâupdates queue.
<bryceh> RAOF, btw when you were going through your packaging tutoring with mlankhorst the other day it occurred to me that we should have some of that workflow documented
<bryceh> RAOF, would you mind adding a "Cherrypicking from upstream git tree" section to https://wiki.ubuntu.com/X/GitUsage ?
<bryceh> I'm also a bit curious because it sounds like  you have a slightly different (and likely more efficient) workflow than I
#ubuntu-x 2012-05-15
<RAOF> What I'd *really* like to do is to git cherry-pick -x on the ubuntu branch, but we don't do that :)
<RAOF> I'll document what I do on that wiki page.
<bryceh> awesome
<RAOF> Also, mesa accepted.
<mlankhorst> morning
<tjaalton> same
<RAOF> Good morning :)
<tjaalton> i was actually up 1:30-5:00, not a great idea to take a nap yesterday :P
<bryceh> heya
<LLStarks> i'm on the 5am to 2pm sleep schedule
<LLStarks> D:
<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
<LLStarks> thesis writing is hell
<tjaalton> oh that was fun
<tjaalton> not really, but still
<LLStarks> tjaalton, can we coerce keithp to merge the new api this year?
<LLStarks> saying no in may seems really shortsighted
<tjaalton> LLStarks: well I didn't read it literally
<tjaalton> "I'll sit down this week and look them over more carefully" to me sounds like he'll review it soon
<LLStarks> everything that gets pushed to 2013 gets pulled into the cluster**** of wayland/xwayland, classic x11, x12 in 2013
<tjaalton> and it already got acks from alanc and aaronp
<tjaalton> the first push that is
<tjaalton> real meat coming later
<LLStarks> nvidia as an early adopter? i like
<bryceh> well, ack != adopt
<tjaalton> still
<bryceh> right, it's good news in any case.
<bryceh> keithp is amenable to prioritization; might be worth mentioning the importance of this for us to him.
<tjaalton> sure, though I do believe he knows the importance already :)
<mlankhorst> Do I need to do anything special to show up in http://status.ubuntu.com/ubuntu-quantal/people.html ?
<RAOF> Have work items assigned to you, I think.
<RAOF> So you should turn up next time the generator is run, I guess ;)
<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?
<RAOF> (For EGL-compiz)
<mlankhorst> full vsync or just swap buffers?
<RAOF> I think just swap buffers.
<mlankhorst> atm im just playing with blueprints, how do I assign one to multiple people?
<mlankhorst> It seems to barf on this: [tjaalton, mlankhorst] build a ppa with the new api for testing: TODO
<tjaalton> ah
<mlankhorst> oh woops that worked, it was just missing TODO before
<RAOF> Oh, that works?
<RAOF> I didn't think you could assign work items to multiple people.
<tjaalton> i'm equally surprised:)
<mlankhorst> hm maybe not
<mlankhorst> shall I just assign it to the team then?
<tjaalton> or me
<tjaalton> running build.sh..
<tjaalton> just for the heck of it
<mlankhorst> sure
<mlankhorst> RAOF: if still awake, should hybrid graphics work item be coalesced into desktop-q-xorg-general?
<tjaalton> nah
<mlankhorst> k
<tjaalton> it's useful for the hwe tasks
<tjaalton> oh you added the notes there, thought it was my task :)
<mlankhorst> its yours if ou want to work on it >:D
<tjaalton> thanks for those, I'll edit it further as needed
<tjaalton> regarding ARB_robustness, it's mentioned in mesa 7.11 relnotes, so maybe that should be removed from the list+
<tjaalton> ?
<mlankhorst> I changed it to investigate
<tjaalton> ahh right
<mlankhorst> might be worth seeing if it can be triggered somehow for testing
<tjaalton> yup
<mlankhorst> toying around a bit with dummy packages atm
<mlankhorst> hm.. anyone from X team awake at this point?
<tjaalton> yup
<tjaalton> EEST here :)
<mlankhorst> ah good, I'm just creating a bunch of ppa's atm to simulate LTS
<tjaalton> on your personal page or elsewhere?
<mlankhorst> yeah personal page
<mlankhorst> I intend to make dummy, dummy-dev and dummy-enablement
<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
<mlankhorst> and some renamed ones to replace
<tjaalton> ok that's good :)
<mlankhorst> xorg-lts-test-mechanics
<mlankhorst> and probably xorg-lts-test-mechanics-lts-q and xorg-lts-test-mechanics-lts-r
<tjaalton> long names :)
<tjaalton> double lts
<mlankhorst> yeah but it simulates a lts-q release and a lts-r release
<tjaalton> ok, guess it doesn't matter
<mlankhorst> I should also create another one to simulate the next lts version I suppose
<tjaalton> probably
<mlankhorst> yuck, no luck yet
<mlankhorst> I created a dummy-enablement package, but installing it doesn't pull in new versions automatically
<mlankhorst> The following packages will be REMOVED:
<mlankhorst>   dummy dummy-dev
<mlankhorst> The following NEW packages will be installed:
<mlankhorst>   dummy-lts-q
<mlankhorst> doesn't grab the new versions yet either. :(
<tjaalton> do you have the packaging somewhere?
<mlankhorst> https://launchpad.net/~mlankhorst has 3 ppa's I'm using for testing atm
<tjaalton> and I wouldn't worry about not getting it to work the second day after uds :)
<mlankhorst> normal one contains dummy dummy-enablement and dummy-dev
<mlankhorst> lts-q should force upgrade to renamed package
<mlankhorst> No, my big worry is that it won't work without transitional packages..
<mlankhorst> or worse, incomplete mirroring and upgrading enablement package conflicting with everything causing it to remove x server
<tjaalton> well, the q repo has a newer package still building
<tjaalton> the current one has the same version as the first one
<mlankhorst> yeah I was trying to see what happened if I added a conflicts on dummy-enablement
<tjaalton> note that in the real world you'd need to rename the source package as well
<tjaalton> the normal one builds have failed
<mlankhorst> yeah but for now I'm just testing the mechanics of upgrading
<tjaalton> Conflicts: dummy dummy-dev
<tjaalton> there's one bug
<tjaalton> missing comma
<tjaalton> also, I don't think the metapackage should conflict
<mlankhorst> yeah I know, but if you enable both it won't upgrade. :/
<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.
<tjaalton> hmm, I don't see where you're upgrading from, since the base repo has the same package
<tjaalton> i don't think there's any way to fall back like that
<mlankhorst> ok then how do I at least go from dummy to dummy-lts-q automatically when I install the enablement?
<tjaalton> dummy-enablement should depend on the new names
<tjaalton> and the actual packages then break/replace the old ones
<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
<mlankhorst> (apt-get install dummy-lts-q)
<tjaalton> the depends are wrong
<tjaalton> Package: dummy-lts-q
<tjaalton> Depends: dummy-enablement
<tjaalton> Package: dummy-dev-lts-q
<tjaalton> Depends: dummy
<tjaalton> they don't need the depends at all
<tjaalton> sorry, dummy-dev-lts-q would depend on dummy-lts-q, if you mean to simulate a library package
<tjaalton> but then maybe create a libdummy or such, so these cases can be more easily noticed..
<tjaalton> and libdummy-dev
<mlankhorst> well, it's just to simulate things
<mlankhorst> you could also call it xserver-xorg-input-wacom or some other thing that doesn't get pulled in by default
<tjaalton> but you have conflicting depends there causing the issues you see :)
<mlankhorst> ah
<tjaalton> lts-q package depending on the old package which would need to get removed
<tjaalton> so nothing happens
<mlankhorst> ok lets retry
<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..
<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.
<tjaalton> nothing breaks if you remove the metapackage
<mlankhorst> everything has a depends on it
<tjaalton> there's nothing we can do to protect from people manually installing the renamed packages
<tjaalton> mlankhorst: umm no
<tjaalton> it's the other way around
<mlankhorst> ok so dummy-enablement should have a depends on dummy-lts-q  for example?
<tjaalton> yes
<tjaalton> look at xserver-xorg, xserver-xorg-input-all etc
<tjaalton> ubuntu-desktop depends on xorg, but xorg-lts-q would Provides: xorg, so the dependency is fulfilled even with the renamed package
<tjaalton> hmm need to check the policy..
<mlankhorst> no.. versioned provides won't work
<tjaalton> there are no versioned depends for the metapackages
<tjaalton> ubuntu-desktop depends on 'xorg'
<tjaalton> no version attached
<tjaalton> dinner ->
<seasons> Can someone please assign Bug #973096?   https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/973096
<ubottu> Launchpad bug 973096 in nvidia-graphics-drivers (Ubuntu) "Nvidia driver causes xorg crash" [High,Confirmed]
<seasons> We have a lot of frustrated users out there...
<bryceh> seasons, anyone test the .49 driver?
<seasons> I did, same results
<seasons> bunch of people have
<seasons> errr, 302.49 ?
<bryceh> no
<bryceh> 295.49
<bryceh> seasons, no indications on the bug report that anyone's tested it
<seasons> yeah, I did
<seasons> same thing occurs
<seasons> #13
<seasons> tried about everything I could, at first I thought it was my X conf, but turns out it doesn't matter
<bryceh> ok, then the bug should be escalated to nvidia.
<seasons> I asked in #nvidia, they said it's ubuntu
<bryceh> nah, there's nothing in the backtrace to say it's ubuntu
<seasons> can you assign it to someone at least?
<bryceh> already did
<seasons> I don't know enough to point a finger at anyone
<seasons> oh, thanks man
<bryceh> your welcome
<seasons> personally, I want to believe it's NVidia
<mlankhorst> lol
<seasons> appreciate the help
<seasons> I love open source, at least people do the right thing here
<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
<seasons> so thanks again
<bryceh> yep
<bryceh> I think a lot of bug reporters don't really grasp what "closed source binary" means.
<cnd> bryceh, can you take a look at bug 973297 for me?
<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
<cnd> the last comment
<cnd> I could use a sanity check
<bryceh> cnd, sure
<cnd> thanks
<bryceh> cnd, seems plausible
<cnd> bryceh, the ABI mismatch?
<bryceh> yeah
<cnd> yeah, but how did it happen?
<cnd> the function signature hasn't changed
<bryceh>  xserver-xorg-dev (>= 2:1.11.3-0ubuntu1),
<bryceh> maybe -evdev needs its build-depends raised?
<bryceh> although I would think the buildds would have built it using the latest xserver bits at the time
<cnd> yeah
<cnd> I checked the logs
<bryceh> what did the logs say it got built against?
<bryceh> RAOF, if you're in yet, might see if you know why the archive's skewed on the abi versions here.
<RAOF> I'm just in.
<RAOF> ...
<RAOF> Yay for ABI changes?
<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. :(
<mlankhorst> but bedtime, nn
<RAOF> I'll have a look at it.  Good night!
<cnd> bryceh, RAOF, evdev was built against 1.11.4-0ubuntu6, IIRC
<cnd> well after the ABI change in 1.11.3-0ubuntu2
<RAOF> cnd: So that's not it?
<cnd> RAOF, well, it doesn't make sense
<cnd> but nothing else makes sense :)
<cnd> it's the closest thing to making sense
<RAOF> Does a rebuild fix it?
<cnd> RAOF, yes
<RAOF> So it's probably *some* ABI change somewhere, then?
<cnd> RAOF, yeah
<cnd> and it's definitely hit at XIChangeDeviceProperty
<cnd> I've used gdb to confirm
#ubuntu-x 2012-05-16
<cnd> RAOF, bryceh: so I guess we just chalk up bug 973297 to some magical ABI illness and SRU a rebuild?
<ubottu> Launchpad bug 973297 in xorg-server (Ubuntu Precise) "Xorg recognizes Logitech Headset USB dongle as input device then segfaults in XIChangeDeviceProperty" [High,Triaged] https://launchpad.net/bugs/973297
<RAOF> It'd be nice to know precisely how that ABI changed, but a rebuild SRU sounds reasonable.
<RAOF> Bah.
<RAOF> Turns out that things get more complicated when you can have more than one pointer.
<mlankhorst> heya
<tjaalton> mlankhorst: what do you mean by a metapackage pulling everything in? isn't that what they're designed for :)
<mlankhorst> I suppose, but was more curious about the -dev packages
<tjaalton> ok so you have libfoo-dev, which needs to be replaced by libfoo-dev-lts-q, without a metapackage pulling it in?
<mlankhorst> yeah
<mlankhorst> and right now it seems to just hold back the dummy-enablement instead
<tjaalton> well for build-depends they are renamed so only -lts-q will get installed
<mlankhorst> I mean
<mlankhorst> The following packages have been kept back:
<mlankhorst>   dummy-enablement
<tjaalton> is there some git repo where you could push the packaging to?
<mlankhorst> tjaalton: I'm using my dummy ppa atm
<tjaalton> right, but it's hard to check things from there
<mlankhorst> although I should probably add a versioned depends to dummy-enablement
<tjaalton> though I don't actually have time for this anyway :)
<tjaalton> holiday time soon
<tjaalton> back next week
<mlankhorst> sure
<mlankhorst> it's just annoying there doesn't seem to be a straight way to force the package manager to upgrade, it doesn't want to replace dummy-dev by dummy-dev-lts-q
<tjaalton> what dependencies does dummy-dev-lts-q have?
<mlankhorst> dummy-lts-q
<tjaalton> right
<mlankhorst> and breaks/replaces on dummy-dev
<tjaalton> sounds correct
<mlankhorst> actually might need a 'conflicts' instead of breaks
<tjaalton> no conflicts shouldn't be needed
<tjaalton> not sure, check debian policy
<tjaalton> read it in any case :)
<mlankhorst> Yes exactly. I know you work for Intel, but surely its not forbidden by
<mlankhorst> contract to look outside of arch/x86/ ? I know!, look at arch/ia64/
<mlankhorst> that's still Intel.
<johanbr> Are multitouch gestures supposed to work on clickpads in precise?
<hyperair> i'm not sure if they are, but they don't.
<johanbr> :) at least then I know it's not a local problem
<johanbr> thank you!
#ubuntu-x 2012-05-17
<cnd> johanbr, yes, multitouch gestures should work on all multitouch trackpads
<johanbr> cnd, oh... they don't work for me on a synaptics clickpad
<cnd> johanbr, are you sure your clickpad is multitouch?
<cnd> xinput list --long | pastebinit
<johanbr> it's advertised as such anyway...
<johanbr> alright, just a sec
<johanbr> hmm, xchat crashed on me...
<johanbr> cnd, http://paste.ubuntu.com/992536/
<cnd> johanbr, ok, it's multitouch, but it only provides two touches
<cnd> which synaptics doesn't let through if you have two-touch scrolling or tap-to-click enabled
<johanbr> oh, I see, that explains things...
<cnd> notice the "Max number of touches"
<johanbr> right...
<cnd> feel free to complain to Synaptics :)
<johanbr> :)
<johanbr> but thank you for the explanation!
<JanC> cnd: does that mean people get more or less functionality if they disable 2-touch scrolling & tap-to-click?
<JanC> or just different functionality?
<cnd> JanC, well, not many applications have support for two-touch gestures yet
<cnd> so the answer right now is that you get less functionality
<JanC> or that it depends on the applications you use, I suppose
<JanC> but less on average
<JanC> wouldn't it be possible to implement "general gestures" (like scrolling) using some automatic compatibility layer?
<cnd> JanC, heh, yes
<cnd> we've been trying to think of sane ways to do that
<cnd> from ld preload wrappers
<cnd> to inserting logic into core X client libraries
<cnd> to other terrible things that one should never do
<cnd> alternatively, we could just support mainstream toolkits like qt and gtk and leave the rest to wallow in their unscrollingness
<cnd> but we'd have to support ff, lo, chromium, too
<JanC> I think that e.g. Windows mouse drivers for early scroll mice did some emulation like that, but I don't remember whether they used emulated keypresses (for scrolling) or something else
<bryceh> mlankhor1t, RAOF, tjaalton: ppa for the lts backports @ https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
<bryceh> I added timg so he can start pumping in kernels
#ubuntu-x 2012-05-18
<mlankhor1t> morning
<tjaalton> bryceh: cool, thanks
<tjaalton> i think we could add unrenamed backports there, if oem needs these soon
<tjaalton> before the rename policy has been tested and rubberstamped
#ubuntu-x 2012-05-19
<FernandoMiguel> olÃ¡
#ubuntu-x 2013-05-13
<tjaalton> "The quality of the Mesa stack in Ubuntu is really bad"
<tjaalton> grÃ¤sslin is upset for some reason
<mlankhorst> sounds like phoronix?
<mlankhorst> either that or http://simple.wikipedia.org
<tjaalton> http://blog.martin-graesslin.com/blog/2013/05/mir-in-kubuntu/
<tjaalton> "patches to the stack"
<mlankhorst> there's no point in arguing about that.. 
<seb128> trolls are trolls...
<tjaalton> i meant the mesa example, not the rest of the post
<mlankhorst> tjaalton: he's made up his mind, without understanding what he's talking about, so really no point in arguing about it
<tjaalton> I'd still like to know what's wrong with the packaging :)
<tjaalton> or just point out he's wrong
<tjaalton> anyway ->
<seb128> well, you can ask him for details
<mlankhorst> maybe he was talking about the nouveau patch series we applied for *stability* ? :p
<mlankhorst> after I cherry picked those to 9.1 branch
<bjsnider> what an annoying blog. he didn't change any of the defaults. the comment nesting seems to go so deep eventually you've got one word per line
#ubuntu-x 2013-05-14
<RAOF> Heh. âI was very fed up with Ubuntu at the time anyway because our bug tracker once again exploded after the Ubuntu release.â
<RAOF> *One* way of interpreting that would be âUbuntu's mesa stack is terribleâ
<RAOF> The other way would be âAlmost all of our users run Ubuntuâ :P
<mlankhorst> haha
<mlankhorst> oooooh
<mlankhorst> looks like we *might* have a patch for the touch bug, finally
<tjaalton> i told the same last week
<tjaalton> the patches are on the list now
<tjaalton> it's still buggy on nexus7 though, but x86 is fine
<mlankhorst> tjaalton: not that, some patch on top of that
<mlankhorst> [PATCH] dix: call UpdateDeviceState() for emulated TouchEndEvents
<mlankhorst> I'm testing now
<tjaalton> where's that?
<mlankhorst> oh he didn't send it publicly, http://paste.debian.net/4065/
<mlankhorst> on top of the -v3 branch
<tjaalton> oh there's v3 now
<mlankhorst> it's a rebase of -v2
<mlankhorst> but another patch is going to get added to it, make check is crashing
<mlankhorst> [PATCH] dix: devices must have valuators before touch is initialized
<mlankhorst> I guess that's the make check fix
<tjaalton> i'm building it as well
<starks> point of inquiry: will mesa be built with ilo?
<starks> it's been really awesome as an experimental platform and it doesn't seem to get in the way of dri unless you set xorg.conf to use it
<RAOF> ilo?
<starks> RAOF, the new gallium stuff for i965
<RAOF> Oh, yeah. That one.
<tjaalton> mlankhorst: failed to build
<tjaalton> starks: maybe for 9.2
<RAOF> starks: What's particularly awesome about it? It seems harmless to enable, although unfortunately we no longer have the dri-drivers-experimental package.
<tjaalton> we do, it's just empty
<starks> i see potential for state trackers and gpgpu seems to be on the way. classic mesa is boring. you can't extend it and nothing hooks together. don't like how intel separates their opencl stuff
<starks> maybe another day i'll share my findings, too tired and i need to pass out
<mlankhorst> tjaalton: worksforme, but I'm stilll doing some analysis
<mlankhorst> i mean it applies, it doesn't fix my issue :)
<tjaalton> /home/tjaalton/xorg-server-1.14.1/build-udeb/dix/../../dix/main.c:361: undefined reference 
<tjaalton> to `dixFreeRegistry'
<mlankhorst> oh that
<mlankhorst> I don't build the udebs
<tjaalton> yeah it only failed there
<tjaalton> what's your "issue"?
<mlankhorst> stuck mouse button if i double tap the dash icon on the nexus
<mlankhorst> second time i start to drag the icon a little
<tjaalton> hmm looks like the workqueue svg's don't update anymore
<mlankhorst> yeah :/
<tjaalton> probably time to move the hosting somewhere else
<tjaalton> or the scripts
<mlankhorst> moving to canonical hosting would be good
<tjaalton> I was thinking somewhere else, so when a person leaves C. the scripts won't get deleted or otherwise become inaccessible
<mlankhorst> well i dont think there is hosting at ubuntu.com for this kind of thing :/
<mlankhorst> would be nice if I was wrong, though
<tjaalton> i was thinking of alioth
<mlankhorst> hm maybe
<seb128> tjaalton, mlankhorst: you can put stuff on people.canonical.com/~platform
<seb128> tjaalton, mlankhorst: that's where we host e.g http://people.canonical.com/~platform/desktop/versions.html
<seb128> so it's not tied to one employee
<seb128> it gives access to any platform team member
<mlankhorst> how do you join platform?
<tjaalton> seb128: that would work, but still needs some place to run the scripts
<tjaalton> and iirc it's quite heavy so probably needs to happen on a personal machine after all
<seb128> tjaalton, well, p.c.c is the box running versions (the script building the page I just show) and most of the ubuntu-archive reports (sru, mir, installability, component mismatch, etc)
<seb128> mlankhorst, https://launchpad.net/~canonical-ubuntu-platform ... you should be in there through desktop team?
<mlankhorst> yeah
<tjaalton> oh it works via sdo
<tjaalton> *sudo
<seb128> tjaalton, right, "sudo -u platform -i" should work on the p.c.c box if you ssh to it
<tjaalton> yuÃ¥
<tjaalton> *yup
<mlankhorst> if only I could remember my password there, heh
<tjaalton> password? you need an ssh key iirc
<seb128> you don't have a password
<seb128> what tjaalton said
<mlankhorst> the sudo command wants my password though
<tjaalton> ah
<tjaalton> not here
<seb128> weird, maybe you are not in the right group or something...
<mlankhorst> I'll ask internally, thanks
<mlankhorst> seb128: porting_team was required :)
<seb128> mlankhorst, you were not in there?
<mlankhorst> nope
<seb128> weird, I though that was automatic
<mlankhorst> apparently not!
<seb128> you managed to be added?
<mlankhorst> yeah
<seb128> great
<tjaalton> oh bah, forgot UTC is -3h from EEST
<mlankhorst> tjaalton: yeah it's late for me too, I sleep early nowadays so I'm in bed at 22:00 normally :/
<seb128> tjaalton, mlankhorst: for what sessions is tht an issue? xorg plans are in 2 hours and hybrid graphic is at the same time tomorrow
<tjaalton> actually hybrid is an hour earlier tomorrow
<tjaalton> well they are best times available for me, can't complain anymore :)
<mlankhorst> oh xorg moved?
<tjaalton> no, hybrid
<tjaalton> first it got cancelled due to a mistake, then we got a better (best) slot for it
<mlankhorst> kind of weird to have xorg general and kernel lts stack in the same slot
<mlankhorst> can one be moved?
<tjaalton> the kernel one is for cloud
<mlankhorst> ah
<tjaalton> added a few Mir bits to the xorg bp
<tjaalton> well, questions
<mlankhorst> I can't answer those, we'd need RAOF for that, not sure if he'll show up though
<tjaalton> there are other folks from the team attending, it seems
<tjaalton> at least subscribed
<tjaalton> if nothing else, we'll just add the questions as work items :)
<mlankhorst> sure
<mlankhorst> Sarvatt: join the uds hangout you slacker
#ubuntu-x 2013-05-15
<tjaalton> saucy it is.. for my laptop
<erappleman> welcome to the club
<mlankhorst> doing mutex debugging first thing in the morning is not good for my sanity ;s
<erappleman> mlankhorst, i don't expect to say much for the hybrid session. i'll probably just talk about nvidia 319 experiences in the uds channel unless it would be helpful to be in the hangout
<mlankhorst> just join in for giggles
<erappleman> don't even know where the hangouts are. you get invited or something?
<erappleman> i'll def have benchmarks for the etherpad
<tjaalton> those who are marked as participation essential
<tjaalton> get the hangout link
<erappleman> i'm not doing design or implementation so i'll leave that judgment up to others
<mlankhorst> just add yourself as participation essntial
<mlankhorst> it's not like many others will join in
<erappleman> okay added as essential
<tjaalton> RAOF: boo, can't get local-repository to work with a saucy schroot, and can't understand what's wrong with it. looks like it doesn't mount the repo dir
<RAOF> tjaalton: Hm, works here?
<RAOF> tjaalton: Although I *have* explicitly bind-mounted $HOME in /etc/schroot/sbuild/fstab, because that didn't seem to be default.
<tjaalton> yeah I don't understand why it works for raring which I set up last time, now fails with saucy. I'll try adding $HOME there
<tjaalton> yep, that did the trick
<tseliot> tjaalton: do you know how to enter an sbuild chroot preventing it from saving any changes?
<tjaalton> tseliot: schroot -c foo?
<tseliot> tjaalton: it complains that the directory for the chroot doesn't exist. My chroot is a tarball
<tjaalton> so it's not for sbuild?
<tjaalton> i've only used mk-sbuild, it creates "real" chroots
<tjaalton> you probably meant pbuilder?
<tseliot> tjaalton: yes, it is sbuild. I used sbuild-createchroot and I passed the --make-sbuild-tarball= argument
<tjaalton> then I don't know
<jcristau> tseliot: what does the chroot config say?
<jcristau> somewhere in /etc/schroot/chroot.d probably
<tseliot> jcristau: http://paste.ubuntu.com/5667181/
<tseliot> jcristau: hah, I think I know what's going on. There was another configuration file that was getting in the way
<jcristau> ah, good :)
<tjaalton> compiz seems to be quite crashy on saucy
<mlankhorst> hybrid session in 50 minutes right?
<tjaalton> yep
<tjaalton> add stuff to the whiteboard if something is missing
<tjaalton> but it'll mostly be just a status update session I guess..
<mlankhorst> yeah not much to say, except I'm aiming to get a lot into 3.11
<tjaalton> whee
<mlankhorst> if upstream doesn't want to review, then it goes in without review, seems airlied is ok with that
<tjaalton> so it's the locking stuff?
<tjaalton> working finally?
<tjaalton> er, syncing
<mlankhorst> it's been working for a while now
<tjaalton> oh
<tjaalton> didn't know that :)
<mlankhorst> the entire discussion was about the locking primitives
<mlankhorst> but it's even been on lwn now https://lwn.net/Articles/548909/
<tjaalton> ah
<seb128> tjaalton, mlankhorst, others: hybrid graphic session in 10 min ... you are coming? who else? who is leading?
<erappleman> i am i guess
<mlankhorst> i ll join
<mlankhorst> ill probably lead too
<tseliot1> seb128: I'll be there too
<mlankhorst> erappleman: could you make notes perhaps? :)
<erappleman> i literally just rolled out of bed
<mlankhorst> you'll be perfect
<erappleman> i can try
<mlankhorst> normally hard liquor is recommended, but just out of bed counts as being dazed enough too ;)
<tjaalton> mlankhorst: yeah take the lead, thanks :)
<tjaalton> no sign of Sarvatt?
 * mlankhorst notes moving mouse to laptop and typing synergyc doesn't work
<seb128> tjaalton, mlankhorst, tseliot, erappleman: https://plus.google.com/hangouts/_/b102d3a35fdd5d0fa05ed599c114588e532db1ad?authuser=0
<erappleman> need hangout invite
<erappleman> ah ok
<erappleman> nice little session. kudos to everyone
<mlankhorst> and google+ is still denying i ever blocked tseliot, tssk
<seb128> thanks everyone for participating
<tseliot> mlankhorst: :D
<erappleman> oh wow the video is already up
<mlankhorst> erappleman: it was up as we streamed it ;)
<erappleman> oh
<erappleman> damn i should've kept my mic muted earlier
<erappleman> XD
<tjaalton> phoronix is slacking
<tjaalton> i didn't realize my kbd was noisy
<tjaalton> probably because the mic is close to it
<erappleman> mine is right beneath the keyboard rows
<tseliot> tjaalton: apparently my macbook's microphone is really bad...
<erappleman> very nasty
<tjaalton> tseliot: nah it was fine
<mlankhorst> it's why I bought a dumb usb headset for 15â¬
<erappleman> awaiting the phoronix tabloid hackjob
<tseliot> :D
<tjaalton> dead pony club!
<tjaalton> my uds is over, so beer time
<tseliot> so is mine ;)
<tjaalton> cheers :)
<jcristau> i have a feeling beer at uds was better when you could share it
<tjaalton> btw, 3.9rc almost worked with nouveau on my laptop, but it's still crashy with acceleration enabled. haven't been able to test any of the stuff before now
<tjaalton> jcristau: heh, yeah
<mlankhorst> tjaalton: what laptop?
<tjaalton> t420s, snb+nvd9
<Sarvatt> t420s, your favorite nvidia gpu mlankhorst
<mlankhorst> heh
<erappleman> jeez my face is all over that video... a lesson to not roll out of bed for uds or telecommuting in the future
<mlankhorst> no it will focus on the person with loudest microphone
<mlankhorst> a lesson not to keep auto volume adjustment on
<mlankhorst> ;P
<seb128> better to just mute mic by click on the icon when you don't speak
<erappleman> my mic is just terrible. i have enough problems with mumble
<mlankhorst> tjaalton: one thing I saw that looked interesting though.. [patch] drm/nvc0-/gr: bug widening a binary "not" operation
<mlankhorst> but I doubt it'll help nvd9 much
<tjaalton> I'll try 3.10rc on it
<tjaalton> here, I shared a beer with ya http://ubuntuone.com/2naTqHksmSjoanLY8gzooD
<mlankhorst> damn timo, you scary ;)
<tjaalton> damn webcam that doesn't work attached to the monitor, so had to take the pic handheld :P
<tjaalton> also, I should shave
<erappleman> webcams add 2 days of stubble
<erappleman> no big deal
<tjaalton> hehe
<jcristau> oh, a brewdog.  melikes.
<tjaalton> bought a new wine fridge, then filled it with beer
<seb128> mlankhorst, want to join https://plus.google.com/hangouts/_/e1f469f457b9603e41b963690d7a3bc02e2056f6?authuser=0 
<seb128> mlankhorst, https://blueprints.launchpad.net/ubuntu/+spec/client-1305-convertibles-and-touch-desktop
 * tjaalton runs
<seb128> mlankhorst, Till said you should be there
<mlankhorst> oh us x team discussed everything we wanted in the xorg cycle about it
<mlankhorst> s/cycle/session/
<mlankhorst> it's multiple bugs manifesting in a single way, it's highest priority, and we're working on it
<seb128> mlankhorst, can you come? ;-)
<mlankhorst> yeah yeah
<erappleman> http://www.phoronix.com/scan.php?page=news_item&px=MTM3MjY
 * erappleman sighs
#ubuntu-x 2013-05-16
<hyperair> [74855.118996] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
<hyperair> Sarvatt: halp.
<hyperair> Sarvatt: do you know of any particular SNB instabilities with linux v3.9 and xorg-edgers?
<hyperair> i've been losing my uptime at least once every three days
<hyperair> and having to invoke SaK to unhang my laptop at least once a day
<hyperair> oh wait, uptime of 25h, SaK'd twice
<hyperair> that makes it twice a day huh
<Sarvatt> hyperair: hope that mesa update helps
<hyperair> Sarvatt: which mesa update?
 * hyperair apt-get updates
<Sarvatt> just updated edgers, will be a few hours
<Sarvatt> hasnt been updated in a bit over a week, might have been a bad time to package it :)
<hyperair> yay
<hyperair> :)
<mlankhorst> Sarvatt: hah, I just packaged wine too
<mlankhorst> ]
<Sarvatt> ScottK: is kubuntu using lightdm or kdm? kdm could probably use updating to fix https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/982889 also, its a real small change https://launchpadlibrarian.net/138995277/lightdm_1.2.3-0ubuntu2_1.2.3-0ubuntu2.1.diff.gz
<ubottu> Launchpad bug 982889 in OEM Priority Project precise "X trying to start before plymouth has finished using the drm driver" [High,In progress]
#ubuntu-x 2013-05-17
<ScottK> Sarvatt: We're using lightdm.
<ScottK> Probably would make sense to fix kdm though for die hards.
<mlankhorst> kdm is not default on kubuntu?
<seb128> mlankhorst, no, they use lightdm by default with their own kde greeter iirc
<ScottK> seb128: That's correct.
<bjsnider> why's that i wonder? what advantage does that offer?
<tseliot> jcristau: do you know where sbuild keeps the deb packages that it pulls a dependencies for building package? I would like to cache them somewhere
<jcristau> /var/cache/apt/archives in the chroot i guess
<jcristau> i'd recommend using a proxy for that though
<tjaalton> yeah
<tjaalton> or just mirror the archive locally :)
<tseliot> thanks!
#ubuntu-x 2013-05-18
<Dandel> i noticed that there was a failed build on the piglit ppa and it did provide an machine nor the build log... all it says is "unknown build machine" and it took down the i386 package for quantal.
<Sarvatt> Dandel: random question but do you have any interest in joining xorg-edgers to keep that ppa going however you want to use it? i just hit rebuild, it'll probably build fine after that
<Sarvatt> if you join you can change things in the piglit ppa however you want, not sure what your launchpad username is though so lemme know :)
<Sarvatt> oh wait are you kphillisjr?
<Sarvatt> aka the guy pushing amd to pay attention to piglit on the beta lists?
<Sarvatt> just added you if so, go nuts on the piglit recipes used in that ppa :)
#ubuntu-x 2014-05-13
<sok> on an optimus graphics card i have to query the gpu information via "optirun nvidia-settings -c:8 ..." and by default, in /etc/bumblebee/bumblebee.conf:
<sok> # Card power state at exit. Set to false if the card shoud be ON when Bumblebee server exits.
<sok> TurnCardOffAtExit=false
<sok> so... if turn on the graphics card via the applet, it immediately starts querying itself, which in turn switches the card off
<sok> either, i open an idle optirun thread when the button is clicked, or the button will have to be made read only
<sok> ugh and this is all the wrong channel but still relevant :P
<tjaalton> btw, /usr/lib/nvidia337/ is not provided by any official package, so if you install from external sources you get to keep both pieces
#ubuntu-x 2014-05-14
<tjaalton> mlankhorst: what's blocking mesa in utopic-proposed?
<mlankhorst> tjaalton: nothing, just didn't get around to it yet
<tjaalton> mlankhorst: oh ok
<mlankhorst> oh should work btw
<tjaalton> it's blocked by libgtkada
<tjaalton> it's autopkgtest fails, but not due to mesa but the transition to gnat-4.9
<mlankhorst> hm
<mlankhorst> nasty
<tjaalton> an update is in debian NEW since sunday
#ubuntu-x 2015-05-14
<oliver__> I'm not sure if it's a bug. That's why I'll ask right here. Has the Xorg server in Ubuntu 14.04.2 LTS problems with Nvidia Optimus and Bumblebee. Because with 14.04.1, there were no problems with it.
<oliver__> Since 14.04.2 closing a SFML, GLFW or SDL Window crashes the Xorg Server.
<oliver__> For a week no one has an idea in any channel. That frustrated me over time. Can not be so, that no one knows anything ;-)
<oliver__> what you are doing here? when you do nothing? ignore is not the best way to popularize a system. or since you simply to fine to answer. no need for stacktraces nothing. forget it.
<tjaalton> haha
<tseliot> 12 minutes is such a long time...
<mdeslaur> lol
#ubuntu-x 2015-05-17
<karolherbst> small question: why does a "service ligthdm start" forces everything to my nvidia card allthough I have bumblebee installed and set the alternatives through update-alternatives to mesa (which gets set to nvidia through the service start again) in 15.04?
<karolherbst> it worked with 14.04 and 14.10 without problems
#ubuntu-x 2016-05-17
<tseliot> ricotz: why did you remove the verbose check from copy-nvidia-options? (I added that so that I can see what is going on when testing)
<tseliot> the rest of the patch is ok
<ricotz> tseliot, imo not very useful while it doesnt provide more information than lsinitramfs
<tseliot> ricotz: yes, well the point was to see if the script was messed up or not
<ricotz> tseliot, the output doesnt provide any info about the success anyway and you will likely double check the content of initrd anyway
<tseliot> always
#ubuntu-x 2016-05-19
<soee> mamarley: NVIDIA 367.18 Beta Linux Driver Released With Many Fixes :)
 * ricotz takes a glimpse at it
<soee> thanks ricotz, if you will have some packages ready to test, ping me
<ricotz> soee, looks good here so far
<soee> ricotz: available somwehre to install?
<ricotz> soee, the upload will take some time
<ricotz> soee, will in the ppa soon, only for xenial/yakkety 
<soee> ricotz: sure, im on xenial and i'll jump on yakkety after first alpha probably
<ricotz> should be there like in an hour
<soee> thank you
<soee_> uhm the driver faild to build
<mamarley> Only on armhf.
<mamarley> I got nvidia-settings 367 uploaded to ppa:mamarley/staging.  Not compiled yet though.
<mamarley> Dangit, I could have sworn I updated that patchâ¦
<mamarley> Oh, looks like uupdate clobbered it.
#ubuntu-x 2017-05-15
<tomreyn> Hi there. I'm trying to get better performance out of an RX580 on 16.04 with Ryzen 1800X (32 GB RAM), running I've got this Ryzen CPU (1800X) with 32 GB of RAM running mainline kernel 4.10.15-041015 (I have to since the CPU is not fully stable on the hwe-edge kernel and earlier).
<tomreyn> I test using the "Shadows of Mordor" game. Its benchmark reports an average of 15 FPS at my native full screen resolution of 3440x1440.
<tomreyn> I'm already using the ubuntu-x-swat/updates repository.
<tomreyn> It's stable (which I understan is an achievement by itself), just not performing well. Any suggestions?
<tjaalton> so you have a hybrid machine?
<tomreyn> tjaalton: hybrid how?
<tjaalton> hmm or not
<tjaalton> ryzen has no iGPU?
<tomreyn> no, not the current generation
<tjaalton> k
<tomreyn> APUs are yet to come
<tjaalton> so it's using hw accel?
<tjaalton> check glxinfo
<tomreyn> glxinfo -B http://paste.ubuntu.com/24582240/
<tomreyn> "Accelerated: yes"
<tjaalton> right
<tjaalton> maybe the driver isn't properly optimized yet in 17.0
<tomreyn> the game detects an RX450/480, as does lspci
<tjaalton> maybe ask on #radeon
<tomreyn> oops i wasnt even aware that exists, thanks
#ubuntu-x 2017-05-16
<soee_> with kernel 4.11.1 drivers work fine
<mamarley> Really? Cool, thanks for letting me know.  I knew a patch was coming to 4.12 to set those symbols back the way they used to be, but I guess it got pulled in to 4.11.1 too.
<soee_> http://i.imgur.com/MJck5Dx.png
#ubuntu-x 2018-05-16
<mamarley> ricotz: 390.59 has been released.  I can package it in a bit.
<mamarley> ricotz: All done: https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages.  I also threw in an updated build of 396 with the changes from the latest release of 390 in the main repository forward-ported.
<ricotz> mamarley, great, thank you
<mamarley> No problem
<ricotz> mamarley, no armhf builds?
<mamarley> ricotz: Darn, I forgot I disabled that on -staging again.  Shall I re-upload?
<ricotz> just enable it and pocket binary-copy the built packages over their-selves
<ricotz> *no need* to re-upload
<ricotz> or even rebuild
<mamarley> Cool, I didn't know you could do that.  Done.
<mamarley> It looks like the armhf build queue is a bit jammed up right now though. :(
#ubuntu-x 2018-05-17
<mamarley> ricotz: All the packages are done compiling now: https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages
<ricotz> mamarley, ok, will take a look when I have time
<mamarley> ricotz: There is apparently also a 396.26 driver that was embedded in the CUDA 9.2 release.  I'm not sure if we want that in the main PPA or not, but I am going to put it in another of my staging PPAs for now.
<ricotz> there is also 396.18.11 to increase the confusion ;)
<mamarley> That is another Vulkan beta, I guess?
<ricotz> yes, maybe this 396.26 picked it up
<ricotz> mamarley, https://devtalk.nvidia.com/default/topic/1035369/linux/x-won-t-start-on-xorg-server-1-20-and-nvidia-legacy-390-new-abi-/post/5260453/#5260453
<mamarley> ricotz: I can confirm that 390.59 works with xorg-server 1.20.
<ricotz> ok
<mamarley> It also doesn't require that hack for kernel >=4.16 anymore.
<ricotz> good
#ubuntu-x 2018-05-19
<ricotz> mamarley, hi, where is this/your 396.26 binary coming from?
<ricotz> I just found http://us.download.nvidia.com/tesla/396.26/NVIDIA-Linux-x86_64-396.26-diagnostic.run
<mamarley> ricotz: I extracted mine from the CUDA 9.2 installer.
